程序员隐退，建造者闪耀 (Programmers fade, but builders continue to shine)

程序员隐退，建造者闪耀 (Programmers fade, but builders continue to shine)

1957年，Edsger W. Dijkstra 在阿姆斯特丹结婚时，按照荷兰习俗需要在登记表上填写职业。他写下“programmer”(程序员)，却被市政当局无情驳回——理由很简单：法律上“没有这个职业”。最终，为了顺利完婚，他的结婚证书上只能妥协地填上“theoretical physicist”(理论物理学家)。

这个带点荒诞色彩的小插曲，恰恰映照出“程序员”这一职业在诞生之初，是多么边缘、新生且不被主流社会所认可。

然而，正是这位当年连职业身份都不被承认的先驱，在接下来的几十年里，试图将“编程”这门手艺，生生拔高到了如同纯粹数学一般神圣且严谨的地位。他给真正的“程序员”设定了极高的智力期望值，也正因如此，他对后来一切试图“降低编程门槛”的世俗化尝试，都报以怀疑和批评。

1978 年，Dijkstra 专门撰文(EWD 667)痛批了“自然语言编程”的愚蠢。他指出，形式化符号系统是人类历史上最伟大的发明之一，正是因为它能 “排除用母语几乎无法避免的各种胡说八道”。如果让机器听懂自然语言，只会把逻辑严密的负担从人转移到机器，让沟通界面变得更宽、更危险。

十年后的 1988 年，Dijkstra 在得克萨斯大学奥斯汀分校写下了著名的 EWD 1036：《On the cruelty of really teaching computing science》。在这篇被后人反复引用的檄文中，他对当时试图用管理学拯救软件危机的“软件工程”学科，表达了刻薄的批评：

“Software engineering has accepted as its charter ‘How to program if you cannot.’” (软件工程已将“如果你不会编程，该如何编程”作为其宗旨。)

他甚至给这门学科贴上了“注定失败的学科”的标签，认为它的存在前提自相矛盾：试图用流程、文档和管理技巧，去掩盖一个残酷的事实——很多人根本无法驾驭编程的智力挑战。

Dijkstra 批评精准地击中了软件开发的核心痛点：软件内在的复杂度和智力门槛，是无法被绕过的。 这与 Fred Brooks 在《没有银弹》中的断言共鸣。正如 Brooks 所指出的，无论是多么精妙的管理学流程，还是多么先进的开发工具，它们顶多只能消除编写代码时的 “偶然复杂性”(Accidental Complexity)。而软件的“本质复杂性”(Essential Complexity) ——那些盘根错节的业务逻辑、状态空间的约束以及严密的概念结构——永远无法用任何神奇的“银弹”来自动消解，它必须由人类的心智去直面和驾驭。

产业演进的三个公式

然而，产业的发展并不会停留在纯粹的象牙塔里。我在《构建之法》中，曾用三个递进的公式来总结这个行业的演进脉络：

1. 程序 = 算法 + 数据结构
2. 软件 = 程序 + 软件工程
3. 企业 = 软件 + 商业模式

Dijkstra 是第一个公式(程序)的终极守护者。他希望把计算科学永远留在严谨的数学殿堂里。但现实是，当几千个程序模块拼凑在一起，由几十个水平参差不齐的人共同维护，并需要在市场上持续交付价值时，我们就必须踏入第二个和第三个公式的深水区。这正是 “软件工程” 即使被 Dijkstra 怀疑，也依然顽强生长、持续壮大的原因。

两种工程：大厂的障眼法 vs. 对抗熵增的武器

当行业迈入“软件 = 程序 + 软件工程”的阶段时，在实践中我们看到了两条路径：

第一种：组织工程(Organizational Engineering)
这是 Dijkstra 最深恶痛绝的部分。它试图把产品经理、业务方等“不会编程的人”拉进软件开发的参与感中。在今天的互联网大厂，它甚至进化出了一套高度套路化的体系：无休止的 Kick-off(项目启动)、各部门的拉通与对齐、行业专家定制的几百页却没人看的大而全的规范，以及纯粹为了在系统崩溃时划清责任边界的 “甩锅文档”(CYA - Cover Your Ass Documents)。

