Uncle Bob谈AI编程：用确定性工具驯服智能体

软件工程领域的传奇人物 Robert C. Martin（人称 Uncle Bob）——《代码整洁之道》（Clean Code）的作者，编程生涯超过半个世纪——在一场直播对谈中分享了他对 AI 编程时代的深刻思考。从 2024 年底开始，这位坚持了几十年"整洁代码"理念的老兵，开始认真拥抱 AI 智能体，并逐渐形成了一套独特的方法论。本文将梳理这场对谈中的核心观点。

从"清理狗屎"到确定性工具

Uncle Bob 坦言，最初使用早期的 Grok 智能体写代码时体验并不好。"它写代码，但总是留下一堆烂摊子（dog doo），我不断地在它后面清理。"更糟的是，随着代码越来越乱，智能体开始陷入困境：改一处坏一处，来回打转，甚至有一次直接"放弃"了任务。

这让他意识到一个关键事实：智能体和人类一样，会被混乱的代码拖垮。"它们可能速度快、相对聪明，但和人类一样受制于混乱代码。也许阈值不同，但那个阈值依然存在。"

真正的转折点在于，他想起了 2000 年前后两个当时"很好但不实用"的创新：CRAP 评分（结合代码覆盖率与圈复杂度衡量函数"糟糕程度"）和变异测试（Mutation Testing，通过翻转代码中的运算符来检验测试套件是否够严格）。

CRAP 评分（Change Risk Anti-Patterns）是由 Alberto Savoia 于 2007 年提出的代码质量度量指标，其计算公式结合了圈复杂度（Cyclomatic Complexity）和代码测试覆盖率。圈复杂度由 Thomas J. McCabe 在 1976 年提出，通过统计代码中独立路径的数量来衡量程序逻辑的复杂程度——每多一个 if/else 分支，复杂度就加一。当一个函数圈复杂度高而测试覆盖率低时，CRAP 分数就会飙升，意味着这段代码既复杂又缺乏测试保护，修改它的风险极高。变异测试则是一种评估测试套件质量的技术，最早的理论可以追溯到 1971 年 Richard Lipton 的学生论文。它的原理是在源代码中自动注入微小的变异（mutation），例如将 > 改成 >=、将 + 改成 -、将 true 改成 false 等，然后运行测试套件。如果测试套件能够检测到这些变异（即测试失败），说明测试是有效的；如果变异后测试依然通过，就暴露了测试中的盲区。由于每个变异都需要完整运行一次测试套件，对于大型项目来说计算量极其庞大。

这两项技术在人类手中太耗时——变异测试甚至要跑一整夜。但智能体不一样："它们速度快，而且不在乎工作多枯燥。"于是他让智能体自动运行 CRAP 分析和变异测试，把过去"不实用"的高质量手段重新激活。

拒绝"引导"，拥抱确定性约束

对谈中一个核心分歧点在于：面对智能体犯错，大多数人的做法是不断往提示词里塞规则（steering，引导），而 Uncle Bob 选择了确定性检查（deterministic checks）。

他解释了为什么引导会失效——模型存在"中间迷失"（lost in the middle）现象：随着上下文窗口膨胀，开头和结尾的内容更受重视，中间的内容会被忽略。这一现象源自斯坦福大学 Nelson F. Liu 等人在 2023 年发表的论文《Lost in the Middle: How Language Models Use Long Contexts》。研究发现，当大语言模型需要从长上下文中检索关键信息时，如果相关信息位于输入的开头或结尾，模型表现最佳；但当信息被埋在中间位置时，模型性能会显著下降。这一现象与人类认知心理学中的"序列位置效应"（Serial Position Effect）有相似之处——人类也倾向于更好地记住列表的开头（首因效应）和结尾（近因效应）。

你写的规则越长，重要的部分越容易被挤到中间被遗忘。"模型对待这些规则，就像《加勒比海盗》里说的——它们更像是'指导原则'。"

因此他的策略是：把初始提示词压缩到极致，只保留最优先的部分，然后依靠事后的确定性工具来保证质量。主持人将其类比为上下文窗口的"聪明区"与"愚笨区"——前 15 万 token 左右模型表现聪明，之后注意力关系被严重稀释，"就像每个 token 都在拥挤的房间里喊叫，信号淹没在噪音中"。

确定性工具的妙处在于：它们不占用上下文，可以层层叠加，把智能体锁进一个"紧身衣"里循环运行，直到工具判定代码合格为止。

多智能体流水线：从规范到质量的五步协作

Uncle Bob 目前正在探索让多个智能体串联协作的流水线，每个智能体专注单一任务：

