9 篇博文 含有标签「metrics」

仪表板显示一切进展顺利。分流率高达 65%。工单量下降。单次咨询成本减半。接着，支持团队开始有人离职，离职面谈中提到了一些仪表板上没有列出的东西：“每一个班次都是煎熬。”

这是 AI 增强型支持中隐藏的机制。分流率衡量的不是消除的难度，而是浓缩后的难度。到达人工客服手中的案例不再是客户现实情况的代表性样本——它们是残余物，是 AI 无法解决的案例。而这些残余物比平均水平要沉重得多。

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

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

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

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

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

有一种特定的失效模式正在悄悄破坏 AI 产品的数据指标，却没有人察觉。你的仪表盘显示建议接受率为 34%、DAU 强劲、功能参与度持续增长。仪表盘没有显示的是：60% 被接受的建议随后被立即重写，参与度最高的用户正是那些点击 AI 输出、全选，然后自己重新输入的人；这个功能对下游任务完成率零可测影响。

这就是"安静放弃"模式：用户系统性地绕过 AI 功能，同时产生活跃用户的全部表面指标。他们不会禁用该功能——他们只是忽略其输出。在你的分析系统中，他们与最佳 AI 用户看起来完全相同。

据一项研究显示，95% 的生成式 AI 试点项目从技术层面来看都算成功——而 74% 使用生成式 AI 的公司至今仍未展现出可量化的业务价值。这两个数字之间的落差并非巧合，而是一个被包装成技术问题的衡量问题。更糟糕的是，大多数组织无法准确诊断这一问题，因为负责衡量的人，恰恰就是被衡量的人。

这就是古德哈特定律（Goodhart's Law）在组织层面的体现：一旦某个 AI 采用率指标成为绩效目标，它就不再能衡量你真正在乎的事情了。指标持续攀升，实际结果却原地踏步甚至每况愈下。

仪表板显示，你的工程师在上个季度采纳了 45% 的 AI 建议。管理层将其解读为“节省了开发人员 45% 的时间”，并签署了续约合同。与此同时，工程师们正在悄悄重写他们采纳内容的一半，调试另一半，并纳闷为什么他们的 Sprint 看起来还是和以前一样长。双方都在看同一个数字，但只有其中一方看对了数字。

2025 年引用次数最多的这项研究，本应单枪匹马地终结“厂商仪表板时代”。METR 衡量了经验丰富的开源维护者在有无 AI 的情况下，处理自己代码库中真实问题的表现。开发者预测 AI 会让他们提速 24%。实验结束后，他们仍然认为 AI 让他们提速了 20%。但秒表显示他们慢了 19%。故事与数据之间存在 39 个百分点的差距——而季度评审中采用的正是那个“故事”。

你的 LLM 幻觉率是 3%。但你的用户仍然讨厌它。这并不矛盾 —— 而是衡量标准错误的症状。

幻觉率已成为 LLM 质量的默认头条指标，因为它很容易向利益相关者解释，且在基准测试（benchmark）中计算起来非常简单。但在生产环境中，它与用户真正关心的东西相关性很低：任务是否完成、结果是否值得信赖并足以据此行动、以及系统是否为他们节省了时间？

你的 AI 功能满意度评分是 4.2/5，用户点赞率高达 68%，A/B 测试显示任务完成率提升了 12%。团队决定上线。六周后，用户已悄然绕开它，遇到真正重要的事情时不再使用。

这就是指标表演。你优化的是看起来像成功的信号，而不是真正的成功。你收集到的反馈来自那 8% 愿意评分的用户——偏向极度满意和极度不满的两端，对那沉默的大多数一无所知——他们发现该功能时不时不可靠，于是悄悄停止信任它了。

构建 AI 功能需要一套与传统软件不同的度量哲学。你从第一天起就埋下的信号，决定了你是否能足够快地学习并改进，还是花六个月追着一个纹丝不动的满意度分数跑。

大多数采用 AI 编程工具的团队都会遇到同样的瓶颈。第一个月看起来像是成功案例：PR 吞吐量上升，Sprint 速率在攀升，工程经理正在制作幻灯片准备向领导层汇报。到了第三个月，事情悄然发生了变化。事故率开始回升。资深工程师在代码审查上花费了更多时间。一个简单的 Bug 修复现在需要理解一段团队中根本没人写过的代码。生产力的提升已经消失殆尽 —— 但衡量体系从未捕捉到这一点。

问题在于，大多数团队最先关注的指标 —— 生成的代码行数、合并的 PR 数量、消耗的故事点数 —— 对于 AI 辅助开发来说是错误的衡量单位。它们衡量的是产出代码的成本，而不是持有代码的成本。AI 让产出几乎变得免费，却让持有成本保持不变。