82 篇博文 含有标签「ai」

一个概念验证（PoC）花费了你 200 美元的 API token。你获得了上线的许可。六周后，账单变成了 18,000 美元。这并非定价变动或计费错误——而是成本建模的失败，也是 AI 工程中最可预见的意外。

AI 功能在预发布（staging）环境和生产环境之间的成本差距并非偶然。它遵循一个一致的模式：预发布环境在结构设计上（通常是无意的）隐藏了生产环境中每一个关键的成本驱动因素。理解这些驱动因素是避免首份账单演变成危机的关键。

这里有一个应该让你感到不安的数字：根据《2025 年 DORA AI 辅助软件开发现状报告》，人均合并的开发者 PR 增长了 98%，而每个 PR 导致的事件增长了 242.7%。部署频率看起来处于“精英”水平。但系统的单位变更故障率比 DORA 测量过的任何时期都要高。

你的仪表盘是一片绿色。你的值班工程师却精疲力竭。测量尺度出了问题。

一个在内部基准测试中得分 94%、在演示中令利益相关者印象深刻、通过所有离线评估的模型，进入生产后仍然可能跌落至 7% 的真实客户数据有效准确率。这不是假设——这是多个企业 AI 部署中有据可查的结果，也是一种更广泛模式的症状：从"试点成功"到"生产价值"之间的鸿沟，正是大多数企业 AI 悄然消亡的地方。

在各行各业，大约 85–88% 的企业 AI 试点项目从未到达生产。每启动 33 个 PoC，只有四个能够上线。尽管模型能力大幅提升，这一比例三年来几乎没有改变。失败的根源几乎从不在于模型是否足够好——几乎总是在于成功演示与真实用户真正依赖该系统完成实际工作之间所发生的事情。

2024 年初，Klarna 部署了其 AI 客服聊天机器人，第一个月便处理了 230 万次对话。满意度评分与人工客服持平。高管们宣告大获全胜。然而到了 2025 年，该公司已悄然开始重新招聘此前裁减的人工客服。

究竟哪里出了问题？指标呈现的是一个故事，用户的实际体验却是另一个故事。该聊天机器人在简单的事务性查询——订单状态、支付问题——上表现出色，却在复杂纠纷、欺诈索赔和情绪化对话中频频失手。跨所有交互类型进行平均的 CSAT 评分根本无法发现这一问题。系统看似运转正常，却在悄悄侵蚀用户信任。

这并非 Klarna 独有的失败。这是一个在 AI 产品开发中反复上演的模式：团队收集满意度信号，针对它们进行优化，却为时已晚地发现这些信号度量的并不是真实价值。问题不在于工具本身——而在于反馈到来的时机与响应后果显现的时机之间存在错位。

你的 AI 功能运行良好。它通过了你构建的每一项基准测试（benchmark）。它处理了团队花费数周进行压力测试的边缘案例。试点（pilot）用户非常喜欢它。你的模型没有产生幻觉。延迟低于 300ms。评估套件（eval suite）显示全部通过。

然而六个月过去了，它仍未投入生产。法务部门要求再进行三轮审查。一位高级副总裁担心“范围（scope）”问题。拥有相邻工作流所有权的团队表示未被征求意见。财务部门说投资回报率（ROI）模型需要重构。你被告知要“进行更广泛的内部沟通（socialize it more broadly）”。

这就是所谓的组织免疫系统在起作用——它杀死的 AI 项目比糟糕的模型要多得多。

你的 ML 团队进行了一项大有可为的实验。模型在评估集上比基准线高出了 8 个百分点。利益相关者们都很兴奋。然而，交付却花了四个月的时间——等到功能上线时，产品路线图已经发生了变化，提出需求的团队有了不同的优先级，而且由于部署目标在过程中发生了改变，一半的基础设施工作都得重做。听起来很耳熟吗？

这就是“时钟不匹配”问题：AI 团队和产品团队运行在完全不同的时间尺度上，而大多数组织将其视为协作失败，但实际上这是一个架构问题。你无法通过更好的站立会议节奏来修复结构性的不匹配。

