AI 功能指标陷阱：为什么 DAU 和留存率在随机化表面 (Stochastic Surfaces) 上会产生误导

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

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

DAU、转化率和留存率是为不再适用的世界构建的

标准的产品分析三元组——日活跃用户（DAU）、通过定义漏斗的转化率以及数周的留存曲线——假设了 AI 功能所违背的三件事。

首先，假设事件是原子性的。点击要么发生了，要么没发生；意义在于计数。而一次 AI 请求发生了，并且产生了一个输出，并且该输出被执行或被忽略了，而且用户可能因为不信任答案而重新询问。你仓库中单一的“使用了 AI 功能”事件将四个正交的事实压缩成了一个位。你在这个位之上构建的任何东西，都会以这个位本身无法揭示的方式出错。

其次，假设参与度与价值相关。对于信息流产品，更多的会话通常意味着更多的价值。对于 AI 功能，针对同一任务的重复会话通常意味着用户第一次没能搞定。相同的指标根据界面是确定性的还是随机性的而反转其含义，而仪表盘根本不知道它处于哪种模式。

第三，假设留存率衡量的是满意度。聊天界面的留存率在用户感到愉悦或用户被困在回退循环中（因为 AI 助手总是“差一点”就能处理好请求）时看起来是一样的。行为特征是相同的：他们都回来了。但解读却是相反的。PostHog 自己关于 LLM 产品指标的文章在这里提到了核心点——用户评价的输出质量与增长和流失相关，但这种评分正是标准仪表盘从未收集过的输入。

两种模式让这种失败变得具体。第一种是“发布即庆祝”模式：团队发布了一个 AI 摘要功能，看到第一个月的页面停留时间增加了 30%，于是宣布胜利。到了第三个月，增幅消失了，关于“摘要是错的，但我分享之后才发现”的客服工单却增加了。团队回过头才意识到，他们衡量的是好奇心带来的新鲜感，而不是实用性。第二种是“参与度 +12%”模式：一个帮助中心添加了 AI 助手，拦截指标上升（同一批用户开启的工单减少了），团队宣告胜利——直到客服主管指出工单的“严重程度”上升了，因为简单的工单都被拦截了，而现在收到的困难工单，其背后的用户已经因为 AI 助手浪费了 20 分钟而满腔怒火。

这两个故事都不是关于模型好坏的问题。它们都是关于测量方法看错了形状。

你真正需要的事件形状：任务弧，而非点击

AI 功能分析的单元是“任务”，而不是“事件”。一个任务有多个阶段——请求、响应、跟进、解决——而解决可能发生在与请求不同的会话中、不同的界面上，由不同的参与者（用户、人工客服，或因为用户放弃而无人解决）完成。你的事件模式（Event Schema）必须将任务作为一个一等实体，并在跨会话的任务弧中持续存在。

具体来说，使正确指标可计算的埋点如下：每个 AI 请求都会开启一个持续存在的 task_id。每一个模型响应、每一个用户回复、每一次升级到人工客服、每一次在 N 分钟后的沉默放弃——都会打上该 task_id 的印记。针对生成式 AI 代理系统的 OpenTelemetry 语义规范明确地朝着这个方向发展：任务是最小的可追踪单元，而操作则汇总到任务中。如果你的仓库无法通过一个单一的键来回答“任务 X 是如何解决的”，那么你拥有的不是 AI 功能分析，而是 AI 功能日志。

第一天就要处理两个边界问题。跨会话边界：用户在周二问了一个问题，不信任答案，周四回来再问一次——这是一个包含两个请求的任务，而不是两个互不相关的请求。如果没有明确的任务连续性（线程 ID、对话 ID 或在一定时间窗口内对近乎重复提示词的客户端回放启发式算法），留存率上升的同时满意度却在下降。跨界面边界：用户询问 AI 助手，助手失败了，用户点击“转人工”链接，人工解决了工单。这是一个成功解决的任务——但 AI 界面的指标会记录为一次放弃，而客服工具的指标会记录为一个新工单，没有任何人的仪表盘会显示“系统工作正常”。升级必须是同一个任务上的标记事件，而不是新任务上的新事件。

这是枯燥的模式设计工作，但它也是下面每一项指标产生意义的前提。跳过这一步而直接发布仪表盘，是这种陷阱中最常见的版本。

应对随机性界面的五项核心指标

随着任务弧（task-arc）埋点机制的就位，真正能预测 AI 功能价值的指标集，看起来与确定性系统的常规打法截然不同。

任务级而非会话级的任务完成率。 分母是“用户开启的任务数”，而不是“用户发起的会话数”。如果一个用户开启了一个任务并解决了它，这算作一个成功的任务，而不是一个低参与度的会话。如果一个用户需要三个会话才能解决一个任务，这算作一个任务，而不是一个高参与度的用户。分母的转变捕捉到了被参与度指标掩盖的倒置情况。对于实现良好的 Agent，结构化任务的行业基准通常在 85–95% 左右；如果低于 80%，无论在精选演示中看起来多么出色，都预示着产品采用率的彻底失败。

将人工介入率视为一级指标，而非失败标志。 团队往往倾向于将每一次人工介入（Escalation）都视为 AI 的失败。不要这样做。对于模型本不该尝试的任务，人工介入是正确的结果；而对于模型本该搞定的任务，人工介入才是错误的结果。有用的框架是按任务类别拆分人工介入率：对于 Agent 应该 处理的任务，人工介入是质量信号；对于 Agent 应该 转发的任务，人工介入则是路由成功的表现。如果将这两类情况混为一个数字进行汇报，会导致团队要么过度微调模型以至于拒绝一切请求，要么微调不足以至于模型在应该推诿时胡编乱造。

