第一章 · 两种复杂度

去年我搬了一次家。搬完那天晚上，坐在纸箱堆里，我突然意识到：这一天里我做的事情，可以干净地分成两类。

第一类，只有我能做：这套书哪些留着、哪些送人；新家的柜子怎么分区，锅放在伸手就能够到的地方；孩子的书桌靠窗还是靠墙。这些事没人能替我决断，因为答案藏在我自己的需求里——我的生活习惯、我的家庭结构、我未来十年的打算。

第二类，我其实不该做：研究哪种纸箱最结实、比价三家搬家平台、搞清楚货拉拉的高速费怎么算、跟物业预约货梯、把书一本本捆好防止散架。这些事烦琐、耗神，但和「我要过什么样的生活」毫无关系。它们存在，只是因为搬家这件事的中间环节太多。

用一个词来称呼这两类事：

必要复杂度，英文叫 essential complexity——问题本身自带的、绕不过去的复杂性。只要你要搬家，「哪些东西值得带进新生活」这个复杂性就永远在那儿，谁也消灭不了它。

表面复杂度，英文叫 accidental complexity——因为工具、流程、中间环节而额外长出来的复杂性。它不该是问题的一部分，只是你恰好在用笨拙的方式解决问题。

这个区分，是软件行业最重要的一次「想明白」

1986 年，IBM 大型机操作系统 OS/360 的项目经理 弗雷德·布鲁克斯（Fred Brooks）写了一篇著名的论文《没有银弹》。在此之前，他已经在《人月神话》里记录过一个惨痛事实：给一个延期的软件项目加人，只会让它更延期。

《没有银弹》的核心论证，就是我们刚才搬家悟出的东西。Brooks 说，软件开发的难度来自两个完全不同的源头：

• 本质的困难：问题域本身的复杂性。一个银行账户系统之所以复杂，不是因为编程语言难，而是因为「转账」背后有一整套业务规则——透支怎么办、并发转账怎么办、退款走哪条路径、月底对账怎么对。这些规则是银行这个现实世界自带的，你把程序员全换成天才，规则一条也不会少。
• 偶然的困难：工具带来的复杂性。得自己管理内存、得记住某个框架的配置文件怎么写、得搞定环境依赖、得等编译。这些困难不是「转账」这个问题要求的，是「用这台机器、这门语言、这个框架」这个选择带来的。

Brooks 的断言是：过去几十年软件变快，几乎全部来自偶然困难的下降；而本质困难几乎没被触碰。所以「没有银弹」——不存在一种技术能让软件生产力十倍提升，因为它瞄准的只能是偶然那一半。

为什么这个区分值得你花三分钟

因为它直接决定你该把力气花在哪。表面复杂度的正确应对是外包、自动化、消灭——能交给工具的绝不自己动手。必要复杂度的正确应对是直面、想清楚、亲自决策——能外包的恰恰是你最不该外包的部分。

搬家时，你可以雇一个搬家公司，把纸箱、货梯、货车这些表面复杂度整个买走。但你没法雇一个人替你决定「什么值得留下」——那是你的必要复杂度，请了人它也不会消失，只会被胡乱决定。

软件世界也一样，只是尺度更大。接下来的问题是：既然这个区分 1986 年就被讲清楚了，为什么四十年里程序员们的主要精力，仍然耗在表面复杂度上？AI 这次又到底改变了哪一半？

别急，我们一层一层来。下一章，先看看表面复杂度是怎么一层一层长出来的。