• Specifier（规范者）：把人类写的文档转化为 Gherkin（given-when-then 验收测试）和 QA 系统测试流程，从"人类操作 UI"的视角来验证系统。Gherkin 是行为驱动开发（BDD, Behavior-Driven Development）框架中使用的领域特定语言，最初由 Cucumber 项目的创始人 Aslak Hellesøy 于 2008 年左右推广。它采用 Given-When-Then 的三段式结构来描述软件行为：Given 描述系统的初始状态，When 描述触发的动作，Then 描述期望的结果。其设计初衷是让非技术人员也能读懂测试用例，弥合业务需求与技术实现之间的鸿沟。
• Coder（编码者）：编写单元测试和实现代码，让 Gherkin 通过。此时代码往往一团糟。
• Cleaner（清理者）：运行 CRAP 分析，做代码审查，清理编码者留下的烂摊子。
• Hardener（加固者）：运行变异测试，"绝不留情"，在每一个等号处追求 100% 覆盖。
• QA 智能体：把 QA 文档转化为可执行脚本，操纵系统得出确定性结果。

"如果一个任务单个智能体 5 分钟能完成但结果存疑，这套流程要花约一小时——但仍然比人类快，人类可能要半天。"他估算整体生产力提升约 4-5 倍，且质量远超人类手工水平。

多智能体的优势有两点：一是可以并行运行；二是聚焦单一任务能控制上下文窗口，缓解"中间迷失"问题，而且可以让智能体"生—做—死"，下一个带着干净的上下文进场。缺点则是启动开销高（每个智能体启动要 10-15 秒并重建上下文）。

对谈中还提出了一个精彩概念——上下文的轨迹（trajectory）：一旦你把智能体引向某个方向，同一会话中后续的所有操作都会延续这个轨迹，唯一清除轨迹的方式就是清空上下文窗口。这也解释了为什么专注单一任务的智能体表现更好。

架构与模块设计：无法被自动化的核心杠杆

即便有了完善的测试和加固流程，Uncle Bob 强调：良好的模块设计依然是巨大的杠杆，而这部分目前仍需人工介入。

他让智能体构建了一个架构查看器，可以弹出 UML 图展示系统的模块结构和依赖流向，点击模块可逐层下钻直到代码。他还编写了确定性工具，用规格文件定义模块间应有的依赖关系，一旦智能体违反规则，检查器就会强制它修复（通过反转依赖、插入接口或拆分模块）。

这里的"反转依赖、插入接口"直接对应 Uncle Bob 本人提出的 SOLID 原则中的依赖反转原则（DIP, Dependency Inversion Principle）。该原则规定：高层模块不应该依赖低层模块，两者都应该依赖于抽象；抽象不应该依赖细节，细节应该依赖抽象。在实践中，这意味着如果模块 A 直接依赖模块 B 的具体实现，应该在两者之间插入一个接口（Interface），让 A 依赖接口、B 实现接口，从而反转依赖方向。Uncle Bob 在 1990 年代至 2000 年代系统化了 SOLID 五大原则（单一职责、开放封闭、里氏替换、接口隔离、依赖反转），并在其著作《架构整洁之道》（Clean Architecture）中进一步发展出"整洁架构"的分层模型，强调业务规则应位于架构中心，不依赖于框架、数据库或 UI 等外围细节。他在对谈中构建的架构查看器和依赖规则检查器，本质上是将这些架构原则编码为确定性约束，让智能体在自动生成代码时也必须遵守模块边界。

"任何良好划分、接口纪律严明的东西，人类能把握，模型也能——因为模型是仿照人类建模的。"他指出，智能体会关注接口命名、结构和测试来理解系统，从而无需阅读底层代码——这既是优势也是危险，前提是代码保持一致。

别把"人类纪律"强加给智能体

关于自己的经典著作是否需要更新，Uncle Bob 给出了两点洞察：

第一，阈值需要调整。 智能体拥有巨大且精确的短期记忆，能处理比人类更高的复杂度。因此他把函数的 CRAP 评分阈值从人类的 4 放宽到 6，甚至尝试推到 8。

第二，纪律不该照搬。 他是测试驱动开发（TDD）的坚定倡导者，但他明确表示不会强迫智能体遵守 TDD 那种"写一行测试、写一行代码"的严格节奏。"TDD 是人类纪律，因为人类的短期记忆有限。对智能体没有意义。"

测试驱动开发（TDD）由 Kent Beck 在 1999 年极限编程（XP）实践中系统化提出，其核心是"红-绿-重构"循环：先写一个会失败的测试（红），再写最少量的代码让测试通过（绿），最后重构代码消除重复和改善设计。TDD 的本质是一种人类的认知辅助工具——通过将大问题拆成极小的步骤，帮助程序员在有限的工作记忆中保持对代码的掌控。而 John Ousterhout 在其著作《软件设计哲学》（A Philosophy of Software Design）中对 TDD 持批评态度，他认为 TDD 鼓励开发者过度关注战术层面的小步骤，而忽视了整体的系统设计和抽象。Ousterhout 倡导的是先思考好接口和抽象、再编写完整的实现代码、最后补充测试的方式。Uncle Bob 在此处的观点耐人寻味——作为 TDD 最著名的布道者之一，他承认对于拥有巨大"工作记忆"的 AI 智能体而言，TDD 的步进节奏失去了意义，智能体自然会倾向于 Ousterhout 式的完整实现优先的方式。

即便命令它们做 TDD，它们最终也总会退回到"先写函数、再写测试"的 Ousterhout 式做法。

