AI 代码 Review 在合并前该看什么

AI 做代码 review 很容易走偏。它会指出命名不够清晰、某个函数可以拆分、某段代码可以更优雅。这些建议有时有用，但不是合并前最重要的事。

真正要防的是行为回归。

一段 AI 生成或 AI 修改的代码，合并前要先回答：它有没有改变不该改变的行为？有没有放宽权限？有没有让缓存读到旧数据？有没有删掉关键测试？有没有把一个局部修复变成了隐形重构？

所以 AI review 不应该只做“代码风格点评”。它应该先像事故预防一样工作。

第一眼先看改动范围

合并前先看范围，而不是先看某一行写得漂不漂亮。

需要确认：

• 改动文件是否和需求匹配。
• 是否混入无关格式化。
• 是否改了配置、锁文件、生成文件。
• 是否新增了依赖。
• 是否改了测试但没有改实现，或者改了实现但没有测试。
• 是否把临时日志、本地路径、调试开关带进来。

如果任务是“修复导出按钮权限”，但 diff 里出现数据库 schema、全局样式、登录逻辑和十几个无关组件，那就不是一个健康的 review 起点。

范围失控时，不要急着逐行审。先要求拆分或清理。

行为回归比代码味道重要

代码味道通常可以以后慢慢改，行为回归会马上伤害用户。

AI review 应该围绕行为问问题：

• 原来的成功路径是否仍然成功。
• 原来的错误路径是否仍然被处理。
• 空值、边界值、重复提交、并发请求是否有变化。
• API 返回结构是否保持兼容。
• 页面刷新、跳转、表单状态是否仍然合理。
• 日志、审计、埋点是否被意外删除。

尤其要注意“为了修一个 bug，顺手改公共 helper”。公共 helper 一旦变了，影响面可能远大于当前任务。

一个好的 review 评论不是“这里可以优化”，而是：

这个 helper 现在会把空数组当成无权限，而之前空数组表示不限制。
请确认所有调用方是否都接受这个语义变化，或者把修复限制在当前页面。

这种评论直接指向行为风险。

权限要按失败模式看

权限相关代码不能只看“有校验”。要看校验在失败模式下怎么表现。

重点问题包括：

• 没有登录时是否拒绝。
• 没有角色时是否拒绝。
• 没有权限绑定时是否拒绝。
• 前端隐藏按钮之外，后端是否仍然校验。
• 管理员和普通用户路径是否分开。
• 能否通过改请求参数访问别人的资源。
• 缓存的权限是否可能跨用户、跨角色污染。

AI 生成代码时，常见风险是把“没有数据”当成“允许”。例如权限列表为空时返回 true，或者资源没有绑定权限时默认通过。这类逻辑在 demo 里很方便，在真实系统里很危险。

权限 review 的默认立场应该是：不确定就拒绝，缺失绑定也拒绝。业务确实需要放行时，应该有明确规则和测试。

缓存和刷新要看边界

缓存问题经常不会在静态 diff 里显得很明显。代码看起来都对，但用户保存后页面还是旧数据，或者另一个用户看到了不该看的状态。

review 时要问：

• 这个数据是全局缓存、按角色缓存，还是按用户缓存？
• mutation 后失效的是哪个 key、路径或 tag？
• 读路径是否绕过了需要失效的缓存层？
• 失效范围是否太大，导致无关页面反复刷新？
• 是否把用户私有数据放进了共享缓存？

AI 很容易只修写入路径，却忘了读路径的缓存边界。也容易为了“保证刷新”做全局刷新，短期看能解决问题，长期会带来性能和状态抖动。

缓存 review 的核心不是“有没有调用 revalidate”，而是“失效边界和数据归属是否匹配”。

测试缺口要说清楚

AI review 不应该只说“建议补测试”。要说清楚缺哪种测试。

例如：

• 缺少无权限用户访问的测试。
• 缺少 mutation 后重新读取的测试。
• 缺少重复提交的测试。
• 缺少旧数据兼容测试。
• 缺少异常返回和空值测试。
• 缺少跨用户访问隔离测试。

更重要的是，review 要区分“必须补”和“可以后补”。如果改动涉及权限、认证、支付、数据迁移、缓存失效，测试缺口通常不能留到以后。如果只是文案、样式微调或内部类型重命名，风险就低很多。

测试不是为了让 diff 看起来完整，而是为了证明关键行为没有被 AI 的改动带偏。

让 AI 做 review 的方式

给 AI 做 review 的输入不能只有“帮我看看”。更好的方式是给它明确优先级：

请按合并前代码 review 的标准检查当前 diff。
优先找行为回归、权限放宽、缓存失效错误、测试缺口和无关改动。
不要把风格建议放在前面。
每个问题都要指向具体文件和行为影响。

如果项目有安全规则，也要写进去：

权限默认 fail closed。
没有绑定 permission 的资源不能默认通过。
不要建议全局刷新来掩盖缓存边界问题。

这样 AI 才会把注意力放在风险上，而不是把 review 变成通用代码美化建议。

合并前的简短清单

可以用这份清单做最后一遍：

• 改动范围是否符合任务。
• 是否存在无关文件、生成文件或配置变化。
• 用户可见行为是否有意改变。
• 权限失败模式是否安全。
• 缓存失效边界是否正确。
• 关键测试是否覆盖。
• 未运行的验证是否明确说明。
• PR 描述是否准确，不虚构测试结果。

如果你还在前一阶段组织任务，可以先看：真实项目里的 AI 上下文工程。如果担心 agent 在本地仓库里误操作，可以看：怎么让 AI agent 不把仓库改坏。

结论

AI 代码 review 的价值，不在于它能指出多少小风格问题，而在于它能帮你更快发现合并风险。

合并前最该看的，是行为有没有回归，权限有没有变松，缓存边界有没有错，测试缺口是否能接受，diff 是否仍然属于这次任务。

把这些放在前面，AI review 才像工程审查。否则，它很容易变成一份看起来专业、但没有守住风险重点的建议列表。