当实现免费时，架构是什么
1972 年，大卫·帕纳斯写了一篇论文——《论将系统分解为模块时使用的标准》。这篇论文只有十二页，但它定义了过去五十年的软件架构。
帕纳斯的论点是：模块化的标准不是"功能"——不是"把所有跟用户相关的代码放在一起"。模块化的标准是——"信息隐藏"——把系统中最可能变化的部分封装在模块内部——让模块之间的接口不暴露这些变化。
这个原则——"把变化关进笼子"——贯穿了所有后续的架构思想。微服务是把"变化"隔离为独立的部署单元。领域驱动设计是把"变化"对齐到业务领域的边界。分层架构是把"变化"分层——上层逻辑变化不影响底层数据操作。
但这些原则——都共享同一个未经检验的前提：实现是需要成本的。模块化之所以有效——是因为"修改代码"是昂贵的——你需要一个人在理解上下文之后重写代码。如果你的模块化能够把"预期会变的部分"关起来——你就在降低修改的系统性成本。
现在——AI 改变了这个前提。
实现的成本在趋近于零。
如果"重写一个函数"的成本——对你来说——接近于零——架构是什么？如果"重构一个模块"——只需要你把需求描述清楚然后让 AI 重新生成——架构是什么？如果"修改代码以适应新的需求"不再是你时间分配的主要部分——你还需要帕纳斯意义上的"信息隐藏"吗？
一个直接的推论：如果实现免费——模块之间不需要"隔离变化"——因为变化本身变便宜了。你可以把两个功能塞进同一个模块——当它们开始冲突——你让 AI 重写整个模块。架构——作为"把变化关进笼子"——的原始功能——正在被掏空。
但这不是架构的终结。这是架构的范式转换。
当实现的成本消失——什么成本不消失？
第一个是认知成本。一个模块——即使 AI 可以瞬间重写——仍然是"理解"的单位。当你需要在六个 AI 生成的模块之间追踪一个 bug——你会发现"信息隐藏"的原始功能——降低人类的认知负荷——不会因为实现免费而消失。只是它的排序——从架构设计的"第一原则"变成了"唯一幸存的原则"。
第二个是集成成本。两个模块——各自由 AI 生成——之间的接口——在第一次对接的时候——几乎肯定会不匹配。AI 生成了模块 A——假设输入是 {userId: string, role: "admin"|"user"}。AI 生成了模块 B——读取用户数据——输出的字段名是 uid: number, type: string。编译不报错——运行时——找不到 userId。
接口——在这个新世界里——不是"实现的一部分"。接口是"合同"。当实现被外包给概率——合同不能外包。因为合同——在它的本质上——是确定性的。一方承诺提供 X。另一方承诺基于 X 产出 Y。概率不能承诺。
第三个是演化成本。系统——在时间的流逝中——会积累"只能在上下文中理解"的知识。为什么这个字段叫 legacy_id？为什么这个表有两个几乎相同的时间戳列？为什么这行代码在被删除六次之后仍然留在仓库里——因为每次删除都会让一个无人维护的 CI 步骤挂掉？这些——AI 不知道。也永远不会知道——因为它们不在训练数据里——它们在"这个组织的历史"里。
架构——在新的范式下——不再是"怎么把系统拆成模块"。架构是——"什么不可以交给 AI"。
第一条：接口合同——不可以交给 AI。不是 AI 写不出接口——是接口的定义必须是人类在知道双方（或所有方）需求的前提下——写下的确定性约定。AI 可以辅助——"给我生成这两种输入格式——哪一种更简洁"——但合同本身——不可委托。
第二条：数据模型——不可以完全交给 AI。表结构——字段含义——约束——这些是系统最底层的"事实"——所有上层行为——都建立在这些事实上。AI 可以生成表结构——可以优化索引——但它不能"拥有"数据模型。因为数据模型的修改——不像代码——没有办法无损回滚。数据一旦写错——它就是错的——而且你可能一年之后才发现。
第三条：不变量——必须由人类定义。一个银行系统的账目必须平衡。一个聊天应用的私聊不能被第三方读取。一个医疗系统的处方剂量必须通过上限检查。这些——不是实现——是规则。规则不能在概率分布里采样。规则必须被写死——不是写在"代码的某个分支"里——是写在系统的契约层——测试验证契约——契约约束行为。
第四条：架构决策的记录——不能只存在于 AI 的输出里。为什么选择了事件溯源而不是 CRUD？为什么这个服务被拆出来——而另一个没有？这些决策——在系统演化两年之后——是唯一能解释"为什么系统长成这样"的东西。如果你让 AI 做了这些决策——两年后没有人——包括你自己——能理解这些决策的理由。
AI 在架构中的正确位置——不是替代决策——是生成"决策空间"。
"给我三种方式来设计这个搜索模块——每一种的取舍是什么。""用 A 方案——但是帮我把它在内存中的数据结构画出来。""B 方案在三千万用户的情况下会怎样——能不能模拟一下？"
AI 的最佳使用——不是让它做决策——是让它展开"你能做哪些决策"。在 AI 之前——评估多种架构方案的成本是 prohibitive 的——你只能凭经验和直觉选一个——上船——希望船不沉。现在——AI 可以在你做出决策之前——把方案之间的比较——具体到代码层面的对比——降低到你一个人的大脑可以覆盖的程度。
这不是"AI 做架构"。这是"AI 让架构师看到更多的可能性——然后架构师选择其中一种——并承担选择的后果"。工具展开了空间——人承担了方向。
帕纳斯在 1972 年说的东西——在新的范式下——有一半错了，另一半比任何时候都更正确。
错了的那半是——"把变化关进笼子"不再是架构的核心——因为变化本身变便宜了。
对的那半是——信息隐藏的真正目的——不是"关住变化"——是"关住复杂度"。系统——在任何一个时刻——只能有若干个"活跃点"——人类能同时关注的——不超过七个。架构不是让 AI 生成一切——然后人类在 AI 的输出中溺水。架构是——定义边界——确定"在边界之内——AI 可以自由；在边界之外——AI 不能碰"。
当实现免费——架构不再是一张蓝图——它是一组边界。边界的一侧——AI 有完全的实现自由。边界的另一侧——AI 的输入不被接受。真正好的架构——在 AI 时代——不是"设计出最好的模块结构"——是"定义好界限和边界"。