检查AI生成应用权限：角色、数据范围和接口

检查 AI 生成应用的权限，要把角色、数据范围和接口授权分开验；只看菜单是否隐藏，挡不住直接访问页面或接口的越权请求。

生成过程容易根据页面文案“补全”可见性和操作，却不一定同步改查询过滤和后端授权。验收时若只点界面，会把一层皮肤当成权限模型。

权限要拆成三层，不能只验菜单

角色层回答“这类人能不能进入这个功能”。数据范围回答“进入之后能看到和改哪些行”。接口层回答“绕过页面时，同样的请求会不会被拒绝”。三层必须指向同一套规则。页面隐藏了删除按钮，接口仍接受删除，这不是小瑕疵，而是权限没有闭环。

AI 生成应用常见的错位是：规格里写了角色名，页面按角色藏了入口，查询却仍返回全表，或把演示用的宽权限角色写进了默认账号。这类问题在管理员路径上几乎看不出来，必须用更窄的角色复测。

规格里的角色名，不能直接当成已生效授权

规格提到“部门经理只能看本部门”，只说明意图被写下来了。生效要看到三处同时成立：入口按角色打开或关闭、列表查询带上范围条件、写操作在服务端再次校验同一范围。缺任何一处，生成结果只是把角色名当成了标签。

三层分别怎么核验

角色层用两个以上真实角色走同一条业务路径，记录谁能进、谁被拒。数据范围层准备两条分属不同范围的数据，确认窄角色既看不见也改不了另一条。接口层把页面上被隐藏的操作，用同一身份直接请求，看返回是否与页面一致。

生成新增的字段和接口更要抽查

生成过程常会补出导出、批量改状态或隐藏查询参数。这些对象如果没写进规格，也很容易没写进权限表。抽查时应列出本次新增的接口和字段，逐个问：哪个角色能用、范围条件在哪一层生效。答不上来的对象，默认视为未授权，而不是默认可开放。

查权限时不要被可视化结果带偏

可视化设计器能让人看见页面和部分逻辑，适合核对入口和表单状态，但查询条件和接口授权仍要在实际请求里确认。看起来“本部门过滤”写在了逻辑块上，如果生成同时保留了一条无过滤的旧查询，运行时仍会漏数。

需要对照生成结果如何被查看和修改时，可以参考 CodeWave 对 AI Coding 与可视化验证的说明。平台能把结构和逻辑摊开，不能代替用窄角色和直接接口把越权打出来。权限通过的标志是拒绝可重复，而不是演示账号操作流畅。

能留下拒绝记录更好。一次越权请求被拒后，应能指出是角色不匹配、范围条件未命中，还是接口未授权。三种原因对应不同修法：改入口解决不了接口放开，补查询过滤也解决不了写操作未校验。查不清失败原因，就不要把权限项标成已通过。

常见问题

前端路由做了守卫，还要测接口吗？

要。路由守卫只约束浏览器里的进入方式。脚本、调试工具或内部调用仍会打到接口。接口与页面规则不一致，权限就没有闭环。

用管理员回归一遍，能不能代表权限验收？

不能。管理员路径用于确认功能存在，不能确认限制生效。至少要有一个应被拒绝的角色和一条应被拒绝的数据。

数据权限是不是等于行级权限？

行级是常见形式，但不是全部。字段级可见、导出范围、附件下载和关联对象读取，都可能扩大实际可见集。核验时按“这次生成碰到的读取和写入面”逐项列，而不是只看列表过滤。

权限写在规格里，生成就应该自动正确吗？

不应该这样假设。规格提供意图，生成给出候选实现。是否生效，只能用角色、范围和接口三层复测证明。意图被写进规格，不等于授权已经落地。

总结

AI 生成应用的权限检查，要分开验证角色入口、数据范围和接口授权，并特别抽查本次新增的字段与接口。三层规则一致，拒绝路径可重复，才算验过。若要结合可视化核对页面和逻辑，可从 AI Coding 能力页对照自己的角色表，而不是只看演示账号能否走完流程。