从未实现“工程化”的软件工程(写在《AI 时代人月神话》出版之前)

第一个深夜，2024 年 7 月 19 日。

网络安全公司 CrowdStrike 推送了一次传感器配置更新。这次更新触发了一个驱动程序里的逻辑缺陷：在某些特定条件下，驱动试图访问一个已经被释放的内存地址。Windows 内核不允许这种行为，于是系统蓝屏。

麻烦在于，这个驱动在系统启动阶段加载。每次重启都会再次触发同样的崩溃。设备陷入无限重启循环，不像普通蓝屏那样重启就能恢复。

微软事后统计：全球约850 万台Windows 设备受影响。机场登机系统和行李分拣瘫痪，数千架航班取消；银行 ATM 和柜台终端离线；医院电子病历和手术排程中断，非紧急手术推迟；美国多个州的 911 紧急呼叫系统故障，最长中断两个多小时。

而这一切的源头，是驱动文件里一行对已释放内存的引用。

第二个深夜，2026 年。

一位工程师在一个技术论坛上这样描述她的日常工作：

"我现在打开 IDE，第一件事不是想我要做什么，而是看 Copilot 给我什么。它给我一段代码，我稍微改改，按 Tab。再给一段，再 Tab。下班前一看，今天的 commit 量是去年的 1.5 倍。"

她的话让周围的人频频点头。没有人觉得这有问题。

这两个深夜之间，隔着软件工程史上最深的一道裂缝。

第一个深夜告诉我们：一行代码的重量，可以压垮半个地球的数字基础设施。我们花了半个世纪，以惊人的速度把人造的数字化系统铺满整个地球，而我们用来驾驭这套系统的工程方法论，始终在追赶它膨胀的速度。

第二个深夜告诉我们：我们正在用一种看起来更高效的方式，悄悄放弃对这套系统的理解权。

这本书，写的就是这两个深夜之间的那段路。

判断一：软件工程从未真正"工程化"过

这句话听起来像是在骂人。它不是。它是一个可以被严格论证的事实。

先看什么叫"工程化"。

1788 年，瓦特的离心调速器被装上蒸汽机。这是人类工程史上最被低估的一个装置：它把"让蒸汽机保持恒定转速"这件事，从一个人的手艺，变成了一台只需投入能源就能持续产生该输出的物理装置。

工程化的本质操作，从来不是帮助人做得更好。它是：找到人脑中某一段可以被精确定义的认知回路，然后用一种只需投入能源就能持续产生该输出的装置或流程，把它替代掉。

化工是这样的，不再依赖老师傅闻味道、看火候，而是用反应釜的温度、压力、流速曲线把产物规格固定下来。电力是这样的。土木也是这样的。系统设计的精度替代了人的手艺。

那么软件呢？

五十多年过去了。我们有了高级语言、分时系统、面向对象、IDE、自动化测试、CI/CD、DevOps、平台工程、可观测性。我们有了这一切。

但软件依然是人一行一行写出来的。它最终的质量，依然取决于写它的那个人对问题的理解深度，以及他对自身错误的自觉程度。

这五十年里所有的方法论，不管取得了多么了不起的成就，本质上都是在更精巧地"管理人"，而不是"替代人"。

结构化编程管理的是人的控制流。面向对象管理的是人的数据流。敏捷管理的是人的协作节奏。DevOps 管理的是人的交付管道。它们全都有效，全都了不起，但它们一个都没有碰那个核心：把"理解问题→解决问题"这段认知回路，从人脑里摘出来。

原因是诚实的：这段认知回路中的抽象建模、意图理解、模糊需求的形式化翻译、跨领域的全局权衡，都属于人类认知的高阶部分。它在过去无法被精确定义为一组在给定输入下具有确定性输出的规则。

直到大模型出现。

这是本书最重要的一句话，也是全书的思想支点：

我们正在见证的，不是一次工具升级，而是软件工程这门学科的"真正降临"。就像 19 世纪初的工匠亲眼看着蒸汽机改写他们赖以生存的整个生产体系。

正视这个事实，决定了你如何看待 AI。如果你把 AI 理解成更好的代码补全，你会用它提速 30%，然后困惑为什么团队并没有真的变强。如果你把它理解成认知引擎的降临，你会开始问一个完全不同的问题：

我有没有能力，重新设计我的软件产线？

判断二：Copilot 模式是一条历史性的弯路

这个判断会让你不舒服。

