AI 时代，软件基本功真的过时了吗？——Uncle Bob 的实战经验与深度思考

AI 时代，软件基本功真的过时了吗？——Uncle Bob 的实战经验与深度思考

当 AI Agent 能在一分钟内写出上百行代码，我们还需要关心圈复杂度、模块设计、测试覆盖率吗？
《代码整洁之道》作者 Robert C. Martin（Uncle Bob）在一次直播中给出了他的答案，并用一套完整的 Agent 流水线证明：软件基本功不仅没有过时，反而是驾驭 AI 的关键。

一、背景：一场跨越半个世纪的对话

2026 年初，TypeScript 专家 Matt Pocock 邀请 Uncle Bob 进行了一场深度对谈。Bob 从 12 岁开始编程（1964 年），至今仍活跃在一线。他在 2023 年底开始认真使用 AI Agent，并在短短几个月内构建了一套令人惊叹的多 Agent 协作系统。

本文将从技术角度拆解 Bob 的核心观点与实践，探讨 AI 时代软件工程的基本原则为何依然重要，以及我们该如何调整策略。

二、AI Agent 的"混乱"与"速度"悖论

2.1 Agent 的典型问题：快速制造混乱

Bob 坦言，早期使用 Agent 时，它就像一个"快速拉屎的小狗"——写得很快，但留下一堆垃圾。更致命的是，当混乱累积到一定程度，Agent 自己也会被困住：它会陷入"修 A 破坏 B → 修 B 又破坏 A"的死循环，甚至直接放弃。

这背后的技术原因是：Agent 的上下文窗口有限，且存在"迷失在中间"效应。当代码库变得杂乱，Agent 无法在有限上下文中理解全局，其推理能力急剧下降。

2.2 解决方案：用确定性工具替代模糊指令

Bob 的做法是：不再试图用长篇规则约束 Agent，而是使用确定性工具进行事后检查。

例如，Bob 引入 CRAP 指标（代码复杂度与覆盖率的综合评分）和 变异测试，让 Agent 在完成任务后自动运行这些检查，若不达标则必须修复。

技术要点：CRAP = (圈复杂度²) × (1 - 覆盖率)³ + 圈复杂度。Bob 对 Human 设定阈值为 4，对 Agent 放宽至 6~8，但前提是覆盖率必须达到 100%。

三、五道 Agent 流水线：从混乱到可靠

Bob 设计了一套高度结构化的多 Agent 流水线，每个 Agent 只负责一个明确任务，上下文窗口短小，从而避免了"迷失在中间"。

[规范器] → [编码器] → [清理器] → [硬化器] → [QA Agent]

3.1 规范器（Specifier）

• 输入：人类编写的需求文档（自然语言）
• 输出：
  • Gherkin 格式的高层验收测试（Given-When-Then）
  • QA 流程文档（面向用户的操作步骤）

3.2 编码器（Coder）

• 任务：根据 Gherkin 编写单元测试和实现代码，使场景通过
• 特点：不追求完美，允许留下混乱

3.3 清理器（Cleaner）

• 任务：静态分析、代码审查、重构
• 工具：ESLint、SonarQube、自定义复杂度检查
• 目标：降低 CRAP 分数，拆分过长函数，消除重复

3.4 硬化器（Hardener）

• 核心武器：变异测试
• 原理：自动翻转源码中的符号（<→>、==→!= 等），运行测试套件，若测试未失败则说明"变异体存活"，代表测试不足
• Bob 的经验：以前跑一夜，现在 Agent 只需 30 分钟

3.5 QA Agent

• 任务：将 QA 文档转化为可执行脚本，模拟真实用户操作
• 输出：确定性测试结果

效率对比：单个 Agent 5 分钟完成但不可靠；完整流水线约 1 小时，但质量极高，相当于人类半天的产出，生产力提升 4~5 倍。

四、模块设计：Agent 也需要"深模块"

4.1 什么是深模块？

John Ousterhout 在《A Philosophy of Software Design》中提出：深模块指接口小而功能强大的模块；浅模块则接口大但隐藏信息少。

