一、一个反直觉的命题：别再造"面向未来"的系统
ACM Queue 最近连发的几篇文章——Building Malleable Systems, not Future-Proof Ones、The Second-System Pit of Failure、KV the Apostate、The Important Decision Document——表面上看是松散的随笔合集，串起来读则像一份对软件工程主流范式的"罪状清单"。
这些文章共同指向一个反直觉的命题：
过去三十年我们孜孜以求的"future-proof 架构"——抽象层、配置驱动、插件机制、微内核、一切皆策略——并没有让系统更适应变化，反而让它们更难改。真正能活下来的系统，是 malleable 的：可拆、可改、可被使用者当场重塑，而不是被原始作者预先一劳永逸地"构想完毕"。
这不是又一篇喊"YAGNI"的口水文。它指出的是更深的结构性失败：当我们试图预测未来需求并把它们编码进抽象层，我们其实在 冻结一组今天的假设，然后逼后人在这组假设的笼子里折腾。十年后笼子还在，需求早变了。
二、Future-Proof 的三种典型死法
把 ACM Queue 这几篇里的反例提炼一下，可以归纳出"面向未来"系统的三种典型死法：
死法 1：抽象层成了化石层
最常见的故事：团队为了"以后可能换数据库"，在 ORM 之上又封装一层 DAO；为了"以后可能换消息队列"，在 Kafka 客户端外面再包一层 EventBus 接口。五年后:
- 没换过数据库，但所有人都要先看三层抽象才知道一条 SQL 是怎么跑的；
- 真要换的时候，发现抽象层只覆盖了 80% 的能力，剩下 20% 全是泄漏的实现细节；
- 抽象层的维护者早就离职，新人只敢加，不敢删。
ACM Queue KV the Apostate 把这种现象叫做"抽象的化石化"——抽象本是为了流动性，结果反而成了沉积岩，每一层都是某一年某个工程师对未来的猜测，叠加起来变成无法穿透的地层。
死法 2：第二系统综合症的现代变体
Fred Brooks 在《人月神话》里讲的"第二系统效应"在 2026 年有了新形态。今天的"第二系统"不再是从大型机迁移到 minicomputer，而是：
- 把单体拆成微服务，每个服务又内嵌"插件框架"；
- 把简单的 CRUD 重写为 CQRS + Event Sourcing + Saga；
- 把内部工具改造成"平台"，再为这个平台造一个 DSL。
The Second-System Pit of Failure 的核心论点是：每一次重写都假设"这次我们考虑得更全"，但全面性本身就是陷阱。一个考虑了所有未来场景的系统，等于把所有场景的复杂度今天就交付了，而真正落地时只用其中 5%——剩下 95% 的复杂度是纯负债。
死法 3：决策文档的不可逆性
The Important Decision Document 讲的是另一个隐性问题：架构决策一旦被写进 ADR（Architecture Decision Record）、被 review、被批准，就获得了一种社会-政治层面的不可逆性。哪怕三年后所有人都觉得这个决策错了，要推翻它需要的不只是技术证据，还要有人愿意承担"否定前任 staff engineer"的政治代价。
于是系统继续在错误的地基上叠加。
三、Malleable Systems：可塑性优于可扩展性
那么"可塑系统"长什么样？这组论文给出的答案不是一个 framework，而是一组设计倾向：
| 维度 | 传统 Future-Proof | Malleable Systems |
|---|---|---|
| 抽象策略 | 预先抽象、统一接口 | 后置抽象、按需提取 |
| 配置 | 大量配置项、Feature Flag | 少配置、读代码即知行为 |
| 扩展点 | 通用插件机制 | 用户可直接 fork 子模块 |
| 状态 | 统一存储、强一致 | 局部状态、用户可见可改 |
| 数据格式 | 二进制、版本协商 | 文本可读、可手工修改 |
| 升级路径 | 中心化迁移脚本 | 数据自描述、向前兼容 |
| 失败模式 | 全局回滚 | 局部降级、用户可介入 |
注意：这不是"敏捷 vs 瀑布"的老套对立，而是关于复杂度何时偿付的根本分歧。
- Future-proof：今天先为未来付出复杂度，希望未来收益。
- Malleable：今天保持简单，把变化的成本留到变化真正发生时偿付，但保证那时偿付的代价是线性的、可见的。
后者押注的是一个经验事实：在过去 30 年的软件历史里，准确预测 5 年后需求的概率几乎为零，而把简单系统重塑为新形态的成本，通常远低于把复杂系统改为另一种复杂形态。
四、为什么 2026 年这件事突然重要起来
可塑系统的理念其实不新——Smalltalk、Lisp Machine、HyperCard、Notion 早期版本都是这个谱系。它在 2026 年突然被 ACM Queue 重新拎出来，是因为三个新变量同时出现：
变量 1：AI 让"重写"的成本数量级下降
当 AI 编码助手能在几小时内重写一个 5000 行的子模块，“以后可能要重写"不再是噩梦。这意味着：预先抽象的 ROI 在崩塌。如果重写代价是 1，预先抽象的代价是 10，那么"赌一把简单"几乎永远胜出。
这一点很多团队还没意识到。AI 不是让我们能造更复杂的系统，而是让"保持简单 + 必要时重写"第一次变成主流可行选项。
变量 2：监管和合规要求"系统行为可解释”
GDPR、欧盟 AI 法案、金融数据本地化……一个被七层抽象包裹的系统已经无法回答监管者的问题：“这条用户数据从输入到删除经过了哪些组件？” 可塑系统因为层数浅、行为可读，反而更容易满足合规审计。
变量 3：分布式系统的复杂度已逼近人类认知极限
ACM Queue 另一篇 Knowledge Graphs over Two Decades 提到一个数据：典型云原生应用的依赖图节点数从 2010 年的 ~30 涨到 2025 年的 400+。这个数字接近人类工作记忆的硬上限。任何要求"全员理解全局"的架构都已经物理上不可能。可塑系统通过承认局部理解就够了，绕开了这堵墙。
五、落地建议：从"控制变化"到"承载变化"
对工程团队，这意味着几个具体的实践转向：
- 先实现，后抽象。除非同一种模式在生产代码里出现 ≥3 次，否则不提取抽象层。Don Norman 的"涌现的设计"原则在代码上同样适用。
- 优先文本格式。配置、协议、数据交换尽量保持人类可读、可 grep、可手工修改。Protobuf 优雅，但牺牲了凌晨 3 点用 vim 救火的能力。
- 本地状态优先于全局状态。能放在用户客户端的不放在服务端，能放在单服务的不放在共享数据库。状态分散是可塑性的物理基础。
- 决策文档加"反悔机制"。每份 ADR 都附带"什么条件下应当推翻这个决策"，把否决权预先合法化，避免社会成本锁死技术演化。
- 拥抱重写，但小颗粒。把"重写"从五年一次的大工程拆成每月一两次的子模块替换。AI 工具让这件事第一次可行。
六、一个更大的判断
如果把 Malleable Systems 这组论文放在更大的尺度上看，它其实在宣告一个时代结束：
企业级软件 1990–2025 的’平台化、抽象化、配置化’范式，正在让位于一个新的’可塑、可读、可重写’范式。
这个转向的根本驱动力不是哲学，而是经济学——AI 改写了重写的边际成本曲线，监管改写了透明度的合规价值，复杂度上限改写了集中式架构的可行性。
接下来 24 个月，最值得观察的不是哪家公司发布了新的"AI Native 平台"，而是哪些敢于砍掉自己抽象层、把代码放回到接近问题本身的团队，能在效率和可维护性上拉开差距。这是一个安静但深刻的转变：软件工程在重学如何拥抱变化——不是通过预测它，而是通过让自己不再害怕它。
引用来源
- Building Malleable Systems, not Future-Proof Ones: Design for Change — ACM Queue
- The Second-System Pit of Failure — ACM Queue
- KV the Apostate — ACM Queue
- The Important Decision Document — ACM Queue
- Knowledge Graphs over Two Decades — ACM Queue
- Fred Brooks, The Mythical Man-Month
- Malleable Systems Collective
