AI 写的代码到底审不审？

Uncle Bob Martin 前几天在 X 上发了段话，我看完愣了几秒。

他说的「不审代码」，核心是把质量保障从事后肉眼审查前移到事前约束加自动化验证。我其实也在按照这个逻辑尝试和优化开发流程。

认同，但我做不到

AI 写代码是真的快。你让它写一个功能，可能半分钟吐完，你要花十分钟去看。它改一版，你又看十分钟。这个过程里你变成了瓶颈。而且说实话，大部分时候 AI 写的代码质量确实比我自己写得好。

所以不审代码这个方向，不是偷懒，是效率的必然。

但我现在的现实是，我还做不到。

企业项目：不敢放手

企业项目里我不敢放手。代码要上线跑生产环境，出了问题不是改一版那么简单。我们有测试团队，但测试团队兜不了所有问题的底。但我也在试着把一些检查项交给自动化，比如用 AI review 做第一道筛选，我看第二轮。这样至少不用从零开始看每一行。

小项目：Agent 互审

小项目我走的是另一条路，基本纯 vibe coding。但我不是完全裸奔。我搭了一套 Agent 互审机制，先让一个 agent 扫描所有改动过的代码，出问题清单。然后换另一个 agent 去验证，不是复读第一个的结果，是它自己跑、自己看、自己判断。最后综合两边产出修复方案，执行修复。

这本质上是把「人肉审查」替换成了「Agent 互相审查」。方向跟 Uncle Bob 是一致的，我没看代码，但 agent 看了，还是两个 agent 交叉验证。

差距在哪

但差距也很明显。Uncle Bob 的约束体系是正儿八经的工程化，变异测试、覆盖率门禁、CI 流水线，整套东西跑完他才有信心。我这套，说到底就是找两个 agent 对了一遍，约束力差得远。能抓到显而易见的错误，但盖不住那些隐性的设计问题。

而且还有个让我不太踏实的地方，两个 agent 背后都是大模型，它们可能共享同样的盲区。这就是 Uncle Bob 说的变异测试和覆盖率的价值，不是「让 AI 检查」，而是给代码施加结构性的压力，逼代码自己证明自己是对的。我这套还做不到。

务实的选择

我不觉得不审代码是态度问题，它是工程基础设施问题。你需要一套足够完备的验证体系包围你的 agent，这个体系现在还不够开箱即用。大厂一定在搞成熟方案，我一边迭代自己的，一边保持观望。这大概是最务实的策略。