我们团队从 2025 年下半年开始让 AI 参与代码评审。半年后回头看，一个数字让所有人沉默了：AI 评审报告平均每份提出 8.4 个问题，最终真正推动代码修改的只有 2.1 个，推动修改率 25.0%。剩下的 6.3 个去哪了？一部分被作者证明「不是问题」，一部分被证明「问题存在但不值得改」，还有相当一部分根本没被打开过。
这件事倒逼我们做了一次彻底的复盘。复盘结论不是「AI 评审没用」，而是我们一直在用错误的方式使用它。这篇文章把我们从 25% 做到 61.8% 推动修改率的过程完整写出来，包括中间走过的弯路——最重要的教训几乎全来自弯路。
一、8.4 个问题里，为什么只有 2.1 个推动了修改？
先把那 6.3 个「没改」的问题分类清楚。这一步比任何优化都重要，因为我们发现浪费的结构和直觉完全不同：
| 问题类别 | 占比 | 是否成立 | 典型表现 |
|---|---|---|---|
| 风格偏好类 | 41.3% | 多不成立 | 「建议用 map 替代 for」「变量名可以更语义化」 |
| 真实缺陷类 | 28.6% | 成立且需改 | 空指针、竞态、资源泄漏 |
| 过度保守类 | 18.5% | 成立但不改 | 建议加 try-catch 兜底本不可能失败的分支 |
| 上下文缺失误报 | 11.6% | 不成立 | 没看到该变量在别处已初始化 |
一眼可见：超过六成的评审意见是风格和保守主义，而不是缺陷。但这些偏偏是看起来最「专业」、最有存在感的意见——因为它们占了报告的大头，作者会默认「AI 认真看过了」。这是最坏的情况：它既没帮上忙，又稀释了那 2.1 个真问题的权重。
我们做过一次内部实验验证这个稀释效应：把同一份报告的「真实缺陷」单独拎出来发，作者的修改响应速度从 3.2 天缩短到 0.8 天。问题从来不是作者不重视，是报告本身让人没法重视。
二、第一轮改造：做减法，把风格类意见全砍掉
第一次优化做得非常粗暴：在提示词里明令禁止输出风格建议，只允许报告「会导致错误的行为」。效果立竿见影，推动修改率从 25.0% 涨到 52.3%，平均意见数从 8.4 降到 3.7。
但我们很快发现副作用：真问题的召回率掉了。回测 300 个 PR，AI 此前能发现的空指针问题，有 23.4% 不再被提及。原因很直接——「禁止风格意见」这个指令，模型在执行时会顺带收紧对一切「非致命问题」的判断标准，包括某些边界条件下才会触发的竞态条件。
教训：一刀切的抑制会把有价值和没价值的一起干掉。这不是模型笨，是「值得改」和「会出错」之间本身没有清晰边界，模型被迫二选一时会选保守的那头。
三、第二轮的正确答案：分级，而不是禁止
第二版方案保留了全部意见，但要求每条必须携带两个字段：严重级别和触发条件。触发条件必须写成「当 X 发生时，会导致 Y」的完整因果句——写不出因果句的意见不允许输出。
- P0：必然触发错误。当前逻辑下一定会出错，缺测试覆盖或缺空值校验的典型场景。
- P1：特定条件触发。并发、边界值、异常输入下才出错。这是团队最需要的层级。
- P2：可能导致未来问题。不触发当前 bug，但会在特定变更后变成 bug。
因果关系是这套方案的核心机制。它逼模型把「我觉得这样写更好」翻译成「如果不改，什么场景会出什么事」。翻译不了的，自然显形为风格偏好，进不了报告。这一改动让平均意见数降到 3.2 条，同时真问题召回率回到了 91.4%——比禁用风格建议时高了 68 个百分点，比全面放开时只低 3.6 个百分点。
四、闭环：让它进入流程，而不是留在报告里
分级解决了「报告可信度」，但没有解决「为什么意见没人跟进」。我们补了两件事：
- P0 和 P1 强制阻断。接入 CI，未处理的 P0/P1 不允许合并。阻断不是让 AI 说了算，而是强制作者对每条 P0/P1 表明态度：改了、或给出不改的书面理由。我们统计过，有 38.7% 的 P1 最终被合理驳回——这恰恰是机制有效的证明。
- 误报回流。作者驳回时选择「误报」并附一句解释，这些解释进训练集，每周用来校准评审规则。两周时间，误报率从 11.6% 压到 4.2%。
加入闭环后，推动修改率最终稳定在 61.8%。其中最关键的改动不是模型或提示词，是 CI 那条红线。有了红线，作者必须逐条表态；驳回成本上升之后，报告的作者（也就是 AI）也会被迫认真。
五、我们仍然不让 AI 碰的评审内容
- 业务语义正确性。代码跑通不代表做对了业务。这类问题需要业务上下文，AI 缺的不是知识是立场。
- 安全策略。涉及鉴权、加密、密钥管理的改动仍然走人工安全评审。AI 在这里的角色是「提前扫描已知模式」，不是「放行依据」。
- 架构性取舍。要不要拆服务、要不要引入新组件，这类判断人工智能只提供论据，决策必须人做。
总结
把 AI 代码评审的推动修改率从 25% 做到 61.8%，中间的关键步骤只有三个：砍掉无因果的意见、用因果句强制分级、把 P0/P1 接进 CI 阻断。没有一个是「换更强的模型」。
一句话总结这次实验的教训：AI 评审的价值不在它指出了多少问题，在它指出的问题里，你敢直接照做的比例有多高。
互动提问：你们团队的 AI 评审报告，审完真正推动了多少代码修改？是报告没人看，还是看完觉得「不至于改」？
互动提问：如果给评审意见加一条「必须写出不改会出什么事」的硬规则，你觉得报告会变短，还是会变准？
— IMAI 编辑部 | 2026-11-06