程序员朋友们，你们一定都听说过《代码整洁之道》（Clean Code）这本书吧？！

憬溺

程序员朋友们，你们一定都听说过《代码整洁之道》（Clean Code）这本书吧？！

《代码整洁之道》的作者罗伯特·C·马丁（人称“鲍勃大叔”）与《真正的工程师技能》（Skills For Real Engineers）的作者马特·波科克进行了一场深入的对话，该书拥有23.1万个赞🌟。对话主题是：在人工智能时代，软件工程的基本原理是否依然适用，以及如何驾驭智能体。

https://youtube.com/watch?v=zcLPGC-tvgk

#鲍勃大叔与智能体协作的实用方法

1. 初次接触智能体的挫败感

去年年底，我开始使用像Grok这样的智能体来编写代码，最初的印象并不好：这些智能体“速度很快，但却拖慢了我的速度”，到处留下“狗屎”——混乱的代码、未清理的依赖项、失败的测试。他很快发现了一个关键事实：智能体和人类一样，也会被脏代码拖累。一旦代码变得足够混乱，智能体就会陷入不断修复问题又破坏其他问题的恶性循环，甚至直接放弃。

2. 转向确定性工具而非“提示堆砌”

Bob 最初尝试用冗长的提示（TDD、代码整洁原则等）来“驯服”智能体，但他发现这些规则就像“加勒比海盗式指南”——充其量也只是可选项。技术原因在于“中间内容丢失”现象：上下文窗口中间的内容会被忽略，初始提示越长，被埋没在中间的内容就越多，从而失效。

因此，他转向了确定性工具链：CRAP（一种结合圈复杂度和测试覆盖率的代码质量评分工具）、变异测试（通过翻转运算符来测试是否仍然能够捕获错误）。早在 2000 年，他就尝试过这些技术，但手动修复成本太高且不切实际。如今，智能体“无惧枯燥乏味，速度飞快”，这些古老的技术焕发了新的生机。

3. 多智能体“流水线”

Bob 构建了一个智能体接力链，每个智能体负责一项任务，从而控制上下文窗口：

· 规范者：将人工编写的文档转换为 Gherkin 验收测试和 QA 流程

· 编码者：编写单元测试和实现代码以通过 Gherkin 测试

· 清理者：运行 CRAP 分析，清理实现者留下的烂摊子

· 强化者：运行变异测试，力求实现 100% 的覆盖率

· QA 智能体：将 QA 文档转换为可执行脚本，用于端到端验证

单个智能体只需 5 分钟就能完成的任务，在这个接力链中大约需要 1 小时；而人工则需要半天时间。其质量远远超过人工通常的投入，这是一种“前期投入生产力，后期获得回报”的投资方式。

# 关于架构和模块设计

鲍勃大叔让智能体构建了一个架构可视化工具（UML 风格，可逐层深入代码），并使用依赖规则规范文件来约束模块间的依赖方向，最终由检查器强制执行——违规行为由智能体通过依赖倒置、接口插入、模块拆分等方式修复。

他赞同约翰·奥斯特豪特的“深度模块”理念（小接口，深度实现）：只要代码保持一致，模型就可以读取接口而无需读取实现。模型还可以通过读取测试来理解系统行为。任何有助于代码结构化的实践也有助于模型理解代码。

# 对整洁代码原则的调整和承诺

需要调整的内容：阈值

智能体拥有庞大而精确的短期记忆，可以处理更高的复杂性。鲍勃将 CRAP 阈值从人类友好的 4 提高到 6，并考虑提高到 8，目前正在测试其极限。

不应强加：人类行为准则

测试驱动开发（TDD）对人类（受限于短期记忆）来说很有价值，但不应强加给智能体——让他们先编写函数，再编写测试（约翰·奥斯特豪特风格），坚持“一行代码对应一行测试”最终只会导致他们回归自然行为方式。

核心论点

你可以将人类价值观强加给智能体，但不要将人类行为准则强加给它们。

# 对“规范驱动开发”的质疑

鲍勃明确反对冗长的预先规划。本周，他仍在尝试“先规划好一切，然后交给智能体”，结果不出所料地惨不忍睹——计划永远无法完成，智能体不够智能来填补空白，最终人类不得不不断地停下来，修改计划，然后重新开始。

他重提了经典的“盖房子”比喻：如果每次变更的成本是 1 美元，你会先请建筑师绘制完美的蓝图，还是直接让承包商边建边调整？答案显而易见。如今，变更成本几乎为零，因此没有理由进行繁琐的前期规划——你应该“反复修改，直到满意为止”。

他建议回归敏捷开发：完成一两个用户故事 → 查看架构 → 手动重构 → 再完成几个用户故事。这个“手动重构”步骤可能永远无法完全自动化。

关于是否