⚡ 开发者 · 方法论之争
AI 写代码，人要不要读？两位顶级程序员给出截然相反的答案
7 月 23 日，Robert C. Martin（Uncle Bob）在 X 上抛出一句「我完全不读 Agent 写的任何代码」，引爆 480 万+ 次浏览。20 天前，HashiCorp 联合创始人 Mitchell Hashimoto 刚说完「我读代码」—— 两条推文，两种截然相反的做法，把开发者圈卷进了一场持续数周的混战。
综合公开信息整理•
2026-07-25•
全文约 4 分钟读完
#AI 编程
#代码审查
#Uncle Bob
#Vibe Coding
#开发者社区
🔥 480 万+
Uncle Bob 推文浏览量 · 7月23日
83 万+
Hashimoto 推文浏览量 · 7月3日
2 种
截然相反的答案 · 同一问题
⚡ 30 秒速览
- 核心冲突：Mitchell Hashimoto 说「我读 AI 写的每一行代码」；Uncle Bob 说「我一个字都不读」—— 两位世界级开发者给出完全相反的答案。
- Uncle Bob 的方法：用单元测试、Gherkin 测试、变异测试、QA 流程等严密约束体系替代逐行审查，让代码自己证明自己。
- 反方立场：Cindy Sridharan 等人认为，不读代码就等于放弃对代码的掌控，无法调试就不配拥有它。
- 中间地带：Theo 提出代码分层模型——用大量廉价 AI 代码去验证一小撮真正不能出错的核心代码，而非所有代码都同等重要。
- 深层信号：争论的本质不是「读不读」，而是软件工程的核心技能正在从「写代码」转向「设计验证系统」。
01两条推文，两种哲学
7 月 3 日，HashiCorp 联合创始人、Ghostty 作者 Mitchell Hashimoto 发了一条推文，只有四个词：「I read the code.」 获得近 83 万次浏览。当时正值 Anthropic Fable、GPT-5.6 等新模型发布，Vibe Coding 支持者正觉得「跟着感觉写代码」已经得到验证，这句话很快被解读为对 Vibe Coding 的公开反驳。
20 天后，另一个更具分量的声音加入了争论。Robert C. Martin—— 开发者熟悉的 Uncle Bob，《代码整洁之道》作者，写了 60 年代码的传奇人物 —— 面对同样的问题，给出了截然相反的答案。
Mitchell Hashimoto
「我读代码。」
理解仍然是工程责任的一部分。AI 写的代码，他会逐行阅读。
推文浏览量：83 万+
Uncle Bob（Robert C. Martin）
「我完全不读 Agent 写的任何代码。」
用严格的约束体系替代逐行审查，让测试和验证流程为代码质量负责。
推文浏览量：480 万+
注：两位都是从业超过 40 年的顶级开发者。Uncle Bob 从 20 世纪 60 年代末开始编程，Hashimoto 是 HashiCorp 联合创始人。他们的对立并非技术能力差异，而是对 AI 时代开发者角色的根本性不同理解。
02开发者站队：读，还是不读？
两条推文像两块磁铁，把整个开发者社区的观点吸了出来。没有中间地带，每个人都在被迫选择立场。
🔴 Cindy Sridharan 强硬派
- 「代码全是 Claude 写的，我不知道它是怎么工作的」—— 听到这句话，我就会认定这个人根本没有能力调试这些代码。
- 能否调试代码，是开发者是否真正掌控代码的明确界线。
- 任何看重可靠性和稳定性的人，都不会信任连自己代码都掌控不了的供应商。
核心立场：不读 = 不拥有 = 不可信。
🟡 Christine Lemmer-Webber 警示派
- 提出 「Vibe 滑坡」概念：一开始谨慎借助 AI 写代码，认真审查；随着速度加快，审查逐渐放松，最后滑向完全凭感觉的 Vibe Coding。
- 「人们对这段旅程的掌控力，远不如他们自认为的那样强大。」
- 在追求速度的过程中，每个环节的监督都可能被削弱，现实中很难找到有效的刹车点。
核心立场：不读是一种危险的惯性，一旦开始就很难停下来。
🟢 Theo（t3.gg 创始人） 分层派
- 对绝大多数工程师来说，目前阅读的代码比例太高了，但生成的代码还远远不够多。
- 如果你真的在编写极其重要的代码，反而更应该生成大量一次性代码，去测试那些真正不能出错的部分。
- 让 AI 瞬间生成 1000 行测试代码，成本近乎为零。用廉价代码去验证昂贵代码。
核心立场：不是所有代码都同等重要，关键在于区分层级。
03Uncle Bob 的方法：用约束取代逐行审查
Uncle Bob 的做法并非「什么都不做」，而是把精力从阅读代码转移到构建验证体系上。他的策略可以拆解为四个步骤：
设置严格约束→Agent 生成代码→自动验证闯关→高置信度交付
约束包括：单元测试、Gherkin 验收测试、QA 流程、质量指标、变异测试、测试覆盖率，以及大量其他机制。当 Agent 生成的代码通过所有这些考验后，他便对最终结果抱有「很高的信心」。
一个诚实的注脚：
有开发者追问，如果真正保障质量的是那些约束，那么谁来保证约束本身是可靠的？Uncle Bob 的回答是：他同样让智能体去编写检查约束的工具。这些工具是确定性的，规模相对较小，同样被大量测试包围。判断工具是否可信的依据，仍然是它能否持续通过验证、稳定完成任务。
这听起来近乎无限递归 —— 智能体写代码，智能体写测试，智能体再写工具检查测试与代码。但 Uncle Bob 的做法并非简单循环，而是通过变异测试和多层级联验证，让篡改测试蒙混过关的难度呈指数级上升。同时，他也会亲自检查 Gherkin 验收测试和 QA 流程，根据任务的关键程度进行全面审核或抽查。
注：已有开发者将这套思路做成开源工具（old-coder），核心理念直接取自 Uncle Bob：不要逐行阅读 Agent 生成的代码，而是让代码先闯过一整套验证关卡。
04不是所有代码都同等重要
这场争论背后，有一个更根本的问题：你认为自己写的代码究竟有多重要？
Theo 提出的代码分层模型，为这个问题提供了一个清晰的框架。他把代码想象成一条光谱：
🗑️ 第一层：一次性垃圾代码
写出来只是为了整理文件或回答某个一次性问题，看一眼都觉得被冒犯。
AI 生成成本：趋近于零
⚠️ 第二层：希望它能正常工作
出了问题会很烦，但不会造成严重后果。
AI 生成成本：极低
🔴 第三层：最好别出问题
一旦出错，可能会被解雇。核心业务逻辑、客户面对的功能。
AI 生成成本：低，但需要人工把关
💀 第四层：出错可能有人死亡
医疗设备、关键基础设施、航天系统。每一行都至关重要。
AI 生成成本：低，但验证成本极高
过去，手写代码的成本太高，大家几乎把所有时间都花在第三层和第四层，根本没有余力去上面两层做探索。现在，AI 让上面两层的代码变得几乎免费 —— 你应该大量进入这些上层区域，用廉价的代码去验证昂贵的代码，而不是用「所有代码都很重要」这个理由把自己锁死在底层。
这个思路与 Uncle Bob 的方法论本质上相通：用大量廉价代码构建一个测试金字塔，在底部堆满垃圾，用这座塔去保护塔尖上那一小撮真正不能出错的东西。
编辑核心判断
AI 代码审查之争的真正价值，不在于「读或不读」的二选一，而在于它迫使每一位开发者重新思考：当代码生成成本趋近于零时，软件工程的核心技能正在从「写代码」转向「设计验证系统」。谁先完成这个转变，谁就掌握了下一个时代的生产力。
◈这场争论没有标准答案
但每一位开发者都需要做出自己的选择。
你站在哪一边？
欢迎在开发者社区分享你的观点。