跨国深谈← 返回←代码评审未死：人类从引擎变飞行员

代码评审未死：人类从引擎变飞行员

关联

人物 Laurie Voss

公司 GitHub · Cursor · OpenAI · Anthropic · Cognition · Bun

概念 代码审查 · 智能体 · 提示词注入 · 基准测试 · 误报 · 生产环境

AI 智能体让写代码的速度暴涨，但人类读代码的速度一分没变——这一集是 Arise AI 开发者关系负责人 Laurie(此前是 NPM Inc. 的联合创始人)在一次技术大会上，讲代码评审怎么被 AI 重构。她甩出的第一个数字就很扎眼：三位经济学家追踪了超过 10 万名 GitHub 开发者，开启自主智能体的开发者多写了 741% 的代码，但实际发布的软件只多了 30%——写代码快了近八倍，上线只多了三分之一，而研究者直言：评审就是瓶颈 。

「多评审」行不通，数字早就说了

一个自然的答案是让一部分人专职评审。但这行不通：二十年前 Cisco 的一项研究(10 个月、2500 次评审、320 万行代码)发现，评审者一次读超过 400 行代码就基本发现不了缺陷，一小时超过 450 行效率就断崖式下跌。算一下账：一个智能体提交的 1 万行 pull request(代码合并申请)，按这个速度要三四个工作日才能获得一次真正的人工评审——而这只是十几个并行智能体中的一个的产出 。

那跳过人类呢？OpenAI 今年 2 月公布了一个内部项目：从空仓库开始，三名工程师、五个月、约一百万行代码、1500 个合并的 pull request,全部由智能体编写，连「审查智能体的智能体」也是智能体写的。

他们的原话是：人类可以审查 pull request,但这不是必须的 。但 Laurie 指出一个耐人寻味的细节：他们既没说这个产品是干什么的，也没开源方法论——说明这套策略仍有漏洞。

「测试通过」不等于「可合并」

问题出在：业界多年用「测试通过」当质量代理指标，而它不准。研究团队 Meter 今年 3 月请来四名开源项目维护者，审查那些已通过 Sweebench(一种代码能力基准测试)评分器的 PR——结果只有约一半真的够格合并，失败不在正确性，而在代码质量和悄悄破坏其他代码的改动 。Cognition(Devon 的开发商)今年 6 月发布了围绕「你会合并这个吗」构建的 Frontier Code 基准：同一模型，在 SweeBench Pro 上 88 分，在 Frontier Code 最难的部分只有 29 分，差了 51 分；GPT 5.5 在同一组测试上不到 6% 。

投资人 Sarah Guo 点破了背后机制：编译器和测试套件是「免费的验证器」，凡是能廉价验证的东西，模型都能靠训练刷到超越为止。所以一旦有人写出可靠的「可合并性」标准，它会立刻变成前沿模型的训练信号——谁写下了今天的评审标准，谁就是在书写明年的默认模型行为 。2024 年 OpenAI 用 Critic GPT(专挑模型所写代码 bug 的评审模型)已经验证过这条路：人机组合既胜过模型也胜过单独的人类，模型几乎立刻变好。

已经上线的自动化评审，长什么样

这不是纸上谈兵：GitHub 的 Copilot 评审员已完成 6000 万次评审，占 GitHub 全部代码评审的五分之一以上——已是全球最大代码托管平台上的主流默认 。Cursor 公开了架构细节，里面全是实战经验：

• 第一版评审员对每个 diff 跑八轮评审、还打乱顺序反复跑，为的是过滤误报——一个把好代码标成坏代码的评审员会被直接无视。北京大学团队独立验证了这招：多轮评审、保留一致结论，质量最多提升 44% 。
• 重建后他们最有趣的发现：模型倾向看着代码说「看起来不错，发布吧」——跟人类一个德行。他们不得不明说：不要默认信任代码，要假设它有问题 。
• 评审正与修复融合：Cursor 的评审员现在会自己生成修复智能体、写好补丁交回 diff 供人批准。

