在最近播出的《总统柯蒂斯（President Curtis）》某一集中，剧中的总统在两个不同的场景里都费力地试图打开一扇门，但每次都没能顺利推开。根据情节展示，这些门之所以无法运作，是因为通行路径上横着明显的障碍物：第一次是一具尸体挡在门前，紧接着第二次则是大约价值十亿美元的黄金堵住了入口。

在最近一集《President Curtis》里，总统两次遇到开门困难。

这些门打不开，是因为有东西挡着：先是一具尸体，然后是大约价值十亿美元的金条。

两次都是，面对这种挫败，角色嘟囔「stupid thing sucks」（蠢东西真烂）。这不是对门的合理理解！门不应该莫名其妙地「烂」！我觉得这些时刻好笑到离谱¹，但也许是我愚蠢的大脑烂。

Jev：制造更多会烂的门

互联网一直在热议 Jev，这是 TypeSafe AI 开发的 AI 模型，返回带概率估计的类型化值。据我看，Jev 的重要之处是：

• 它快且便宜；
• 你能很快在上面构建。

我不太擅长判断什么技术会被采用。我至今仍不理解² Slack。

等等。

你仍然得做难的那部分吗？

也许我的问题是期望产品能工作。

买这个的人没人在跑评估。他们只是把不透明的问题交给 Jev，得到不透明的回答。往好里说，这让他们能勾选「AI 驱动」并在周五前发布；当这破坏下游逻辑时，他们总能耸肩说「好吧，AI 会犯错」。错误预算？失败模式？测试集？这些都可以以后处理。用户可以去发现失败率！你已经发布了！

虚假信心

「哦，」回应我帖子的稻草人说，「你没考虑到 Jev 给你信心分数！」

你要拿它们做什么？

要对信心分数做合理的事，你需要既理解这些分数的校准，也理解不确定性的成本模型。

校准方面：Jev 的头部广告文案主要讲他们在各种基准上得分多好，而不是他们的信心分数校准得如何。有一份利用信心分数爬分类树的 cookbook，但这根本上不是关于信心分数有多好。

最好情况下，人们以货物崇拜的方式使用信心分数。最坏情况下，人们用它们当作 API 调用失败的借口。模型只有 73% 信心！这意味着我的错误预算是 27%！

问责

当网站上的按钮坏了，我对应该发生什么有个模型。某处有契约被破坏。我的 DNS 坏了。有人发布了烂代码，只在某条特定路径上有 JavaScript 语法错误。一个本来不该抛异常的处理程序抛了异常。我可能只有一个 HTTP 500 状态，没法调试，但我期望有某个人的工作就是理解为什么端点会 500。责任归属是明确的，尽管不透明³。

然而对许多用户来说，实际体验大概就是「stupid thing sucks」。软件本来就感觉反复无常；更多失败只是改变沮丧的频率。去掉把一个失败追到具体原因的可能性，似乎没多大损失。有时候东西就是烂。

这导致莫名其妙性的常态化。

我担心的不是当 LLM 驱动的开发加速时会有更多东西失败。它们会。它们已经会了。这是以新方式构建事物的部分代价。

我担心的是，「有时候它就是烂」会越来越成为调查的公认终点。这很可悲，因为 LLM 加速的开发确实能帮我们解决其中一些问题。有很多自动化 QA 工作流因为缺少工程时间而没被写出来。那个能让你差不多替换（甚至只是证明使用）Jev 的评估，可能就在几个提示词之外。

当今软件工程的悲剧在于，我们正在积极工程化那些用户和构建者似乎都无意检查门后是否有尸体的系统。

我们只是耸肩得出结论：stupid thing sucks。

¹ 这让我想起一句我觉得同样好笑的话：「有时候你得到电梯，有时候你得到竖井。」这也不是对电梯的合理理解！！ ² 锁定网络效应对我来说说得通，但我仍然困惑人们为什么会标准化在一个甚至不能可靠传递消息的产品上。我见过免费、付费和企业实例上消息被丢弃，几周后才出现。 ³ 好吧，也许「明确」是乐观的。在比尔·盖茨著名地无法下载 Movie Maker 之后，大家都同意这大概是某个人的问题，只是不一定是他们的问题。理想情况下，我们甚至能在客户不是比尔·盖茨的情况下获得这种问责水平。

