《代码审查的终结：编程 agent 取代人工检查》笔记

这是一篇什么论文

作者 Martin Monperrus，2026 年 6 月 11 日发在 arXiv（编号 2606.13175），标题直译是《代码审查的终结：编程 agent 取代人工检查》。

它的主张一句话说完：合并代码之前要有人看一眼。这条从 1976 年 Fagan 把代码检查形式化之后立下、已经管了五十年的规矩，可以取消了。

有一点要先说清楚，否则整篇都会读歪：他说的不是不检查，是检查的那个人换成机器。

还有一点也得先说：这是立场论文，不是实验研究。作者综合别人已有的研究来论证，自己没有做实验。下面提到的所有数据，都是他引用的，不是他测的。

论点一：人审代码的四个目的，机器现在都能达成

他先问了一个很基本的问题：人审代码到底在干嘛？

学术上（他引 Bacchelli 和 Bird 的分类）拆成四件事：找 bug、管风格、传知识、让团队知道别人在改什么。他挨个对：

管风格这块二十年前就自动化了，linter、格式化工具、类型检查器干的就是这个活，agent 只是把它从语法层延伸到语义层。

找 bug，他引 Pornprasit 和 Tantithamthavorn 2023 年的研究，说 LLM 审查系统产出的缺陷报告，质量可以比得上受过训练的人类审查者。

安全审查，他引 Yildiz 等人 2025 年的结果，AI 安全扫描器在标准漏洞基准上已经超过不少人工审查者。

传知识，他的说法是 agent 可以在合并的时候按需生成解释、架构摘要和更新后的文档，比人写得还勤。

论点二：人审本来就没大家以为的那么管用

这一条是加强论证，比上一条狠。上一条说机器够格，这一条说人本来就不太行。

他引 Czerwonka 等人对微软的研究，结论是代码审查「在深层逻辑意义上找不到 bug」。

他又引 Bacchelli 和 Bird 的观察：人在审查里留下的评论，压倒性地是改风格、提小建议、问「你这是想干嘛」，真正的缺陷检出并不占主导。

换句话说，我们一直以为代码审查是在守质量的门，实际数据显示它大部分时间在做别的事。

论点三：「AI 写、人必审」是死路

这是全篇最扎实的一段。

很多团队现在的默认做法是：让 AI 写，但保留人工审查作为闸门，觉得这样既快又稳。他说这条路走不通，两个原因，各自独立成立，不需要互相支撑。

第一，审不出来。大模型能写出几百行看着合理、前后自洽、但藏着微妙语义错误的代码。这种错盯着 diff 是看不出来的，得把完整测试套件跑完才现形。人面对这种材料，审查很快就退化成盖章。

第二，不够审。他引 Peng 等人 2023 年的研究，AI 工具确实提高了开发者的产出。但人看代码的速度一点没变。于是产出涨多少，队列就堵多少，瓶颈是跟着生产力成比例长的。

这一条对管理者最有用，因为它说明「加人审」不是一个可以靠努力解决的问题。它是结构性的。

论点四：成本收益上，人审已经不划算

成本侧，他引 Sadowski 等人对 Google 的案例研究：大公司的开发者有 10% 到 15% 的工作时间花在审别人的代码上；从提交改动到拿到能用的反馈，延迟经常超过 24 小时。

收益侧，随着 agent 扫描每个文件、每个测试、每次提交的召回率提高，「逃过了 agent、但人能抓到」的那部分缺陷在缩小。

机器这边还有个结构性优势：agent 能同时把整个文件、完整测试套件、每个被改函数的 git 历史、项目文档一起放进上下文；人类审查者只有日历、时区和有限的注意力。他有一句话写得挺好：agent 在周日凌晨三点的审查强度，跟周一早上开工时是一样的。

能力上的证据是 SWE-bench 的轨迹。SWE-bench 是一套拿真实 GitHub issue 考 AI 能不能修 bug 的题目。成绩从 GPT-4 基线的不到 2%，到 2024 年 SWE-agent 的 12.5%，再到 2025 年底的 70% 以上。他说这个改进速度史无前例。

