依然没有银弹

# 依然没有银弹 来源：https://cekrem.github.io/posts/there-is-still-no-silver-bullet/ > 在我们民间传说噩梦中所有的怪物里，狼人最令人恐惧，因为他们会出乎意料地从熟悉之物变身为恐怖之物。为此，人们寻找能用魔法将其镇伏的银弹。 软件工程领域最著名的论文正是以此开篇。弗雷德·布鲁克斯于1986年在IFIP会议上发表的《没有银弹：软件工程的本质与偶然》（http://worrydream.com/refs/Brooks-NoSilverBullet.pdf）。今年这篇论文迎来四十周年，此刻恰是指出其从未出错的良机。 这篇论文著名的论断是一个预言：**“在软件开发中，无论是技术还是管理方法，没有任何单一的进展能在十年内将生产力、可靠性或简洁性提升一个数量级。”** 人们大多只记得标题（甚至可能只是标题），而忽略了论证过程。这很遗憾，因为其论证对过去三年行业现象的解释力，比过去三年任何文字都更强😵💫。 ## 本质与偶然 （章节链接：https://cekrem.github.io/posts/there-is-still-no-silver-bullet/#the-essence-and-the-accident） 布鲁克斯将软件开发工作划分为两大范畴。 *本质*是概念性构造：相互关联的概念、数据及其关系、关于系统应意味着什么、应做什么以及拒绝做什么的决策。“构建软件的困难部分在于概念构造的规范、设计和测试，”他写道，“而非表达概念构造和检验表达保真度的劳动。” *偶然*是表达性的劳动。语法。构建工具。样板代码。二十多个几乎一模一样的工厂类（真是让人爱死Java，对吧？）。类型系统。 如果你读过我这个系列的早期文章（https://cekrem.github.io/posts/programming-as-theory-building-naur/），第一部分或许听起来耳熟。彼得·诺尔在布鲁克斯之前一年将其称为程序的*理论*：源代码仅部分体现的共享心智模型。两位学者在同一十年间从两端抵达同一结论；诺尔从观察编译器团队将程序（包括源代码和文档）移交给新程序员，却发现新人的补丁总是与原始设计冲突；布鲁克斯从观察项目错过他所见过的所有估算。两人都得出结论：编程的困难在于构建共享理解，而磁盘上的制品所承载的这种理解远少于我们的想象。 （注意：他们都没说代码很简单，尽管互联网上半数人正在断章取义。） 基于这种划分，布鲁克斯用“简单到能在餐巾纸上计算”的算术推导出他的预言：工具只能压缩偶然部分。因此，除非偶然占据你工作的十分之九，否则无论多神奇的工具，都不可能让你快十倍。本质设定了节奏。 ## 他甚至在1986年就审视了AI （章节链接：https://cekrem.github.io/posts/there-is-still-no-silver-bullet/#he-even-reviewed-ai-in-1986） 布鲁克斯不仅提出抽象预言，还亲自逐一审视当时的银弹：Ada、面向对象编程、程序验证、图形化编程——以及（！）没错，人工智能和专家系统，每个都有专门章节。他的结论始终如一：有用，部分确实有用，但都瞄准了偶然部分。 显然，1986年的AI不同于2026年的AI。但他的论证从不依赖于能力本身。关键在于帮助落入*哪个范畴*。“构建软件系统最困难的部分在于精确决定要构建什么，”他写道。任何接收规范的工具都无法解决这样一个事实：产出规范才是真正的工作。 历经四十年银弹（CASE工具、第四代语言、UML、无代码、低代码），这篇论文未尝败绩。如今它面对的是迄今最强劲的挑战者——至少若按炒作热度衡量。大语言模型可能是（我是真诚的）有史以来最有效的偶然压缩器。它们编写样板代码、搭建测试框架，还会毫无怨言地生成第二十个几乎一模一样的工厂类。我正是这样使用它们的（https://cekrem.github.io/posts/if-you-re-running-claude-code-run-it-in-a-box/），在沙盒中，在监督下使用。 ## 镜鉴 （章节链接：https://cekrem.github.io/posts/there-is-still-no-silver-bullet/#the-mirror） 如果布鲁克斯的论断正确——工具只能压缩偶然，那么每一次对AI生产力的宣称都无意中变成了一种坦白： **你的AI加速效果，衡量的是你工作中偶然部分的占比。** 如果Claude Code确实让你快了十倍，那么按布鲁克斯的餐巾纸算术，你所做的工作十分之九是*表达*的劳动，而非概念工作（或按我自己的说法：工程与技艺）。顺便说，这并非要侮辱任何人（真正的侮辱马上来）。偶然也是实实在在的工作，总得有人去做，而我们行业花了二十年制造了海量这样的工作（说这话的人可是配置过webpack，并在Azure虚拟机上启用过临时存储的😅）。对某些角色而言，比例确实如此悬殊，对此类角色，压缩是一种恩赐。 但把镜子转过来：那些报告收益平平的资深工程师并非迟钝的采纳者或否认现实的卢德分子。他们用一个数字告诉你他们一周的构成：领域对话、设计决策、命名、评审、那些关于系统应拒绝表达什么的缓慢摸索。全是本质工作，而这些工作不会因为打字速度变快就加速。 来自我桌上的一个小例子。当我为这个站点构建那个小巧的Elm推荐组件时，我让AI把一堆混乱的DOM节点转换成干净的JSON（https://cekrem.github.io/posts/claude-code-game-changer-or-or-just-hype/）——纯粹的偶然工作，为我节省了真正无聊的半小时。然后我亲手编写组件本身，耗时与2019年相差无几。并非出于原则拒绝帮助（老实说我本来会拒绝——毕竟我是为了*乐趣*才做这个的！），而是因为时间花在了决定哪些状态应不可能存在、消息应具有何种语义上。那些主张“全部交给代理”的人往往忽视了这些决策发生之处：其中一半发生在*编写代码时*，指尖敲击键盘，编译器给予反馈。根本没有东西可交托，因为编码过程正是决策发生之所。 ## “代码从来都不是困难的部分” （章节链接：https://cekrem.github.io/posts/there-is-still-no-silver-bullet/#code-was-never-the-hard-part） 这引出了一句流传甚广的话，听起来似乎与上文观点一致：“代码从来都不是困难的部分。” 你肯定听过。真正的工作永远在于需求和利益相关者会议，所以让机器处理琐碎的编码部分，释放人类去从事更高级的事务吧。 森科·拉西奇最近写了一篇回应（https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers），称这句话是对所有程序员的侮辱，他说得对。如果代码从来都不是困难的部分，为何这个行业花了二十年追寻“十倍效率忍者摇滚明星”程序员，并在白板前拷问候选人？为何有《代码整洁之道》（https://amzn.to/3VIleoE）和《计算机程序的构造和解释》（https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/index.html）存在，为何几代人将它们翻烂？你不会围绕一份工作的简单部分构建五十年的技艺文献。现在说这话的人（大多是为了推销什么）正在重写一个职业的历史。 但这并非布鲁克斯所言，无论他被多少次援引来说这句话。本质与偶然的分界线并非划在编码与其他一切之间，会议在重要一侧，键盘在琐碎一侧。它*贯穿编码活动本身*。当你编写真正的代码——选择一个名称或拒绝一个类型，感受到设计在抵制你并因此改变方向；你正在编译器的注视下从事本质工作。偶然藏匿于活动内部：抄录、仪式/样板代码、第二十个工厂类。而诺尔的核心观点，也是本系列反复强调的（https://cekrem.github.io/posts/programming-as-theory-building-naur/），在于理论并非在会议中构建然后仅仅被“实现”。它主要是在键盘前，在旧体育馆里构建的（https://cekrem.github.io/posts/coding-as-craft-going-back-to-the-old-gym/）。打字从来不是重点，进一步说：写作从来不只是打字。 因此，销售话术（“让AI写代码，这样你就能专注于重要的事”）对它的目标受众而言完全颠倒；这**恰恰是错的**。对一个配得上称号的程序员而言，编写代码是完成重要工作的主要场所。（再说一次，也别低估这部分：它也很有趣。） ## 本质鸿沟 （章节链接：https://cekrem.github.io/posts/there-is-still-no-silver-bullet/#the-essence-gap） 2025年，METR进行了一项真实的随机对照试验（https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/）：十六位经验丰富的开源开发者，在其熟悉的成熟代码库中工作，任务随机分配是否使用AI辅助。使用AI时，他们**慢了19%**。他们事后的自我估计是AI让他们快了大约20%。¹ (https://cekrem.github.io/posts/there-is-still-no-silver-bullet/#fn:1) 感知速度与实测速度之间存在约四十个百分点的差距！布鲁克斯会预言这种差距的迹象并解释其原因。加速是真实的且被*感知到*——样板代码瞬间出现，差异增大，工具明显在做事。但这些是专家，深谙其代码库，这意味着他们的工作几乎全是本质：决策、判断、基于他们头脑中系统的理论进行验证。压缩一项主要由本质构成的工作的偶然部分，你得到的正是研究所发现的：感觉更快但测量更慢的开发者。 19%还有第二个解释，即上一节的观点：对于此类工程师，编写代码是保持理论更新的方式。将写作交给工具，剩下的就是将他人的猜测与一个悄然停止更新的心智模型进行核对。那是另一份工作，更糟的工作，而秒表注意到了。与此同时，仪表盘曲线上扬，而结果停滞不前。（指向同一方向的代码重复和冗余数据，我已经讲过（https://cekrem.github.io/posts/architecture-by-autocomplete/），此处不再赘述。） 我能听到反对意见正在形成：“但自1986年以来生产力提升了一个数量级——编译器、垃圾回收、开源、云计算！” 确实如此，布鲁克斯从未否认。他的赌注是针对*单一技术*，在*十年内*，每当有人宣称射杀了狼人，这赌注都应验了。累积的进展来自数十年对偶然部分的持续削减，顺便说，这正是他关于进步如何运作的模型。 ## 培养设计师，而非提示者 （章节链接：https://cekrem.github.io/posts/there-is-still-no-silver-bullet/#grow-designers-not-prompters） 人们忘记了《没有银弹》并非以绝望告终。在拆解了市面上每一颗银弹后，布鲁克斯告诉你他认为真正的杠杆在哪里，而这根本不是技术。“提升软件技艺的核心问题始终围绕着人。”他的具体提议是以培养管理者同等的严肃性，去发现并刻意培养伟大的设计师（能从事本质工作的人）。 四十年后，这仍是全部的游戏规则，我认为赌注更高了。本质工作正是本系列的主题：理论（https://cekrem.github.io/posts/programming-as-theory-building-naor/）、无法写下的知识（https://cekrem.github.io/posts/the-tacit-dimension/）、以及传承两者的机构（https://cekrem.github.io/posts/programming-as-theory-building-part-ii/）。这些都无法压缩，且目前都因布鲁克斯算术所证明无法实现的加速之名而受到冷落。 不，这不是将人分成两个阵营。每个人的一周都包含两个范畴。周一转换DOM混乱的初级工程师，周二可能在进行团队最深层的建模。问题在于你的日程表——以及你雇主的激励机制——实际保护的是哪个范畴。 认真对待布鲁克斯所带来的习惯并不复杂： - **诚实地审视你自己的上周**：多少小时用于决定系统应意味着什么，多少小时用于表达已做出的决定？后一个数字是你任何AI加速效果的上限，值得在你经理阅读厂商基准测试之前了解。 - **将AI有意指向偶然，带着约束**：自己设定理论，让工具在其中打字——我已写过这如何运作（https://cekrem.github.io/posts/programming-as-theory-building-part-ii/），且有效。 - **保护本质时间免受速度仪表盘的影响**：设计对话和领域建模在Jira中永远显得缓慢，因为Jira只会计数偶然部分。 - **如果你领导团队：培养设计师**。布鲁克斯在1986年说过，而传承机制从未改变——学徒制、代码评审、在懂行的人身边工作（https://cekrem.github.io/posts/the-tacit-dimension/）。没有任何提示能培养出设计师。 布鲁克斯以*人*结束他的论文，我也将以他结束本文。这个行业目前正花费数千亿美元于有史以来最闪亮的子弹，其目标——如同之前的每一颗——直指怪物那从来不是问题的部分。当“十倍收益”持续未能体现在资产负债表上，而餐巾纸预言它们将继续失败时，企业将寻找那些能推动本质的人：当其他人都在压缩偶然时，他们仍在持续构建理论的人。 代码始终是它一直是的那样：一门技艺，而非已解决的问题。（而且猎杀狼人很有趣。）