他的总结精辟："把人类的价值观（value）施加给智能体没问题，但把人类的纪律（discipline）、行为方式强加给它们，是不明智的。"

规格是易逝的：回归敏捷思想

在"规格驱动开发"（spec-driven development）风靡的当下，Uncle Bob 的立场颇为反潮流。他做过大量前期规划实验，结果"总是灾难"——智能体会写出华丽详尽的计划，但执行时全部崩塌，因为你不可能想到一切，而它们又没有你聪明。

"这正是我们 70 年代经历过的诱惑，它导致了瀑布模型。"瀑布模型（Waterfall Model）的概念可追溯到 1970 年 Winston W. Royce 的论文，它将软件开发分为需求分析、系统设计、编码、测试、部署等严格按序执行的阶段。讽刺的是，Royce 在原始论文中实际上是在批评这种线性流程的缺陷，但业界却将其作为标准模型广泛采用了数十年。到了 1990 年代末，软件行业普遍认识到瀑布模型在应对需求变化时的脆弱性。2001 年，包括 Uncle Bob 在内的 17 位软件开发者在犹他州雪鸟滑雪胜地签署了《敏捷宣言》（Agile Manifesto），正式拉开了敏捷运动的序幕。敏捷的核心理念是拥抱变化、短周期迭代、持续交付可工作的软件。

Uncle Bob 认为答案还是敏捷：做一两个 story，看架构，手动整理，再做几个，再整理。

他用一个绝妙的比喻说明为什么放弃前期重规划：如果改动房子只需 1 美元，你会花几千美元请建筑师做完美方案吗？还是直接和承包商反复调整？"变更成本已经暴跌到接近于零，为什么还要做昂贵的前期规划？"

因此他不在仓库里持久化保存规格文档——"规格是易逝的（ephemeral）"。过去源代码是人写的最终规范，如今源代码不再由人书写。他现在的做法反而是把最终结果当作规范，并建议大家不要下载他写的工具，而是让自己的智能体去参考它们、再定制一个属于自己的版本。

战略编程与基本功：AI时代新人如何成长

借用 John Ousterhout 的框架，Uncle Bob 区分了战术编程（地面上的军士）和战略编程（指挥战争的将军）。智能体极擅长战术，却不擅长战略。

那么在 AI 吃掉所有战术工作的时代，新人如何学会战略编程？他的建议很有画面感：

1. 先写代码，写上一年，理解智能体在处理什么。
2. 入职后被当作智能体对待——让主管把你当成一个智能体来分配任务、施加同样的确定性工具约束，"痛苦地不高产几个月，但学到大量东西"。
3. 补齐从二进制到汇编、C、Python 的完整抽象链条。他重申十年前的建议：花一个周末写汇编语言，才能明白幕后真正发生了什么。

他还推荐阅读那些"没人读的老书"——Tom DeMarco、Ed Yourdon 的著作，以及《程序员修炼之道》（The Pragmatic Programmer），过滤掉过时内容，从中汲取高层战略思维。Tom DeMarco 和 Ed Yourdon 是结构化分析与设计方法的先驱，他们在 1970-80 年代的著作（如 DeMarco 的《Peopleware》和 Yourdon 的《结构化分析》）奠定了软件工程管理和系统设计的理论基础，许多核心思想——如关注人的因素、模块化分解、信息隐藏——在今天的 AI 编程时代依然具有指导意义。

基本功为何永不过时

对谈的落点是软件基本功的价值。Uncle Bob 引用 Dijkstra 的观点：软件是人类尝试过的最复杂的事物。

Edsger W. Dijkstra（1930-2002）是计算机科学的奠基人之一，1972 年图灵奖得主。他最为人知的贡献包括最短路径算法（Dijkstra 算法）、结构化编程的倡导、以及对 goto 语句的著名批判（1968 年的《Go To Statement Considered Harmful》）。Dijkstra 对软件复杂性有深刻的洞察，他曾写道："编程的艺术就是组织复杂性的艺术"，并指出人类智力的局限性是软件工程必须直面的根本约束。他在 EWD 系列手稿中反复强调，程序的正确性不应依赖于测试（"测试只能证明 bug 的存在，不能证明 bug 的不存在"），而应通过严格的数学推理来保证。

"因此基本功就是我们把复杂性组织成可被理解形式的方式——不仅被人类理解，也被我们的模型理解，毕竟模型是仿照人类建模的。"

他把这一次抽象层跃迁类比历史：从二进制到汇编，从汇编到编译器，每一步下层的人都在喊"这要毁掉一切"，但同样的规则始终适用。"你扔掉的规则，一年后会从地上捡起来，掸掉灰尘，想起当初为什么需要它。"

对于认为基本功不再重要的人，他的预言毫不留情："他们会学到教训，而且是以艰难的方式学到——不会花太久。我亲眼见过智能体撞上那堵墙，我知道那堵墙就在那儿。"

这场对谈最动人的地方在于：一位坚守"整洁代码"数十年的老兵，没有固守成规，而是用他毕生积累的工程智慧，为 AI 智能体时代重新校准了方法——工具变了，速度变了，但组织复杂性的基本功，从未改变。

核心要点