他要换成什么

不是取消审查，是把审查从「人点个勾」改造成工程闸门：

合并闸从人工审批变成结构化的 agent 签字，产出覆盖率阈值、安全扫描结果、风格合规报告。

跑多个独立的 agent，基于不同的模型和不同的提问策略，要求达成共识才放行。这条要记住，它是全文最可落地的一句。

agent 嵌进编辑器，提交前就审，反馈从小时压到秒。

审查变成 CI 里的一等公民，用他的类比：就像编译一样，它运行、它报告、要么通过要么阻塞。

输出用 JSON、SARIF 这类机器可读格式，而不是评论串，方便审计和统计。

人还留在哪儿

这一点最容易被误读，很多人以为他主张全交给机器。原文写得很明确：

人工批准没有被取消，它被留给了真正需要它的决策：高风险改动、新的架构选择，以及必须有一个具名的人承担法律责任的受监管代码路径。

日常那些改动（加功能、修 bug、升依赖、重构）agent 签字就够了。他要废的是「每个改动都得有人逐行看」这条默认规矩，不是人的判断。

他预先回应的五个反对

「agent 会幻觉、会漏报」：跑多个独立 agent 要求共识；让审查者在不确定的时候明确弃权，而不是硬给结论。

「AI 写的代码有安全问题」：用专门做安全的前沿模型来做安全签字，新一代模型已经比传统静态分析工具强。

「prompt injection 怎么办」：他承认这是一等威胁模型，没有完全解决的防御手段，属于活跃的安全研究领域。

「架构一致性谁来保证」：他说这本来就不该靠逐个提交看 diff 来保证，应该走设计文档、架构决策记录和专门的架构评审。

「出了事谁负责」：他认为伦理和责任的审视属于需求工程和上线后监控，agent 审查受和其他自动质量闸门同样的制度约束。

他自己承认没解决的

prompt injection。代码里可以藏指令，去操纵那个正在审它的 agent。他称之为质变的新攻击面，明说没有完全解决的防御。说白了：你的 AI 审查员，是可以被它正在审查的代码说服的。

同模型自审。一个模型既生成又审查，两边的盲点是相关的。它写的时候没想到要转义，它审的时候同样想不到。

架构判断。AI 可能无法以足够的保真度，持有长期系统设计的心智模型。

默会知识流失。人审代码时那些非正式的、来回的对话没了，团队文化和说不清道不明的经验会跟着一起流失。

对照我自己的实践

我是先有了一些实践和体感，才翻出这篇论文的，所以读的时候很有共鸣。我的实践是这样：

• 用 Claude Opus 做设计和代码实施，提交 PR 之前用 Codex GPT 做一遍代码评审。
• 进入 PR 评审后，再独立用 Claude 和 GPT 各做一轮评审。

从实践看，这三轮评审很少空手而归。拿两个真实的 PR 举例：一个是 Codex 一轮提了 4 条意见，其中 1 条是权限提升；另一个走了两轮，第二轮才发现归属字段没做类型校验，传个布尔值进去任务会用错误的身份执行。两轮的 4 个 Agent 互相 PK 并达成一致之后上线，代码质量至少在人的信心上是显著提升的。

论文最薄的两处

一是他用来证明「人审没用」的那两份研究，观察的都是人写的代码。人审人写的代码效果差，推不出人审 AI 写的代码也没用。Veracode 2026 春季那份报告里，AI 生成代码的语法正确率超过 95%、安全通过率只有 55%，这个剪刀差说明两者的出错分布根本不在一个形状上。这一步外推，他没有交代。

二是他引的 SWE-bench 衡量的是「agent 能不能修 bug」，不是「agent 能不能发现另一个 agent 的 bug」。这两件事之间有距离，而他整篇论证恰恰建立在后者上。

上面那三轮评审做的正是后者。论文缺的那块，眼下只能靠实践去补。

PS. 论文中论点与论据对照

（表中所有研究都是这篇论文的引用，我没有回去读原始研究本身。）