它的核心价值，是给管理层提供可见性与控制感，给参与者提供情绪价值与免责声明。Dijkstra 视其为纯粹的“障眼法(eyewash)”，因为它将解决系统复杂度的智力挑战，巧妙地伪装成了一场职场沟通与表演艺术。

有讽刺意味的是，AI 的普及正在将这种组织工程推向进一步荒诞。 既然生成文本的边际成本趋近于零，人们开始心安理得地用 AI 快速生成洋洋洒洒、滴水不漏的规划、周报和甩锅长文；而另一端的读者，同样反手用 AI 提取三行摘要，甚至用 AI 自动回复“收到，已对齐”。人类的真实意图彻底淹没在机器对机器的虚假繁荣中。值得指出的是，AI 做出的精美 PPT，巧舌如簧的文稿，并不是银弹，很多是浪费时间的白噪音。

第二种：技术工程(Technical Engineering)
这是 CI/CD、自动化测试、静态代码分析、规范即代码(Policy-as-Code)、混沌工程……这是程序员为了对抗 “下个月自己都看不懂今天写的代码” ，“不知道代码会碰到什么外界情况”， “不知道软件的行为是否可测试” ... 而被迫建立的防御体系。它的核心价值是可维护性与系统韧性。即使是顶尖工程师，面对复杂项目，也必须依赖 V&V(验证与确认)，混沌工程，可观测性(Observability)等方法论与工具。

大教堂的倒塌与集市的演化：Linux 的第一记反击

如果说 Dijkstra 坚信构建软件必须像修建“数学大教堂”一样，依靠自顶向下的形式化推导；那么，以 Linux 为代表的开源运动，则给了这种纯粹的理想主义明确的回击。

Linux 的内核不是在纸上证明出来的，而是在残酷的“达尔文演化”中长出来的。开源社区秉持“早发布，常发布”的集市模式，用海量的试错和修补生硬地在混乱中蹚出了一条路。支撑这个庞大集市的，是深厚的默会知识(Tacit Knowledge)。即使没有完美的数学证明，依靠强大的工程脚手架和群体的演化反馈，人类依然构建出了撑起全球互联网底座的可靠现实。

卸载 IDE 与代码的商品化：Scaling Laws 的无情碾压

如果说 Linux 只是在工程方法上绕过了 Dijkstra，那么 2022 到 2026 年的 AI 浪潮，则是直接在物理定律层面将 Dijkstra 的讽刺变成了冰冷的现实。

2026 年，来自大模型最前沿阵地的技术领袖 Boris，向整个行业展示了一个残酷的切片：

“自从 Opus 4.5 发布之后，我的编码工作基本就是 100% 交给 AI。我把 IDE 都卸载了，不再手写任何一行代码，现在每天能合并 20 个 PR。在我们的很多团队里，这个比例也是 100%。”

当大模型沿着无情的指数曲线(Scaling Laws)，用暴力的算力和海量的数据生生“拟合”出逻辑解答时，“编程”这项曾经充满智力门槛的技能，正在被彻底解决。

这就引出了一个颠覆性的工程范式转移：在《构建之法》的三个公式中，AI 彻底“击穿”了第一个公式。代码正在沦为“快速消费品”(Disposable Commodity)，而契约(Contract)成为了唯一的核心资产。 既然任何模块都可以让 AI 在几秒钟内推翻重写，代码便不再金贵。那些由 TDD(测试驱动开发)和 CI/CD 流水线死死守护的接口契约、输入输出规范和业务逻辑，才是最有价值的。我们要用钢铁般的测试用例打造一个坚不可摧的“模具”，然后放手任由 AI 往里面倾倒任何编程语言实现的逻辑，只要它不溢出契约的边界。

古腾堡的排字工与创造者的解放

