智能体取代的是审查者，而非审查本身

2026年6月，以自动程序修复研究著称的软件工程研究者Martin Monperrus发表了一篇题为《代码审查的终结：编程智能体取代人工检查》（The End of Code Review: Coding Agents Supersede Human Inspection）的论文。其论点是，编程智能体已经跨越了某种能力阈值，让人在合并前逐行检查差异不再是一道必要的质量关卡，而那种由智能体写代码、由人充当强制审查者的常见安排是一条死胡同。¹

这篇论文正确的地方比批评者愿意承认的要多，而它出错的那一个具体之处恰恰至关重要。智能体确实取代了审查者：那个逐行阅读差异、寻找缺陷的人，所做的工作如今由一组智能体做得更好，并且覆盖每一次提交。但论文把这个角色与审查本身混为一谈。当你真正运行它所开出的智能体流程时，人的工作并没有消失。它发生了迁移，从检查代码转向掌管代码本应满足的意图。 我正在运行那条流程。审查者正在消亡，审查本身则在向技术栈上方移动。

我想认真对待这篇论文，因为对它的大多数回应都不会如此。条件反射式的回复是「可是智能体会产生幻觉」，而Monperrus早已承认这一点。诚实的探讨，应当从承认他正确的部分开始。

摘要

• Monperrus主张编程智能体已经终结了对人工代码审查的需要，因为审查的每一个目标（缺陷检测、风格、安全、知识传递）都由智能体以更好、更低成本的方式实现，而人工审查能力无法随智能体驱动的吞吐量一同扩展。¹
• 他正确地指出，那个强制性的人工批准复选框已经走到尽头，也正确地指出智能体进行系统性检查的水平，胜过一个疲惫的人草草浏览一大段差异。
• 他对此并不天真：论文承认了幻觉、提示注入、安全盲点的相关性等问题，并将高风险、新颖、受监管和涉及伦理的变更保留给人来处理。¹
• 缺口在于，他把残余的人工角色当作一小套需要升级处理的特例。而在生产环境中，它是承重的核心：智能体针对它所拿到的规格进行优化，而编写并掌管那份规格，正是不可化约的人之行为。
• 审查者这一角色正在被自动化。而审查本身，即关于软件对其目的而言是否正确的判断，正在迁移到智能体无法跟随之处。

这篇论文正确的地方

Monperrus建立在Bacchelli和Bird对团队为何审查代码的枚举之上：缺陷检测、风格与标准的执行、知识传递、团队认知，再加上作为第五个维度的安全。¹² 他的做法是逐一拿起每个目标，论证智能体能把它做得更好。智能体检查每一次提交，不会疲劳，也不受时区延迟影响。它们比人做临时性的一遍扫查更系统地枚举各类漏洞。它们在合并时生成架构摘要和更新后的文档。论文动用SWE-bench的能力曲线来论证阈值已被跨越：从该基准2023年推出时最佳模型解决不到2%的真实GitHub问题，到2025年底顶尖智能体超过70%。¹³

我对这一部分毫无异议，因为我每天都看着它运转。我的自主构建循环运行着一道三审查者关卡：在代码合并前，由各自独立的智能体分别检查正确性、规范和安全，第二道循环再把实现交给一个独立模型做对抗性的一遍审查。那些智能体捕捉到真实的缺陷，而且是在每一次变更上都捕捉到，而不只是在人有时间过目的那些变更上。本站此前发布的两篇文章，每一篇都通过了一个智能体评估器，它依照评分标准给文章打分，并标记出我随后不得不修正的具体事实问题。论文所称智能体能产出可操作的、结构化的、可与受过训练的审查者相媲美的审查输出，这一点对我而言并非猜想。它就是我的家常便饭。

