AI 写的代码,程序员到底还要不要读?

要不要逐行去读 AI 写出的代码？这场争论正在重新定义“程序员”这三个字。

这场争议的起点是2026 年 7 月 3 日，HashiCorp 联合创始人（Terraform、Vagrant 创造者）、Go 语言大师 Mitchell Hashimoto 在 X 上发的一条推文：

简短四个字，获得了近 83 万次浏览。当时正值 Anthropic Claude/GPT 等新一轮高效能模型发布，跟随感觉写代码的 Vibe Coding 正风靡社区——大家觉得不用抠细节，AI 给出代码看感觉差不多能用就行。Mitchell 的推文，正是对这种“不求甚解”趋势的公开反击。

然而，整整 20 天后，另一位更重磅的技术巨匠站了出来——《代码整洁之道（Clean Code）》作者、写了 60 多年代码的 Uncle Bob（Robert C. Martin），面对同样的问题给出了截然相反的答案：

一位是当下基础设施领域的顶尖实践者，说“我要读”；一位是影响了无数人的软件工程泰斗，说“我不读”。这直接引发了一场持续数周、吸引数百万次浏览的全网大厮杀。

“我读代码”派：调试能力与职业责任底线

支持 Mitchell 的这一派，核心逻辑非常接地气：代码是你提交、部署和维护的，你就必须理解它；否则出了 Bug，你连调试它的资格都没有。

• 调试能力的缺失：分布式系统专家 Cindy Sridharan 提出极其强硬的立场。她指出，现在很多开发者遇到 Bug，只是机械地把报错信息扔给 Claude，再把 AI 给的修复方案贴回去，跑通就算完。遇到稍微复杂的非典型 Bug，就要反复试探好几轮才能定位。因为他们根本不理解代码是怎么跑起来的，“你调试不了它，就没有资格说自己掌控它”。
• “外幻滑坡”现象（Sliding Slope）：开源工程师 Kristian Mølhave 提出，开发者最初只是谨慎地让 AI 辅助，写完认真审查；但随着 AI 生成速度越来越快，审查会逐渐放松——今天跳过一个小函数，明天觉得模块逻辑差不多就行，最终一路滑向凭感觉写代码。这个滑坡是顺着惯性发生的，现实中人类很难找到真正有效的“刹车点”。
• 审查的物理极限：今天的大模型一次就能生成数百行代码，甚至经验丰富的程序员，想完整审查出膨胀的代码中的潜在 Bug，客观上也变得越来越困难。

“我不读代码”派：用严密的约束体系代替人工阅读

Uncle Bob 难道是闭着眼睛把 AI 代码直接合并吗？当然不是。他的核心在于将责任重心从“逐行阅读代码”转移到“构建严密的质量保障体系”。

Uncle Bob 的做法是给智能体设置极苛刻的约束：单元测试、集成测试、QA 流程、质量指标、变异测试（Mutation Testing）以及覆盖率限制。

面对社区层层逼问的尖锐质疑，Uncle Bob 展现了他的全套闭环逻辑：

• 追问一：谁来保证测试约束本身是可靠的？—— Uncle Bob：依然让智能体编写检查约束的工具。这些工具是确定性的、规模较小，用来检查质量和覆盖率。
• 追问二：那你审不审查这些检查工具的代码？—— Uncle Bob：依然不读。检查工具本身也会被大量的单元测试和验收测试包围。判断一个工具是否可信，从来不是逐行读它，而是看它能否持续稳定地通过验证。
• 追问三：AI 自己写代码、自己写测试、自己写检查工具，这不是 AI 自己检查自己吗？—— Uncle Bob：通过变异测试（Mutation Testing）和复杂的 QA 流程防止 AI 作弊。智能体如果想篡改测试蒙混过关，需要同时修改一大批相互关联的测试，作弊难度极高。同时，他会亲自检查验收测试，并在关键节点做人工测试。

烂代码依然是毒药：对于“既然代码修改这么便宜，代码乱一点是否无所谓”的提问，Uncle Bob 强调：代码质量依然极其重要。混乱的代码不仅拖慢人，也会困住 AI 智能体自身。他曾多次看到 AI 被自己造出的混乱结构困住折腾。因此，严格限制函数长度和复杂度，是为了让 AI 能顺畅推进任务。

为什么会有这种截然不同的分歧？因为两派人讨论的起点不同——你认为自己写的代码究竟有多重要？

第三机（37signals）创始人 Theo 提出：对绝大多数工程师来说，目前大家阅读代码的比例太高了，而生成的代码还远远不够多。

在过去，写代码和写测试成本都很高，为了验证一行核心代码，专门写 1,000 行测试在人力上很不划算，因此“人工读代码”是性价比最高的手段。但今天，让 AI 瞬间生成 1,000 行测试代码的成本几乎为零。

视频中分享了一个极其到位的代码四层金字塔模型：

旧时代：因为手写代码太贵，大家几乎把所有时间花在第 1 和第 2 层，根本没有余力去上面两层探索。

新时代：AI 让上面两层（廉价代码）变得几乎免费。我们可以用大量廉价、用完即扔的代码，去构建一个庞大的测试金字塔，保护最底层的核心代码。

回到最初的问题：AI 写的代码到底要不要读？

• 假设一个工程师每天依然手写并逐行验证80 行极其关键的核心代码——这部分质量标准绝不降低，该读还是读，该审还是审。
• 在这 80 行之外，让 AI 生成800 行甚至 8,000 行验证代码（压力测试、变异测试、专用的 Lint 规则、专项调试工具）。
• 这些验证代码不会上线给用户用，但它们从各个角度攻击那 80 行核心逻辑，从而极大提升核心代码的可信度。

我是 Viking Den，热衷于分享 AI 观察、工具与工程实践。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见

THANKS FOR READING