AI 写代码以后，工程师更需要系统直觉

Martin Kleppmann 讲《Designing Data-Intensive Applications》第二版时，真正值得带走的不是哪些技术被加入或删掉，而是一个更大的变化：云和 AI 正在继续降低实现成本，但工程师并没有因此变得不重要，重要性反而转移到了更难外包的地方。

第一版《Designing Data-Intensive Applications》之所以影响大，不是因为它教人使用某个数据库，而是因为它把一堆看似分散的系统选择，翻译成了工程师可以讨论的权衡：可靠性、可扩展性、可维护性，背后分别对应故障、负载、演进和人的理解成本。

第二版出现时，技术世界已经换了一层地基。很多团队不再直接管理本地磁盘和数据库进程，而是把对象存储、托管数据库、serverless、流处理、向量索引和数据湖当作基础设施。与此同时，AI 开始生成越来越多代码。表面看，工程师离底层更远了，写代码也更快了。

但 Kleppmann 在访谈里反复指向同一个判断：抽象层变高，并不意味着系统直觉变得多余。恰恰相反，当更多实现细节被云服务和 AI 隐藏以后，工程师最稀缺的能力变成了知道哪里不能偷懒，哪里必须看穿抽象。

抽象省掉了操作，不会省掉后果

云服务最大的好处，是把许多过去很重的操作成本拿走了。

以前你要运行数据库，就要考虑机器、本地磁盘、复制、容量规划、故障恢复。现在，很多系统直接构建在对象存储和托管服务之上。复制可能发生在对象存储层，而不再完全由数据库软件自己处理。serverless 甚至让一个每天只有几个请求的小服务，也可以用极低成本运行。

这确实是进步。没有必要把每个应用工程师都训练成存储引擎专家，也没有必要让每个团队重复搭一遍基础设施。

问题是，抽象只会隐藏操作细节，不会取消物理和经济后果。

你使用列式存储还是行式存储，仍然会影响查询性能。你是否跨区域部署，仍然会影响成本、一致性和故障恢复方式。你依赖单一云厂商还是多云，仍然是在可用性、复杂度、价格和业务风险之间做选择。你是否理解 B-tree、LSM tree、复制、分片和时钟问题，也仍然会决定你在异常发生时能不能判断问题在哪里。

所以，系统直觉不是“会自己造数据库”。它更像一种工程嗅觉：当一个托管服务表现奇怪时，你能猜到它背后可能是哪类机制在起作用；当一个架构方案看起来很省事时，你知道它把风险挪到了哪里。

“规模”不再只意味着变大

Kleppmann 对 scalability 的解释很有意思。他没有把它说成“能支撑百万用户”，而是说成处理负载变化的能力。

这个定义放到今天更重要。过去大家讲扩展性，通常想到的是 scale up 或 scale out：机器更大，节点更多，分片更复杂。云把很多水平扩展的基础能力产品化以后，另一个方向变得同样重要：scale down。

一个系统能不能在很小的负载下便宜地运行？能不能在没有持续流量时几乎不花钱？能不能让成本和真实负载更接近线性关系？

这对很多产品不是小事。过去，低流量服务也要占一台机器或一个虚拟机；现在，serverless 和托管服务让“小但长期存在”的系统更经济。它改变了实验、内部工具、边缘服务和长尾应用的成本结构。

但这也带来新的判断题。一个团队不再只是问“能不能扛住峰值”，还要问：

这张表背后的变化是：系统设计越来越不像单纯的技术选型，越来越像把技术后果翻译成业务风险。

工程师的职责也随之变化。以前，一个强工程师常常是“能实现复杂方案的人”。现在，更稀缺的是“能说清复杂方案代价的人”。他要能告诉团队：这个多区域方案可以抗住一个区域失效，但会牺牲什么一致性；这个多云方案能降低供应商锁定风险，但会引入多少运维和数据同步复杂度；这个托管服务省掉了我们多少操作成本，又让我们失去了哪些可观察性和控制权。

AI 让代码更便宜，也让验证更昂贵

访谈里有一个判断和今天的软件工程直接相关：当 AI 写越来越多代码，工程师的工作会更少停留在“用某种编程语言表达逻辑”，更多转向高层权衡。

这句话容易被误读成“写代码不重要了”。更准确的说法是：代码生成变便宜以后，验证和责任变得更贵。

如果一个人手写所有逻辑，人类 review 还能勉强跟上。可是一旦 agent 可以生成大量代码、重构、迁移和胶水逻辑，人工逐行审查很快会变成瓶颈。你可以写更多测试，但测试只能覆盖有限样例。对于安全、数据一致性、权限、加密、支付这类高风险场景，一个小漏洞就可能破坏整个系统。