吞吐量这一论点同样正确，而且这是人们低估的部分。一位由智能体辅助的开发者每天产出的拉取请求，多过人工审查能力所能吸收的量。当写代码的一方很快、而审查的一方是人时，审查队列就成了约束瓶颈，审查也退化为在时间压力下走过场的形式。¹ Monperrus说得对，那种天真的安排，即智能体写、人盖橡皮图章，提供不了真正的保障。一个因为代码看起来正确、测试也通过就批准的人，并不是在审查。他只是在签字。

他所描述的那条流程，正是我在运行的那条

论文用来取代人工审查的，并不是「信任某一个模型」。而是一条人机回环（agent-in-the-loop）的验证流程：多个独立的智能体，最好是不同的模型，产出经过校准的、结构化的签核（测试覆盖率、安全扫描、以JSON或SARIF——静态分析结果的标准交换格式——形式呈现的推理轨迹），而非随意的评论串，并指示智能体在不确定时弃权，把困难的情形保留给人。¹

那，换个名字，正是我一年来一直在构建并撰文论述的架构。我曾主张智能体的拉取请求需要更小的审查面，主张自动化审查需要异见而非一个自信的单一裁判，也主张由结构化证据构成的审查包正在取代随意的差异评论。所以我并不是在反对这条流程。我帮着论证了它的合理性。我所争论的，是一旦这条流程存在，留给人的还剩什么，因为我一直活在那个答案里，而它并不是论文给出的那个答案。

论证崩裂之处：审查从来不只是检查

Monperrus把高风险变更、新颖架构、受监管的代码路径以及伦理判断保留给人，并把这些框定为升级处理：当智能体标记出来时，例外情形被路由给某个人。¹ 这种框定让人的角色听起来像是一条原本已自动化的产线上偶发的中断。

而真正运行这条产线，教给人的恰恰相反。智能体并不生成它自身的目的。它针对手中拿到的规格进行优化，而在每一次有分量的变更上，总得有人先决定「正确」意味着什么，智能体才能据此去核对任何东西。论文本身在其讨论章节里承认了这条边界：智能体针对技术质量指标进行优化，并不可靠地具备能力去察觉一项遥测变更违反了用户合理的隐私预期，或一处排序调整放大了偏见。¹ 这被呈现为一种处于边缘的局限。但它并不在边缘。「这项变更对我们真正想要的而言是否正确」这个问题，端坐于每一次非平凡合并的中心，而它恰恰是一个被校准到某份规格上的智能体无法针对那份规格本身去发问的问题。

在我于本篇之前发布的那两篇文章上，我具体地体会到了这一点。智能体审查者给它们打了分，并各自捕捉到一处事实上的越界：一篇里有一项未经核实的机构性论断，另一篇里有一处被误归属的统计数据。捕捉到，是智能体的功劳。修正，则不是。如何如实地纠正一处越界，哪份来源才真正支持那项论断，那个句子诚实的版本是什么，这些都需要关于意图的判断，而评分标准能标记却无法解决。智能体发现了某处有错。是人决定了「对」该是什么样子。那种分工就是迁移，而它发生在日常内容上，并非什么受监管的边缘情形。

所以人并没有离开这条循环。人从它的末端移到了它的开端。审查过去是最后一道检查点，一个人检视写完的代码。在智能体流程中，检查被自动化了，不可化约的人类工作移到了前端：把意图说明得足够精确，让智能体有某种真实的东西可供核对；并在交付的结果符合规格却没抓住要点时，承担其后果。问责无法委派给一个针对指标进行优化的系统，因为问责是甘愿故意承担错误并为之作答的意愿。

这一论断的诚实版本

剥去标题里的挑衅，可辩护的论断比「代码审查的终结」要窄。可辩护的论断是：人作为差异检查者和强制性批准复选框的角色已经终结。那个角色确实走到了尽头，而为了守护一套舒适的仪式而假装并非如此，本身就是一种不诚实。那些把人留在检查席位上充当戏码的团队，批准着他们其实无法真正审视的智能体代码，早已失去了他们自以为拥有的那份保障。

