上周刷 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 的逻辑拆开看就三层：
能自动化的，全部自动化——单元测试、集成测试、 Gherkin场景测试、变异测试，覆盖所有可量化的质量维度不能自动化的，用规则约束——架构边界、编码规范、设计原则，通过工具强制执行 剩下的，才是人的事——需求是否合理、架构是否合适、设计是否可扩展
所以他的做法，相当于把 review 从微观拉升到宏观。人的精力从『这行代码写得对不对』变成了『这套方案是否满足业务需求』。
4 四、能从中学到什么
这套思路不是 Uncle Bob 的发明，他只是在 AI 时代把这个理念推到了极致。不过每个团队现在就可以借鉴其中的做法。
第一条，用测试定义行为，而不是用代码定义行为。你不需要理解 AI 怎么写代码，但必须清楚系统应该有什么行为。用 Gherkin 或类似工具把业务行为写清楚，比读代码有用得多。
第二条，质量门禁必须可量化。『我觉得代码质量不错』——这句话在 AI 时代没有意义。需要有明确的通过标准：测试覆盖率、变异测试通过率、性能基线、安全扫描结果，每项都要有数字门槛。
第三条，人的精力要往策略层面走。逐行 review 是执行层的事，自动化工具有能力做。人的价值在于定义标准、设计架构、判断取舍——这些才是 AI 目前还做不到的。
5 五、更深一层：
过去 50 年，软件工程里最值钱的能力是『写代码』——代码写得越干净、越规范，水平越高。代码评审就是让有经验的人检查代码写得对不对、好不好。
但到了 AI 时代，代码生成能力不再是稀缺资源。
稀缺的是另一种东西：定义能力。
你能否清晰定义系统行为？你能否设计有效的质量门禁？你能否判断 AI 产出的方案是否存在架构风险？
Uncle Bob 的做法，等于在重新定义工程师的角色——从『代码的生产者』变成『质量的守门者』。
代码谁来写不重要，重要的是代码是否满足你定义的标准。
6 总结
回到开头那个问题：AI 写的代码，你敢不看就上线？
Uncle Bob 的答案是：不看，但要有比看更严格的约束。
他不是放弃质量，而是把质量的保证方式从『人审』升级为『自动门禁』。这背后不是什么高深理论，就是 60 年编程经验带来的务实判断——真正重要的不是代码本身，而是代码承载的行为和逻辑。
如果你也在纠结『要不要 review AI 代码』，不妨试试这个思路：先把业务行为写清楚，建好质量门禁，然后放手让 AI 跑。你只需要在关键节点上把关，而不是在每一行代码上较劲。
未来的工程师，更可能是一个规则的制定者，而不是逐行检查代码的质检员。
