AI 辅助代码评审：把“能跑就行”变成可落地的检查清单

代码评审（Code Review）是最容易流于形式的环节之一：评审人时间紧，只看格式和命名；提交人怕返工，只求尽快合入。大模型出现后，评审第一次可以做到“机器先扫一遍、人只看关键点”。本文分享一套我在团队里跑通的 AI 辅助代码评审流程：先让 AI 做全量初筛，再由人按检查清单定稿。

一、评审先分层：不是所有问题都值得人看

把评审发现按三层划分，AI 和人的分工立刻清晰：

1. 机械层：格式、命名、重复代码、未使用的变量和导入，这类问题 AI 扫得又快又全，人不用再逐行挑；
2. 逻辑层：边界条件、空值处理、并发竞争、异常分支，这是 AI 能提示、人必须判断的部分；
3. 设计层：模块划分是否合理、接口是否过度耦合、这个改动会不会给三个月后埋坑，这层 AI 只能给参考意见，决策权在人。

分层的意义在于：不要让 AI 的输出直接变成评审意见。机械层可以直接采纳，逻辑层要人逐条确认，设计层只当作讨论素材。分不清层次，评审就会变成“AI 说啥就是啥”。

二、第一步：给 AI 一份评审提示词，而不是直接贴代码

直接把 diff 贴给 AI 说“帮我评审”，得到的多半是泛泛而谈。我的做法是先给 AI 一份明确的评审指令：

• 评审范围：只看本次 diff，不要评价整个文件的历史问题；
• 输出格式：按“问题-位置-严重程度-修改建议”四列列出，严重程度只分高、中、低三档；
• 关注重点：空指针与边界、资源未释放、SQL 注入与越权、并发写冲突、日志里不要打印敏感信息；
• 禁止事项：不要改写业务逻辑，不要对风格问题长篇大论。

把这份指令固定下来，每次评审只换 diff，AI 的输出稳定性会明显提高。提示词越具体，AI 越少“自由发挥”。

三、第二步：让 AI 先扫机械层，生成待确认清单

以一次真实的 PR 为例，改动约 300 行，涉及订单退款接口。AI 初筛后列出 11 条发现，其中 7 条是机械层：两个未使用的导入、一段重复的金额校验逻辑、三个命名不一致的变量。这一类我直接按 AI 的建议改掉，不用再等人评审。

剩下 4 条是逻辑层，AI 的原话大概是这样的：

• 退款金额为 0 时流程继续往下走，是否应该提前返回？
• 并发退款时没有加锁，同一订单可能重复退款；
• 异常分支里只记了日志，没有把失败状态写回数据库；
• 退款接口没有校验调用方是否有该订单的操作权限。

这 4 条里，前面两条是真问题，后两条一个是已有兜底、一个是上游网关已校验。我逐条确认后，只把真问题写进评审意见。AI 的价值在这里不是“替人判断”，而是“让人少漏”。

四、第三步：把高频问题沉淀成检查清单

评审做多了会发现，同一个团队的问题高度重复：空值、边界、并发、权限、日志，翻来覆去就是这几类。我的做法是每两周把 AI 发现的真问题归类一次，沉淀成一份团队检查清单，贴在 PR 模板里：

提交前自查：
[ ] 空值与边界：输入为 null、0、空字符串时行为是否明确
[ ] 并发：同一资源被并发操作时是否有锁或幂等保护
[ ] 权限：接口是否校验了调用方的操作权限
[ ] 异常：失败时状态是否回写，错误信息是否可定位
[ ] 敏感信息：日志与报错里有没有手机号、密钥、Token

清单一旦进模板，AI 评审的提示词也可以同步更新，让 AI 重点盯清单上的项。几轮下来，低级问题的出现频率会明显下降——评审从“每次救火”变成了“事前预防”。

五、一个可直接套用的评审提示词模板

你是代码评审员，只评审本次 diff，不评价文件历史问题。
输出格式：问题 | 位置（文件:行号） | 严重程度（高/中/低） | 修改建议。
重点检查：
1. 空值、边界条件与异常分支；
2. 并发写冲突与幂等性；
3. 资源泄漏（连接、文件、锁未释放）；
4. 越权与注入风险；
5. 日志与报错中的敏感信息。
不要改写业务逻辑，不要展开讲风格问题。
待评审 diff：
[粘贴 diff]

六、效果与注意事项

按这套流程，我们团队的评审周期从平均 1.5 天压到半天左右，评审人每轮真正要看的从几百行 diff 变成十几条待确认项。但有三条红线必须守住：AI 的发现不能直接当结论，每一条逻辑层问题都要人确认；涉及安全与资金的代码（支付、退款、权限）必须人逐行看，AI 只做辅助；评审记录要留档，AI 的建议和最终处理结果都要能追溯。

AI 不会替团队对代码质量负责，它只是把“找问题”这一步变快了。判断哪些问题真要改、哪些可以接受，仍然是评审人的工作。把判断留给人，把扫描交给 AI，这才是 AI 辅助代码评审的正确分工。