如何终结代码评审
今天公布了 AIE Europe 的第二波 speakers 以及 AIE World’s Fair 的 CFP，同时 OpenCode 已确认落地 Miami！我们也会去 Melbourne 和 Singapore。
编辑注：这是 我们的 guest post 计划 的最新一篇。我们会发布值得认真思考的 AI Engineering 文章，即便我们并不完全认同其结论——我们刚刚发布了一个 AI review tool，而这正是我“还没完全到那一步、但明显已在地平线内”的议题之一，也很高兴由 Ankit 来完整阐述这一立场！
当代码还是由人类以“人类速度”编写时，人类就已经跟不上 code review 了。和我交流过的每个工程组织（链接）都有同一个“公开的秘密”：PR 一放就是好几天、审批流于形式、reviewer 因为手头也有自己的工作，只能草草扫一眼 500 行的 diff。
我们一直告诉自己这是质量闸门，但事实上，团队几十年来都在没有逐行 review 的情况下发布代码。就有资深工程师告诉我，code review 真正“无处不在”其实也就是 2012-2014 年之后的事，只是现在还记得那个时代的人已经不多了。
而且即便有 review，系统照样会出问题。我们早就学会了构建“可承受失败”的系统，因为我们接受了一个现实：单靠 review 不够。这体现在 feature flag、分批 rollout、以及即时回滚机制上。
来自 这份数据（覆盖 1,255 个团队、超过 10,000 名开发者）显示：高 AI 采用率的团队完成任务量多 21%，合并 pull request 多 98%，但 PR review 时间也增加了 91%。
[
现在有两件事在指数级增长：变更的数量和变更的体量。人类已经不可能“消费”这么多代码。更糟的是，开发者普遍反映：review AI 生成代码，比 review 同事写的代码更费劲。结果就是，团队产出更多代码，却也花更多时间 review。
靠手工 code review，我们不可能赢下这场仗。code review 是一个历史遗留的审批闸门，它已经不匹配当下工作的形态。
AI code review 工具只是在帮我们争取时间。如果代码由 AI 写、也由 AI 审，那我们为什么还需要一个漂亮的 review UI 来展示这些？AI code review 当然有价值，但它会左移到开发周期更前面。没必要在 review 周期之间浪费 CI 资源、还要管理版本流转。
在“人写代码”的时代，PR 之后的 review 合情合理，因为需要“新鲜视角”。但当代码由 Agent 生成时，“新鲜视角”往往只是另一个有同类盲点的 Agent。真正有价值的是迭代闭环，而不是审批闸门。
我们都知道 Agent 还不总是可靠。人类很容易这样想：我曾抓到 AI 犯过蠢，所以我必须永远盯着它。这种直觉在“可手工验证”的时代没问题，但在当前规模下已经不现实，而且只会越来越糟。
答案是把人类检查点前移。你如果觉得“不 review 代码”很可怕，请记住：软件开发中的检查点不是第一次迁移。我们曾从瀑布式签字转向持续集成，现在也可以再次迁移。
Spec-driven development 正在成为与 AI 协作的主流方式。人类应该 review 的是 spec、plan、constraints 和 acceptance criteria，而不是 500 行 diff。
在这个新范式下，Spec 成为事实来源（source of truth）。代码只是 spec 的产物。你不需要 review 代码本身；你 review 的是步骤、verification rules，以及代码必须履行的契约。
Human-in-the-loop 的审批重心将从“你写得对不对？”转向“我们是不是在正确约束下解决正确的问题？”最有价值的人类判断，发生在第一行代码生成之前，而不是之后。
在我们真正停止阅读代码之前，我们到底需要达到多高的心理舒适度？
用规则来表达：
代码不应由人类编写
代码不应由人类评审
LLM 并不擅长严格执行指令，它们经常偏离。而且它们在自我验证上也不可靠——即使代码已经“起火”，它也会自信地告诉你一切正常。解决方式不是让 LLM 去“判断是否正确”，而是让它写出“可验证的脚本”。把重心从主观判断转为可验证产物。
信任是分层的。这就是 Swiss-cheese model：没有任何单一闸门能挡住一切。你要叠加多个不完美过滤层，直到漏洞不再对齐。所以问题是：我们还能把审批闸门放在哪里？
[
不要只让一个 Agent 去“做对”，而是让三个 Agent 用不同方式尝试，再选最优结果。让它们竞争。在软件工程史上，“保留选项”的成本从未这么低。
选择过程也不必手工完成。你可以按“谁通过更多验证步骤”“谁产生更小 diff”“谁没有引入新依赖”来排序输出。竞争会产生单次尝试得不到的信号。
必须有确定性的方法来验证工作结果：tests、type checks、contract verification——这些不靠观点，只看事实。
与其问 LLM “这次成功了吗？”，不如先定义能产出一系列 pass/fail 结果的验证步骤。Agent 无法和失败的测试谈判：要么满足规范，要么不满足。
这些护栏本身也可以分层定义：
-
Coding guidelines - 可以通过定制 linter 落地
-
Organization-wide invariants - 组织级不可妥协项，例如禁止硬编码 credentials、API keys 或 tokens
-
Domain Contracts - 针对某个框架、服务或代码库局部的约束，例如支付域：所有金额必须使用 Money type
-
Acceptance Criteria - 任务级验收标准
验证步骤应该在写代码之前定义，而不是事后“发明”出来去佐证既有实现。若 Agent 同时写代码又写测试，你只是把问题平移了——你仍在相信 Agent 会测对东西。验证标准必须来自 spec，而不是来自实现。
那人类的价值在哪里？在上游，定义“成功到底是什么样”。
这也是 Behavior-Driven Development 重新变得关键的原因。BDD 一直都是好思路：用自然语言写行为规范，再把规范自动化为测试。它过去没能全面普及，是因为当时你既要写 spec 又要写代码，spec 看起来像额外负担。
但有了 Agent，等式反过来了。spec 不是额外工作，而是核心产物。你写下：
[
由 Agent 实现，由 BDD framework 验证。除非失败，你根本不需要读实现细节。
这才是人类擅长的事：定义“正确”意味着什么，编码业务逻辑与边界条件，思考可能出错之处。Agent 负责把意图翻译成代码。BDD spec 成为你的验证层——确定性、自动化、且在第一行代码写出前就已定义。
由人类编写 Acceptance criteria，由机器验证。这才是真正关键的闸门。
这个 Agent 能触达什么？什么操作必须升级审批？这些都应是架构决策，而非事后补丁。
大多数 Agent framework 把权限当成“全有或全无”：要么给 shell access，要么不给。但粒度至关重要。一个修 utility function bug 的 Agent，不需要访问你的基础设施配置。一个写测试的 Agent，也不需要修改 CI pipeline。
作用域应尽可能小，同时又保证 Agent 能完成有价值的工作。如果任务是“修复 utils/dates.py 的日期解析 bug”，那 Agent 的文件系统权限就应只限于该文件及其测试文件。不是整个代码库，不是“src/ 和 tests/”，而是这次任务真正相关的文件。
升级触发器同样重要。某些模式——如触及 auth 逻辑、修改数据库 schema、引入新依赖——无论 Agent 自信度多高，都应自动触发人类 review。
职责分离：一个 Agent 负责实现，另一个 Agent 负责验证。它们彼此不信任，而这正是设计目的。
这其实是老原则：为什么 QA 团队不该向工程经理汇报，为什么写代码的人不该是唯一 review 代码的人。
在 Agent 时代，你可以把这种分离直接固化到架构里。coding Agent 不知道 verification Agent 具体会查什么；verification Agent 也无权修改代码来降低自己的验证难度。它们是“设计上的对抗关系”。
还可以再进一步：加入第三个 Agent，专门尝试攻破第一个 Agent 的产物，重点打边界情况与失效模式。Red team、blue team——但自动化，并且对每次变更都运行。
Agentic system 的激励很简单：给我一个任务，我能否完成？我能否让任务提出者满意？Agent 的“成功”天然不会由长期准确性或业务目标来驱动。
把这些约束编码进去，是我们的工作。
当代码由 Agent 生成、由 Agent 阅读时，“好代码”的标准会更趋于统一。对新代码库而言，你需要给出的指导会越来越少，因为默认行为会越来越一致。
未来会是：快速 ship、全面观测、更快回滚。
而不是：慢速 review、照样漏 bug、再去生产环境救火。
我们不可能比机器读得更多。我们必须比它们想得更深——在上游、在真正决定成败的地方。
归根到底，如果 Agent 已经能很好地处理代码，那我们自己能不能读懂它，究竟还重要吗？
Ankit Jain 是 Aviator 的创始人兼 CEO，正在构建面向 AI-native 工程团队的基础设施。Aviator 平台帮助现代组织在保持高工程标准的同时提升 AI 采用率。