讨论普遍认同软件不可解释性正在蔓延并侵蚀信任，分歧集中在这是行业长期积弊还是 LLM/agent 时代的新危机，以及靠工程纪律和个人标准能否把可预测性夺回来。

认为不可解释性不是新问题，行业从一开始就如此

• 质疑文章把“不可解释的失败被正常化”当成新现象，指出行业一直如此，连“重启试试”这种老建议都长期有效（较多人）
• 开发者面对云服务故障同样只能接受“蠢东西真烂”，并非只有普通用户才无助（较多人）
• 不可靠软件在 agent 出现之前就已经不可持续（较多人） > 作者说得好像不可解释的失败直到现在才被正常化，可这个行业一直如此；连“你试过关掉再开吗”这种老话都能生效。（@perching_aix）

认为概率化计算和 agent 会把不可预测性扩散到整个技术栈

• 功能越窄越能界定预期和故障原因，“什么都能做”的机器很难给出合同和保证；用概率作为底层计算方式，就等于放弃可预测性；确定性工具正因能力受限才好组合、可理解（较多人）
• 如果连库、基础设施和编译器都开始把失败正常化，整个行业都会陷入不可靠，拖慢所有人和所有事（较多人）
• 软件工程越来越远离传统工程，没有失效模式分析，也没有根因分析，只剩对着魔法盒子说话（较多人） > 用概率当底层计算方式，灵活性极强，代价就是可预测性和预期。（@voidhorse）

认为真正的问题是责任缺失被正常化

• 不可解释性与“没人负责”相伴而生，作者期待接口报 500 时总有一个人负责查明原因，但现实中开发者用云服务时同样找不到负责人（较多人） > 不可解释性的正常化，也紧密连着责任缺失的正常化。（@layer8）

认为复杂系统中“正常事故”不可避免，云和消费硬件让故障无主

• 正常事故理论指出，极复杂系统中的多重故障相互作用不可避免，组织因素往往比技术因素更关键（较多人）
• 云服务故障的最佳对策常常只是“明天再试”，指望六个时区外的后端哪天被修好（较多人）
• 电动车警告自行消失，技师说“它有时就这样”；导航连不上或按钮一直转，原因不明；保修明确不覆盖软件或固件故障（较多人） > 很多问题的最佳解法就是“明天再试”，指望六个时区外的 Azure 后端哪天被修好。（@nikanj）

认为提高个人标准和工程纪律后，agent 辅助开发仍然可控

• 同时重视可复现性、确定性、测试和九个九可靠性的人也在用 agent 辅助开发，并认为只要配齐检查、提高个人标准就能保持效率；agent 写出过自己不会写的 bug，也修过自己的 bug（少数人）
• 也有少数声音强调，LLM 能从非结构化数据中做出决策，人们并非只因为便宜才采用它（少数人） > 不可靠软件在 agent（落到外行手里）之前就已经不堪重负，该做的是提高个人标准。（@pmarreck）

认为浪费用户的时间和资源本身就是一种支配

• 花更多时间使用一个产品，就更可能再次选择它，哪怕原因是失败或恼火，人会自我合理化；超市货架上颜色鲜艳的盒子因为被看得更久更早而更可能被选中（少数人） > 浪费时间和资源是一种权力象征，但让你浪费自己的时间和资源，是霸权。（@hyperhello）

认为工具一旦有了自己的“秘密生活”就不再是工具

• 不可解释性从“我解释不了”到“这不在可能性范围内”有一个谱系，Windows 尤其正从前者滑向后者，这种无力感极强（较多人） > 不可解释从“我解释不了”到“这不在可能性范围内”，工具如果有自己的秘密生活就不再是工具。（@ajrouvoet）

有价值的补充

• “置信分数”把统计输出拟人化了：算法没有人的“置信”，商业决策者却会把它当成有意义的评分；人们本就不懂统计，只产出统计的机器尤其令人困惑，LLM 同理。（@WorldMaker）
• 电动车案例里，保修条款明确不覆盖软件或固件不能正确运行——不可解释性在制度层面被承认并免责。（@teraflop）
• 有评论顺带提到“申请 FTP 账号、用 curlftpfs 挂载、再跑 SVN/CVS”这套操作，如今可能让年轻读者茫然，说明可解释的工作流预期已经改变。（@layer8）
• 讨论中最精炼的类比之一是“对着魔法盒子说话”，用来概括没有失效模式和根因分析的开发方式。（@Sharlin）