转载说明：本文译自 How to Kill the Code Review，作者为 Ankit Jain。原文发布时间：2026-03-02。如何终结代码评审 人类手写代码已在 2025 年死去，代码评审将在 2026 年死去。 编者按：这是 Latent.Space 客座文章计划 的最新一篇。我们会刊发那些值得 AI 工程师认真思考的文章，即便我们自己未必完全赞同。我们最近刚上线了一款 AI review 工具，所以这恰好就是一个我自己还没完全站到同一立场、但明显已经逼近现实的问题，也很乐意让 Ankit 来完整论证它。 当人类还在以“人类速度”写代码的时候，我们其实就已经跟不上代码评审了。我接触过的每一家工程组织都有同一个不太愿意公开的秘密：PR 一放就是好几天，审批流于形式，评审者只是草草扫一眼 500 行 diff，因为他们自己手头还有正事。 我们一直把它说成质量闸门，但团队在没有逐行审查的情况下也已经交付了几十年软件。直到 2012 到 2014 年左右，代码评审才真正开始普及。一位资深工程师告诉我，只是现在已经没有多少人还记得那个时代了。 而且即便做了评审，系统照样会出问题。我们早就学会了构建能够承受失败的系统，因为我们已经承认：单靠 review 根本不够。这一点体现在 feature flag、渐进发布和即时回滚等实践里。我们必须放弃“把所有代码都读一遍” 采用 AI 最深入的团队，完成的任务数提高了 21%，合并的 PR 数提高了 98%，但 PR 评审时间却增加了 91%。这来自一份针对 1,255 个团队、超过 10,000 名开发者的数据。 图 1 正在指数级增长的有两件事：变更的数量，以及变更的规模。我们根本不可能消费这么多代码，就这么简单。更别提开发者还不断反馈：审查 AI 生成的代码，比审查同事写的代码更费劲。团队写出更多代码，然后又把更多时间花在评审这些代码上。 我们不可能靠人工 code review 打赢这场仗。代码评审是一种历史时期形成的审批闸门，它已经不再匹配今天这份工作的形状。AI 代码评审依然是评审 AI 代码评审工具只是替我们多争取一点时间。如果代码由 AI 写、评审也由 AI 做，那我们为什么还需要一个漂亮的 review 界面去展示这些结果？AI review 当然可能有价值，但它会越来越早地左移进开发流程。在 review 周期之间浪费 CI 资源、维护版本状态，已经没有太大理由。 PR 之后再做评审，在“代码由人写、需要别人再看一眼”的时代是合理的。当代码由 agent 生成时，“另一双新鲜的眼睛”不过是另一个拥有同类盲点的 agent。真正有价值的是生成与修正的迭代闭环，而不是把它当成审批闸门。 我们都知道 agent 并不总是可靠，人也很容易这样想：我曾经抓到过 AI 干蠢事，所以我必须始终亲自检查。这个直觉在人工验证还可行的时候是合理的。但在今天的规模下，它已经不成立了，而且只会越来越糟。从审代码转向审意图 答案是把人工检查点前移。如果你觉得“不看代码”很可怕，请记住：软件工程里的检查点早就不是第一次迁移了。我们已经从瀑布式签字放行迁移到持续集成，再迁一次并不奇怪。 Spec-driven development 正在成为与 AI 协作的主要工作方式。人类应该审的是规格、计划、约束和验收标准，而不是 500 行 diff。 在这个新范式里，Spec 会成为真正的事实来源。代码只是 spec 的产物。你不需要 review 代码本身，你要 review 的是步骤，是验证规则，是代码必须满足的契约。 Human-in-the-loop 的审批重点，也会从“你是不是把它写对了？”转向“我们是不是在正确约束下解决正确的问题？”最有价值的人类判断，应当发生在第一行代码生成之前，而不是之后。通过分层建立信任 我们究竟需要对什么程度的自动化感到安心，才愿意不再逐行读代码？ 如果写成规则，它会是这样： 代码不应由人类编写 代码不应由人类评审 LLM 并不擅长严格执行命令。它们经常偏航，也不擅长自证正确性：哪怕代码已经着火了，它也会很自信地告诉你“一切正常”。解决办法不是继续问 LLM“你验证过了吗？”，而是让它去写一个做验证的脚本。要把信任从“主观判断”转移到“可执行产物”上。 信任是分层建立的。这就是瑞士奶酪模型：没有任何一道单独的闸门能挡住所有问题，你要把多层都不完美的过滤器叠起来，直到漏洞不再重合。那么，审批闸门还可以放在哪里？ 图 2Layer 1：比较多个候选方案 与其要求一个 agent 一次就做对，不如让三个 agent 用不同方式尝试，再从中挑出最优结果。让它们彼此竞争。为“多给几个备选方案”付出的成本，如今在软件工程史上已经降到最低。 这个选择甚至不一定要人工来做。…