当软件故障变成“该死的东西”
The Normalization of Inexplicable Failures
最近我在《President Curtis》中看到总统因门打不开而抱怨“这破玩意儿真烂”，这让我联想到当下软件工程的怪象。TypeSafe AI推出的Jev模型主打快速廉价，却鼓励开发者跳过测试，直接用“AI会犯错”来掩盖逻辑漏洞。所谓的置信度分数往往沦为甩锅借口，而非校准工具。当按钮失效不再被深究，而是被归咎于“有时候就是不行”，我们便正在将不可解释的失败常态化。悲剧在于，LLM本可加速自动化测试，如今却让我们对门后是否有尸体都懒得检查，只剩一声无奈的叹息。
软件工程的悲剧在于，我们正主动构建这样的系统：用户和开发者似乎都不关心门后是否藏着尸体，只是耸耸肩得出结论：这破玩意儿真烂。
HN 评论区
95- pmarreck
我极度重视可复现性（nix 爱好者）、确定性（在我这里，测试失败是红色警报，全员待命的紧急状况）以及正确性。
我也极度重视测试（测试正确的事物）。还有九位数的可用性（Elixir 在这方面很强）。
而且……我也非常推崇代理辅助开发。这需要近乎书里所有的检查项才能保持生产力。但这对我没问题。我见过我自己绝不会写出的 bug，也见过我自己的 bug 被修复。它们都在短时间内被修好了。我不明白这有什么问题。
提高你的个人标准吧。
事实是，在代理（被滥用的代理）让情况变得更糟之前，不可靠软件的局面就已经难以维持了。
- adamddev1
写得真好。人们总是用“好吧，够用了”或者“大部分时候都能跑”来为代理/LLM 驱动的开发辩护。
这对某些面向用户的应用来说或许可以容忍。但如果我们开始在库、基础设施和编译器中把故障常态化呢？一切都会陷入不可靠的混乱，这会拖慢所有事、所有人。
- theamk
> 当网站上的一个按钮坏了，我对本该发生什么有一个模型。某处的契约被打破了。[...] 我可能无法调试一个 HTTP 500 状态码，但我期望有专人负责弄清楚为什么这个端点会返回 500。所有权定义得很清楚，尽管不透明³。
> 然而，对许多用户来说，实际体验大概就是“这蠢东西真烂”。软件本身就显得反复无常；更多的故障只是改变了沮丧发生的频率。
我敢打赌作者不怎么用云服务。这不仅仅是“用户”的问题，开发者也一样。Github 返回 5xx？AWS 服务挂了？你的邮件没送达？我们（开发者）什么都做不了，只能感叹“这蠢东西真烂”。
- layer8
> 这导致了不可解释性的常态化。
这也与缺乏问责制的常态化紧密相连。
> 这可不是“弄个 FTP 账号，用 curlftpfs 本地挂载，然后在挂载的文件系统上用 SVN 或 CVS”——你依然得做最难的那部分。
这话估计把年轻一代的受众给吓跑了。;)
- WorldMaker
“置信度分数”一直暗示着一种并不存在的人本主义含义。算法不像人那样拥有“信心”，但一旦你把叫这个名字的东西摆在一个商务人士面前，他们就会认为这个数字总是一个有意义的“等级评分”或“通用百分比”。我依然坚信那句老话“有谎言，有该死的谎言，还有统计”是理解为什么 ML 会导致愚蠢结果而非炒作的关键。人们不懂统计学，所以那些只产出统计数据的机器尤其让人困惑。（我觉得这对 LLM 也适用。）