如何终结代码审查

来源：https://www.latent.space/p/reviews-dead 第二届 AIE 欧洲（https://ai.engineer/europe）和 AIE 世界博览会（https://ai.engineer/wf）的第二波演讲者名单今日公布，OpenCode 确认参加迈阿密站（https://x.com/AIEMiami/status/2028546958239973420）！我们还将前往墨尔本（https://webdirections.org/ai-engineer/）和新加坡（https://www.ai.engineer/singapore）。

编辑：这是我们在客座文章计划（https://docs.google.com/forms/d/e/1FAIpQLSeHQAgupNkVRgjNfMJG9d7SFTWUytdS6SNCJVkd0SMNMXHHwA/viewform?usp=dialog）中发布的最新文章，我们计划发布值得思考的 AI 工程类文章，即使我们个人未必认同——考虑到我们刚刚推出了一个 AI 审查工具（https://x.com/cognition/status/2014079905755955592?s=20），这次属于我尚未完全认同、但前景显然可期的情况，因此很高兴 Ankit（https://x.com/ankitxg）能来阐述这个观点！

当人类以人类速度编写代码时，人类就已经跟不上代码审查了。我交谈过的每一家工程组织（https://dx.org/）都有同一个不可告人的秘密：PR（拉取请求）闲置数日、橡皮图章式的批准，以及审阅者因为他们自己也有工作要完成而只能草草浏览 500 行的差异。

我们告诉自己这是一个质量关卡，但团队几十年来一直在没有逐行审查的情况下交付产品。一位资深工程师告诉我，代码审查直到 2012-2014 年左右才普及开来，我们中很多人都记不清了。

即使有审查，问题依然出现。我们已经学会构建能够处理故障的系统，因为我们接受了仅靠审查是不够的。这体现在功能标记、渐进式发布和即时回滚上。

根据来自 1,255 个团队、超过 10,000 名开发者的数据（https://www.faros.ai/blog/ai-software-engineering），AI 采用率高的团队完成的任务多 21%，合并的拉取请求多 98%，但 PR 审查时间却增加了 91%。

有两个方面正在呈指数级增长：变更的数量和变更的规模。我们无法消化如此大量的代码。就是这样。此外，开发者们一直表示，审查 AI 生成的代码比审查同事编写的代码需要更多精力。团队产出更多代码，然后花费更多时间去审查它。

我们无法通过人工代码审查赢得这场战斗。代码审查是一个历史性的批准关卡，它已不再匹配当前的工作形态。

AI 代码审查工具只是在为我们争取时间。如果 AI 编写代码，AI 也审查代码，为什么我们还需要一个漂亮的审查界面来展示这些？尽管 AI 代码审查很有价值，但这些审查将在开发周期中进一步左移。没有理由在审查周期之间浪费 CI 资源并管理版本。

在人类编写代码并需要新鲜视角的时代，PR 后审查是有意义的。当智能体编写代码时，“新鲜视角”只是另一个具有相同盲点的智能体。这里的迭代循环才有价值，而不是作为一个批准关卡。

我们从经验中得知智能体并不总是可靠的，而且人类很自然地会想，我曾经发现 AI 做了一次蠢事；因此，我必须总是检查它。这种本能曾经是合理的，当时人工验证是可行的。但以目前的规模，已经不行了。而且情况只会越来越糟。

答案是将人工检查点前移。如果想到不审查代码让你感到害怕，请让我提醒你，在软件开发中，检查点曾经移动过。我们从瀑布式的签字批准转为持续集成。我们可以再次移动它们。

规范驱动开发正成为与 AI 协作的主要方式。人类应该审查规范、计划、约束和验收标准——而不是 500 行的差异。

在这个新范式中，规范成为真实来源。代码成为规范的产物。你不需要审查代码。你审查的是步骤。你审查的是验证规则（https://verify.aviator.co/）。你审查的是代码必须满足的契约。

人在环路中的批准从“你写对了吗？”转变为“我们是否在用正确的约束解决正确的问题？”最有价值的人类判断是在第一行代码生成之前行使的，而不是之后。

在完全停止阅读代码（https://simonwillison.net/2026/Feb/7/software-factory/）之前，我们需要达到多高的舒适度？

以规则形式表达： 代码不应由人类编写 代码不应由人类审查

大语言模型并不擅长遵循指令。它们会偏离。经常如此。而且它们在自我验证方面不可靠——它们会自信地告诉你代码能运行，尽管它实际上已经崩溃了。解决方法不是要求大语言模型去验证。而是要求它编写一个验证脚本。从判断转向产物。

信任是分层的。这是瑞士奶酪模型（https://en.wikipedia.org/wiki/Swiss_cheese_model）：没有单个关卡能捕获所有问题。你堆叠不完美的过滤器，直到孔洞不再对齐。那么，我们还可以在哪里设置批准关卡？