你最值得信任的功能也是你最危险的 AI 部署目标。这是一个产品团队不断以惨痛代价发现的直觉相反的现实：用户最依赖的功能，那些信任深厚且自动化的功能，恰恰是 AI 引入的变异性（variance）会造成最灾难性信任损害的地方。一个新功能的失败令人失望，而一个现有功能突然变得不可预测则是一种背叛。

这就是 AI 产品改造陷阱（retrofit trap）。陷阱并不在于决定添加 AI——这通常是正确的；陷阱在于认为在成熟功能中添加 AI 比构建新功能更安全，因为你已经拥有了用户。事实上，情况恰恰相反。你花费数月或数年赢得的信任并不是 AI 实验的基础；如果实验失败，它反而会成为一种负担。

你的 AI 功能通过了压力测试。达到了延迟 SLA。回滚程序运行正常。成本估算在预算之内。你的 post-mortem 模板每一行旁边都有一个绿色的对勾。

上线两个月后，该产品出现在一篇关于歧视性结果的调查文章中。你花了六周时间进行法律审查。

这就是双重报纸测试旨在弥补的差距。大多数工程团队为技术故障构建了完善的发布前流程——可靠性退化、API 不稳定、基础设施成本飙升。他们阅读有关停机的 post-mortem 并进行相应优化。但第二类 AI 故障能直接穿透这些流程，因为它们看起来不像 bug：功能完全按设计运行，但伤害仍然发生了。

AI 平台团队最常见的失败模式不是技术问题，而是组织问题：中央平台团队成了每个产品团队将 AI 能力推上生产的必经关卡。请求队列不断增长，交付周期从几天膨胀到几周。产品团队愈发沮丧，开始拼凑非官方的绕道方案——硬编码 API 密钥、私下接入 LLM、用个人信用卡注册供应商账户。等平台团队察觉时，组织里已有一半的 AI 工作游离在任何治理体系之外。

问题不在于平台团队关心治理，而在于他们把治理实现成了审批流程，而非基础设施。

每个上线 AI 功能的工程团队最终都会碰到同一堵墙：财务部门要看一份证明支出合理性的表格，但你做的那份根本行不通。

问题不在于 AI 功能缺乏 ROI，而在于 AI 的经济逻辑打破了标准 ROI 模型的每一个假设——固定资本、线性成本曲线、可预期的回收时间线。把 AI 支出当作 SaaS 许可费来处理的团队，要么在上线前看到虚高的数字，要么在投产六个月后看着数字崩塌。有计划的 AI 项目（ROI 达 55%）与随意部署的项目（ROI 仅 5.9%）之间近十倍的差距，几乎完全来自于团队是否在上线之前就建立了正确的度量模型。

几乎每一次企业 AI 部署中都会出现同一种模式：工具在演示中表现出色，上线生产后却悄然止步于 70–80% 的潜力。团队将其归咎于模型质量、上下文窗口限制或检索失效。然而大多数情况下，这个诊断是错的。真正的问题在于：他们要求 AI 扮演一个它在结构上无法胜任的角色——至少目前如此，也许永远如此。

"AI 能完成这项任务"与"AI 能胜任这个角色"之间的鸿沟，是企业 AI 领域最昂贵的误解。

当 Google 的 AI Overview 建议用户在披萨酱中加胶水，并为了消化健康而吃石头时，这不仅仅是让产品团队蒙羞——它暴露了我们在思考 AI 可靠性方面的系统性鸿沟。失败的原因不仅在于模型错了。失败的原因在于模型在高度受关注的情境下“自信地”犯错，而且没有为被误导的用户提供任何补救路径。

对 AI 系统的信任并非逐渐流失。研究表明，它遵循一种“悬崖式”崩塌模式：一个明显的错误就能导致信任度大幅下降，并产生可衡量的影响。只有 29% 的开发者表示他们信任 AI 工具——尽管采用率攀升至 84%，但这一比例比前一年下降了 11 个百分点。我们正在构建人们虽然在使用但并不信任的系统。当你的产品发布了代表用户行动的智能体 (agentic) 功能时，这种差距就显得至关重要。

本篇文章讨论的是工程师和产品构建者在错误发生“之后”应该做什么——而不仅仅是如何预防错误。