编程界新分水岭：Uncle Bob说"绝不读AI写的代码"，Hashimoto却说他"逐行阅读

7 月 3 日，HashiCorp 联合创始人、Ghostty 作者 Mitchell Hashimoto 发了一条推文——"I read the code"（我读代码），获得近 83 万次浏览。20 天后，Robert C. Martin，也就是《代码整洁之道》的作者、写了六十年代码的 Uncle Bob，给出了一个截然相反的答案："我完全不去读 Agent 写出来的任何代码。"

两条推文，两位世界级开发者，两种完全相反的做法，把整个开发者圈卷进了一场持续数周的混战。

文章题图：Uncle Bob 与 Hashimoto 的对立

一、"我读代码"：理解仍然是工程责任的一部分

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 行的代码，人类想要完整审查这些不断膨胀的输出，会变得越来越困难。

二、"我不读"：Uncle Bob 用约束取代逐行审查

20 天后，另一个更具分量的声音加入了这场争论。

Robert C. Martin，从 20 世纪 60 年代末开始编程，至今已从事编程超过 60 年。面对"你是否阅读 AI 生成的代码"这个问题，他的回答很干脆："我不读。"

起因是开发者 Ori Pomerantz 在 X 上发的一段话："我正试着让 Claude 帮我写点东西，但我总觉得让 AI 直接编辑我的文件不太舒服。如果我要对代码负责，我就必须理解它，哪怕只是心理上需要这么做。"他还补了一句："1983 年开始编程，算老了吗？"

Uncle Bob 回复说，自己开始写代码的时间比 Pomerantz 还早得多，但他现在采取的策略，是"完全不去读 Agent 写出来的任何代码"。他的做法是给 Agent 设置极其严格的约束，包括单元测试、Gherkin 测试、QA 流程、质量指标、变异测试、测试覆盖率，以及大量其他机制。当 Agent 生成的代码通过这些约束和测试的重重考验后，他便会对最终结果抱有"很高的信心"。

不过，这条推文反而招来了更多追问（获得超过 480 万次浏览，远超 Hashimoto 那条）：

追问一：如果真正保障质量的是那些约束，那么谁来保证约束本身是可靠的？

Uncle Bob 的回答是，他同样让智能体去编写检查约束的工具。这些工具是确定性的，规模相对较小，可以用来检查代码质量、测试覆盖率，或对代码进行修改再观察是否暴露错误。

追问二：那你会审查这些检查工具的代码吗？

Uncle Bob 依然回答："不会，还是同样的流程。"这些工具也会被大量单元测试和验收测试包围。判断工具是否可信的依据，仍然是它能否持续通过验证、稳定完成任务。

这听起来近乎无限递归：智能体写代码，智能体写测试，智能体再写工具检查测试与代码。Uncle Bob 的解法是用变异测试、QA 流程、Gherkin 测试等方式把测试体系做得非常严密——智能体需要修改的并不只是一项测试，而是一大批相互关联的测试，这会显著增加篡改测试蒙混过关的难度。同时他也会亲自检查 Gherkin 验收测试和 QA 流程，根据任务关键程度进行全面审核或抽查，并定期做最终的人工测试。

有意思的是，他这套思路很快被其他开发者做成了可以直接使用的工具。开发者 AmazingAng 推出了一个名为 old-coder 的开源 Skill，核心理念直接取自 Uncle Bob：不要逐行阅读 Agent 生成的代码，而是让代码先闯过一整套验证关卡。

old-coder 开源 Skill

来源：https://github.com/AmazingAng/old-coder/tree/main

追问三：代码本身的质量怎么办？

既然如今修改代码已经如此便宜、容易，代码是否整洁、结构是否清晰，还像过去那样重要吗？Uncle Bob 认为"代码质量依然重要，而且重要得多"。混乱的代码不仅会拖慢人，也会拖慢 Agent——他见过 Agent 被自己制造的混乱结构困住，来回折腾却始终无法解决问题，最后仍然需要他亲自介入理顺。因此他会对函数长度、圈复杂度和测试覆盖率设置极其严格的限制，尽量从一开始就阻止智能体制造难以维护的结构。

三、读代码是旧世界的习惯？

互联网上的技术争论，很容易被简化成非黑即白的两派：读代码还是不读？立场越极端，声音越大，中间那些复杂的考量反而被淹没。围绕 AI 代码吵了这么久，背后其实是一个更根本的问题：你认为自己写的代码究竟有多重要？