与其要求一个智能体做对，不如让三个智能体尝试不同的方法，并选择最佳结果。让它们竞争。选择的成本是软件工程史上最低的。

选择过程也不必是手动的。你可以根据哪个通过了最多的验证步骤、哪个产生的差异最小、哪个没有引入新依赖来对输出进行排序。竞争会产生单次尝试无法获得的信号。

应该有一种确定性的方式来验证工作。测试、类型检查、契约验证（https://verify.aviator.co/）——这些都是客观事实，没有主观意见。

与其问大语言模型“这个能用吗？”，你应该定义验证步骤，生成一系列通过/失败的产物。智能体无法与失败的测试讨价还价。它要么满足规范，要么不满足。

这些护栏本身也可以定义为多层：

• 编码准则——可以是自定义的代码检查工具
• 全组织不变项——不可协商的规则，例如，禁止硬编码的凭据、API 密钥或令牌
• 领域契约——特定于框架、服务或代码库的某个部分，例如，支付领域：所有金额使用 Money 类型
• 验收标准——特定于任务

验证步骤应在代码编写之前定义，而不是事后发明来确认已有的内容。如果智能体既编写代码又编写测试，你只是转移了问题——现在你是在信任智能体会测试正确的内容。验证标准需要来自规范，而不是来自实现。

那么人类在哪里增加价值呢？在上游，定义成功是什么样子。

这就是行为驱动开发（BDD）重新变得相关的地方。BDD 一直是个好主意——用自然语言编写规范来描述预期行为，然后将这些规范自动化为测试。但它从未完全流行起来，因为当你也要编写代码时，编写规范感觉像是额外的工作。

有了智能体，这个等式就反转了。规范不再是额外的工作；它是主要的产物。你写：

智能体来实现。BDD 框架进行验证。你永远不需要阅读实现，除非出现问题。

这就是人类在做人类擅长的事情：定义“正确”的含义，编码业务逻辑和边界情况，思考可能出错的地方。智能体处理从意图到代码的转换。BDD 规范成为你的验证层——确定性的、自动化的，并且在第一行代码编写之前就已定义。

由人类编写的验收标准（https://docs.aviator.co/verify/how-to-guides/writing-effective-acceptance-criteria），由机器验证。这才是真正重要的关卡。

这个智能体能触及什么？什么需要上报？这些成为架构决策，而不是事后思考。

大多数智能体框架将权限视为全有或全无的设置。智能体要么有 shell 访问权限，要么没有。但粒度很重要。修复实用程序函数中错误的智能体不需要访问你的基础设施配置。编写测试的智能体不需要修改 CI 流水线。

范围应尽可能窄，同时仍让智能体能完成有用的工作。如果任务是“修复 utils/dates.py 中的日期解析错误”，那么智能体的文件系统访问权限应仅限于该文件及其测试文件。不是整个代码库。不是“src/ 和 tests/”。只是与当前任务相关的文件。

升级触发器同样重要。某些模式——涉及身份验证逻辑、修改数据库模式、添加新的依赖项——无论智能体多么自信，都应自动标记为需要人工审查。

职责分离：一个智能体负责工作，另一个负责验证。它们互不信任，这正是关键所在。

这是一个旧模式——这就是为什么你的 QA 团队不应向工程经理汇报，以及为什么编写代码的人不应是唯一审查代码的人。

有了智能体，你可以在架构上强制执行这一点。编码智能体不知道验证智能体会检查什么。验证智能体无法修改代码来让自己的工作更容易。它们在设计上就是对抗性的。

你可以更进一步：让第三个智能体尝试破坏第一个智能体构建的内容，专门针对边界情况和故障模式。红队、蓝队——但是自动化的，并且在每次变更时运行。

智能体系统的激励很简单：给定一个任务，我能完成它吗？我能取悦那个给我任务的人吗？智能体的成功从来不是由长期准确性或业务需求驱动的。

这是我们的工作——在约束中编码。

对于由智能体生成并由智能体读取的代码，什么是“好代码”将变得更加标准化。对于新的代码库，你将需要提供更少的指导，因为默认设置将更加一致。

未来是快速发布、全面观察、更快地回滚。

而不是：缓慢审查、依然漏掉 bug、在生产环境中调试。

我们无法比机器读得更多。我们需要比它们想得更远——在上游，在决策真正重要的地方。

最终，如果智能体能很好地处理代码，我们是否能读懂它又有什么关系呢？

Ankit Jain（https://www.linkedin.com/in/ankitjaindce/）是 Aviator（https://www.aviator.co/）的创始人兼 CEO，该公司正在为 AI 原生工程团队构建基础设施。Aviator 的平台帮助现代组织提高 AI 采用率，同时保持高标准的工程实践。