面对“编程已被解决”的终局，许多人感到恐慌，但真正的工程师却感到狂喜。因为一个经常被忽略的事实是：许多顶尖的创造者并不真正享受“敲击键盘写符合语法的代码” 的枯燥过程，他们只是为了解决现实问题而不得已为之。

我们可以类比：15 世纪中叶的古腾堡印刷机。在印刷术发明之前，知识被垄断在极少数的“抄写员”手中；而印刷术普及后，又催生了熟练的“排字工人”。排字工每天与沉甸甸的铅字块较劲，将字母一个个、一行行地机械拼接。当全自动排版技术(甚至后来的数字排版)出现时，排字工人这一职业彻底消亡了。

但这摧毁了书籍吗？没有。排字工人的隐退，换来的是出版家、作者和书籍构建者(Builder)的黄金时代。

在过去几十年里，哪怕是最具天赋的架构师，也不得不把大量的时间耗费在处理 API 调用、纠结语法错误、修复低级 Bug 这些相当于 “手工排字” 的枯燥劳动上。而现在，AI 终于让写程序变成了一件用 AI token 就可以解决的小事。

它释放了什么？它将创造者从底层的泥沼中彻底解放出来，去完成《构建之法》中第二个和第三个公式里那些真正属于人类智慧的事业：想清楚系统到底要做什么，构筑坚固的软件工程底座，以及去寻找真正能跑通的商业模式。

结语：存在主义的转移，缔造者接管世界
正如前沿开发者所断言的，“程序员/Programmer”这个头衔将会逐渐消失，或者仅仅沦为一个遗留符号。传统意义上的 Programmer——那个将思想逐行翻译为特定语法、死磕底层逻辑的代码排字工——正在隐退。

但这绝不意味着软件工程的消亡。在这场技术范式的巨变中，我们可以清晰地看到一场存在主义的转移：

程序员：我编程，故我在。 当“敲击语法”变成了编译器的活儿，如果你的价值仅仅是做一个人肉翻译机，那么当超级编译器(AI)到来时，你的“存在”就会被抹除。

编译器(AI)： 我编译，故我在。 AI 接管了所有确定性的逻辑转换。它极度重要，但它只是基础设施，正如我们现代生活中的水和电。

建造者(Builder)： 我构思蓝图，建立工程体系，故我在。 这就是为什么只有 Builder 能跨越周期。因为“构思蓝图”定义了系统要解决什么真实的现实问题，“建立工程体系”划定了系统的边界和契约。这两件事永远无法被概率引擎自动推导。

未来的 Builder 不再沉溺于手工排布代码或者 debug，他们的日常将发生质的跃迁：定义真理与契约守护： 用极致严密的逻辑和 TDD 测试用例，给 AI 生成的混沌代码套上形式化的枷锁，这是他们对内容的终极审校。

连接真实世界： 花更多的时间与用户沟通，挖掘业务的本质诉求(那才是机器无法凭空推导的默会知识)。

构筑工程底座： 搭建无坚不摧的 CI/CD、监控和容灾体系，用坚固的工程脚手架抵御系统熵增的洪流。

半个多世纪前，当 Dijkstra 在结婚登记表上写下 "programmer" 时，那个不被认可的职业，最终用它的严谨和伟大塑造了人类的数字文明。

今天，Dijkstra 的讽刺并未失效，它只是被大模型的指数曲线放大了十倍。Linus 的集市并未终结，它只是迎来了名为 AI 的超级代码生成引擎。在这个波澜壮阔的大航海时代，不懂计算科学、缺乏工程敬畏的人，依然造不出伟大的软件；而只会低头写代码、抱残守缺于 IDE 的“排字工”，也注定被时代淘汰。

只有那些既保留了 Dijkstra 般的逻辑严密性，懂得 Linus 工程+社区的演化规律，用 TDD 构筑契约边界，又能以出版家/架构师姿态跨越从程序到商业闭环的建造者(Builder)，才会在技术发展的曲线上继续闪耀。