1910 年，很多工厂做了一件在当时看来非常进步的事：把蒸汽机拆掉，换上电动机。动力源升级了，效率提升了，大家都挺满意。

但为蒸汽机时代设计的天轴和皮带，一根没动。

整个厂房的布局、传动结构、生产流程，依然是围绕一根中央天轴通过皮带把动力分给所有机器这个蒸汽机时代的范式设计的。电动机真正的革命性应该是每台机器可以有自己的独立电机、可以按工序重新排列产线、可以彻底重构生产组织方式，这个后面等了几十年后才被释放出来。

而历史一再证明：在旧范式里优化得越好，离新范式反而越远。

今天的"人为中心 + AI 辅助"模式，就是那根没被拆掉的天轴。

先说一句公道话：AI一次写不对，需要循环来改进本身没有错。

很多人把问题归咎于 AI 不够聪明，才需要反复修改，然后寄希望于下一代模型一次做对。这个判断只对了一半。

人自己写代码，本来就是写、测、改、再测、再改的循环。凭什么要求 AI 一次做对？

真正的问题不在有循环，而在循环里最有价值的三件事，全被省略了。

第一件：观察 AI 每一轮怎么错。AI 给了一段代码，你看了觉得不对，动手改了。改完继续工作。那一次"它错了"和"你怎么改对的"之间的差异，消失在时间里，没有任何地方记录它。明天同样的上下文，它还犯同样的错，你还得再改一次。

这不是在训练一条产线，这是在无穷无尽地手动兜底。

第二件：把后置的质量管控搬到前置。AI 的代码合进主干，CI 挂了，回滚，人手动修，再提交。这个流程"能工作"，但每一次质量把关都发生在最晚的时刻。

一个团队用 Copilot 一年，如果它的 Spec、知识库、lint 规则、类型定义没有比一年前更严格更精确，那它就是在空转。

第三件：把最厉害那个人的品味蒸馏成 Skill。一个团队真正的护城河，从来不是我们有多少行代码，而是资深工程师做决策时依据的那些说不清但确实在起作用的判断。

这件事在过去五十年从未真正成功过。Wiki、KM、SOP 手册，每个组织都试过，每次都失败。因为知识不会自然流淌出来，它必须被具体的问题和场景逼出来。

而 AI 交互本身，正在第一次工业化地生产这种场景：每一次 AI 生成得不够好、被资深工程师改动，都是一个"品味逼问"的窗口。不是让他"总结经验"，而是问他"你为什么这么改，而不是那样改"。

这三件事要么一起做，要么等于一件都没做。

只观察不前置管控，你记了一堆日志，产线永远不会自愈。只前置管制不蒸馏，你的 lint 和 Spec 只能覆盖能形式化的部分。只蒸馏不观察，几个月后那些品味就过时了。

Copilot 模式的病灶就在于：它没有为这三件事留任何接口。你就算想做也做不了，因为拒绝某段代码的信号，进了模型厂商的服务器，没进你团队的资产库。

于是你会得到这本书里最刺耳的一个词：

数字佃农。 你付了月费，还贡献了数据，用两样东西换了当下的便利。AI 厂商用你提供的数据训练更好的模型，然后卖给更多的团队，包括你的竞争对手。

你在别人的土地上耕作，你的劳动产出归地主所有。

而这不是阴谋，是耦合动力学的必然分配：你不爬坡，坡就长在别人身上。

判断三："AI 吞噬软件"，是一个被混淆的命题

近两年流行一种论调：AI 会吞噬软件，未来不再需要写那么多代码。

用 Brooks 的本质/偶然复杂性这把尺子一拆，它的边界立刻清晰。

第一层误读，是把"业务逻辑层的重构"当成了"代码本身的消亡"。

确实有一大类代码正在被接管：与用户交互有关的部分、流程编排与控制的部分、以及大量本来就可以用自然语言直接表达的业务规则。这部分代码的减少是真实的。

但另一大类代码的消失，与 AI 毫无关系。企业软件里大量的历史遗留，比如过度耦合的模块、没解耦干净的分层、早已无人调用的死代码、为兼容旧版本保留的分支，这些本来就该消失。它们还在，不是因为业务需要，而是因为过去没有人负担得起清理它们的成本。

这是偶然复杂度的清理，不是 AI 的吞噬。

分清这一点很重要，因为它决定了你的行动：如果你以为 AI 会让代码消失，你就会等着它发生；如果你看清消失的那部分是偶然复杂度，你就会知道，那是一次必须主动发起的重建，不会自动到来。

