先别急着夸它会看代码

过去一年，AI code review 的推进速度很快，快到这个问题已经不能只在工具演示里讨论了。

2025 年 2 月，GitHub 把 Copilot code review 推到 public preview。4 月，它转成 generally available。到了 2026 年 3 月 5 日，GitHub 又宣布 Copilot code review 已经切到 agentic architecture，可以主动拉更多仓库上下文来减少噪音、提高信号质量。产品路线很清楚：AI review 不是边角功能，而是要进入默认工程流程。

采用速度也很猛。GitHub 在 2025 年 4 月说，Copilot code review 在公开预览后一个多月里，已经有超过 100 万开发者用过。另一边，字节跳动的 BitsAI-CR 论文给了一个更工程化的参照：这套系统在内部服务超过 12,000 周活用户，评论精度做到 75.0%。

看到这里，很容易得出一个顺滑结论：既然 AI 已经能给很多 review comment，而且规模化也跑起来了，那 code review 这件事大概也会越来越自动化。

但真正的问题其实不是它会不会看代码，而是它做完这些动作之后，我们还能不能把这个过程叫作软件工程里原来意义上的 review。

Code review 从来不只是“帮你挑错”

很多团队谈 code review，默认把它理解成一个找 bug 的环节。这个理解不算错，但不够。

一个真正有效的 review，至少同时承担 4 个功能。

• 它在发现问题。
• 它在传播上下文。
• 它在约束未来维护成本。
• 它在分配责任。

前 3 个功能，AI 已经开始部分接手。它可以指出空值风险、边界条件、潜在性能问题，甚至能结合仓库上下文提出更成体系的修改建议。GitHub 那项 2024 年的随机对照研究也确实给了 AI 一个正面分数：202 名有 5 年以上经验的开发者里，拿到 Copilot 的一组通过全部 10 个单测的概率高出 53.2%，盲评里代码在可读性、可靠性、可维护性和简洁性上也有小幅但显著的提升，最终批准率高了 5%。

这说明一件很重要的事：AI 确实能帮团队写出更快进入“看起来可 merge”状态的代码。这个进展不能假装没发生。

但第 4 个功能，才是真正麻烦的地方。review 的隐藏动作，不只是“看见问题”，而是“某个具体的人对这次 merge 之后的后果承担签字责任”。软件工程很多制度最后都收束到这一点：谁看过，谁理解了，谁同意让它进主干。

一旦这个动作开始空心化，review 就会保留表面形状，失去原来的制度含义。

现在最尴尬的，不是 AI 看不看得见问题

真正尴尬的地方在于，AI 和人类正在把 review 拖向两个不同方向。

AI 擅长的是吞吐量。它不嫌 PR 多，不嫌注释长，不嫌代码风格重复。它可以在很短时间内生成大量评论，还能在“表面合理”的层面给出不错的建议。

人类 reviewer 擅长的不是吞吐量，而是责任判断。哪些地方看起来对，其实会把未来维护拖下水；哪些改动虽然能过测试，但会把调用边界搞脆；哪些地方即便没有立刻出 bug，也不该在这个时间点 merge。真正值钱的 review 往往长在这里。

问题是，一旦 AI 先给出大量评论，人类 reviewer 很容易从“判断者”退化成“二次浏览者”。流程上他还在，界面上他也点了 approve，但真实的角色已经开始滑动了。

这就是为什么很多团队会产生一种奇怪的错觉：明明 review 更频繁了，大家却不一定更安心。因为评论数变多，不等于有人真正理解得更深。

研究已经在提醒：模型会评论，不代表模型真懂 review

这不是凭感觉说 AI 不行。过去一年的研究已经开始把这个问题拆开测。

最直接的一项是 CodeReviewQA。这项 ACL 2025 的工作没有继续沿用“让模型根据 review comment 改代码，再看结果好不好”那套容易失真的评估，而是把 code review 理解拆成 3 步：识别改动类型、定位改动位置、找出解法。研究者用 900 个手工整理的高质量样本、横跨 9 种语言，测试了 72 个模型。结论很值得记住：模型在真实 code review comprehension 上有清晰、可暴露的弱点，而且这些弱点跟“它最后能不能生成一个像样补丁”不是一回事。

这说明一个很关键的问题。很多时候，模型生成的改法看着像对的，不代表它真的理解了 reviewer 当时为什么提这个意见。它也可能只是撞上了一个统计上常见的修补模式。

另一项 2025 年关于 defect-focused automated code review 的研究，把问题拉回更接近工业流程的地方。作者明确指出，过去很多自动 code review 工作把任务想得太简单了，喜欢用片段级 code-to-text 和 BLEU 一类指标做评估，但真实世界里更难的是 4 件事：拿到足够上下文、找到关键 bug、控制误报率、接入人类工作流。换句话说，困难从来不只是“让模型说点什么”，而是“让评论在真实工程链路里有足够的可信度和可用性”。

更难的部分是：它可能看错，而且错得很像对

如果上面的问题还只是“懂得不够深”，那下一层更麻烦：模型会在验证任务里出现系统性误判，而且这些误判不一定能被直觉发现。

2025 年关于规格验证的一篇研究发现，LLM 在判断代码是否满足自然语言需求时会出现系统性失败。更反直觉的是，加入更复杂的 prompt engineering，尤其是要求模型一边解释、一边给修改建议时，误判率反而更高。这个结论对 review 很要命，因为真实 review 场景恰恰最喜欢让模型“解释一下为什么有问题，顺便给个修法”。

