没人用的 AI 产品指标：超越准确率，走向用户价值信号

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

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

无人谈及的度量盲区

AI 产品失败时，它鲜少败在团队追踪的指标上，而是败在无人关注的指标上。

技术上正确的输出在特定情境下可能完全无用。一个快速响应若需要五分钟的认知核验，其总任务时间可能比一个稍慢却能立即付诸行动的响应更长。在留存测试集上测得的准确率，告诉你的是模型在与标注数据相似的样本上的表现，而非用户实际发送的那些杂乱、模糊、依赖上下文的查询。

古德哈特定律潜伏在每个角落。一旦团队开始把某个基准作为质量代理来优化，这个基准就不再能衡量它本应衡量的东西。模型开发者通过过拟合基准格式来刷榜；内部团队通过挑选最优案例来拉高评估分数。指标上涨，产品变差。

核心失败在于：将系统性能指标（准确率、精确率、延迟）当作产品性能（任务成功率、用户价值、留存）的代理。两者顶多弱相关，在压力下这种相关性更会瓦解。

任务完成率：真正预测留存的指标

任务完成率（TCR）——已发起任务中达到成功终态的比例——是最接近 AI 产品北极星的指标。

一些团队将其称为意图解析率（IRR）：对话中用户明确或推断意图被成功解决的比例。区分健康产品与挣扎中产品的阈值约为 70%。即使日活数字看起来相同，超过这一阈值的产品 30 天留存也显著优于低于 55% 的产品。使用指标可以持平甚至增长，而产品却在悄然侵蚀。

实现细节至关重要：「已完成任务」必须在产品层面定义，而非模型层面。模型层面的完成意味着「模型无错误地返回了响应」，产品层面的完成意味着「用户得到了想要的东西，无需再次询问」。这两个数字往往差距悬殊。

对于编程助手，TCR 意味着用户接受了实际可用的代码，而不仅仅是被生成出来的代码。对于搜索产品，意味着用户找到了目标且未重新构建查询。对于 AI 写作工具，意味着文档被保存或发布，而非仅仅被起草。

大多数团队度量的是错误的一端：他们追踪建议展示量和 Token 数，却忽视这些建议是否真正被使用。

编辑率：高信号量的信任指标

当用户收到 AI 输出并在使用前进行修改，这些编辑本身就是数据。编辑模式所揭示的真实质量，远超任何离线基准。

编辑率（使用前修改输出的比例）结合编辑距离（修改幅度）提供了准确率分数无法给出的信任信号。低编辑率加高任务完成率，意味着 AI 输出用户直接信任并使用；高编辑率加任务完成率，意味着用户在花费认知成本来弥补方向正确但不够精准的 AI 输出；低编辑率加低任务完成率是危险区——用户不是在编辑，而是在放弃。

GitHub Copilot 的企业研究发现，开发者在编辑器中保留了所接受字符的 88%——这比原始接受率更能体现信任。Glean 将 70% 以上的响应无需修改直接接受作为健康信任校准的基准。

重要区分在于编辑率与重新生成率。编辑意味着用户认为输出值得挽救；请求全新响应意味着他们已经放弃当前这个。两者都携带信息。重新生成频率随时间上升是输出质量相对于用户预期下降的早期预警信号，往往在任何准确率指标移动之前便已出现。

会话深度：不分组就会误导的参与度代理

会话深度（每次对话的平均轮次）是作为单一数字报告时产生最多误导性解读的指标。

一次 12 轮的对话，可能意味着用户与 AI 共同处理了真正复杂的问题，每一步都有收获；也可能意味着用户用五种不同方式反复追问，每次都得到令人困惑的回应，最终未能解决便放弃了。聚合数字看起来完全一样。

正确使用会话深度的方式是按结果分组。将会话分为已解决和已放弃两类，再分别追踪深度。对于编程助手中已解决的对话，生产性范围是 4–7 轮——足以建立上下文并迭代，不至于陷入循环。对于已放弃的对话，超过 10 轮但无法解决的情况很少在 7 天内带来重新参与。

