AI代码审查实战：机器能抓什么、抓不到什么、怎么配合人

AI 审查上线三个月，为什么评审时间没降

很多团队的第一版 AI 代码审查很朴素：PR 一开，机器人挂上去，输出一堆评论。三个月后发现两个现象——评论越来越多，人越来越不读；真正出问题的 PR 还是靠人抓出来。

问题不在模型，在分工设计。AI 和人被放在了同一层做同一件事，结果就是噪音叠加。要让 AI 审查真正生效，得先想清楚它擅长哪一层。

三层能力边界

第一层：确定性检查（AI 高价值区）

语法错误、未使用变量、空指针风险、并发锁使用不当、日志打印敏感字段、SQL 拼接口子。这一类问题规则明确、可验证、几乎没有歧义。AI 加上静态分析工具在这里是碾压人类效率的，而且评审者乐意接受——因为每一条都是对的。

实践建议：这一层交给 AI 自动修复或直接阻断合并，不要让人再点一遍。

第二层：上下文一致性（AI 中等价值区）

新代码有没有破坏调用方假设、改了接口有没有同步改文档和测试、边界条件有没有处理。这类问题需要跨文件理解，AI 能做，但容易自信地错——它会基于不完整上下文给出”看起来合理”的建议。

实践建议：让 AI 评论”提出疑问”而不是”下结论”，并且强制附上它引用的代码位置。

第三层：业务正确性与架构取舍（AI 低价值区）

这个字段该不该允许为空、这个功能该不该拆服务、这笔交易的幂等怎么定义。AI 不知道你的业务，它给的往往是”教科书式的正确答案”，而正确答案常常和你们的约束冲突。

实践建议：这一层不让 AI 出评论，只让它做变更摘要——把这个 PR 改了什么、影响面在哪讲清楚，帮人类评审者更快进入状态。

分层审查流水线的设计

我推荐的落法是一根流水线三个闸门：

1. 提交前：本地 linter + AI 单文件修复，问题在作者手里消失
2. 开 PR 时：AI 自动生成变更摘要 + 第二层提问式评论，同时静态检查阻断
3. 人类评审：只看摘要 + 第三层判断，不再逐行找语法问题

关键设计原则是去重：同一条问题在不同层级只能出现一次。很多团队抱怨 AI 审查看不出价值，其实就是第一层的琐碎问题淹没了后面的信号。

三种最常见的误报来源

• 上下文缺失：AI 只看到 diff，看不到被调用的那个函数早就处理了 null
• 规范幻觉：模型按”通用最佳实践”评论，而不是你的团队规范——解决办法是把团队规范写进提示词或作为检索资料
• 过度修改：建议把三行代码重构成设计模式，评审成本高于收益

应对方法很统一：给 AI 喂仓库级的上下文和团队规范，并明确要求”只报告会导致 bug 或安全问题的情况”。限制它的报告欲，比提升它的聪明度更有用。

一个可量化的验收标准

上线 AI 审查后，别看”生成了多少评论”，看这三个数：

• 被采纳的评论占比（低于 40% 说明噪音太多）
• 缺陷逃逸率变化（线上事故有没有下降）
• PR 从提交到合并的中位时长

如果第二个数没动，说明 AI 只在做表面功夫，得往第一层加规则、往第三层收手。