Bob 发现，Agent 在处理深模块时表现远优于浅模块。因为 Agent 只需要理解接口契约，无需关心内部实现细节，这大大降低了上下文负担。

4.2 如何确保模块结构良好？

Bob 开发了一个架构查看器，能自动生成 UML 图，并配合一个确定性依赖规则工具：

# 依赖规则示例
rules:
  - from: "domain"
    to: ["infrastructure", "application"]
    direction: "inward"  # 依赖指向核心层
  - from: "infrastructure"
    to: []               # 基础设施不能反向依赖

Agent 若违反规则，工具会阻止提交并要求修复（如反转依赖、插入接口）。

五、TDD 与 Agent：该不该强制？

5.1 人类 TDD ≠ Agent TDD

Bob 明确指出：TDD 是人类认知局限的产物（先写测试，将问题锁定在短期记忆中）。Agent 的"短期记忆"远超人类，强行模仿人类 TDD 节奏（写一行测试→写一行代码）毫无意义。

5.2 正确的做法：灌输价值观，而非纪律

• ✅ 允许 Agent 先写完整函数，再为其编写测试
• ✅ 要求最终覆盖率达标（通过硬化器强制执行）
• ❌ 强制要求"测试先行"的步骤顺序

核心原则：强加人类纪律可能是错误的，但向 Agent 灌输人类价值观并没有错。

六、战略 vs. 战术：人类的新角色

6.1 Agent 擅长战术，人类负责战略

• 战术编程：解决眼前具体问题（Agent 的强项）
• 战略编程：决定整体方向、模块划分、技术选型（人类主导）

6.2 新人如何成长？

Bob 提出了一个有趣的训练方案：

1. 先学底层：从二进制、汇编、C 语言开始，理解计算机本质
2. 成为 Agent 的下属：让新人接手 Agent 的任务，使用相同的确定性工具，体验 Agent 的局限性
3. 阅读经典：《代码整洁之道》《务实的程序员》《人月神话》等，汲取战略思维
4. 逐步授权：经过数月训练后，才允许新人管理自己的 Agent

警示：如果完全依赖 Agent 写代码而不理解底层，你可能会在关键时刻无法诊断问题——就像只会用高级语言却不理解内存泄漏的开发者。

七、常见误区与反思

7.1 误区一：前期规划越详细越好

Bob 直言："先计划再交给 Agent 执行"是瀑布模型的翻版。计划永远赶不上变化，Agent 在执行中会发现未预见的依赖或冲突。正确做法是：让 Agent 先跑几个 Story，获取反馈，再调整架构。

7.2 误区二：规范驱动开发（Spec-Driven Dev）

这个词很容易被滥用。Bob 认为：规范应该是短暂的、可变的。真正的规范是最终生成的代码本身。与其维护一份永不更新的规范文档，不如让 Agent 产出结果后，人类根据结果调整后续方向。

7.3 误区三：自动化检查越多越好

过多的检查会拖慢 Agent，使其效率低于人类。Bob 的经验是：只要 Agent 仍比人类快 2~4 倍，检查就是值得的。一旦接近平衡点，就需要优化检查流程。

八、结语：基础原理永不过时

回顾软件发展史：从二进制到汇编，从汇编到高级语言，再到今天的 AI Agent，每一次抽象层提升都伴随着"基础无用论"的喧嚣。但事实是：

• 抽象层越高，底层原理越容易被忽视，也越致命
• 模块化、测试、复杂度控制、清晰接口——这些原则既服务于人类，也服务于模型

正如 Bob 所说：

“你今天扔掉的规则，一年后可能会从地上把它捡起来，掸掉灰尘，然后想起当初为什么需要它。”

AI 不会淘汰软件工程师，但会淘汰那些放弃基本功的工程师。

本文基于 Matt Pocock 与 Uncle Bob 的直播对话整理，并结合相关技术概念进行了扩展。如果你想深入了解 CRAP 指标、变异测试或深模块设计，欢迎留言讨论。