这也是 Kleppmann 重新强调形式化验证的原因。

形式化方法并不适合所有系统。它学习成本高、建模成本高，过去在工业界很难大规模采用。但 AI 改变了两边的成本：一方面，AI 让生成代码更多，增加了自动化验证的需求；另一方面，LLM 也可能帮助人生成规格、写证明、探索模型，让原本太贵的验证方式变得更可用。

短期看，普通团队不需要一下子跳到 Coq、Lean 或 Isabelle。更实际的入口是模型检查：用 TLA+ 这类工具把系统的关键行为写成规格，让工具在大量状态里寻找反例。

这不是为了追求学术洁癖，而是为了把“我觉得不会出问题”换成“我知道在哪些条件下不会出问题”。在 AI 生成代码越来越多的工作流里，这种差别会越来越值钱。

Local-first 是另一种系统权衡

访谈后半段谈到 local-first software。它表面上是一个产品理念：让用户更掌控自己的数据，减少对单一云服务的依赖。更深一层，它其实是一次系统权衡的反转。

中心化服务为什么流行？因为它简单、可控、好收费。权限判断发生在服务器上，撤销权限、同步状态、处理冲突都更直接。SaaS 商业模式也天然喜欢这种结构，因为用户的数据和工作流被托管在服务方那里，订阅关系更稳定。

local-first 则选择了另一边的价值：用户拥有数据，应用离线可用，多个设备或多个同步服务都可以参与，单一云服务不再是必须信任的中心。

这听起来很好，但工程代价很高。

一个简单的权限撤销，在中心化系统里可以由服务器裁决先后顺序。放到去中心化环境里，就会变成难题：某个用户被撤销编辑权限的同时，他又提交了一次编辑。不同设备看到事件的顺序可能不同，有的接受编辑，有的拒绝编辑，系统就可能永久不一致。用时间戳也不可靠，因为时钟会漂移，恶意用户还可以伪造时间。

这就是系统设计最迷人的地方：价值选择会生成工程问题。

如果你把商业效率放在第一位，中心化是合理选择。如果你把用户自主权、可迁移性和长期韧性放在第一位，就必须面对更难的同步、权限和一致性问题。local-first 不是“更先进所以更好”，而是为了另一组价值，主动承担另一组成本。

这对今天的产品团队也有提醒。很多架构选择看起来是技术题，其实背后是产品和商业题。云优先、端侧优先、中心化、去中心化、托管、可导出、可迁移，每一个选项都在定义用户和公司的权力关系。

工程师要重新练习“把风险说清楚”

Kleppmann 在访谈里提到伦理章节时，说工程师需要把社会风险也纳入权衡讨论。这个观点和分布式系统并不割裂。

系统设计从来不只是吞吐量、延迟和一致性。数据采集、隐私、用户锁定、算法影响、监管风险、供应链透明度，都是系统后果的一部分。工程师未必拥有最终决策权，但工程师通常最早知道一个设计会把风险推向哪里。

如果团队只把工程师当实现者，这些风险就很容易被压成“以后再说”。如果工程师只把自己当实现者，也会主动放弃这部分影响力。

AI 时代尤其如此。因为代码会更快出现，方案会更快成型，产品会更快上线。速度变快以后，原本靠流程拖延暴露的问题，会更晚才被看见。工程师必须更早地把问题说出来。

可以用一个很简单的检查表来判断自己有没有尽到系统设计责任：

这不是要求每个工程师都变成架构委员会。它只是说明，工程师的高级能力正在从“多写代码”转向“让组织看见后果”。

基础知识没有过时，只是换了入口

很多人读 DDIA，是为了补分布式系统、数据库和存储引擎的基础。到了第二版，这些基础没有变得不重要，只是入口变了。

过去你可能因为要自己搭系统而学习复制、分片、事务和索引。今天你可能因为使用托管服务、调试性能问题、评估多云风险、设计 AI 数据管线、审查 agent 生成代码，重新遇到同样的问题。

技术栈会变。MapReduce 会从主角退成历史教材，Spark、Flink、向量索引、dataframe、对象存储会进入新叙事。可是底层问题仍然在：数据如何移动，故障如何发生，状态如何一致，成本如何变化，谁来验证正确性，谁来承担系统后果。

这就是系统直觉的价值。

它不是怀旧地坚持“每个人都要懂底层”。它是在更高抽象、更快生成、更复杂依赖的环境里，保留一种判断能力：当工具说“交给我”时，你仍然知道该追问什么。

资料来源：

• The Pragmatic Engineer 访谈：Designing Data-intensive Applications with Martin Kleppmann，2026-04-22。
• O’Reilly：《Designing Data-Intensive Applications, 2nd Edition》，Martin Kleppmann 与 Chris Riccomini，2026。