AI 写的代码要不要读？先问它有权改变什么

最近，一场关于 AI 写的代码到底要不要读的争论引起了我的好奇。

Mitchell Hashimoto 的回答只有四个词：“I read the code.”

当时，他刚介绍了一套多模型协作流程：一个模型做计划，一个写代码，再由另一个判断结果。但最后的质量关，仍然是他自己读源码。

他后来把边界说得更清楚：代码只留在自己手里是一回事，交给别人维护又是另一回事。

Uncle Bob 的做法几乎相反。他不读 agent 生成的实现，而是把精力放到规格、单元测试、Gherkin 验收测试、变异测试、质量指标、QA 和最终验证上。他对工程师角色的定义也很直接：“I am the engineer because I am accountable.”

讨论很快呈现出两种主张。

一派认为，不读源码，出了问题怎么维护、怎么排查？另一派反问，如果每一行都要重新读一遍，AI 带来的效率在哪里？

两边都有道理。Mitchell 把人的理解放在实现里；Uncle Bob 把大量判断前移到规格和证据中。他们都认为结果必须由人负责，真正的分歧是：承担责任，到底需要多深的源码理解？

这不是一个纯粹的哲学问题。它也是我工作中面对的实际取舍。

一进入关键系统，问题就变了

我不会读完 AI 生成的每一行代码。

AI 让实现变快了，但人的注意力没有同步增加。真正的挑战，是哪些代码可以只看结果，哪些必须理解到底。

如果是私有原型、一次性分析，或者随时可以丢弃的脚本，我通常看结果、跑测试，确认没有明显问题就继续。影响范围有限，恢复也很简单。

但只要 AI 动到关键系统或 system of record（权威记录系统），我的审查方式就会改变。

关键系统之所以重要，是因为失败后果严重。System of record 之所以重要，是因为其他人和系统会把它的数据当成事实。两者经常重叠，但风险来源不同。

五行权限判断、余额更新、客户状态修改或数据迁移，可能比一千行原型界面更值得深读。Diff 大小，并不能代表后果大小。

同一段数据清洗逻辑，如果只处理复制出来的 CSV，结果错了可以丢掉重来；如果它直接写入 system of record，错误就可能进入报表、权限、客户沟通和自动流程。

回滚代码或许能阻止下一次错误写入，却未必能恢复已经被改坏的数据、下游副本、审计记录，以及基于错误状态做出的决定。

我没有一个戏剧性的事故故事。这恰恰是重点：边界应该设在事故发生之前。

我的观点：审查深度应该跟着权威走

“AI 写的代码要不要读？”这个问题问错了。

我真正关心的是：这段代码有权改变什么？

审查深度不应该由谁写了代码、改了多少行决定，而应该由这项修改的权威、后果由谁承担，以及出错后能否发现和恢复来决定。

读源码和跑测试都重要，但它们会以不同方式失效。阅读能帮助人建立维护系统所需的心智模型，却不能证明代码正确；测试可以反复检查已经写进去的预期，却不能保证我们一开始就问对了问题。如果实现、测试和审查都来自同一份 AI context，它们还可能重复同一个错误假设。

少读源码还有一项代价：团队可能逐渐失去共同的系统模型。所以，进入生产和关键路径的修改，不能只靠测试证据。

所以，我把审查分成四层：

• 结果： 私有、可丢弃、容易恢复的工作，确认结果即可。
• 证据： 一旦有人或流程依赖输出，就要检查测试、日志、CI，以及采用不同方法或 context 的验证。
• 系统模型： 修改进入生产或影响权威状态，必须有人能解释数据流、业务不变量、错误传播、可观测性和恢复方案。
• 关键路径： 涉及权限、资金、隐私、删除、迁移、安全或 system-of-record 写入，必须理解相关源码路径。

这四层是累积的。读过关键路径不能代替测试，测试全绿也不能代替对状态变化的理解。

对我来说，system-of-record 修改最低从“系统模型”开始；关键写入路径通常必须下沉到源码。

我的发布规则很简单：没有明确负责人，没有审过关键写入路径，没有写清业务不变量，也没有可信的对账与恢复方案，就不发布。

真正的 ownership，是对状态变化负责

AI 降低了实现成本，却没有降低后果的成本。

我们不可能用同样强度读完每一行生成代码，也不能让没人理解的代码变成下一个人的问题。真正需要决定的，是人的理解必须在哪些地方最深。

我不必理解 AI 写出的每一行。但只要它能够改写业务认定的事实，或者制造业务无法接受的后果，就必须有人说得清：状态如何变化、哪些不变量必须成立、它可能怎样失败，以及如何恢复事实。

接受一项 AI 生成的修改之前，我现在会问：如果所有测试都是绿的，但现实仍然错了，谁能解释原因，并把事实恢复回来？