无法解释的故障的常态化
软件和联网设备越来越多地以用户甚至开发者都无法解释的方式失败，从含糊的云宕机到现代汽车里的晦涩错误，催生了一种“这破玩意儿就是不行”的文化，而不是清晰的责任归属和根因分析。评论者把这种变化与概率系统和 AI 驱动工具、管理层对速度高于严谨的压力，以及对传统工程实践重视不足联系起来，并警告说，把这种无法解释的故障常态化会侵蚀整个技术栈的信任与可靠性。也有人认为，只要有合适的评测、测试，以及在安全关键领域的受限使用，AI 仍然可以是强大的助力，而不是混乱的来源。
“无法解释的故障”的范围
- 评论者认为，难以看懂、无法调试的故障在越来越多的领域变得普遍：
- 云服务和 API 偶尔返回 5xx，“重试就好”已成常态。
- 消费电子设备（尤其是汽车）出现含糊的警告和不稳定的连接，却没有明确诊断。
- 日常软件/操作系统行为中，“关掉再打开”成了事实上的修复方式。
- 有人认为这一直如此；也有人觉得“快速行动、打破常规”、持续部署以及 QA 减少，明显让情况恶化了。
确定性、概率系统与 AI
- 确定性系统因其可预测的故障模式和清晰的契约而受到赞赏；基于概率/LLM 的系统被视为强大，但难以推理或保证。
- 担忧在于：如果在核心库、基础设施和编译器中将概率行为常态化，可能会侵蚀整个技术栈的可靠性。
- 反方观点：即使是 AI 生成的代码，一旦写出来也仍然是确定性的；真正的问题是可维护性和设计质量，而不是概率本身。
工程文化、质量与责任
- 对“Bug 是不可避免的”存在分歧：
- 一方认为：Bug 在很大程度上是商业选择；“没有 Bug”是可能的，但对大多数人来说成本太高。
- 另一方认为：深层技术栈和复杂的分布式系统使某些故障实际上不可避免；应当为不完美和韧性进行设计（例如混沌测试）。
- 有人讲述了以下故事：
- 围绕过度设计与 YAGNI 的争论，边缘情况常被忽视，直到它们真的出问题。
- 企业用 cron 重启和容忍糟糕的尾延迟来掩盖系统性问题。
- 几位评论者将“无法解释”与缺乏问责联系起来：责任可以推给供应商、云服务，或者现在的“AI”。
用户体验与错误报告
- 含糊的错误对话框（“出了一些问题”）受到广泛批评。
- 许多人更愿意看到详细、甚至技术性的消息和正确的日志，而不是模糊的提示。
- 极简主义的“它就是能工作”设计被认为有一个“邪恶双生子”：“它就是不工作，而且你还看不出为什么。”
高风险领域与不同容错标准
- 传统银行和航空被提及为仍然要求低错误率和可追踪行为的领域，尽管也存在反例和面向消费者的银行故障。
- 有人认为，接触这类领域会提高开发者的标准；也有人强调管理层的激励（速度、成本）会压倒质量考量。
LLM、agentic 开发、Jev 与评测
- 许多人重度使用 LLM，并表示它们：
- 加速开发，包括测试。
- 如果配合强测试以及确定性/可复现文化，可以迅速引入和修复 Bug。
- 担忧包括：
- “vibe-coded”的开源软件和业务软件：功能更多，但 UX 不连贯、性能问题以及难以调试的行为也更多。
- 管理者利用 AI 以更快速度交付更多内容，把静默的 10% 失败率常态化为“够好了”。
- 像 Jev 这样的分类服务：
- 有人报告验证了它的置信度分数，并发现其性能强且成本效益高。
- 也有人强调，这种验证（评测、基准测试、A/B 测试）正是经常缺失的部分；在没有独立评测的情况下信任工具自己的置信度被指出是危险的。
- 普遍共识：好的评测很难，但至关重要。没有它们，令人兴奋的 AI 演示可能掩盖现实世界中的平庸表现，并加深“无法解释的故障”文化。