本系列不推荐解决方案。不教 FastAPI、不教 LangChain、不拆 Transformer、不带你调 PyTorch 的 API。本系列只讲算法原理与设计判断——目标是让你在设计信息系统时尽可能把复杂度砍到最低而不是为了用上流行框架让客户觉得高大上去堆一套看起来很重、其实活不长的架构。一、先从一句扎心的话说起1986 年Fred Brooks 写了一篇文章叫《没有银弹——软件工程中的本质与偶然》No Silver Bullet — Essence and Accidents of Software Engineering。它后来成了软件工程史上被引用最多的文章之一。文章里最著名的那句结论是没有任何单一的技术或方法能在十年内让软件工程的生产力提升十倍。[ref:1,2,12]二十年过去了四十年也过去了。从 1986 到现在每一波银弹都来过了面向对象、UML、敏捷、SOA、低代码、微服务、云原生、中台……到今天的 AI 编程。每一波都有人拍胸脯说这次不一样这次是银弹 [ref:11]。但 Brooks 的判断至今没被推翻。为什么因为他讲的不是技术不够好而是一个更底层的东西——软件的复杂度有一部分是天生的你用什么框架都消不掉。二、他把复杂度分成了两类这是全系列的地基这是本章、也是整个系列最重要的一张表本质复杂度Essential偶然复杂度Accidental来源问题本身实现手段具体是业务规则、例外情况、领域本身固有的难度 [ref:6]语言、工具、平台的不完善或低效 [ref:6]能不能消除不可化简必然存在[ref:5]可以大幅削减谁来消除只能管理不能消灭组件化、高级语言、更好的 IDE、更好的框架 [ref:3]翻译成人话本质复杂度 “这个业务本来就难”。比如打样单逾期要判原因、订单口径要对齐、客户随时改需求——这些难是问题本身难不是你代码写得差。你换个语言、换个框架、加十个人它还是那么难。偶然复杂度 “我们自己搞出来的难”。比如为了显得专业硬套了一套分布式的架构为了用上某个流行框架把本来一张表能表达的东西拆成五个服务。这种难是我们额外加的。Brooks 的核心洞察过去几十年所有的技术突破解决的都是偶然复杂度而本质复杂度几乎原封不动。[ref:3,9]框架、语言、IDE、云——它们让实现变简单了但没有让问题变简单。也就是说框架能干掉的是偶然复杂度干不掉本质复杂度。这就是本章标题那句话的出处也是它二十年、四十年都成立的原因。三、为什么单靠一种技术/框架不可能让生产力翻十倍因为框架动的是偶然复杂度那一半而本质复杂度那一半它碰都不碰。[ref:3,9]打个比方你搬家本来 100 箱东西本质。用了更好的搬家带、更快的货车框架你的搬运效率确实提高了——但如果这 100 箱东西本身就有 60 箱是不知道怎么归类、必须现场决策的卡车再快你也搬不更快地想清楚哪箱放哪。软件就是这么个行业。大部分难难在**“想清楚要做什么”本质复杂度不难在用什么写**偶然复杂度。框架帮你解决的是后者而后者本来就不是瓶颈。所以 Brooks 的结论一点都不悲观它极其冷静不存在任何单一的技术或管理上的进展能够独自承诺在十年内让生产力、可靠性或简洁性获得哪怕一个数量级的提升。[ref:11]一个数量级 十倍。这句话到今天依然成立。四、这件事对设计系统意味着什么本章最实用的一段既然框架干不掉本质复杂度那**选一个流行框架这件事本身就不是设计系统的核心动作。** 核心动作是① 先把本质复杂度识别出来。这个业务到底是哪一部分天生就难是权限是口径是例外流程是数据不一致把它写下来。你会发现真正难的往往只有那么两三处而且跟框架毫无关系。② 再把偶然复杂度砍掉。你加的每一层框架、每一个中间件、每一次为了架构感的拆分——都在给偶然复杂度加码。Brooks 说得很清楚语言、工具、平台的不完善都是偶然复杂度 [ref:6]。而你主动引入的过度设计是其中代价最高的一种。③ 判断标准换掉“不是能不能用上而是需不需要用”。别问这个框架流不流行、客户会不会觉得高级要问它是不是刚好解决了那两三处本质复杂度。凡是不解决本质复杂度的框架都是在给未来的重构埋雷。五、一个必须说破的现实你在为了显得高级而选型时已经输了一半我把这些年看过的项目归纳成一句话一个系统的短命很少是因为技术太简单大多是因为复杂度加得太早、太多。“为了让客户觉得高大上而用重架构”本质上是把偶然复杂度当成能力卖。它短期唬得住人长期一定会反噬——因为多出来的每一层都要有人维护、有人理解、有人重构。而 Brooks 早就提醒过本质复杂度不可化简你只能管理它而你多堆的那些框架恰恰会让管理本质复杂度变得更难。这就是为什么后面每一章我都会回到同一个问题这个设计是在帮我们逼近本质复杂度还是在帮我们逃避它六、本章小结《没有银弹》的结论几十年不破没有任何 SINGLE 技术能让软件生产力十年翻十倍。[ref:1,2]软件复杂度分两类本质的问题本身不可消除、偶然的实现手段可以削减。[ref:5,6]所有技术突破解决的都是偶然复杂度本质复杂度原封不动。[ref:3,9]所以框架能干掉偶然复杂度干不掉本质复杂度。设计系统的关键动作不是选流行框架而是识别本质复杂度 砍掉偶然复杂度。下一篇第 2 章你的系统难难在哪本质复杂度 vs 偶然复杂度这一章立了银弹不存在的论。下一章我们把这把刀磨得更细用一个真实的业务场景打样单为什么会逾期、口径为什么对不上现场演示怎么把你系统的难拆成这两类并给你一把尺子——判断一个设计是在逼近问题还是在绕开问题。如果你也在被上一套先进架构逼着走关注我这个系列只讲一件事怎么少给自己加复杂度。