AI Agent 写代码后，人类该逐行审查，还是用测试与流程接管信任？
原文标题：世界级编程大师：AI写的代码，我一行都不看
原文作者：机器之心
冷月清谈：
不少开发者对此持保留态度：只要最终要对代码负责，就需要理解实现；测试通过也不能证明需求完整、设计正确或没有隐藏问题。还有人担心 Agent 可能修改测试、遗漏要求，甚至生成“看起来通过”的假象。
更折中的观点认为，问题不再是“审不审”，而是“审什么、审到什么程度”。Uncle Bob 后续也补充，他并非完全放弃人工把关，而是减少对底层实现和单元测试的逐行检查，保留对验收测试、QA 流程、关键功能和最终产品表现的人工验证。文章最终引出一个更大的问题：当 AI 让重写和修改代码成本大幅下降，代码可读性和传统代码质量标准是否仍像过去一样重要。
怜星夜思：
2、测试、覆盖率、QA 流程，真的能替代代码审查吗？
3、如果 AI 可以随时重写模块，代码可读性还重要吗？
原文内容
有了大模型后，你以为在驾驭 AI，结果半小时后发现，根本没自己什么事了。
Agent 会自己拆解需求、修改文件、补充单元测试、运行代码，再根据报错继续迭代。你原本只是想让它写一个函数，回过神来，它已经改动了十几个文件，顺手完成了重构，甚至开始规划下一阶段的架构。
等等，这些由 AI 写出的代码，我们还要不要逐行阅读？
这个问题值得深思，近日 X 平台上就有不少开发者围绕这个问题争论。
有人认为，只要最终要对代码负责，开发者就必须理解每一行代码。另一方则认为，当 AI Agent 的代码生成速度远远超过人类阅读速度，继续沿用传统代码审查方式，最终只会把生产力重新压回人类的处理上限。
随后，《代码整洁之道》作者 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 随后进一步解释了自己的审查边界。
他的 Agent 会负责编写单元测试，这部分内容通常不会经过人工审查。Agent 也会生成 Gherkin 验收测试和 QA 流程，而这两类内容仍由他亲自检查。具体审查强度则取决于项目风险：关键功能会被全面审查，普通功能可能只做抽查。此外，他还会定期进行最终的人工测试，直接验证产品在真实使用中的表现。
换句话说，Uncle Bob 并没有把整个质量控制过程交给 Agent。人类减少了对底层实现和单元测试的逐行检查，却仍然掌握着验收标准、QA 流程和最终验证。
有网友认为，在 AI 编程环境下，代码质量的重要性可能正在下降。只要实现没有明显的性能问题，功能可以正常运行，并且能够通过测试，或许就已经足够好。
你会审核 AI 写的代码吗？欢迎评论区留言。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com