SaaS 系统里，权限改造是最容易被低估的需求。产品说“加一个子管理员角色”，老板说“让客户自己分配权限”，听起来像是后台多几个开关。真正打开代码才发现，权限散在前端菜单、后端接口、数据库字段、缓存、审批流、导出功能和第三方回调里。改得好是升级，改不好就是越权事故。

很多人搜“RBAC 权限设计”“SaaS 多租户权限”“Claude Code 代码审查”“Codex 重构权限模块”，其实都在找一个答案：我怎么知道这次权限改动会影响哪里？靠脑补不行，靠一个人从头翻代码也慢。AI 编程工具适合先帮团队把这张网画出来。

权限改造不是写几个 if

权限问题最容易在演示环境里看起来没事，上线后才出问题。原因很简单：演示时只点了菜单入口，真实用户可能从接口直接调；测试时只看了普通用户和管理员，真实客户还有部门管理员、项目成员、外部协作者；开发时只改了查询接口，导出接口却漏了。

所以权限改造第一步不是写代码，而是列矩阵。角色有哪些，资源有哪些，动作有哪些，租户边界在哪里，哪些接口是读，哪些接口是写，哪些地方会导出数据，哪些地方会触发异步任务。这个矩阵写出来，需求才算有地基。

让 AI 先做影响面扫描

Codex / Claude Code 可以做的第一件事，是读取路由、控制器、中间件、权限函数和前端菜单配置，整理一份“权限检查点清单”。你可以让它只分析不修改：哪些接口做了权限判断，哪些接口只在前端隐藏了菜单，哪些导出、批量操作、后台任务可能绕过权限。

这类扫描特别适合 AI，因为它不嫌麻烦。人看代码容易跳过重复文件，AI 可以一遍一遍找关键词、查调用链、整理路径。它不一定能直接判断业务正确性，但能帮你找到该看的地方。你再让资深开发确认，效率会高很多。

把角色资源矩阵写成人能看懂的文档

权限改造最怕产品、研发、测试三方说的不是一件事。产品说“部门管理员能看部门数据”，研发问“能不能导出”，测试问“跨部门共享怎么算”，运营问“历史数据怎么处理”。如果没有矩阵，大家就靠口头理解，很容易漏。

可以让 AI 根据现有代码和需求，生成一份角色资源矩阵草稿。不要要求它一次就正确，而是把它当成讨论底稿。矩阵里要包含角色、可访问资源、允许操作、禁止操作、异常场景、需要确认的问题。这样会议讨论就不会空转。

测试要专门防越权

权限改造不能只测正常流程。正常用户能看自己的数据，这当然要测；更重要的是，普通用户不能看别人的数据，部门管理员不能看其他部门，租户 A 不能访问租户 B，已离职用户不能继续调接口，前端隐藏菜单不能等于后端放行。

AI 可以帮你根据矩阵生成测试样例，尤其是越权测试。比如同一个接口，用不同角色、不同租户、不同资源 ID 去请求，预期结果是什么。很多团队不是不知道越权危险，而是测试样例写起来太烦。AI 正好适合干这种细碎但重要的活。

老数据迁移要慢一点

权限改造经常会动数据库，比如给角色加字段、给资源加 owner、给旧数据补租户 ID。这里不要让 AI 一口气改完。正确做法是让它先生成迁移计划：哪些表受影响，哪些字段要补，旧数据怎么兜底，是否需要回滚脚本，是否要灰度开关。

你可以让它把迁移拆成小 PR。第一个 PR 只加字段和兼容逻辑，第二个 PR 写回填脚本，第三个 PR 切读写逻辑，第四个 PR 清理旧逻辑。这样每一步都能验证，也能回滚。权限系统最怕“看起来一次到位”，实际风险最大。

适合哪些人看

这篇文章最适合 SaaS 创业团队、B 端系统开发、后台管理系统负责人、测试负责人和产品经理。只要你的系统里有角色、部门、租户、项目、组织、审批、导出，就应该认真对待权限改造。越是客户数据敏感，越不能凭感觉改。

不适合的用法是让 AI 自己决定权限规则。权限规则是业务和安全决策，必须由人定。AI 可以帮你扫描、整理、补测试、写脚本，但不能替公司决定谁能看什么数据。

智脑API 怎么帮团队落地

权限改造往往不是一次性任务，后续每次加新角色、新资源、新导出接口，都要走同样的检查流程。把 Codex / Claude Code 接到智脑API统一入口后，团队可以把“权限影响面扫描、矩阵整理、越权测试生成、迁移拆分”沉淀成固定提示词。接入配置可以看这份教程：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg。

一个可直接用的提示词

请只分析当前仓库，不要修改代码。请找出权限相关入口，包括中间件、装饰器、路由守卫、前端菜单、导出接口和批量操作。输出一份权限检查点清单，并指出哪些接口可能只做了前端限制，哪些地方需要补越权测试。结论请按“有代码证据”和“需要人工确认”分开。

落地时别忘了灰度和监控

权限改造还有一个容易被忽略的环节：上线后怎么观察。你可以让 AI 帮你列出关键监控点，比如 403 数量是否异常上涨、某些角色访问失败是否集中、导出接口是否被异常调用、老用户是否因为历史数据缺字段而失败。监控不是大公司才需要，小团队更需要，因为小团队排查人少，越早发现越省成本。

灰度也要写进计划里。先给内部账号开，再给少量客户开，最后逐步扩大。每一步都要有回滚条件：错误率超过多少要停，客户反馈集中在哪类场景要停，哪些日志必须人工确认。AI 可以帮你把这些条件写成上线检查清单，但是否上线和是否回滚，必须由负责人决定。

最后提醒

权限改造不是展示 AI 能写多少代码，而是让团队少漏边界。AI 的正确位置，是帮你把暗处照亮：哪些文件该看，哪些接口该测，哪些迁移该拆，哪些规则需要确认。只要把这些动作固定下来，权限改造就不会再靠一个人的记忆硬扛。