但所有这些厂商的成功指标都是同一个：有没有人类接受了我的答案？也就是说，人还是要评审这些评审。那能彻底去掉吗？

跳过人类的两次实验，代价都摆在台面上了

Anthropic 的 Nicholas Carlini 让 16 个智能体用 Rust 从零写了能编译 Linux 内核的 C 编译器，约 2000 个会话、全程无人审批——但审查代码、验证代码的系统全是他手工写的。用他自己的警告说：很容易看到测试通过就以为完事了，而很少真的完事 。

Bun(现为 Anthropic 一部分)六天把上百万行代码从 Zig 移植到 Rust,测试套件 99.8% 通过——但有人细查后发现移植代码里有 13,044 个 unsafe 块(Rust 中作者「断言」而非「证明」内存安全的地方)，同等规模的人类代码只有约 74 个，多了三个数量级。测试能验证公共接口行为，验证不了这 1.3 万个它从没设计过要找的隐患 。

最有分量的反悔来自 Dexter Horthy:他花了六个月到处讲「别评审代码，直接发布」，去年还在大会上公开这么宣传；今年 3 月他在台上收回：「我错了。请、请去读代码。

我们不读代码试了大约六个月，结局不好，不得不把系统的大部分拆掉重做。」

人的角色没消失，是在往栈的上层走

Laurie 的结论：代码评审没死，但正在被重构为工程化系统，人类从逐行读代码的「引擎」变成「飞行员」。人类检查点存活在可预测的地方：正确性无法廉价检验处、爆炸半径大处、以及必须有人签字担责处 。

而且去掉人还有安全代价：Anthropic 自家的自动化安全审查器，readme 里明写着「未针对提示词注入攻击加固」——审查器能被它正在审查的代码说服而放弃结论。今年 3 月的研究复现了这一点：披着无害提交信息的漏洞代码骗过自动审查智能体的成功率是 88%,骗过人类的只有 35%。

把人拿出去，你不只是失去一个审查者，是失去了那个难以被欺骗的东西 。更糟的是，领域连「怎么给评分者打分」都没共识——于是一旦合并前全是机器，生产环境就成了最后一个屹立不倒的审查者：观察代码上线后实际做了什么 。

本集带走

• 停止逐个审查 PR:对 2026 年来说它是错误的抽象层级。把你的判断力投入更高层——审查系统、规则、评测集——把「好」的定义、公司上下文、领域知识编纂成代码，再让智能体在上面全力运转。
• 别把「测试通过」当「可合并」：测试套件之外存在测试找不到的上下文(谁在依赖这个模块、没人承认的定时任务)，这些恰恰是评审的真正价值所在。
• 自动化评审的头号敌人是误报：多轮评审、只保留一致结论是被反复验证有效的做法；并明确告诉模型「默认怀疑代码」。
• 跳过人类评审的实验，代价是已知的：Carlini 的编译器靠的是人写的验证系统，Bun 的 Rust 里藏着 1.3 万个 unsafe 块，Dexter Horthy 公开收回了自己的主张。
• 机器评审有安全软肋：自动审查器可被提示词注入骗过(88% vs 人类的 35%),安全敏感场景的人工关卡短期去不掉；上线后的生产行为观测，是合并前全机器化之后最后的人工检查点。

开启自主智能体的开发者多写了 741% 的代码，但实际发布的软件只多了 30%。
The developers who turned on autonomous agents wrote 741% more code, but only 30% more software shipped.
—— Laurie Voss · [01:47]

该研究指出，评审者一次读超过 400 行代码就基本发现不了缺陷，一小时超过 450 行效率就完全断崖式下跌。
And the study says that reviewers stop finding defects effectively if they try to read more than 400 lines of code in one sitting and their effectiveness completely falls off a cliff if they try to review more than 450 lines of code in an hour.
—— Laurie Voss · [03:54]

OpenClaw 的创造者 Peter Steinberger 说，你不应该再去提示编码智能体了，你应该去设计那些提示你的智能体的循环。
Peter Steinberger, who is the creator of OpenClaw, says that you shouldn’t be prompting coding agents anymore, you should be designing the loops that prompt your agents.
—— Laurie Voss · [04:53]