第二层误读更隐蔽：以为"交互越自然，底层就可以越轻"。

智能应用的悖论在于，越是强调自然语言交互的 Software 3.0，越需要底层代码的硬核支撑。

大模型接管的是理解意图和组织行动，它没有接管确定性地执行。当交互层变得模糊、灵活、充满歧义，下方就必须有一层绝对不含糊的东西把它兜住。

金融交易中的风控规则必须由确定性的代码保障，而不能完全交给大模型的黑箱判断。这不是保守，是责任归属的必然：一个可以接受"大致正确"的推荐系统，和一个不能接受"大致正确"的清算系统，对确定性的要求根本不在同一个量级。

AI 会让一部分代码减少（本质复杂度、可用意图表达的部分），也会让一部分代码消失（偶然复杂度的历史遗留），但它同时要求另一部分代码变得更硬、更精确、更不可妥协。减少与加固，同时发生。

判断四：0 人工代码，不等于 0 人工接管

这是过去两年 AI 化项目里出现频次最高的自欺欺人。

自动驾驶圈流传着一个经典判断：L2 做得越好，距离 L4 越远。

L2 是辅助驾驶，人类主导。L4 是无人驾驶，系统完全主导。表面看是同一条路上的两个里程碑，实际上它们之间隔着一道物种鸿沟，穷尽一生打磨一匹马的缰绳，它也不可能变成一辆汽车。

四重悖论解释了这道鸿沟为什么跨不过去：

责任倒挂。L2 越丝滑，人越容易陷入"自动化自满"。GitHub 2024 年的一项内部研究发现：Copilot 生成的代码中安全漏洞比例与手写代码相当，但被开发者发现并修复的比例显著低于手写代码。AI 生成的 bug 不是更容易有，而是更不容易被人发现。你对手写代码有责任感，对 AI 生成的代码有疏离感。

路径锁定。一个在 L2 规则框架里深耕五年的团队，它的组织架构、验证方法论、数据闭环、人才认知，全部被锁死在规则思维里。越成功的 L2 团队，这堵墙越厚。

成本陷阱。"现在不是挺好的吗？"这句话，和那些保留旧传动轴的工厂主在 1910 年说的一模一样，它不是傲慢，是被当前的成功蒙蔽了双眼。

数据诅咒。Copilot 的训练数据是 GitHub 上的公开代码，结构清晰、规范工整。但真实企业系统的"地狱级长尾"，无人维护的遗留巨石、千奇百怪的内部依赖版本冲突、只有一个老员工知道为什么不能升这个库、只在凌晨三点触发的偶发性内存泄漏，这些永远不会出现在开源语料里。

放到 AI 编程里，这道鸿沟有一个更精细的版本：

"0 人工代码"不等于"0 人工接管"。

在临界点之前，即使 AI 代码占了 80%，只要人还在 review、还在合并，责任归属仍然是"人主 AI 副"。跨过临界点之后，即使只是从 80% 升到 95%，责任结构已经完全反转，出了事，谁签字？谁担责？？

如果你的团队在庆祝"AI 代码占比达到 80%"，却仍然维持着"人主 AI 副"的责任结构，你在老的阶段。任何"我们已经进入无人化"的自我评价，如果不同时改变责任结构，都是幻觉。

判断五：那些"失败"的废墟，恰好是新地基

这是全书我最喜欢的一条逆向叙事。

1987 年，David Parnas 在 ICSE 上发表了一篇著名的论文，题为《软件工程：一场未完成的婚姻》。他的核心观点是：软件工程自称"工程"，但它缺乏真正的工程学科根基。

三十多年后回望，Parnas 的批评依然成立。

过去五十年那些不断被提出、被尝试、又被归入"未能彻底解决问题"之列的东西，比如形式化验证、极限编程的持续集成、面向对象、敏捷宣言、UML、CMM加在一起，并没有让软件开发的失败率降低到可接受的工程水平。

但故事的另一面是：这些“失败”留下的遗骸，恰好构成了让 AI 的概率性输出变得工程级可靠的那套基础设施。

CI/CD 流水线、自动化测试框架、类型系统、静态分析工具。

这不是一个"努力了五十年终于成功了"的故事。这是一个"努力了五十年，然后出现了一个新问题，而之前所有的努力凑巧正好能解决这个新问题"的机缘。

