Brooks 的设计课，为什么在 AI Coding 时代反而更值得重读
2025 年以来，AI coding 工具的采用曲线陡得让很多人来不及思考。Cursor、Claude Code、Copilot、Windsurf——各家的命题都是「让开发者更快地写代码」，而讨论区里最常见的句式也变成了「以前要三天，现在十分钟」。
但这里有一个讨论错位：「写代码更快」和「系统设计更好」被当成同一件事在聊。 速度是产出维度的指标，设计是判断维度的能力。混淆这两者，不是技术问题，是认知问题。
在展开「AI 时代到底需要什么样的设计能力」之前，值得先回到一个老源头——Frederick Brooks Jr. 的《The Design of Design》。
一、Brooks 到底在说什么
Brooks 是《人月神话》的作者，IBM System/360 的关键人物。他在《The Design of Design》里讨论的不是视觉设计，不是 UI，不是敏捷流程，而是一个更根本的问题：复杂系统到底是怎样被设计出来的？
他关心的命题可以拆成四个维度：
| 维度 | Brooks 的判断 | 流行观点的反面 |
|---|---|---|
| 设计是什么 | 反复试探、修正和整合的探索过程 | 按流程填表：需求→规格→分解→分配→集成 |
| 好设计从哪来 | 统一的设计思想和强有力的设计主脑 | 委员会民主讨论、投票决策 |
| 设计问题本质 | Wicked Problem——没有清晰边界，没有唯一正确答案 | 可以被形式化方法解决的工程问题 |
| 评判标准 | 概念完整性（Conceptual Integrity） | 功能数量、交付速度、覆盖率 |
根源在于： 大多数人对「设计」的理解停留在产出层面——画出了什么图、写出了什么文档、交付了多少功能。但 Brooks 反复强调，设计的核心是判断——在约束之间权衡，在冲突中取舍，在模糊中建立清晰的概念模型。
二、一个关键词：概念完整性
如果只从 Brooks 的设计思想里抓一个概念，那就是 Conceptual Integrity。
一个有概念完整性的系统，用户会觉得它：思路一致、操作统一、模型清楚、各部分像出自同一个头脑。反过来，缺乏概念完整性的系统：每个模块风格不同、相似功能行为不一致、命名混乱、学会一处不能推理另一处。
这在软件里太常见了。一个产品里，一个页面叫 Project，另一个叫 Workspace；有的按钮是 Save，有的是 Apply，有的是 Done；同样的权限在不同模块表现不同。每一个不一致都不是 Bug，而是设计缺位的症状。
Brooks 的判断很尖锐：很多系统失败，不是因为功能少，而是因为没有统一的设计思想。
讲到这里，多半会有一个疑问：这跟 AI coding 有什么关系？关系比大多数人以为的大。
三、AI Coding 时代的五面墙
把 Brooks 的思想映射到当下的 AI coding 实践里，会撞上五面墙。每一面墙的本质，都是「产出能力」超过了「判断能力」。
墙一：局部正确 ≠ 整体优秀
AI 生成代码的典型模式是根据当前上下文做局部推断。它能把某个函数写得不错、某个页面实现得不错、某个接口封装得不错。但局部质量的叠加不等于系统质量。
| AI 生成现象 | 表面看起来 | 深层问题 |
|---|---|---|
| 每个功能都能跑 | 交付很快 | 概念模型不统一 |
| 每个模块有自己的命名风格 | 代码似乎清楚 | 全局语言混乱 |
| 相似功能用不同实现方式 | 局部合理 | 系统学习成本上升 |
| 临时需求被快速完成 | 响应敏捷 | 架构被持续侵蚀 |
根源在于： AI 优化的是局部上下文的拟合度，不是全局概念的一致性。它会帮你把每一块砖砌得又快又好，但它不会告诉你这面墙该不该存在。
墙二：需求到错误系统的链路变短了
以前一个错误需求从提出到变成代码，中间有评审、讨论、反复，有很多「减速带」。现在 AI 可以根据一句话直接生成实现——「给后台加一个批量导入功能」「给用户加一个推荐模块」「做一个权限管理页面」。
但 Brooks 式的问题会是：为什么需要这个功能？它服务于哪个核心流程？它是临时补丁还是长期能力？它会不会破坏现有模型？用户真正想解决的到底是什么？
错误需求变成错误系统的速度更快了。 以前好歹还有时间在漫长的编码过程中发现问题，现在连这个缓冲窗口都被压缩了。
墙三：设计责任的真空
当 AI 可以快速写出代码，团队很容易产生一种错觉：「我们产出很快，所以我们的开发流程没问题。」
但 Brooks 的框架会追问：谁在维护概念完整性？谁在判断取舍？谁在审查抽象质量？谁在决定什么不做？
过去这些责任分散在「写代码的过程中」——因为写代码慢，所以人们在写的途中会自然地思考这些问题。现在代码生成速度太快，如果没有人显式地承担设计判断的责任，就会出现设计真空。
原则不变，工程实践变了： 设计判断从「隐式分布在编码过程中」变成了「需要显式独立存在的活动」。
墙四：命名混乱的加速器
Brooks 非常重视命名，因为命名背后是概念。AI coding 中尤其容易出现这种混乱：同一个概念出现多个名字、不同概念被混用同一个名字、数据库字段/API/前端状态/产品文案互相不一致、AI 根据局部文件风格创造了新术语。
系统里同时出现 user、member、account、profile、customer——它们到底是不是同一个东西？如果不是，边界在哪？如果是，为什么有五种叫法？
这种混乱不是小问题。它会逐渐变成沟通成本、Bug 来源和架构负担。而 AI 会加速这个过程，因为每次生成代码时它都会基于局部上下文选择「看起来最自然」的命名，而不是基于全局一致性的命名。
墙五：架构错误的高速放大
以前糟糕设计的代价暴露得慢，因为代码写得也慢。现在不同了：一天可以生成过去一周的代码、一个需求可以快速拆出多个模块、一个原型可以迅速变成「准生产代码」、临时方案很容易被复制扩散。
AI coding 不是降低了架构的重要性，而是让架构从「高级工程实践」变成了「生存技能」。 没有架构判断力的团队，以前是慢慢烂掉，现在是快速烂掉。
四、共识地基
在讨论「怎么办」之前，先拉几条最少争议的共识：
- AI 显著降低了代码产出的边际成本。 这不是预测，这是已经发生的事实。
- 代码生成解决的是表达问题，不是设计问题。 表达是把想法变成可运行的代码；设计是决定想法本身应该是什么。
- 局部质量不等于系统质量。 每个函数都写对了，不等于整个系统设计对了。
- 概念完整性不会因为工具变强而自动出现。 它需要有人负责、有人判断、有人维护。
- 开发者的核心竞争力正在转移。 从「亲手实现每一行代码」转向「设计结构、控制质量、审查判断」。
这些共识应该没什么争议。分歧在于：既然这些判断成立，那 AI coding 时代的开发实践应该怎么调整？
五、五条可执行原则
把 Brooks 的思想转化成具体实践，不是照搬四十多年前的结论——工具环境完全不同了——而是把底层原则映射到新的约束条件下。
原则一：先设计概念，再生成代码
不要一上来就让 AI 写实现。更好的顺序是：定义核心对象和关系 → 明确系统边界 → 统一命名语言 → 设计数据流和状态模型 → 讨论异常和边界场景 → 再让 AI 生成代码。
比如不要直接说「帮我写一个订单退款模块」，而是先明确：Refund 和 Cancellation 是不是同一个概念？Refund 是订单状态还是支付状态？部分退款如何表示？退款失败后订单处于什么状态？退款是否影响库存、积分、优惠券？退款流程由谁发起、谁审批、谁执行？
这些问题没想清楚，AI 写得越快，后面越热闹。
原则二：把 AI 当成候选方案生成器，不是架构负责人
AI 很适合给方案，但不应默认采用第一个方案。
| 任务 | 低质量用法 | 高质量用法 |
|---|---|---|
| 需求实现 | 直接让 AI 写代码 | 先让 AI 提出设计问题 |
| 架构设计 | 让 AI 给一个最佳方案 | 让 AI 比较多个方案的取舍 |
| 代码审查 | 只检查能否运行 | 检查是否破坏概念完整性 |
| 重构 | 让 AI 局部优化 | 让 AI 识别重复概念和边界混乱 |
关键区别：不要只问 AI 怎么做，要问它为什么这样做、还有哪些做法、代价是什么。
原则三：维护统一语言
建立并维护一份「设计宪法」——不是厚重的文档，而是一组轻量但强制的约定：
- 核心领域概念如何命名
- 哪些抽象是系统级概念
- 哪些模式允许使用，哪些禁止
- API 的语义规则是什么
- 错误处理遵循什么模型
- 数据流是单向还是双向
- 状态应该放在哪里
- 哪些能力属于平台层，哪些属于业务层
AI 可以参与执行这些规则，但规则本身需要人类设计者制定。
原则四：让 AI 写代码，也让 AI 写设计记录
AI 时代不该减少文档，反而应该让文档更轻量、更即时。尤其建议保留：架构决策记录（ADR）、API 设计说明、核心领域模型说明、状态流转图、重要取舍原因、被拒绝方案及原因。
代码告诉你「系统现在是什么」。设计记录告诉你「系统为什么变成这样」。
原则五：用 AI 做概念完整性审查
AI 不只可以生成代码，也可以反过来检查系统是否一致。例如可以让 AI 审查：是否存在重复领域概念、命名是否统一、API 风格是否一致、模块边界是否清晰、是否存在循环依赖、是否有相似逻辑散落多处、错误处理是否统一、新功能是否违背现有架构原则。
一个实用的 prompt 思路：
请从概念完整性的角度审查这组代码。重点检查命名、抽象边界、状态模型、错误处理、模块职责是否一致。不要先改代码，先列出设计层面的不一致。
这比单纯「帮我写个函数」更有价值。
六、最核心的变化：从打字员到主编
AI coding 时代，开发者的工作形态会发生一个根本性的转变。
以前很多时间花在：写样板代码、查库文档、调整语法、搬运类似实现、重复写 CRUD、手工补测试。未来更多时间应该花在：判断需求是否合理、组织系统概念、选择架构边界、审查 AI 输出、维护设计一致性、重构概念模型、设计演化路径。
这很像从「作者」变成「主编」。主编不一定逐字写每篇稿子，但他决定栏目结构、叙事风格、质量标准、什么能发、什么要删、哪些内容互相冲突、整本杂志有没有统一气质。AI 可以写很多段落，但一本杂志有没有灵魂，还是看主编。
换一个终点：最强的 AI coding 团队，不一定是「最会让 AI 写代码」的团队，而是「最能让 AI 在统一设计思想下工作」的团队。
诚实边界
这篇文章的适用范围需要说清楚：
- 适用对象： 已经在用 AI coding 工具、并且开始感觉到「产出变快了但系统变乱了」的团队和个人。如果你还在纯手写代码阶段，先解决工具采用的问题。
- 不适用场景： 小型脚本、一次性原型、个人工具——这些场景下概念完整性的收益不足以覆盖维护设计宪法的成本。
- Brooks 的局限： 他的经验主要来自大型系统工程（操作系统、数据库、企业软件）。Web 应用、移动端、数据管道的设计约束不完全相同。原则相通不等于可以直接搬。
- 趋势判断的风险： AI coding 工具还在快速迭代。如果未来 AI 具备跨文件、跨模块的全局理解能力，部分判断（比如命名混乱加速）可能需要修正。但「设计判断不可替代」这个核心论点，短期内不会过期。
参考
- Frederick P. Brooks Jr., The Design of Design: Essays from a Computer Scientist, Addison-Wesley, 2010.
- Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975 (20th anniversary edition 1995).
- Frederick P. Brooks Jr., “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer, 1987.
- Horst W. J. Rittel & Melvin M. Webber, “Dilemmas in a General Theory of Planning,” Policy Sciences, 1973.（Wicked Problem 概念的原始论文）