Uncle Bob分享AI时代代码整洁之道，了解智能体协作实战，学习软件工程基本功。
Uncle Bob与Matt Pocock探讨AI时代软件工程基本功，分享智能体协作实战方法，包括转向确定性工具链、多智能体流水线等。
程序员朋友们，应该都知道 Clean Code (代码整洁之道) 这本书吧？！ Clean Code 的作者 Robert C. Martin (Uncle Bob) 和 231K 🌟 Skill...
程序员朋友们，应该都知道 Clean Code (代码整洁之道) 这本书吧？！ Clean Code 的作者 Robert C. Martin (Uncle Bob) 和 231K 🌟 Skills For Real Engineers 作者 Matt Pocock 做了一次深度对谈：AI 时代下，软件工程的基本功是否仍然成立，以及如何驾驭智能体。 youtube.com/watch?v=zcLPGC… F # Uncle Bob 与智能体协作的实战方法 1. 初识智能体的挫折 去年底开始用 Grok 等智能体写代码，最初印象平平：智能体"很快但让我变慢"，到处留下"狗粪"——混乱的代码、未清理的依赖、破碎的测试。他很快发现一个关键事实：智能体和人类一样，会被脏代码拖垮。 代码足够混乱后，智能体会陷入改一处坏另一处的循环，甚至直接放弃。 2. 转向确定性工具而非"指令堆砌" Bob 最初尝试用冗长的 prompt（TDD、Clean Code 规则等）"驯化"智能体，但发现模型把这些规则当成"加勒比海盗式的指南"——可遵守可不遵守。技术原因是 "lost in the middle"现象：上下文窗口中段的内容会被忽略，越长的初始 prompt 越多内容被埋没在中段而失效。 于是他转向确定性工具链：CRAP（结合圈复杂度与测试覆盖率的代码质量评分）、变异测试（mutation testing，翻转运算符后看测试是否仍能捕获）。这两项技术他在 2000 年就尝试过，但人工修复成本太高、不可行。如今智能体"不在乎枯燥、速度极快"，反而让这些老技术焕发新生。 3. 多智能体"流水线" Bob 搭建了一条智能体接力链，每个智能体只承担单一任务以控制上下文窗口： · Specifier：把人类文档转为 Gherkin 验收测试 + QA 程序 · Coder：写单元测试与实现代码，让 Gherkin 通过 · Cleaner：跑 CRAP 分析，清理实现者留下的烂摊子 · Hardener：跑变异测试，"毫不留情"地追求 100% 覆盖 · QA Agent：把 QA 文档转为可执行脚本，端到端验证 单智能体 5 分钟的任务，这条链约 1 小时；人类则需约半天。质量远高于人类通常会投入的水平，且是"早期投入生产力、后期收回"的投资。 # 关于架构与模块设计 Uncle Bob 让智能体构建了一个架构可视化工具（UML 风格，可逐层下钻到代码），并用一个依赖规则规范文件约束模块间依赖方向，由检查器在结尾强制执行——违反就由智能体通过依赖倒置、插入接口、拆分模块等方式修复。 他认同 John Ousterhout 的"深模块"理念（小接口、深实现）：模型可以读接口而不必读实现，只要代码一致即可。模型也通过读测试来理解系统行为。任何有助于代码结构的做法，都有助于模型理解代码。 # 对 Clean Code 原则的调整与坚守 需要调整的：阈值 智能体短期记忆巨大且精确，可承受更高复杂度。Bob 将 CRAP 阈值从人类的 4 上调到 6，考虑推到 8，正在试探边界。 不应强加的：人类纪律 TDD 对人类有价值（受限于短期记忆），但不应强加给智能体——让它们先写函数再写测试（John Ousterhout 风格）即可，强行要求"一行测试一行实现"它们最终都会回退到自然方式。 核心论断 可以把人类价值观强加给智能体，但不要把人类的行为纪律强加给智能体。 # 对"规格驱动开发"的质疑 Bob 明确反对冗长的前期规划。他本周还在实验"先把一切规划好再交给智能体"，结果一如既往地灾难——计划永远不完整，智能体不够聪明去填补，人类只能不断叫停、改计划、重启。 他重提经典的"盖房子"比喻：如果每次改动成本是 1 美元，你会先雇建筑师画完美图纸，还是直接对承包商边改边建？答案显而易见。如今改动成本已接近零，没有理由做沉重的前期规划，应该"摆弄、摆弄、摆弄直到看起来对"。 他建议回归敏捷：做一两个故事 → 看架构 → 手动整理 → 再做几个故事。那个"手动整理"步骤可能永远无法完全自动化。 关于规格是否持久化：不持久化。规格是临时的、不断变化的，最终产物（代码）本身就是规格。他甚至建议别人不要直接下载他写的工具，而是让智能体看他的工具、再为用户自己定制一份。 # 新人如何学习"战略性编程" John Ousterhout 区分了战术编程（一线战斗）与战略编程（统帅指挥）。智能体擅长战术、糟糕于战略。问题是：AI 已吞掉战术工作，新人如何学战略？ Bob 的建议路径： 1. 先写一年代码，理解智能体在应对什么 2. 入职后被当作智能体对待——交给智能体一样的任务，受同样的确定性工具约束，几个月内极度低产但学到大量 3. 通过这条"流水线"后，才可被信任去运行自己的智能体 4. 读老书：Tom DeMarco、Ed Yourdon、《The Pragmatic Programmer》等 70-80 年代的经典——那时这些教训刚被学到，需过滤掉过时部分 5. 必须亲身"感受"过挣扎才能识别智能体的挣扎 他强调：不能完全脱离代码。 十年前他建议人花一个周末写汇编，以理解 Java 之下的真实世界。这个道理在 AI 时代依然成立。 # 软件基本功是否仍然重要 仍然重要，理由一如既往。 引用 Dijkstra：软件是人类尝试过最复杂的事物。基本功是把复杂性组织成可被构想的形式——不仅人能构想，模仿人类的模型也能。 那些认为基本功不再重要的人"会以痛苦的方式学到，且不会太久"。Bob 亲眼见过智能体撞上那堵墙。 抽象层的纵向类比 从二进制 → 汇编 → 编译器 → 模型，每一次抽象层上升，下层的人都会哀叹"这会毁掉一切、连五岁小孩都能写代码"。每次都没发生。同样的规则、同样的基本功，因同样的理由存在。被你扔掉的规则，一年后你会从地上捡起来拍拍灰，想起为什么需要它。 💬 6 🔄 2 ❤️ 10 👀 1017 📊 11 ⚡