传统代码评审为什么在AI时代失效？一个7层门禁方案

上周刷 X 的时候，看到 Uncle Bob（Robert C. Martin）发了一条推文，被一位开发者的提问戳中了痛点。

那位开发者的问题很直接：AI 生成的代码，如果我对最终质量负责，怎么可能不逐行读一遍就放行？

Uncle Bob 的回答，让我愣了几秒。

他说：『我现在根本不去读 AI 写的任何一行代码。逼自己读，就等于放弃了 AI 带来的生产力红利。』

他不是在赌运气。他后面跟了一长串条件：单元测试、Gherkin 验收测试、QA 流程、质量度量、变异测试、测试覆盖率……

他放弃的是『人眼看代码』这个动作，不是质量管控。

1一、传统代码评审，为什么在 

先还原一下那个典型场景。

你让 AI 生成了一个 PR，几百行代码。你深吸一口气，开始逐行 review。

逻辑对不对？边界情况有没有？安全漏洞呢？性能问题呢？

看完了，你觉得没问题，合入。然后发现线上出了问题——AI 写的代码本身没错，但因为你没注意到上下文，漏掉了一个业务分支。

更现实的问题是：AI 一天能生成 10 个 PR，你一个都 review 不过来。

Uncle Bob 看到的矛盾正在于此：逐行阅读 AI 代码的速度，远远跟不上 AI 生成代码的速度。

如果你坚持传统 CR 流程，无非两种结局： - 要么你累死，效率回到解放前 - 要么 review 流于形式，变成『看一眼就过』

所以这场争论的本质，其实是在问：用什么样的方式 review，才能跟得上 AI 的速度？

2二、

Uncle Bob 的解法很简单：把管控节点从『人看代码』前移到『规则约束代码』。

他搭建了一套自动化质量门禁体系，代码必须闯过所有关卡，才算合格。

第一层：单元测试。 老爷子写了几十年代码，TDD 是他最常用的习惯。AI 生成的代码，必须先过单元测试这一关。

第二层：Gherkin 验收测试。 这是整套体系中他反复强调的一层。Gherkin 是一种业务行为描述语言，用 Given-When-Then 的句式描述系统行为：

Scenario: 用户登录成功Given 用户打开登录页面When 输入正确账号密码，点击登录Then 跳转到首页

这套语言的特点在于：业务人员看得懂，程序也能自动执行。AI 把代码写成什么样他不管，只要 Gherkin 场景全部通过，业务行为就是对的。

第三到第七层QA 流程、质量度量指标、变异测试、测试覆盖率，加上一系列他长期积累的自动化校验规则。

这些关卡合在一起，构成了一条『质量闯关赛道』。AI 产出的代码必须跑通全部关卡，才能进入代码库。

3三、一个关键问题：自动门禁能替代人眼吗？

你可能会说：自动化测试能发现所有问题吗？架构设计问题、边界情况、安全漏洞，测试能覆盖吗？

是的，这确实是自动化测试的边界。

但这里有一个容易被忽略的事实：传统代码评审的价值，其实不在于『看代码』，而在于『发现问题』。

如果同样的问题可以通过自动化手段更高效、更全面地发现，为什么还要坚持人工看代码？

我见过一个团队，他们的 CR 流程是这样的：PR 上来，reviewer 先跑一遍测试，再跑一遍 lint，再看代码。结果每次 review 的前 15 分钟，都在做自动化工具已经能做的事。

Uncle Bob 的逻辑拆开看就三层：

1. 能自动化的，全部自动化——单元测试、集成测试、Gherkin 场景测试、变异测试，覆盖所有可量化的质量维度
2. 不能自动化的，用规则约束——架构边界、编码规范、设计原则，通过工具强制执行
3. 剩下的，才是人的事——需求是否合理、架构是否合适、设计是否可扩展

所以他的做法，相当于把 review 从微观拉升到宏观。人的精力从『这行代码写得对不对』变成了『这套方案是否满足业务需求』。

4四、能从中学到什么

这套思路不是 Uncle Bob 的发明，他只是在 AI 时代把这个理念推到了极致。不过每个团队现在就可以借鉴其中的做法。

第一条，用测试定义行为，而不是用代码定义行为。你不需要理解 AI 怎么写代码，但必须清楚系统应该有什么行为。用 Gherkin 或类似工具把业务行为写清楚，比读代码有用得多。

第二条，质量门禁必须可量化。『我觉得代码质量不错』——这句话在 AI 时代没有意义。需要有明确的通过标准：测试覆盖率、变异测试通过率、性能基线、安全扫描结果，每项都要有数字门槛。

第三条，人的精力要往策略层面走。逐行 review 是执行层的事，自动化工具有能力做。人的价值在于定义标准、设计架构、判断取舍——这些才是 AI 目前还做不到的。

5五、更深一层：

过去 50 年，软件工程里最值钱的能力是『写代码』——代码写得越干净、越规范，水平越高。代码评审就是让有经验的人检查代码写得对不对、好不好。

但到了 AI 时代，代码生成能力不再是稀缺资源。

稀缺的是另一种东西：定义能力。

你能否清晰定义系统行为？你能否设计有效的质量门禁？你能否判断 AI 产出的方案是否存在架构风险？

Uncle Bob 的做法，等于在重新定义工程师的角色——从『代码的生产者』变成『质量的守门者』。

代码谁来写不重要，重要的是代码是否满足你定义的标准。

6总结

回到开头那个问题：AI 写的代码，你敢不看就上线？

Uncle Bob 的答案是：不看，但要有比看更严格的约束。

他不是放弃质量，而是把质量的保证方式从『人审』升级为『自动门禁』。这背后不是什么高深理论，就是 60 年编程经验带来的务实判断——真正重要的不是代码本身，而是代码承载的行为和逻辑。

如果你也在纠结『要不要 review AI 代码』，不妨试试这个思路：先把业务行为写清楚，建好质量门禁，然后放手让 AI 跑。你只需要在关键节点上把关，而不是在每一行代码上较劲。

未来的工程师，更可能是一个规则的制定者，而不是逐行检查代码的质检员。

本文由 JOTO AI 智库整理。

原始来源：授权原文