区分用户参与度与信任崩溃的重复任务率。 同一个用户提出三个相关但不同的问题是参与度表现。同一个用户在一小时内三次重新组织同一个问题则是失败。一个廉价的代理方案是在一个时间窗口内对 Prompt 进行近似重复检测，在 第二次 请求时标记重复，并将任务弧汇总，使指标读作“需要用户重新询问的已解决任务比例”。如果不进行这种拆分，重复使用看起来像是产品与市场契合（PMF），但往往其实是产品与市场的挫败感。

将输出后放弃率作为质量代理指标。 用户得到了答案；用户没有根据答案采取行动；用户也没有重新询问。他们看了一眼就离开了。这是最隐蔽的失败模式，也是在点击流数仓中最难发现的模式，因为缺失后续事件本身就是信号。埋点机制必须对任务断言一个超时——在响应后的 N 分钟内，如果没有后续行动，且客户端没有反馈放弃原因事件（如关闭标签页、导航离开、将输出复制到剪贴板），则将该任务标记为 abandoned-after-output。然后按功能界面、按任务类别、按模型版本观察该比率。模型升级后放弃率的激增就是一次回归，即使其他所有指标都有所改善。

用户保留但重写的 AI 生成内容的编辑距离。 GitHub Copilot 公布的采纳率指标（平均约 30% 的建议被采纳）是头条数字，但对于产品质量来说，更有趣的数字是接下来十分钟内被采纳的建议发生了什么。如果中位数采纳建议在短时间内被编辑超过了莱文斯坦（Levenshtein）阈值，那么采纳率就过度计算了成功案例。同样的逻辑适用于任何生成用户可保留并编辑文本的 AI 界面：草稿、摘要、代码、回复。在合理的延迟后计算与原始输出的编辑距离，可以将“采纳”与“认可”区分开来。

这些指标都不能完全取代确定性仪表盘。它们与原有指标共存并约束其解读。参与度上升而输出后放弃率也同时上升，意味着参与度是虚假的。重复任务率上升而任务完成率也上升，意味着参与度是真实的。指标间的相互作用比任何单一数字都更重要。

确定性仪表盘曾被允许忽略的方差问题

确定性功能存在来自采样产生的测量噪声——昨天的流量与今天的流量并不完全相同——但底层事件是稳定的。AI 功能增加了一个二阶噪声源：模型本身是随机的（Stochastic），同一天内的同一个 Prompt 可能会产生不同的输出，并导致不同的下游任务结果。近期关于分解 LLM 评估噪声的研究称之为 预测噪声（prediction noise），并表明它在评估套件中通常超过了 数据噪声（data noise），这意味着跨用户平均并不能像分析师习惯的那样平滑这些噪声。

在实践中，这从两个方面冲击了 A/B 测试。首先，最小可检测效应（MDE）会膨胀，因为单任务方差高于单点击方差。一个确定性测试在两周内可以判定的 5% 改进，在随机性功能中可能需要六周，而不为此预留预算的团队最终会基于噪声发布 Prompt 更改。其次，日常的指标漂移看起来比实际更大，针对 10% 下跌报警的仪表盘会不断误报。发布了 LLM 观测实践的公司已转向采用更粗的时间窗口、跨模型版本的配对比较，以及为每个汇报数字标注明确的置信区间——这些都不是确定性功能分析师天生具备的习惯。

评估文献中的“评审团”（cohort-of-judges）模式在产品分析中有一个类比：在测量线上质量时，采样多个独立的质量信号——任务完成率、人工介入率、放弃率、编辑距离——并要求其中至少两个信号协同变动，然后再宣布存在回归。单一指标的变动是噪声；正交信号间的协调变动才是信号。执行这种纪律的团队会在一个数字跨过阈值前几周就发现真正的回归。

仪表盘掩盖下的组织失败模式

仪表盘显示参与度增长了 12%。客服团队的待处理队列显示，由 AI 路由且用户反馈不佳的工单增加了 22%。模型评估（Evals）显示质量持平。CFO 看到的是仪表盘。客服主管看到的是队列。模型团队看到的是评估结果。他们都没错。只是他们关注的并不是同一个东西。

解决方案量并不是寻找一个更好的指标。而是需要一位 AI 界面分析的单一负责人，他横跨在产品经理的仪表盘、客服遥测数据和模型评估流水线（Eval Pipeline）之间，其职责是在这三者出现分歧时发出警示。大多数组织都没有这个角色。他们有一位负责仪表盘的分析师、一位负责队列的运营主管和一位负责评估的机器学习工程师——而这三者之间的分歧变成了每个人的问题，却不属于任何人的职责。AI 功能的指标陷阱在组织层面其实是一个伪装成衡量问题的协作问题。

请将 AI 产品分析视为一门独立的学科，拥有其独特的事件形态（Event Shape）、指标集、偏差预算（Variance Budget），以及一名指定的跨系统全局视图负责人。确定性的仪表盘不会消失——它仍然可以回答关于漏斗、定价页面和新手引导的问题。只不过，一旦它所指向的界面在每次请求时都可能产生不同的输出，它就不再是那个正确的工具了。