但「代码审查」一直都是个代称。它命名的是一道检查点，意指的却是一项判断：这项变更是否以一种我们能为之背书的方式，安全地做到了我们所需要的。把检查点自动化，那项判断并不会蒸发。它迁移到了入口处的意图说明与出口处的问责，而在一个以智能体速度推进的团队里，它变得更重要而非更次要，因为智能体会忠实而迅速地构建出规格所言的一切，包括错误的那件事。写代码的一方越快，瓶颈就越落在「知道该要求什么」上。Monperrus说得对，审查者正在被取代。但他说审查本身正在终结，则是错的。它正在迁往那个唯一智能体无法占据的席位。

关键要点

对工程领导者： - 别再把人工审查安排成差异检查。智能体把这件事做得更好，而且持续不断；在智能体代码上加一个人工批准复选框是保障的戏码。 - 把那份人力重新分配到意图说明与问责上，即审查中决定「符合规格的正确」是否「合乎事实的正确」的那些部分。

对开发者工具的构建者： - 构建论文所描述的那种合奏式审查流程：多个模型、经过校准的弃权、结构化的签核。审查者之间的异见就是信号。 - 设计流程的前端，而不只是那道关卡。价值最高的接触面，在于人把意图转化为一份智能体可据以核对的规格之处。

对工程师： - 你的审查技能并非正在变得一文不值；它只是在更换地址。价值从在差异里发现缺陷，转移到了界定代码本应做什么、并对结果负责。

常见问题

这篇论文是不是意味着人工代码审查已经结束？

人作为逐行差异检查者和强制批准者的角色已经结束，这是论文最有力的一点：智能体进行系统性检查更出色，而且覆盖每一次提交。不会结束的，是代码审查所代称的那项判断，即一项变更对其实际目的而言是否正确。那项判断迁移到了说明意图与承担后果，而非消失。

Monperrus究竟主张了什么？

他主张编程智能体如今能以更低的成本和更高的吞吐量，服务于代码审查所有既定的目标（缺陷检测、风格、知识传递、安全），而把人留作智能体所写代码的强制审查者是一条死胡同，因为它给不出真正的保障，也无法扩展。他提议由一个智能体合奏产出结构化的签核，把高风险和涉及伦理的情形保留给人。这是一篇立场论文，而非一项实证研究。¹

论证最薄弱之处在哪里？

在于把残余的人工角色当作一种罕见的升级处理。实际上，人的角色在每一次非平凡的变更上都是承重的，因为智能体针对一份它既无法撰写也无法质疑的规格进行优化。界定规格并为结果作答是核心工作，而非边缘情形。

团队是否应该在智能体的拉取请求上保留一道人工批准步骤？

不该作为检查的戏码。如果人无法真正审视那项变更，那么这次批准就是一个签名，而不是一次审查。更好的做法是把人的精力投到上游，去精确地说明意图，并投到下游，去掌管交付的结果，同时让一个智能体合奏来完成检查。

来源

• Martin Monperrus，《代码审查的终结：编程智能体取代人工检查》，arXiv，2026年6月11日：arxiv.org/abs/2606.13175。一篇综合既有能力证据的立场论文；它枚举了出自Bacchelli和Bird的代码审查目标，引用了SWE-bench能力曲线，并讨论了包括幻觉、提示注入和伦理问责在内的种种局限。
• Alberto Bacchelli和Christian Bird，《现代代码审查的预期、结果与挑战》，ICSE 2013，论文所建立其上的审查目标分类法的实证来源：Microsoft Research
• Carlos E. Jimenez等人，《SWE-bench：语言模型能解决真实世界的GitHub问题吗？》，ICLR 2024，能力曲线背后的基准（推出时最佳模型解决1.96%）：arxiv.org/abs/2310.06770
• 来自生产经验的智能体审查相关文章：更小的审查面、审查需要异见、审查包，以及那条自主构建循环，其三审查者关卡正是本文所描述运行的流程。