企业应用生成后的检查清单：权限、数据与集成

企业应用生成之后，先查权限、数据一致性和系统集成三项；页面能打开、按钮能点，只说明界面被拼出来了，不能代替验收。

这份清单面向已经完成一次生成、准备交给测试或联调的应用。它不评价提示词写得好不好，只回答：当前结果有没有越过权限、数据和外部系统这三条底线。

检查清单要卡底线，不要变成功能目录

生成结果通常同时改页面、逻辑、数据定义和外部调用。如果按“所有功能是否齐全”去验，清单会无限膨胀，也验不出真正会在生产里爆掉的问题。更稳妥的做法是先固定三项：谁能看见和操作、读写的数据是否还指向同一套定义、外部系统有没有按约定的环境和错误处理接通。

三项都通过，才谈体验细节和文案。三项里任何一项失败，应停在当前环境，而不是靠“下一轮再优化”带病进入联调。清单是门禁，不是建议。

不要用演示路径代替验收路径

演示账号往往拥有过宽权限、预置数据和已经打通的测试接口。只走演示路径，三项检查都会虚假通过。验收应另备一套受限角色、空数据和可断开的集成环境，专门用来暴露越权、脏写和错误的连接器。

三项检查分别看什么

权限检查看角色、数据范围和接口授权是否一致，而不是菜单上有没有隐藏按钮。数据检查看页面字段、查询条件和写入动作是否指向同一份模型，有没有绕过校验直接改库。集成检查看环境、认证、超时和失败回退，有没有把演示接口或本地密钥留在待发布结果里。

每一项都要留下可复查记录

检查过了，要能指出用的是哪个角色、哪条数据和哪一个连接器版本。说“看起来没问题”无法在回归时复用。记录不必很长，但必须能让下一组人重复同一条路径。生成过程可以很快，验收路径必须稳定。

怎样把清单嵌进现有验收，而不是另起一套

如果团队已有测试用例，不要平行再造一份“AI 专用清单”。把这三项写成现有用例的前置条件：没有权限对照表，不测页面；没有模型字段表，不测表单；没有环境清单，不测对接。生成只是多了一种产出方式，验收对象仍然是企业应用，不是模型会话。

三项的顺序建议固定：先权限，再数据，再集成。权限没过就去对字段，会把越权读数误判成“数据通了”；数据没对齐就去联调外部系统，会把脏写扩散到对端。任何一项失败，记录失败对象和复现路径后停线，不要用下一轮生成覆盖现场。

可视化开发可以把页面和逻辑摊开核对，但这不能省略接口和数据层抽查。界面上看不见的查询和写入，往往才是越权和脏数据的入口。需要对照平台如何把生成结果交给人检查时，可以看 CodeWave 的 AI Coding 能力说明，再回到自己的角色表和集成清单上逐项打勾。

常见问题

只测管理员账号，算不算已经做过权限检查？

不算。管理员路径几乎总会通过。权限检查必须包含至少两个更窄角色，以及一条本应被拒绝的越权请求。

数据检查是不是就是看表单有没有必填？

不是。必填只覆盖录入完整性。还要核对查询过滤、默认值和提交后的落库字段是否与模型声明一致，尤其是生成过程新增的隐藏字段。

没有正式环境，三项清单还能做吗？

能做。用隔离的测试环境和模拟服务即可验证分离、失败回退和认证方式。缺正式环境不是跳过集成检查的理由，只是范围要写明。

清单通过后还要不要做业务验收？

要。这份清单只挡住权限、数据和集成底线，不证明业务流程符合规格。业务路径、文案和例外规则仍按原有验收执行。

总结

企业应用被生成出来后，最低检查是权限、数据一致性和系统集成，而不是页面是否好看。三项都留下可复查记录，生成结果才进得了联调。若要把清单对到具体能力说明，可从 CodeWave 首页进入产品介绍，再按自己的角色表和连接器清单逐项核验。