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

传统代码评审为何在AI时代失效

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

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

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

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

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

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

Uncle Bob 的7层质量门禁体系

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

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

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

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

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

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

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

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

自动门禁能替代人眼吗？

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

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

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

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

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

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

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

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

能从中学到什么

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

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

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

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

工程师角色的重新定义

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

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

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

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

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

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

总结

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

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

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

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

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