为什么必须靠这套东西，而不是靠更聪明的模型？

因为有一个反直觉但致命的认知偏差：AI 的"自信"和"正确"之间没有相关性。

它可能以完全相同的确定语气，生成一段完全正确的代码，和一段包含微妙错误的代码。你在阅读时感受不到任何这段是不是不太对的信号。它的"确定性"只是在这个训练分布中，这段代码的 token 排列概率最高，而不是这段代码在逻辑上是正确的。

所以裁判必须是外部的、确定性的、机器可执行的，因为 AI 自己识别不了自己什么时候在瞎编。

而这场范式转换里最有意思的一件事是：测试的主要受众，从人变成了 AI。

过去你写测试，是为了让自己和团队有信心这段代码是对的。现在你写测试，是为了给 AI 一个你做对了还是做错了的信号。没有这个信号，AI 是在黑暗中投篮的球员；有了它，AI 是一个能看到记分牌的球员。

这也意味着覆盖率的标准必须重写。Software 1.0 时代 80% 的覆盖率可以接受，因为人类开发者有能力在脑海里补上没被覆盖的路径。但 Software 3.0 时代，80% 意味着 AI 生成的代码有 20% 完全不受验证保护。

一个裁判看不到的地方，就是错误可以肆无忌惮地存在的地方。

太阳底下无新事。这从来不是一句哀叹，而是一声敬意。

判断六：你的新位置，是"偏差拉回者"

自动化史上有一条 150 年未失效的铁律。

从织布机到控制室，从化工反应釜到核电站控制室，每一次自动化升级，人的位置都发生了同一件事：他没有消失，他往边界移动了。

自动化越彻底，人的位置越往"边界"移动，而不是往"消失"移动。他被从每一步的执行者，推到了系统跑偏时把偏差拉回来的那个人。

AI 时代，这个角色有了三个名字：

产线设计师。你设计的不再是一个用 AI 的工作流，而是一条能自我进化的 AI 产线。

认知边界守卫者。处理 AI 拉不回来的那些偏差。这要求你同时具备三样东西：比 AI 更深的领域知识（否则识别不出它错在哪）、比普通人更强的元认知（能判断 AI 的判断本身是否合理）、以及形式化思维（能把模糊偏差转化为可验证的规则）。

价值定义者。质量还是速度，安全还是可用性，通用性还是专用性，这些不是技术问题，是价值判断。AI 可以帮你实现更快或更安全，但无法帮你判断在当前情境下哪一个更重要。

这里有个残酷但清醒的结论，我把它叫做递归一致性：

没有哪一类角色是"被特殊优待保留"的。 所有团队都会在它对应的确定性裁判成熟时被产线化吸收，然后人退守到该产线的边界监督位。

这适用于执行层的编码和测试，适用于协调层的编排调度，甚至适用于产线设计师本身。安全感不应该建立在"我的岗位无法被自动化"的幻觉之上。它应该建立在"我始终在工程化边界的外侧"的持续修炼之上。

这不是一个你可以到达后就能停下来的位置。它是一个你需要不断向上移动的动态过程。

判断七：慢，是 AI 时代最稀缺的战略能力

全书最后落在一个行动哲学上。

"正确战略方向下的慢，远远好过错误方向下的快。"

在一个 AI 让一切加速的时代，这句话听起来像不合时宜的异端。但正因为一切都在加速，"慢"反而成了一种极度稀缺的战略能力。

什么是"正确的慢"？

• 引入 AI 编码时，先花三周定义规范和验收体系，再让 AI 参与核心代码，而不是第一天就放 AI 进去，三个月后发现代码库变成了没有人能完全理解的泥潭。
• 架构演进时，在每次加个临时方案的诱惑面前停下来，追问六个月后我们会不会后悔。因为经验反复告诉我们："后面再改"在绝大多数情况下意味着"再也不改"。
• 团队建设时，花时间做代码审查、写设计文档、做知识分享。这些事在当周看耽误了写代码的时间，但当季度和当年看，省下了无数次重复沟通和返工的时间。

软件工程有一个残酷的速度颠倒效应：当下越快的决策，后续越慢；当下越慢的投入，后续越快。

跳过测试写代码很快，但 bug 的修复时间是写测试时间的数倍，而且这个倍数随系统复杂度非线性增长。跳过架构设计直接撸代码很快，但架构腐化后的重构成本是指数级的。跳过规范写 AI 提示词很快，但 AI 输出质量会随需求复杂度增加断崖式下降，因为你没给它足够的"正确指南"。