同年另一篇研究还展示了一个更糟的点：LLM 做静态分析时存在 abstraction bias，也就是它会因为太熟悉某种常见模式，而忽略掉代码里那些很小但很关键的真实 bug。研究者甚至证明，这种偏差可以被专门利用，最小化改动就能把模型带偏，而且显式提醒也不一定能完全缓解。

说得直白一点，AI review 最危险的地方不是它明显瞎说，而是它说得很像一个认真 reviewer，却把真正值得卡住的地方漏掉了。

这就让“AI 已经帮我们看过一遍”变成一句非常危险的话。因为它听起来像降低了风险，实际上可能只是在给风险盖一层更顺眼的包装。

仅靠 AI 审 AI，离真正的 review 还差一截

那是不是让另一个 AI 来审第一个 AI，就行了？

这是很多团队正在默认采取的路线：AI 写，AI review，人类做最后抽查。这条路当然有现实吸引力，但它和“真正的 review”之间还隔着一层责任真空。

工业界最有价值的进展，反而都在说明一个相反事实：你必须给 AI review 增加更多非模型约束，它才会稍微像一个可信系统。

BitsAI-CR 靠的是两阶段设计，不是单纯对着 diff 直接吐评论。SGCR 这类 2025 年的工作更明确，核心方法是 specification grounding，把模型评论绑到人类写下来的规范和显式规则上。它在真实工业环境里把建议采纳率从 22% 拉到 42%，相对提升 90.9%。这不是在说明“模型终于够聪明了”，而是在说明“光靠模型不够，必须把 review 重新接上规则、上下文和组织标准”。

所以问题已经很清楚。AI review 有用，但它真正有用的时候，往往不是最像“完全自动”，而是最像“被约束得足够严格”。

这和很多团队的幻想刚好相反。大家嘴上说想减少 review 负担，最后却发现，真正能让 AI review 变得可信的，恰恰是额外的规则、规格、仓库约束、提示指令、扫描器和人工责任链。也就是说，省下来的不是制度，更多只是体力。

真正的 review，越来越像一种责任协议

到了这里，问题就可以回答得更准确一点了。

AI 时代的 code review，不是不能算 review。 但只有在一个前提下，它才配叫真正的 review：最后仍然有人类对这次改动的理解深度、验证过程和 merge 后果承担真实责任。

没有这一层，review 就更像“经过了一道自动化评论流程”，而不是工程意义上的 review。

从这个角度看，未来真正需要守住的不是“必须由人类亲手写大部分代码”，而是下面这几件更具体的事。

• reviewer 是否真的理解了这次改动的意图、边界和影响范围。
• review comment 是否能被追溯到规则、需求、架构上下文，而不是只是一段概率上合理的话。
• approve 是否意味着“我愿意为这个 merge 的后果负责”，而不是“界面上总得有人点一下按钮”。
• 对高风险区域，团队是否保留了比普通 PR 更高的人工审阅门槛。

这也是为什么我不太喜欢那种“AI 让 review 更高效，所以 review 会越来越自动化”的说法。它只说了吞吐量，没有说责任。

而真正的 review，从来不是吞吐量制度。它首先是一种责任制度。

人类 reviewer 接下来更像什么人

如果 AI 写代码、AI 先审代码都继续发生，人类 reviewer 的角色会明显变化。

以后最稀缺的能力，也许不是快速写出一段实现，而是快速判断一段实现到底值不值得被相信。

这会把 reviewer 往 4 个方向推。

• 更像风险编辑，而不只是代码语法警察。
• 更像上下文持有人，而不只是 comment 机器。
• 更像合并签字人，而不只是流程节点。
• 更像“把 AI 生成物当作不可信输入来处理”的验证者，而不是默认接盘者。

这一点其实和最近的人机协作研究很一致。HAI-Eval 发现，单靠人或者单靠模型都不够，真正有效的是协同；45 名参与者与 5 个主流模型的实验里，纯模型通过率只有 0.67%，单独人类是 18.89%，人机协作能到 31.11%。另一项 2026 年的人类-人类-AI 三方编程研究也发现，一旦 AI 的使用对另一个人类同伴可见、可追问，参与者对 AI 代码的依赖会明显下降，责任感反而会上升。

这两个结果连起来看，很有意思。AI 最适合进入的是“协作结构”，不是“责任黑洞”。它该让 review 更强，而不是让 review 更空。

最后别只问“它能不能审”，先问“谁还在签字”

所以，AI 时代的 code review 还能不能算真正的 review？

答案是：能，但不是默认能。

如果 review 仍然意味着：

• 有人真正理解了改动，
• 有人真正验证了风险，
• 有人愿意为 merge 后果承担责任，

那它还是 review，只是工具变了。

但如果 review 逐渐变成：

• AI 先写，
• AI 再审，
• 人类只做快速滑过，
• 最后留一个形式上的批准痕迹，

那它就已经不是原来那个 software engineering 里的 review 了。它更像一种自动化安慰剂，让团队感觉自己还在守门，实际上门已经越来越虚。

未来几年，AI code review 一定会更强，覆盖更多语言，拿到更多上下文，给出更少噪音、更像回事的评论。这几乎是确定的。

但真正决定这件事有没有价值的，最后还是一个很老派的问题：

当 bug 进入主干、漏洞进入生产、事故开始扩散时，谁能站出来说，这段代码我真的看过，我知道它为什么能进。

如果这个人还在，review 就还在。 如果这个人只剩名字，review 就只剩界面了。