本文来自微信公众号： InfoQ ，作者：Tina
7月3日，HashiCorp联合创始人、Ghostty作者Mitchell Hashimoto发了一条推文，“I read the code”，获得近83万次浏览。
20天后，Robert C.Martin，也就是《代码整洁之道》的作者、写了六十年代码的Uncle Bob，给出了一个截然相反的答案：“我完全不去读Agent写出来的任何代码。”
两条推文，两位世界级开发者，两种完全相反的做法，把整个开发者圈卷进了一场持续数周的混战。
1“我读代码”：理解仍然是工程责任的一部分
AI写出来的代码，Mitchell Hashimoto会自己读。
当时Anthropic的Fable、GPT-5.6等新模型刚刚发布，编程智能体的能力不断提升，Vibe Coding的拥护者正觉得，“跟着感觉写代码”这条路已经得到了新一轮验证。于是，原本只是在陈述个人工作习惯的三个词，很快被解读成了对Vibe Coding的公开反驳。
那么，AI写出来的代码，人到底还要不要读？
有人认为，读代码是开发者不可放弃的职业底线。只要代码最终由你提交、部署和维护，你就必须理解它在做什么，也必须有能力在出错时接手调试。有人则认为，逐行阅读正在变成一种刻舟求剑的工作方式：AI生成代码的速度早已超过人类检查代码的速度，假如仍然要求开发者逐行读完，刚刚被释放出来的生产力，很快又会被人工审查的速度重新限制住。
分布式系统工程师、《分布式系统可观测性》作者Cindy Sridharan给出了一个很强硬的立场：“每当我听见有人说，‘代码全是Claude写的，我不知道它是怎么工作的’，我就会认定，这个人根本没有能力调试这些代码。没什么好争的。你调试不了它，就没资格说自己拥有它、掌控它。而一套代码连你自己都掌控不了，那么任何真正看重可靠性和稳定性的人，都不可能信任你这样的供应商。”
在她看来，能否调试代码，是开发者是否真正掌控代码的一条明确界线。她经常看到开发者直接采用Claude生成的错误修复方案，而一旦遇到稍微棘手的Bug，他们往往需要反复尝试好几轮，才能真正定位并解决问题。
开源软件工程师Christine Lemmer-Webber则把这种现象称为“Vibe滑坡”：一开始，人们只是谨慎地借助AI写代码，也会认真做代码审查；但随着速度越来越快，审查会一点点被放松，最后一路滑向完全凭感觉写代码的Vibe Coding。她认为，这个过程很多时候并非开发者主动做出的选择，更像是顺着惯性越滑越快。
“人们对这段旅程的掌控力，远不如他们自认为的那样强大。”
在追求速度的过程中，每一个环节的监督都可能被进一步削弱，现实中也很难找到一个真正有效的刹车点。更麻烦的是，即便经验丰富的程序员，也未必能发现一个只有100行代码的程序里所有的Bug。如今，大语言模型一次就能生成远超100行的代码，人类想要完整审查这些不断膨胀的输出，也会变得越来越困难。
2“我不读”：Uncle Bob用约束取代逐行审查
20天后，另一个更具分量的声音加入了这场争论。
Robert C.Martin，也就是开发者熟悉的Uncle Bob，《代码整洁之道》的作者。从20世纪60年代末开始编程，至今已经从事编程超过60年。面对“你是否阅读AI生成的代码”这个问题，他的回答很干脆：“我不读。”
起因是另一位开发者Ori Pomerantz在X上发了一段话：“我正试着让Claude帮我写点东西，但我总觉得让AI直接编辑我的文件不太舒服。有人有同感吗？如果我要对代码负责，我就必须理解它，哪怕只是心理上需要这么做。”
他还补了一句：“1983年开始编程，算老了吗？”
Uncle Bob回复说，自己开始写代码的时间比Pomerantz还早得多，从事编程已经超过60年了，但他现在采取的策略，是“完全不去读Agent写出来的任何代码”。
他的做法是给Agent设置极其严格的约束，包括单元测试、Gherkin测试、QA流程、质量指标、变异测试、测试覆盖率，以及大量其他机制。当Agent生成的代码通过这些约束和测试的重重考验后，他便会对最终结果抱有“很高的信心”。
不过，Uncle Bob的回复并没有结束这场争论，反而招来了更多追问。他这条推文也因此获得了超过480万次浏览，远远超过Mitchell Hashimoto那条“I read the code”。
其中一个提问是：如果真正保障质量的是那些约束，那么谁来保证约束本身是可靠的？
有开发者追问道，如果单元测试、质量指标和检查工具承担了主要工作，那么这些约束的质量，岂不是成了真正的工程难题？Uncle Bob的回答是，他同样让智能体去编写检查约束的工具。这些工具是确定性的，规模相对较小，可以用来检查代码质量、测试覆盖率，或者对代码进行修改，再观察是否能暴露错误。
随即又来了一层追问：那你会审查这些检查工具的代码吗？
Uncle Bob依然回答：“不会，还是同样的流程。”这些工具也会被大量单元测试和验收测试包围。对他来说，判断工具是否可信的依据仍然是它能否持续通过验证、稳定完成任务。
这听起来近乎无限递归：智能体写代码，智能体写测试，智能体再写工具检查测试与代码。Uncle Bob的做法，是用变异测试、QA流程、Gherkin测试等方式，把测试体系做得非常严密。智能体需要修改的并不只是一项测试，而是一大批相互关联的测试，这会显著增加篡改测试来蒙混过关的难度。同时，他也会亲自检查Gherkin验收测试和QA流程，根据任务的关键程度进行全面审核或抽查，并定期做最终的人工测试。
有意思的是，他这套思路很快被其他开发者做成了可以直接使用的工具。开发者AmazingAng推出了一个名为old-coder的开源Skill，核心理念直接取自Uncle Bob：不要逐行阅读Agent生成的代码，而是让代码先闯过一整套验证关卡。
来源：https://github.com/AmazingAng/old-coder/tree/main
还有人问，测试或许可以保证产品功能符合预期，但代码本身的质量怎么办？既然如今修改代码已经如此便宜、容易，代码是否整洁、结构是否清晰，还像过去那样重要吗？
在这个问题上，Uncle Bob认为“代码质量依然重要，而且重要得多”。混乱的代码不仅会拖慢人，也会拖慢Agent。他见过Agent被自己制造的混乱结构困住，来回折腾却始终无法解决问题，最后仍然需要他亲自介入，把这些乱麻重新理顺。
因此，他会对函数长度、圈复杂度和测试覆盖率设置极其严格的限制，尽量从一开始就阻止智能体制造难以维护的结构。在他看来，这些约束能够让智能体持续顺畅地推进任务。
3读代码是旧世界的习惯？！
互联网上的技术争论，很容易被简化成非黑即白的两派：读代码还是不读？立场越极端，声音越大，中间那些复杂的考量反而被淹没。围绕AI代码吵了这么久，背后其实是一个更根本的问题：你认为自己写的代码究竟有多重要？
如果把代码的重要性想象成一条光谱：一端是粗制滥造的个人项目，另一端是支撑关键基础设施、医疗设备等不能轻易出错的系统。后者每一行代码当然都很重要，毕竟一旦弄错，真可能造成严重后果。但大多数开发者生活在两端之间，既容易高估自己代码的重要性，也没有充分意识到，今天已经可以生成大量“不那么重要”的代码。
t3.gg创始人Theo的观点是：对绝大多数工程师来说，目前阅读的代码比例很可能太高了，但生成的代码还远远不够多：我们应该从AI生成的代码中获得尽可能多的价值。
如果你真的在编写极其重要的代码，反而更应该生成大量一次性代码，去测试那些真正不能出错的部分。这个思路与Uncle Bob用约束和验证体系替代逐行理解的做法，本质上相通。
在那个写代码成本很高、所有合并代码都很重要的时代，我们必须花时间阅读其他人大量编写的代码。为了验证一行核心代码是否正确而写1000行测试代码，完全不划算。但现在，情况已经变了，代码便宜多了。让AI瞬间生成1000行测试代码，成本近乎为零。你可以为每一行生产环境的核心代码生成100行、1000行、甚至1万行验证代码，用来做压力测试、做变异测试、做专门的运行时分析器。
定制lint规则？过去一辈子只写过一两条，现在随时生成。一次性调试工具？以前只会依赖浏览器自带的工具，现在可以构建专属的调试器和编译器Hook。过去做压力测试需要协调人员和环境，现在可以让智能体直接启动云资源，反复探测系统极限。
当代码的生成成本下降后，“代码”便不只指最终合并进主干的产品代码。它还可以是一次性实验、临时脚本、边缘情况测试、替代实现，或者为了回答某个问题而存在几个小时的工具。
假设一名工程师每天仍然手写并逐行验证80行核心代码，这部分标准完全不必降低。但在此之外，他还可以让AI生成800行甚至8000行代码，用来验证那80行。这些代码不会进入产品，却能测试更多边缘情况，暴露隐藏问题，提升核心代码的可信度。
没有人会主张把心脏起搏器里的代码交给AI随意生成。但如果一套系统真的重要到不能出错，那么为它建立更庞大的验证体系，也应该同样值得。关键代码越重要，围绕它生成的测试、模拟和验证代码就应该越多。
可以把代码分成四个层级。最顶层是纯粹的垃圾代码，写出来只是为了整理文件或回答某个一次性问题，看一眼都觉得被冒犯；第二层是希望它能正常工作，出了问题会很烦；第三层是它最好别出问题，否则可能会被解雇；最底层是它一旦出错，可能有人死亡。
过去，手写代码的成本太高，以至于大家几乎把所有时间都花在最底层和第三层，根本没有余力去上面两层做探索。而现在，AI让上面两层的代码变得几乎免费——你应该大量进入这些上层区域，用廉价的代码去验证昂贵的代码，而不是用“所有代码都很重要”这个理由把自己锁死在底层。
就是Uncle Bob那套“无限递归”测试策略的延伸：用大量廉价代码构建一个测试金字塔，在底部堆满垃圾，用这座塔去保护塔尖上那一小撮真正不能出错的东西。
参考链接：
https://x.com/unclebobmartin/status/2080257779395154409
https://dustycloud.org/blog/faulty-towers-vibe-sickness-and-the-vibe-bobsled/
https://www.youtube.com/watch?v=434cG4g5KLE
声明：本文为InfoQ整理，不代表平台观点，也不构成投资建议，未经许可禁止转载。