有一支团队把整条业务线从 Copilot 模式切换到规范驱动模式，用了六个月。

第一个月，生产力指标下降约 15%。第二个月恢复基线。第三个月超过基线约 20%。第六个月，比迁移前提升约 60%。

第一个月的"没有产出"不是失败，是必要投入。

那个团队后来说过一句让我印象很深的话：

"第一个月我们不是在开发，是在给自己造一台机器。第二个月机器造好了，交付才开始。"

尾声：代码会老去，人会传承

写到这里，我想说一件在整本书的工程讨论里常常被忽略的事。

代码是所有人类记录介质中寿命最短的一种。

你五年前写的代码，大概率已被重构、替换或废弃。十年前的代码如果还在线上运行，通常被称为遗留系统，这是一个带有贬义色彩、暗示着"应该被替换"的词。二十年前的代码是考古遗迹。三十年前的 COBOL，是数字遗产。

代码的短命不是偶然的。它是活的，必须持续被修改以适应变化。代码是为了"被使用"而创作的，而使用本身在改变它、甚至毁灭它。

但代码所承载的东西，不是代码本身。

一个支付系统的代码，记录了那个时代对"信任"的工程表达。一个医疗系统的代码，记录了一群人对"生命"的算法化理解。当代码被废弃、被重写、被遗忘时，那些关于人类如何组织世界、如何在不确定性中做出判断的智慧，并没有消失。

它被传承了下去，不是以"那行代码"的形式，而是以"后来所有代码"的形式。

你今天写下的每一个设计模式，是 1994 年四个人合写的一本书里定义的。你今天遵循的每一条敏捷原则，是 2001 年十七个人在雪鸟滑雪场签署的一份宣言里提出的。你 IDE 里那个"提取方法"的快捷键，背后是 Martin Fowler 在 1999 年那本《重构》里系统化的。你现在愤怒地对着 eslint 红色波浪线咒骂的那条"函数不能超过 50 行"。这个可能来自 1970 年代 Dijkstra 的思想，经过几代人的提炼，最终变成了一条自动执行的规则。

它们没有以"那行代码"的形式活下来，它们以"后来所有代码"的形式活了下来。

软件工程的代际传承，是活的知识在活的人群中的流动，不是文件的归档，而是心智的播种。

所以，这本书不叫"AI 会做什么"，它叫《AI 时代的人月神话》。

因为真正值得被记住的，从来不是哪一代工具赢了，而是每一代人在驾驭复杂性的过程中，付出的智慧、责任和审美。

关于这本书

《AI 时代的人月神话（副标题待定）》茹炳晟、王鹏程、朱征宇 著｜清华大学出版社

全书四篇二十章，约 26 万字：

• 溯源篇：1968 · 没有银弹 · 人月神话 · 方法论的钟摆
• 围城篇：规模与复杂度 · 生长的代码 · 技术债的滞后审判 · 救命治病养生 · 度量的尺度
• 跃迁篇：认知引擎降临 · 从补全到智能体 · Software 3.0 · 历史性的弯路 · 失败的废墟即新地基 · 新复杂度与新技术债 · 评测的真相 · 雪崩与涟漪
• 共生篇：从代码工匠到 AI 牧羊人 · 新工程治理与长期主义
• 终章：代码会老去，人会传承

它不教你如何写好代码，市面上已经有很多这样的书，而且它们的保质期都很短。

它试图回答的是另一个层次的问题：在一门只有五十多年历史、却已经深刻重塑人类文明的年轻学科里，那些写下代码的人，究竟在与什么搏斗？他们又在守护什么？

如果你此刻心里带着一些不安，关于你的职业前景、关于 AI 是否会让你花了十年积累的手艺一夜贬值，这本书不会简单地安抚你。

它会诚实地面对这个行业正在经历的结构性变化，诚实地分析哪些正在被替代、哪些不会、在什么条件下不会。它会把软件工程放回人类工程文明的整条时间长河里，让你看到：你不是第一个面临自己的手艺被机器重写的人，也不会是最后一个。你是这条长河里的一代人，而每一代人都有自己的仗要打。

这个过程让人不安，也让人兴奋。确切地说，这两个感受根本就是同一种感受的两个名字。

你现在站在历史的什么位置，决定了你该往哪个方向走。

新书已经写作完成，编加工作即将开始，相信很快能够上市，敬请期待。