如果把代码的重要性想象成一条光谱：一端是粗制滥造的个人项目，另一端是支撑关键基础设施、医疗设备等不能轻易出错的系统。大多数开发者生活在两端之间，既容易高估自己代码的重要性，也没有充分意识到，今天已经可以生成大量"不那么重要"的代码。

t3.gg 创始人 Theo 的观点是：对绝大多数工程师来说，目前阅读的代码比例很可能太高了，但生成的代码还远远不够多。如果你真的在编写极其重要的代码，反而更应该生成大量一次性代码，去测试那些真正不能出错的部分。 这个思路与 Uncle Bob 用约束和验证体系替代逐行理解的做法，本质上相通。

在那个写代码成本很高、所有合并代码都很重要的时代，为验证一行核心代码而写 1000 行测试代码完全不划算。但现在情况变了，代码便宜多了。让 AI 瞬间生成 1000 行测试代码，成本近乎为零——你可以为每一行生产环境的核心代码生成 100 行、1000 行、甚至 1 万行验证代码，用来做压力测试、变异测试、专门的运行时分析器。定制 lint 规则、一次性调试工具、专属的调试器和编译器 Hook，过去一辈子才写一两条的东西，现在随时生成。

当代码的生成成本下降后，"代码"便不只指最终合并进主干的产品代码。它还可以是一次性实验、临时脚本、边缘情况测试、替代实现，或者为了回答某个问题而存在几个小时的工具。

文章给出了一个代码四层分级：

最顶层：纯粹的垃圾代码，写出来只是为了整理文件或回答某个一次性问题，看一眼都觉得被冒犯。
第二层：希望它能正常工作，出了问题会很烦。
第三层：它最好别出问题，否则可能会被解雇。
最底层：它一旦出错，可能有人死亡。

过去手写代码成本太高，大家几乎把所有时间都花在最底层和第三层，根本没有余力去上面两层做探索。而现在，AI 让上面两层的代码变得几乎免费——你应该大量进入这些上层区域，用廉价的代码去验证昂贵的代码，而不是用"所有代码都很重要"这个理由把自己锁死在底层。

这就是 Uncle Bob 那套"无限递归"测试策略的延伸：用大量廉价代码构建一个测试金字塔，在底部堆满"垃圾"，用这座塔去保护塔尖上那一小撮真正不能出错的东西。

我的看法

这场争论表面上是"读不读 AI 代码"，本质是当代码生成成本趋近于零时，工程责任的边界在哪里。两位大佬其实并没有真正对立——Hashimoto 读的是"自己要负责到底的核心代码"，Uncle Bob 不读的是"已被约束体系层层包裹的产物"，两者都在回答同一个问题：如何在不丧失掌控力的前提下，吃下 AI 带来的生产力红利。

作为前端工程师，我觉得有三点值得直接落地：

"Vibe 滑坡"在 UI 代码里更隐蔽。 组件代码看起来"能跑就行"，但状态管理、副作用、可访问性的退化往往要到生产事故才暴露。把 Storybook 交互测试、Playwright E2E、视觉回归纳入 Agent 的约束集，比逐行读它写的 JSX 更可持续——这正是 Uncle Bob 思路在前端的映射。
"无限递归"的真正价值不在递归，而在变异测试。 Uncle Bob 能放心不读，关键不是"AI 写了测试"，而是变异测试让"篡改测试蒙混过关"的成本极高。对 React 项目而言，把变异测试（如 Stryker）接入 CI，是让"约束本身可靠"的最务实一步；没有这一层，"AI 写测试 AI 验证"就只是自我安慰。
"用廉价代码验证昂贵代码"是 AI Coding 最被低估的范式。 与其让 Agent 直接改生产组件，不如让它为每个核心组件生成几十个边缘用例的测试组件、属性探查（property-based）脚本、甚至是临时搭建的调试沙盒。这些代码不进主干，却能逼出隐藏 bug。这比纠结"读不读"更接近问题的实质。

一句话总结：读不读代码不是原则问题，而是信任校准问题——你为 AI 搭建的验证金字塔有多密，你就能省下多少逐行阅读的时间。Uncle Bob 给的不是一个答案，而是一套可复用的工程框架。