76 篇博文 含有标签「ai」

Diff 看起来很干净。Agent 导入了正确的模块，调用了看起来正确的函数，TypeScript 也没有报错。PR 描述甚至引用了文档。随后 CI 中的构建开始运行，调用却由于 TypeError: x is not a function 而崩溃 —— 这是因为该函数在八个月前的一次小版本更新中被拆分成了两个，而 Agent 是根据其训练数据中存在的库版本生成的代码，而不是你 package.json 中安装的版本。

这并不是“LLM 会产生幻觉”这一框架能让你做好准备的那种故障。模型并不是在发明一个从未存在的 API。它是在记忆一个曾经存在但现在已不存在的 API。Agent 进行推理的心智模型是一个冻结在训练时的快照。世界在向前发展。代码库在向前发展。而 Agent 却一无所知，因为没人告诉它。

推理模型会输出思维链（chain-of-thought）轨迹，因为这是它的计算方式。产品团队在 UI 中渲染该轨迹，是因为隐藏它感觉像是丢掉了用户付费购买的 token。这是两个不同的决定，而产品端几乎没有人意识到他们做了第二个决定。于是，轨迹变成了面板，面板变成了功能，功能有了文档页面。六个月后，有人在季度回顾中问，为什么支持队列里全是用户在反驳推理过程，而不是针对答案本身。

推理轨迹本质上是调试输出。它的存在是为了让工程师了解模型为什么选择某个工具、在日期上含糊其辞，或者在段落中间悄悄切换了角色。在没有经过设计审查的情况下将其推给终端用户，等同于在生产环境中留下 console.log 调用并称之为“透明度”。它看起来像个功能，渲染成本几乎为零，但它会以团队构建的任何仪表盘都无法显示的方式悄悄削弱信任。

每个构建 AI 产品的团队都面临同一个路口：AI 应该为人类提供建议，还是自主行动？这个问题听起来很有哲学意味，但答案实际上是可以量化的——而且弄错代价高昂，往往在上线六个月后才会显现，那时你的覆盖率指标看起来很好，但用户信任分数已经在悄悄崩溃。

Klarna 在 2024 年初用一套自主 AI 系统替换了 700 名客服人员。到 2025 年，CEO 承认他们"走得太远了"，并悄悄开始为复杂案例重新招聘人工客服。该 AI 在一个月内处理了 230 万次对话，将问题解决时间从 11 分钟缩短到不到 2 分钟。数字看起来很漂亮。但根本问题——金融产品的客户服务需要同理心和判断力，而不仅仅是解决速度——在所有偏离常规路径的场景中，以下降的满意度形式滞后显现。

2026 年初，Atlassian 报告了一件公司历史上从未发生过的事情：企业席位数量下降。对于一家增长模式完全依赖于扩张收入（随着客户组织增长而销售更多席位）的公司来说，这是一个结构性警报，而非偶然波动。直接原因并非客户流失或产品失败。而是 Atlassian 自身的 AI 功能大幅提高了团队效率，以至于完成同样的工作量所需的席位更少了。

这就是 AI 效率悖论：构建一个真正为用户节省时间的功能，你可能正在训练他们减少对你产品的使用。你的 AI 越有用，你的定价模型崩溃得就越快。

当你的 AI 功能上线，各项指标开始亮眼——DAU 飙升、NPS 攀升、点赞反馈涌入——你可能正在目睹真正的产品市场契合度。也可能只是两幕故事的第一幕，而第二幕以一个没人预料到的留存悬崖收场。

问题在于，这些信号对概率性 AI 功能而言在结构上就是失效的。它们是为确定性软件设计的——在那里，"已激活"有明确含义，五星好评能预测未来使用，新鲜感在数天内消退，而不是掩盖一个六个月后才显现的流失浪潮。AI 功能的行为模式截然不同，而标准 PMF 工具包是针对错误输入校准的。

你的团队发布了一项 AI 功能。你为本地化工作感到欢欣鼓舞：每个按钮标签、工具提示和错误消息都被翻译成了 12 种语言。产品经理签了字。该功能在全球上线。

然而，六周后，一位德国用户发布了一张截图。AI 的回答用词正确但语域（Register）不对 —— 在非正式的客服场景中显得过于生硬。一位日本用户反映，结构化输出中的日期格式为 MM/DD/YYYY，这导致他们的下游工具出现故障。一位巴西的支持工程师注意到，AI 在对复杂查询进行推理时，偶尔会在句子中途滑入英语。这些并不是基础设施故障。你的仪表盘显示一切正常。但对于非英语用户来说，产品正在悄无声息地变得更糟。

根本原因几乎总是一样的：团队翻译了 UI 字符串，但却让系统提示词保留为英文。这看起来像是本地化，但事实并非如此。

一个概念验证（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 团队和产品团队运行在完全不同的时间尺度上，而大多数组织将其视为协作失败，但实际上这是一个架构问题。你无法通过更好的站立会议节奏来修复结构性的不匹配。