不可解释失败的常态化——为什么AI驱动的工具正在转移责任
核心观点
AI驱动的开发工具（如Jev）正在培养一种文化，即对不透明的失败接受为"就是这样"，这降低了责任性，使软件可靠性更难保证。
最初的观察：总是"吸"的门
作者以《总统柯蒂斯》中的一段幽默片段开场，其中角色因荒谬的障碍（先是具尸体，然后是一百亿美金的黄金）反复无法打开门。角色的反应"这该死的东西总是吸"被用作比喻，说明开发者和用户在面对不可解释的软件故障时的常见反应。
"门不应该莫名其妙地'吸'！"——作者，引用该卡通片段。
这个轶事为更广泛的批评奠定了基础：现代软件，尤其是AI增强的组件，正越来越多地被视为一个偶尔"就是吸"的黑箱。
Jev：快速、廉价且不透明
Jev是TypeSafe AI推出的AI模型，承诺：
- 以低成本实现快速推理
- 对开发者而言易于集成
- 重复强调速度和低成本（作者列了两次）
文章质疑，在缺乏严格评估的情况下，这种模型是否能被负责任地采用：
- 缺少评估流程 – 用户将不透明的查询发送给Jev，而没有测试套件。
- 依赖置信度分数 – 模型返回概率估计，但文章认为这些分数很少被校准或理解。
- 商业合理性 – 公司可以声称"AI会出错"来为下游故障开脱。
对概率分数的虚假信心
一种常见的辩护是Jev的置信度分数提供了安全网。文章反驳道：
- 校准未知 – 基准测试显示原始准确率，而非置信度数值是否真实反映实际可能性。
- 成本建模缺失 – 没有明确的置信度与业务影响之间的映射，这些分数就毫无意义。
- 迷信式使用 – 团队可能将任何置信度数字当作失败的借口，例如"模型只有73%的置信度，所以误差预算就是27%。"
"最乐观的情况是，人们以迷信的方式使用置信度分数。最糟糕的情况是，他们用它作为API调用失败的理由。" – 文章作者。
当失败被常态化时，责任逐渐消失
当一个Web端点返回HTTP 500时，开发者通常期望有负责的团队来调查断裂的契约。作者将这种态度与"这该死的东西总是吸"的心态对比，后者接受失败而无需根本原因分析。
- 传统责任：明确的所有权、调试工具和事后分析。
- AI驱动的不透明性：不透明的响应、没有明确契约，以及一种耸肩的态度。
文章警告，这种转变使软件显得反复无常，增加了用户挫败感，却并未提升可靠性。
社区反应：共识与不同观点
Hacker News的评论强化并扩展了文章的担忧：
- 可复现性倡导者（pmarreck）强调，即使有AI辅助，确定性测试仍然至关重要。
- 可靠性怀疑者（adamddev1）认为，将库和基础设施中的失败常态化将摧毁整个生态系统。
- 统计素养（WorldMaker）指出，置信度分数常被误解为普遍评分，导致信任错位。
- 现实案例（teraflop）描述了电动车软件间歇性失败且无明确诊断，与"就是吸"的态度如出一辙。
- 乐观者（benjaminsky2）报告称，在他们的测试中，Jev的置信度分数与准确率呈线性相关，表明在正确验证时具有潜在价值。
- 系统理论视角（sixdimensional）引用"正常事故"理论，警告复杂且紧密耦合的系统不可避免地会产生无法解释的故障。
这些评论共同凸显出一种分歧：一些人认为AI工具在配合扎实评估时是生产力的提升，而另一些人则视这一趋势为工程严谨性的危险侵蚀。
为何现在尤为重要
AI辅助开发的加速降低了快速发布功能的门槛，但也减少了构建稳健测试套件、进行根本原因分析和维护清晰服务契约的动力。随着越来越多关键系统（如云服务、汽车软件）采用概率性组件，无法解释的失败成本不断上升——从用户挫败感到安全风险。
对实践者的建议
- 将置信度分数视为数据，而非保证 – 针对每个使用场景进行校准验证。
- 保持确定性测试环境 – 即使AI生成代码，自动生成的测试也应经过审查并纳入版本控制。
- 记录失败契约 – 为任何AI增强的API定义预期的误差预算和可观测的失败模式。
- 投资事后分析文化 – 当AI组件表现异常时，应追溯根本原因，而非归因于"AI错误"。
- 平衡速度与质量 – 使用AI进行原型设计，但在生产部署前强制要求人工验证正确性。
结论
AI驱动工具（如Jev）放大了不可解释失败的常态化，正威胁着可复现性、责任性和校准风险评估等基础工程实践。若无明确的防护措施，行业可能最终接受"这该死的东西总是吸"作为软件崩溃的默认解释，从而侵蚀对技术及开发团队的信任。
Sources
相关
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch