10 篇博文 含有标签「product-metrics」

重新生成（reroll）按钮是 AI 产品中最容易发布的 UX 交互功能。一个图标，一个处理器，在下一个请求中加一个清除缓存（cache-busting）的标志位。这似乎是对非确定性系统显而易见的妥协 —— 模型是随机的，所以让用户重新采样。两周的工程开发，发布到正式版（GA），然后开始下一个功能的开发。

六个月后，团队查看会话日志，发现中位深度用户每条回复会点击 2.4 次重新生成。第 90 百分位的用户会点击 8 次。有些用户已经完全不再阅读第一条回复 —— 他们发送提示词后，立即重新生成两次，然后才开始评估这三个草稿中哪一个最不差。团队发布的不是一个重新生成按钮，而是一种行为重塑，教会了他们的用户把模型当作一台老虎机。

有一类 LLM 失败，既不会出现在安全仪表板上，也不会触发故障工单。模型委婉地表示拒绝，并引用了一个听起来合理的政策。它提供了一段长达四段的对冲陈述，而不是直接给出答案。用户关闭了标签页。事后分析中的信任评分显示“无事故”。然而，六周后的留存率图表却显示了另一番景象。

拒绝率是大多数安全团队首先部署的指标，因为它最容易定义。模型要么遵循了指令，要么没有，而你可以统计那些“没有”的情况。这种二元法对于捕捉一种特定失败非常有用——即模型在生产环境中生成有害内容。但在结构上，它无法捕捉相反的失败：模型在生产环境中没有产出任何有用的东西，但从各项安全指标来看，它的表现却完美无缺。这种第二类失败现在已成为 AI 功能流失的主要原因，这些功能通过了安全审查，却从未针对“有用性”进行过衡量。

麦当劳得来速 AI 的失败，并非因为用户抱怨。它失败，是因为用户停止使用得来速。三年来，这套系统一直记录着"健康"的接受率，而病毒式传播的视频却显示顾客在苦苦哀求它从订单中删除 260 块鸡块。当合作关系终止时，官方给出的理由是技术"尚未成熟"。真正的信号其实一直隐藏在客流量数据里——无人阅读，无人量化，无人汇报。

这就是大多数 AI 功能在生产环境中失败的样子。用户不会关闭你的功能。他们不会提交工单。他们不会留下一星评价。他们悄悄地绕开它，而你的仪表板依然一片绿色。

一位产品经理（PM）带着一张幻灯片走进 AI 功能评审会，上面写着：“参与度 +12%，会话时长 +8%，留存率上升 3 个百分点。” 房间里的人纷纷点头。而在两个工位之外，客服主管正盯着另一张图表：涉及 AI 界面的工单增加了 22%，最常见的处理逻辑是“用户放弃，由人工客服协助”。这两个数字都是真实的，且都来自同一个产品。PM 的仪表盘建立在这样一个假设之上：AI 功能产生的事件形状与它所取代的按钮完全相同。事实并非如此。仪表盘统计的数据与用户实际体验之间的差距，正是 AI 功能在众目睽睽之下悄然失败的原因。

确定性功能的操作手册将交互视为点击流：用户触发一个事件，系统做出反应，用户继续操作。AI 功能具有不同的事件形状——一个包含阶段、重试、转向人工以及遥测数据永远无法看到的离线判断的“任务弧”（Task Arc）。将确定性仪表盘套用在这个任务弧上，就像是用 2018 年的面试流程来筛选 2026 年的工作职位。数字在上升，但这些数字本应预测的结果却在下降。

大多数AI产品团队上线一个点赞/点踩组件，就称之为满意度度量系统。他们确实在度量某些东西——只是那不是满意度。

一个因为函数签名错误而对Copilot建议点踩的开发者，和一个因为建议虽然优秀但当前不适用而点踩的开发者，产生的是完全相同的信号。与此同时，那个悄悄重新生成了四次最终放弃的开发者，根本没有产生任何显式信号。而那个缺失的信号，比评分组件捕获的任何东西都更能预测用户流失。

用户在使用AI产品时留下的隐式行为记录，比他们自愿输入或点击的任何内容都更丰富、更真实、更可操作。本文介绍该收集哪些信号、为何这些信号优于显式反馈，以及防止AI专项遥测污染通用产品分析的埋点方案。

一家加拿大航空公司的支持聊天机器人凭空捏造了一项根本不存在的丧亲票价政策。该机器人表现得非常自信、格式规范且彬彬有礼。乘客们相信了它。法院随后判定航空公司应对这一虚假政策负责。与此同时，该聊天机器人的满意度评分可能还相当不错。

这就是隐式反馈陷阱。大多数团队用来衡量 AI 质量的信号——点赞评级、点击率、满意度评分——不仅充满噪点。它们还在衡量错误目标方面存在系统性偏见。而针对这些信号进行优化，只会让你的 AI 变得更糟。

METR 于 2025 年发布的一项研究，邀请 16 位经验丰富的开源开发者预测 AI 工具能让他们效率提升多少。他们猜测会快 24%。该研究随后对 246 个真实任务（包括修复 bug、开发功能、代码重构）进行了测量，这些任务被随机分配到"允许使用 AI"和"禁止使用 AI"两组。结果是：使用 AI 的开发者实际上慢了 19%。研究结束后，参与者再次接受调查。他们仍然认为 AI 让自己效率提升了 20%。

这种感知生产力与实测生产力之间的差距，并非某项研究的特例。这是大多数团队目前衡量 AI 功能时所面临的核心问题。那些看起来像成功的信号，在很多情况下衡量的是工具的新鲜感，而非其实用价值。而上线后的头 30 天，是最不适合观察的时间窗口。

你的 AI 功能三个月前上线了。DAU 在增长。会话时长在攀升。仪表盘一片绿色。但这里有一个让人不舒服的问题：你的用户到底是在真正采用这个功能，还是仅仅在容忍它？

大多数团队用衡量传统产品功能的相同指标来跟踪 AI 功能采用——日活跃用户数、会话时长、功能激活率。当功能表现是确定性的时候，这些指标运作良好。点击按钮，得到结果，衡量参与度。但 AI 功能有本质区别：它们的输出是变化的，价值是概率性的，用户通过反复接触建立信任（或不信任）。标准指标不仅无法捕捉这一点——它们还在积极地误导你。

你为文档编辑器推出了一个 AI 驱动的摘要功能。采用率很高——第一周就有 40% 的用户激活了它。你的产品经理在 Slack 上写了一条庆祝消息。两个月后，平均会话时长下降了 25%，协作编辑量减少，你的高价值用户正在悄悄流失。没有人将这些趋势与那个闪亮的新功能联系起来，因为跟踪摘要功能的仪表板显示的全是绿色指标。

这就是 AI 功能自相残杀：当 AI 快捷方式解决了用户的即时问题，同时摧毁了让你的产品值得付费的参与循环。这是当今产品开发中最隐蔽的失败模式之一，因为跟踪功能本身的每个指标看起来都很健康，即使产品级别的指标正在衰退。

一套联络中心 AI 系统在验证基准上的准确率超过 90%，但主管们仍然要求客服人员手动录入笔记。18 个月后，该产品以"采用率低"为由被砍掉。这种模式在企业 AI 部署中反复上演——技术上无可挑剔却无人使用的系统，被一套根本看不见失败的指标所衡量。

问题在于，团队所度量的内容与预测产品成败的内容之间存在系统性错配。工程组织从经典 ML 那里继承了度量本能：准确率、精确率/召回率、BLEU 分、延迟百分位、评估通过率。这些指标描述的是孤立的模型行为，几乎无法告诉你 AI 是否真正有用。