2026年7月21日，Stephen Wolfram 发表了一篇长文《Towards a Theory of Bugs: The Ruliology of the Unexpected》。文章试图建立一个Bug的”形式化理论”——核心论点只有一个：Bug是计算不可约性（computational irreducibility）的必然结果。
这篇文章在Hacker News上获得了1294分和508条评论，当日最高。但评论区弥漫着一种微妙的氛围——“你到底在说什么”。
一个数学家的宏大叙事
Wolfram是谁？如果你不写代码，你可能在另一个语境下见过这个名字：Mathematica 软件的创始人、Wolfram Alpha 知识引擎的缔造者、“新科学”（A New Kind of Science）的鼓吹者。他有一个根深蒂固的习惯——把所有现象都塞进他那套”计算等价原理”（Principle of Computational Equivalence）的框架里。
这次他把矛头对准了软件Bug。
Wolfram 的核心论证路径是这样的：即使是极其简单的程序——比如只有3个状态、2种颜色的图灵机——也会在某些特定输入下产生”意外行为”。他在文章中给出了一个具体的例子：一台看起来是在计算 n+1 的图灵机，对输入0到6都给出正确结果，但在输入7时输出了9。
他接着展示了更极端的案例：一台4状态的图灵机对输入0到62都正确，但到63时莫名输出了72。
这些”意外”在 Wolfram 看来就是Bug的雏形。而它们的根源，是他所谓的”计算不可约性”。
计算不可约性：一个围棋比喻
这里必须停下来解释一下这个关键概念，因为整篇文章的争论焦点全在于此。
“计算不可约性”是 Wolfram 在2002年《一种新科学》中提出的概念。它的核心直觉可以用一个问题来概括：你能在不下完一局围棋之前，就确定每一步的结果吗？
不能。围棋的每一步都取决于对手的回应，而对手的回应又取决于你的下一步。除了真正下完这盘棋，没有任何捷径能精确预测终局。
这就是”不可约”的含义——当你运行一个程序时，它的行为无法被任何”更快的计算方法”所预测，唯一的办法就是实际运行它直到结束。
Wolfram 的逻辑链条因此非常直接：如果Bug本质上是一种”意外行为”，而计算不可约性意味着任何足够复杂的程序都必然会产生你无法预先知道的行为——那么Bug就不仅仅是”程序员犯了错”，它是一个数学上的必然。
他甚至提出，只要一个程序值得运行（即它完成了某种有意义的计算），它就必然包含了某些你无法预先预测的部分，也就必然存在潜在的Bug。这听起来像是一个存在主义困境：你要么写一个无聊到没有Bug的程序，要么接受Bug是计算本身的代价。
工程师的回应：“这跟我的日常经验对不上”
如果故事到此为止，它只是一个数学家的哲学沉思。但精彩的从评论区开始。
HN用户 gjm11 的评论被顶到了最顶端。他指出了一个尖锐的问题：Wolfram 文章里讨论的”Bug”，跟一线开发者每天面对的根本不是同一种东西。
gjm11 区分了两种完全不同的场景。
场景一：你想写一个做X的程序。你仔细思考了做X需要什么逻辑，然后写了一个你认为能产生结果X的程序——但你可能犯了一些错误。这是绝大多数实际Bug的由来：程序员写错了逻辑、边界条件处理不当、误解了API文档。
场景二：你写了一大堆随机程序，一个一个测试，发现某个程序在小样本上看起来像是能做X，就拿来用了——但它在某些边界情况下会失败。
Wolfram 的文章通篇讨论的是场景二。他用随机生成的图灵机举例，这些机器恰好”在多数情况下”表现得像在做正确的事，然后在某些特定输入上暴露。但这跟场景一——程序员有意识地设计程序、然后不小心犯了错误——是完全不同的两码事。
gjm11 直言Wolfram的论证”有些傻”（silly），并指出Wolfram只是在硬把他钟爱的”计算不可约性”概念塞进一个它并不适用的地方。
更深层的分歧
另一位HN用户 seanhunter 的评论切中了问题的另一面：Wolfram 从未真正定义过他的核心概念。
“计算等价原理”和”计算不可约性”在Wolfram的体系中充当了几乎无所不能的解释工具，但它们从未被严格定义。在正常的科研中，一个概念如果不能被定义，就无法被检验。而无法被检验的理论，与其说是科学，不如说是信仰宣言。
PaulHoule 的观察更带有一丝悲悯。他指出Wolfram有一个模式：每当他发现一个新规则家族，总能在里面找到类似”规则30”那样的有趣现象，然后他兴奋地宣布自己发现了一个”理论”——但除了”这个也是计算不可约的”之外，他再也说不出更多东西。
这也许是最大的讽刺。一个自称”新科学”的运动，二三十年来产出的核心洞见，似乎就剩下了一条：很多事是不可预测的。
一场更古老的争论的回响
如果我们退后一步，这场争论其实并不新鲜。
Wolfram 关于”Bug不可避免”的论点，本质上是在为”无法彻底消除软件缺陷”这个工程经验提供数学基础。在这点上他并不孤单——图灵停机问题早已告诉我们，不可能有一个通用算法能判定任意程序是否会终止。实践中，大型软件系统永远有Bug也是一个多数工程师会接受的事实。
但问题在于，从”Bug不可避免”到”计算不可约性就是Bug理论”，中间缺了太多环节。
Wolfram 的论证跨越了多个层次。他从图灵机的数学性质出发，跳跃到了日常软件开发中的Bug现象。这种跳跃忽略了一个关键事实：绝大多数生产环境中的Bug，根源是人类的认知局限——遗漏的边界条件、误解需求规格——而不是什么深层的计算不可约性。
这些”人类的Bug”可能确实也与计算不可约性有某种间接关联（毕竟人类认知本身也是一种计算过程），但Wolfram的文章没有建立起这种关联。他只是用了一个听起来很深刻的数学概念，来解释一个本可以用更朴素语言描述的现象。
公平地说，Wolfram 也并非全无道理
作为一种思想实验，“计算不可约性导致Bug”的叙事并非毫无价值。
一方面，它确实触及了一个反直觉的事实：即使是最简单的规则系统，也可能产生无法预测的行为。这在人工智能领域尤其值得深思——当你用机器学习模型生成代码，连写代码的人自己都不完全理解模型内部发生了什么时，传统的”程序员犯错了”的解释框架确实就不够用了。
另一方面，Wolfram 讨论的”形式验证”的局限性也是真实的。任何形式验证系统都无法覆盖所有可能输入，这确实根植于计算理论的基本限制。在这个意义上，对于某些安全关键的软件——例如自动驾驶系统、医疗设备控制软件——理解Bug的”不可消除性”是有实际意义的。
但正如评论区多位用户指出的，这更像是一个已知结论的重新包装：停机问题不可判定、形式验证成本高昂——这些在软件工程领域早已是常识。Wolfram的贡献，最多是给这些常识增加了一个标签。
数学家的自负与工程师的务实
这场争论背后，其实是一种更深层的文化冲突。
Wolfram 是数学家和理论家。他的思维方式是从第一性原理出发，构建一个宏大框架，然后用这个框架解释一切。他不做实验去收集真实的Bug数据、不分析实际的软件缺陷报告——他通过随机生成图灵机来”模拟”Bug现象。
工程师的思维则相反。他们面对的是真实世界中的混乱：一个空指针异常、一个竞态条件、一个由于时区处理错误导致的支付失败。这些Bug的根源往往非常具体，与”计算不可约性”之间隔着重重抽象层。对于工程师来说，Wolfram的理论与其说是解释，不如说是噪音。
这正是gjm11评论中最具杀伤力的点——Wolfram混淆了两种调试路径。工程师走的是前一条路径：理解代码、修复错误。Wolfram描述的后一条路径——“先找一段看起来能跑的代码，再祈祷它在所有情况下都能工作”——与其说是一种调试方法，不如说是一种反模式。
结语：理论的边界
Wolfram 试图用计算不可约性为Bug提供一个”终极解释”，至少说明他正视了软件工程中一个真实而令人不安的事实：我们永远无法写出完全没有Bug的软件。
但把”Bug不可避免”这个工程经验提升到”Bug理论”的高度，中间需要的不仅仅是几个漂亮的概念。它需要实际的数据支撑、可操作的预测能力、以及对真实开发实践的深入理解——这些在Wolfram的文章中都是缺失的。
这并不意味着Wolfram的方向没有价值。计算不可约性确实描述了一类计算机科学中真实存在的现象。只是，用来解释软件工程师每天都在面对的Bug——那些由人的疏忽、沟通不畅、需求变更、以及代码审查中漏掉的一个极端情况引发的Bug——这个概念的粒度太粗了。
正如一篇评论所说：也许Wolfram”只是找到了另一个存在规则30的地方，兴奋地以为自己发现了一个理论”。在计算宇宙的尺度上，这或许没错。但对于一个正在调试生产环境Bug的工程师来说，知道”Bug是因为计算不可约性”的价值，约等于知道”人最终会死”对你的感冒治疗有多大帮助。
参考链接：
- Stephen Wolfram: Towards a Theory of Bugs: The Ruliology of the Unexpected
- HN讨论 (item?id=49033114)
- 计算不可约性 - Wikipedia
- Wolfram: Principle of Computational Equivalence
本文所有图片来自 Wolfram 原文页面。