深度已解决会话与深度已放弃会话之比是交互质量的诊断指标。深度已放弃会话比例上升，预示着一种特定失败模式：用户努力尝试却反复失败，这比快速失败对信任的伤害更大。会话深度作为独立参与指标几乎毫无意义；按结果分组的会话深度则是强有力的健康指标。

回访率与激活阈值

AI 产品的留存集中在一个上游变量上：用户是否在早期就达成了第一次有意义的成功。Notion 在其 AI 写作功能推出时清晰地看到了这一点——留存与「首次笔记的时间」强相关。快速获得第一次成功的用户会回来；没有获得的，不会。

最可靠预测 3 个月留存的激活指标是 7 天激活率——用户是否在第一周内获得了成功结果。这比会话数量、查询量或任何准确率相关指标都更具预测力。

GitHub Copilot 的企业部署许可证利用率约为 80%，月度流失率约 1%。ChatGPT Plus 6 个月留存率为 71%，Claude Pro 为 62%。这些数字之间的差距不是由准确率基准驱动的，而是由用户多快能达到没有该工具就无法实现的结果来驱动的。

回访率作为独立指标是滞后的。当你看到流失时，失败早在数周前就已发生。领先指标是挫败指数——一个结合了消息重复、冗长响应后的简短追问、明确的澄清请求以及在 AI 响应后放弃会话等行为信号的综合指标。连续两次会话挫败指数上升的用户，在 14 天内流失的概率约为其他人的 3 倍。你可以在失去他们之前就采取行动。

为用户价值埋点：真正该追踪的内容

度量系统性能的团队与度量用户价值的团队之间的埋点差距，归结为事件 Schema 的设计。只度量系统性能的团队记录生成事件；度量用户价值的团队记录生成之后发生的事情。

重要的事件对：

• suggestion_shown → suggestion_accepted / suggestion_rejected / suggestion_edited
• task_started → task_completed / task_abandoned
• output_generated → output_used_as_is / output_modified / output_regenerated
• session_started → session_completed_with_success / session_abandoned

认知延迟——输出生成到用户接受或拒绝之间的时间——是一个特别未被充分利用的信号。快速接受意味着即时信任；长时间斟酌后进行编辑意味着用户在手动核验；长时间斟酌后拒绝意味着输出未能提供帮助。三者在生成层面具有相同的延迟形态，但在接受层面形态截然不同。

核验成本是认知延迟背后的指标：用户需要付出多少努力才能验证 AI 输出是否正确？高核验成本表明无论技术准确率如何，用户信心都偏低。那些选择继续手动录入笔记而不接受 AI 摘要的联络中心客服，正在支付极高的核验成本——审阅 AI 输出、发现不一致、加以修正，最终决定从头开始更快。

微软度量的是「Copilot 协助时长」——一种基于动作计数和研究衍生乘数估算的员工总辅助时间。其员工平均每月节省 9 小时，这是一个价值指标。API 调用次数则不是。

框架：系统性能 vs. 产品性能

任何 AI 产品指标的诊断性问题是：这个指标在 AI 帮助用户成功时会移动，还是在 AI 产生更多输出时才会移动？

系统性能指标在 AI 产生更多输出时移动：准确率、延迟、Token 消耗、建议展示量、API 调用次数、基准分数。这些对工程质量控制而言是必要的，但不足以作为产品质量信号。

产品性能指标在用户成功时移动：任务完成率、编辑率与编辑距离、首次成功结果的时间、回访率、AI 响应后的放弃率。这些决定了用户是否会持续回来。

目标不是抛弃系统性能指标——准确率重要，延迟重要。目标是停止把它们当作用户价值的代理。它们是上游输入；完成率、编辑率和回访率才是决定你是否构建了一个真正有人用的产品的输出指标。

大多数 AI 团队拥有完善的系统性能指标基础设施，却几乎没有产品性能指标的基础设施。解决方案在于埋点设计：构建捕获用户如何使用 AI 输出的事件 Schema，而不仅仅是 AI 输出被产生这一事实。然后度量完成率、信任度和回访率。这些数字才能告诉你，你究竟是否在构建一个人们真正愿意使用的东西。