七月中旬，X（原 Twitter）上的一条回复，让程序员圈子吵翻了天。
发这条回复的人叫罗伯特·马丁（Robert C. Martin），业内更习惯叫他“鲍勃大叔”——《代码整洁之道》（Clean Code）作者，SOLID 原则的提出者之一，也是《敏捷宣言》的联合发起人。
面对网友关于 AI 编程的质疑，他回复了一句后来被大量转发的话：
“我从 20 世纪 60 年代末就开始写代码了。现在我的策略是：我不阅读智能体（Agent）写的任何一行代码。这是我能够真正享受到它们生产力红利的唯一办法。”
如果这句话出自一个刚学会用 Copilot 半年的新人，大概率会被当成一句不负责任的玩笑。
但说这句话的人，恰恰是那个几十年来一直倡导“代码应该可读”“代码应该整洁”的人。
这条回复一天内获得了上万点赞，评论区很快分裂成两派：有人认为这是 AI 时代最诚实的实践经验，也有人认为他正在亲手推翻自己过去几十年建立的软件工程理念。
他到底在做什么？
鲍勃大叔的说法听起来很激进，但拆开来看，其实没有那么极端。
他说的不是“不管代码”，而是把质量把关的重点，从“阅读代码”转移到了“验证行为”。
他的做法是给 AI Agent 设置一层又一层的护栏：
- 单元测试（Unit Test）
- Gherkin 验收测试（用接近自然语言描述系统行为）
- QA 流程
- 静态分析
- 测试覆盖率
- 变异测试（Mutation Testing，通过故意引入错误来验证测试是否足够有效）
- 圈复杂度、依赖关系、模块规模等质量指标
他的逻辑很简单：
如果 AI 每小时能生成几万行代码，而人类仍然坚持逐行阅读，那么 AI 带来的效率优势最终会被人工 Review 全部抵消。
因此，人真正应该做的，不再是检查每一行实现，而是定义什么叫“正确”。
今年早些时候，他又把这套思路整理成了一个名为 Swarm Forge 的实验性项目，用来演示多 Agent 协作的软件开发流程。
整个流程由四个 Agent 组成：
需求规格化 → 编码 → 重构 → 架构审查
每一个 Agent 都负责不同职责，后面的 Agent 不断约束前面的 Agent。
随着流程不断推进，规格越来越明确，人工干预越来越少。
与此同时，他关注的也不再是代码本身，而是：
- 测试覆盖率
- 依赖结构
- 圈复杂度（Cyclomatic Complexity）
- 模块大小
- 静态分析结果
换句话说，他希望通过指标推断代码质量，而不是通过阅读代码推断代码质量。
后来，这套方法也逐渐演变成了他的课程：《AI Agents for Clean Code》以及 Clean Coders 平台上的《Clean AI: Agentic Discipline》。
它们讨论的其实都是同一个主题：
AI Agent 并不是不需要纪律，而是需要一种新的纪律。
但真正值得注意的是，这里面发生变化的，其实并不是 AI。
真正变化的是软件工程开始尝试把“信任代码”的方式，从“相信写代码的人”，逐渐转向“相信验证代码的系统”。
数据并没有完全站在他这一边
问题在于，目前支持这套方法的证据，还远没有他说得那么笃定。
一些代码质量分析公司的客户统计显示，AI 生成代码的缺陷率通常高于人工代码，部分商业报告甚至给出了约 1.7 倍的问题密度。这些问题不仅包括逻辑错误，也包括更多安全漏洞和边界条件遗漏。
不过，这些数字主要来自商业工具公司的真实客户数据，不同机构之间差异较大，目前还没有形成统一的行业结论。
真正麻烦的地方在于：
AI 写出来的问题，往往不是一眼就能发现的语法错误。
它们更像是：
- 代码完全能运行；
- 测试基本全部通过；
- 甚至代码风格也十分漂亮；
- 唯独在某一个极少出现的业务边界条件下，悄悄出错。
学术界的研究也指出，代码覆盖率并不等于质量覆盖率。
覆盖率只能说明哪些代码被执行过，却不能证明真正重要的业务场景都经过了验证。
更根本的问题在于：
如果生成代码和生成测试的是同一个模型，那么它们很可能共享同一套知识盲区。
AI 很难主动设计出自己都没有意识到的问题。
真正困难的，并不是测试怎么写。
而是：
首先要知道，哪些地方值得测试。
真正的问题，其实不是 AI
很多人以为，这场争论讨论的是：
AI 能不能写代码。
其实不是。
真正的问题是：
过去几十年，软件工程一直建立在一个默认假设上：
只要有经验丰富的工程师认真阅读过代码，我们就更容易相信它。
而鲍勃大叔提出的是另一种假设：
只要规格足够清晰、测试足够充分、指标足够严格，即使没人真正阅读过代码，我们依然可以相信它。
这不是工具的变化。
这是软件工程信任来源的变化。
未来真正需要回答的问题，也不是 AI 会不会写代码，而是：
什么样的证据，足以让我们相信一段代码是可靠的？
谁在这场辩论里赚钱？
还有一件事很少被摆到台面上讨论。
这场关于“要不要读 AI 写的代码”的争论，恰好发生在 AI 编程工具高速增长的时候。
AI IDE、AI Code Review、AI Agent 平台、自动化测试平台、代码质量平台……整个市场规模正在快速扩大。
这些公司的核心叙事几乎一致：
AI 的产出速度已经超过人工审查能力，因此必须把软件质量保证自动化。
这并不意味着这种观点就是错误的。
历史上，从自动化测试、持续集成到 DevOps，几乎所有新的软件工程实践，最终都会形成商业产品。
但值得注意的是，鲍勃大叔本人也不是完全意义上的旁观者。
他正在教授这套方法，也正在销售相关课程。
这并不影响他的观点本身是否成立，但至少说明了一件事：
今天这场讨论的传播速度，不仅来自技术本身，也来自一整条正在快速成长的商业生态。
这不是第一次了
其实，“不再检查底层实现，而是信任更高层抽象”，在计算机历史上已经发生过很多次。
1984 年，肯·汤普森（Ken Thompson）在图灵奖演讲《Reflections on Trusting Trust》中提出了著名的“信任信任”（Trusting Trust）思想实验。
一个被植入后门的编译器，可以在编译任何程序——甚至编译它自己——时自动植入恶意代码，而这些恶意逻辑永远不会出现在任何一行你能够阅读的源代码里。
他的结论是：
你无法完全信任任何不是由你亲手创造的系统。
今天，这个思想实验再次具有了新的现实意义。
过去，我们需要信任一个编译器。
今天，我们需要信任一整条由：
- 大模型
- 训练数据
- Agent
- MCP 工具
- 第三方依赖
共同组成的软件供应链。
历史告诉我们的，并不是每一次抽象都会失败。
而是：
每一次抽象层级提升，都必须建立一套新的信任机制。
高级语言如此。
互联网如此。
云计算如此。
AI 编程也不会例外。
只是，这套新的软件信任基础设施，目前还远没有成熟。
一个没人愿意细想的问题
把这些线索放在一起，会浮现出一个更隐蔽的问题。
鲍勃大叔能够做到“只看几个指标，就推断出代码质量”，这种判断力本身，恰恰来自他几十年亲手写代码、调试代码、阅读别人代码积累出来的经验。
而他今天教给年轻工程师的方法，却是让他们尽量少读代码。
传统上，一个优秀工程师是怎么成长起来的？
靠阅读海量生产代码。
靠一次次 Debug。
靠无数次 Code Review。
靠前辈一条条指出设计上的问题。
这些经验最终沉淀成了今天那些看似简单的指标：
圈复杂度该设多少？
哪些测试真正重要？
覆盖率达到多少才算够？
这些数字本身，并不是凭空出现的。
它们背后依赖的是长期的软件工程经验。
如果下一代工程师从来没有真正深入理解过大型系统，他们未来凭什么知道这些指标应该如何调整？
这可能才是 AI 编程时代最容易被忽视的问题。
还漏了一块：责任归谁？
技术之外，还有另一个几乎没人讨论，却可能比任何技术争论都更早影响行业发展的因素：
法律责任。
如果未来：
- AI Agent 自动修改生产数据库；
- 自动发布线上版本；
- 自动执行删除操作；
一旦发生事故，责任到底属于：
- 开发者？
- 企业？
- 还是 AI 工具提供商？
目前，整个行业仍然缺少成熟的责任框架。
这个问题一旦真正进入监管和司法层面，讨论的重点就会从：
AI 能不能做到？
转变成：
即使 AI 能做到，谁来承担失败的责任？
对于金融、医疗、能源、基础设施等高风险行业来说，这个问题甚至可能比技术本身更重要。
写在最后
回到最开始那条回复。
鲍勃大叔后来还说过一句没有前一句传播得那么广的话：
即使我们能够做到这些，也不意味着我们一定应该这样做。
相比那句“我不读 AI 写的代码”，我反而觉得，这句话更值得记住。
因为整场争论，从来没有任何一方主张“完全相信 AI”。
真正的分歧只是：
软件质量应该由什么来证明？
是依靠经验丰富的工程师阅读代码？
还是依靠规格、测试、指标和自动化验证体系？
答案今天还没有出现。
但也许几年以后，程序员真的会越来越少地阅读 AI 写下的每一行代码。
即使那一天到来，人们也不会停止验证软件，只是验证的对象，会从代码本身逐渐变成产生代码的整个系统。
真正发生变化的，从来不是代码，而是我们选择相信代码的方式。