这里的赌注是，循环设计可以替代检查。
The bet there is that loop design substitutes for inspection.
—— Laurie Voss · [06:21]

在她谈论这件事的文章里，她讲清楚了模型为什么在生成代码上进步得这么快——因为编译器是一个免费的验证器。
In the essay where she was talking about this, she made clear why models got so good so fast at generating code, and that is because a compiler is a free verifier.
—— Laurie Voss · [09:36]

所以一个可合并性的基准，如果我们能做出来的话，不仅仅是一种度量，它会立刻成为前沿模型的训练信号——也就是可维护性、范围纪律、回归安全性这些。
So a benchmark of mergeability, if we could make one, wouldn’t only be a measurement, it would immediately become a training signal for the frontier models, which means maintainability, scope, discipline, regression safety.
—— Laurie Voss · [09:59]

谁写下了今天的评审标准，谁就是在书写明年的默认模型行为。
And whoever writes today’s review standard is writing next year’s default model behavior.
—— Laurie Voss · [10:18]

所以对拉取请求的机器评审，已经是全球最大代码托管平台上的主流默认做法。
So machine review of pull requests is the mainstream default on the world’s largest code host.
—— Laurie Voss · [11:24]

多轮这一招不断被重新发现，因为误报正是杀死一个评审员的东西，而且它确实有效。
The multi-pass trick keeps getting rediscovered because false positives are the thing that kill a reviewer, and it actually works.
—— Laurie Voss · [12:30]

模型倾向于看着代码说，嗯，这在我看来不错，所以就发布吧——而这恰恰是人类在那种情况下会做的事。
The model tended to look at the code and say, well, that looks good to me, so ship it, which is exactly what a human would do in that situation.
—— Laurie Voss · [12:54]

这个实验的教训是：审查并没有消失。它被重建成一个系统，而那个系统是由人类构建的。
Review didn’t disappear is the lesson of this experiment. It got rebuilt as a system and that system is built by humans.
—— Laurie Voss · [18:31]

他说，我错了。请、请去读代码。我们有大约六个月的时间尝试不读代码。结局并不好。我们不得不把那个系统的大部分拆掉重做。
He said, I was wrong. Please, please read the code. We tried not reading the code for like six months. It did not end well. We had to rip out and replace large parts of that system.
—— Laurie Voss · [19:01]

但正在发生的是，人类的角色并没有消失，它正在向栈的上层移动，可能移动了栈的好几层——从直接检查代码，转到设计和调优那些检查代码的系统，以及设计「好」的定义。
But what’s happening is the human role isn’t disappearing, it is moving up the stack, possibly several levels of the stack, from inspecting the code directly to designing and tuning the systems that inspect the code and designing the definition of good.
—— Laurie Voss · [20:21]

所以你把人类从环中拿掉，你不只是失去了一个审查者，你失去了那个难以被欺骗的东西。
So you take the human out of the loop, you don’t just lose a reviewer, you lose the thing that was hard to fool.
—— Laurie Voss · [21:26]

所以自动化审查会栽在那些以自信姿态包装的坏代码上，而以自信姿态包装的坏代码恰恰是智能体非常擅长生产的那种代码。
So automated reviews fall for confidently framed bad code, and confidently framed bad code is exactly the kind of code that agents are very good at producing.
—— Laurie Voss · [21:33]

一旦合并前的审查全部由机器完成，观察代码实际做了什么就成了最后一个屹立不倒的审查者。
Once the pre-merge review is all machines, watching what the code actually does becomes the last reviewer standing.
—— Laurie Voss · [22:07]

而未来几年胜出的团队，不会是生成最多代码的团队，而是那些能够拿出证据说明他们为什么信任自己所发布内容的团队。
And the teams that win the next few years won’t be the ones that generate the most code, they’ll be the ones who can say with evidence why they trust what they shipped.
—— Laurie Voss · [23:15]