有了大模型之后，你本来觉得自己是在驯服 AI，结果半小时不到，就发现——好像没自己什么事了。

Agent 开始自动拆解需求、修改文件、补充单元测试、运行代码，然后根据报错再迭代。你原本只想让它写个函数，转头一看，它已经改了十几个文件，顺手完成了重构，甚至已经在规划下一阶段的架构了。

AI 写的代码，还要逐行读吗？

那么问题来了：这些 AI 写的代码，我们到底还要不要逐行读一遍？

这个问题最近在 X 平台上引起了不小的争论。有开发者认为，只要最终要对代码负责，就必须理解每一行；另一派则觉得，当 AI Agent 的代码生成速度已经远远超过人类阅读速度，继续沿用传统的代码审查方式，等于把生产力重新压回人类处理的上限。

Uncle Bob 的激进策略：一行都不读

随后，《代码整洁之道》的作者 Robert C. Martin——也就是开发者熟悉的 Uncle Bob——给出了一个更激进的答案：

他现在的策略，是完全不去读 Agent 写出来的代码。

Robert C. Martin 是资深软件工程师，从 20 世纪 60 年代末就开始写代码，拥有超过半个世纪的开发经验。他最广为人知的身份是《代码整洁之道》（Clean Code）的作者，还出版了《程序员的职业素养》《架构整洁之道》等著作。他长期倡导测试驱动开发、代码重构、模块化设计与软件专业主义，这些观点影响了几代程序员对代码质量和软件架构的理解。

他的原话是这样的：

「我从 20 世纪 60 年代末就开始写代码了。

目前的策略，是完全不去阅读 Agent 写出的任何代码。只有这样，才能真正利用它们带来的生产力提升。

我的做法，是在 Agent 周围设置极其严格的约束，包括单元测试、Gherkin 测试、QA 流程、质量指标、变异测试、测试覆盖率，以及大量其他检查机制。

最终，我对它们生成的代码有很高的信心，因为这些代码必须通过我设置的重重约束与测试。」

一种全新的信任方式

在 Uncle Bob 看来，要真正利用 AI Agent 的生产力，就不能继续把人工阅读作为每一段代码进入生产环境前的必经关卡。

这是一种完全不同的信任方式。

传统代码审查依赖开发者的经验——阅读实现、寻找漏洞、判断设计是否合理。而新的方式更接近工业质量控制：预先定义规格、约束、指标和验收条件，再通过自动化系统持续验证结果。这背后，其实是对质量管控思路的底层重构。

真的不需要审核 AI 写的代码了吗？

对很多开发者来说，这套方法很难接受。

一位程序员在 X 上写道，自己正在尝试用 Claude 编程，但始终不放心让它直接修改文件。

「只要我要对这段代码负责，我就必须理解它。哪怕没有其他原因，单从心理上说，我也需要做到这一点。」

这种不安并不难理解。当开发者不再阅读代码，责任似乎就失去了最直观的落脚点。

质疑者进一步指出，仅靠测试和约束，未必足以建立对 AI 代码的信任。

• AI 已经多次表现出指令遵循并不稳定。 既然如此，凭什么相信它会始终待在预设的护栏之内？
• 如果 Agent 擅自修改测试，让测试结果适配自己的实现，或者制造出测试通过的假象，人类又该如何察觉？

更现实的问题是，测试通过、QA 通过，也不代表软件没有 Bug。传统开发中，人类同样经常遇到这种情况：最初的需求理解存在偏差，关键假设后来被证明是错误的，甚至整个技术方向都需要推倒重来。进入 AI 编程时代后，这类问题不会自动消失，反而可能因为代码生成速度更快、规模更大而更加难以发现。

这也引出了一个更深层的担忧：我们是否能够接受这样一种未来——软件可以稳定通过所有测试，但没有人能够真正说清楚它究竟做了什么？ 测试只能证明程序满足了被写进测试的条件，却无法证明这些条件本身就是完整、正确的。

两个极端之间的中间路线

也有开发者认为，问题的答案或许位于两个极端之间。

在他看来，逐行阅读所有依赖代码，未必值得投入如此高的时间成本；但完全放弃代码审查，同样过于激进。Uncle Bob 并没有忽视代码质量，他只是把质量控制的重心转移到了自动化测试和指标体系上——既验证功能需求，也检查性能、复杂度、依赖关系等非功能性要求。

真正值得追问的是，这套流程在实际运行中，是否仍然需要保留一定程度的代码审查。

这位开发者表示，按照自己 25 年的从业经验，答案依然是肯定的。即使规格已经定义得非常清楚，前沿模型也经常会忽略部分要求。它们会为暂时跳过某项任务寻找理由，承诺稍后处理，随后又将其遗忘——表现得和人类开发者颇为相似。

因此，无论面对人类还是 AI，代码审查可能仍然是发现遗漏、校验真实实现、掌握项目状态的重要手段。问题或许已经从要不要审查代码，转向了哪些代码必须审、审查到什么程度，以及哪些环节可以交给自动化系统。

代码质量还像过去一样重要吗？

还有网友把问题继续向前推了一步：当 AI 让代码的生成和修改成本大幅下降，代码本身的质量，还像过去一样重要吗？

过去，糟糕的代码意味着高昂的维护成本。开发者需要花费大量时间理解逻辑、定位问题和完成重构。但在 Agent 可以随时重写模块、补充测试甚至重新实现功能的情况下，代码是否足够优雅、是否便于人类阅读，似乎正在变得没那么关键。

Uncle Bob 的实际审查边界

Uncle Bob 随后进一步解释了自己的审查边界。

• Agent 负责编写单元测试，这部分内容通常不会经过人工审查。
• Agent 也会生成 Gherkin 验收测试和 QA 流程，而这两类内容仍由他亲自检查。
• 具体审查强度则取决于项目风险：关键功能会被全面审查，普通功能可能只做抽查。
• 此外，他还会定期进行最终的人工测试，直接验证产品在真实使用中的表现。

换句话说，Uncle Bob 并没有把整个质量控制过程交给 Agent。人类减少了对底层实现和单元测试的逐行检查，却仍然掌握着验收标准、QA 流程和最终验证。

有网友认为，在 AI 编程环境下，代码质量的重要性可能正在下降。只要实现没有明显的性能问题，功能可以正常运行，并且能够通过测试，或许就已经足够好。