安静放弃模式:AI 参与度指标为何在说谎
有一种特定的失效模式正在悄悄破坏 AI 产品的数据指标,却没有人察觉。你的仪表盘显示建议接受率为 34%、DAU 强劲、功能参与度持续增长。仪表盘没有显示的是:60% 被接受的建议随后被立即重写,参与度最高的用户正是那些点击 AI 输出、全选,然后自己重新输入的人;这个功能对下游任务完成率零可测影响。
这就是"安静放弃"模式:用户系统性地绕过 AI 功能,同时产生活跃用户的全部表面指标。他们不会禁用该功能——他们只是忽略其输出。在你的分析系统中,他们与最佳 AI 用户看起来完全相同。
为什么标准参与度指标无法识别这一问题
测量问题是结构性的。标准 AI 参与度指标——建议接受率、功能调用次数、会话计数、生成代码行数——都是输入指标,而非结果指标。它们记录的是用户触碰了 AI,却无法记录 AI 是否改变了用户的行为。
一个接受 Copilot 建议并原封不动地发布它的用户,与一个接受建议、全选、然后自己重写的用户,在每个仪表盘中看起来都完全相同。两者都触发了"接受事件"。前者是真正的决策委托;后者只是用了一个键盘快捷键。当前的分析系统将二者等同对待。
同样的差距在所有 AI 产品类别中都存在。一个建议点击率达 80% 的 AI 写作助手,可能掩盖着用户点击的目的是关闭弹窗而非采纳文本这一事实。一个 AI 客服机器人可以在会话参与度很高的情况下,默默地没有解决任何工单。一个 AI 代码审查工具可能显示很高的评论接受率,而开发者私下表示他们标记"已接受"只是为了清理界面,然后实施自己的修复。
接受事件不是价值的代理指标,它只是按钮点击的代理指标。
差距背后的研究数据
最有力的证据来自 2025 年的一项随机对照试验。16 位有经验的开源开发者在有无 AI 辅助的情况下完成了 246 项任务。实际结果:开发者使用 AI 工具比不使用慢了 19%。研究开始前的预测:AI 会让他们快 24%。研究完成后的信念:AI 让他们快了 20%。
感知与现实之间的总差距约为 40 个百分点。那些认为 AI 有效的开发者——大多数企业 AI 测量所依赖的信号——在有利于 AI 的方向上系统性地出错了。机制很微妙:提示词开销、调试看似正确但实际有误的 AI 生成代码,以及管理 AI 所了解的内容与代码库实际要求之间上下文的认知 成本。
在团队层面,同样的模式大规模出现。Faros AI 对 AI 编码工具采用的研究发现,开发者完成任务数增加了 21%,合并的 PR 数增加了 98%——单个层面的数字看起来很有说服力。但 PR 审查时间增加了 91%,每位开发者的 bug 数增加了 9%,平均 PR 大小增长了 154%。瓶颈从编写转移到了审查。在公司层面,"AI 采用与关键绩效指标之间的任何相关性都消失了"。
GitClear 对 1.53 亿行变更代码的分析发现,代码流失率——即在编写后两周内被回滚或更新的代码行——预计将比 AI 出现前的基准翻倍。被发布后立即被重写的代码是一个负面生产力结果,却被登记为正面参与度。
你的仪表盘折叠成一个数字的三种参与状态
Mixpanel 的 AI 分析框架识别出三种截然不同的行为状态,而接受率将它们折叠成了一个数字:
- 已接受:用户获取了输出并未经修改地继续
- 已编辑:用户在使用前修改了输出
- 已拒绝:用户忽略了输出并重新提示或放弃
这些是本质不同的事件。干净的接受意味着 AI 真正参与了决策循环。接受后大量编辑意味着用户在支付一种税:他们仍然需要做认知工作,而 AI 输出带来了额外的重新格式化开销。拒绝是诚实的信号。问题是标准仪表盘将三者全部报告为"已参与"。
覆盖率——编辑加上拒绝与接受 的比率——是模型退化最重要的领先指标。上升的覆盖率揭示了即使原始接受率数字看起来稳定,输出也无法满足用户需求。大多数团队没有追踪这个指标。
编辑距离:你没有测量的信号
AI 影响力最直接的行为信号是用户在最终确定之前修改了多少 AI 输出。2024 年的一篇论文开发了一种基于压缩的编辑距离指标,与实际人类编辑时间的相关性达到 0.81。传统的 Levenshtein 距离达到 0.59。语义相似度测量——如 BERTScore——达到负相关,意味着它们会主动误导你关于人类做了多少工作的判断。
这一含义是实践性的。你的埋点系统可能不测量 AI 输出与最终输出之间的编辑距离,它测量的是接受率。这两者是不同的。一个接受了 200 字 AI 段落并重写了 190 字的用户,在你的漏斗中被记录为一次转化。编辑距离是 95%,这不是一个成功指标。
你真正想知道的是:用户"接受"的 AI 输出中,有多少实际上在最终产物中存活下来?这就是存活率,它是可测量的。在代码中,它是 AI 生成的代码行中未经修改出现在最终提交中的比例。在写作工具中,它是被接受建议与提交文档之间的字符级编辑距离。这两个数字都不出现在标准 AI 产品仪表盘中。
行动时间和修订循环
大多数团队忽略的另外两个行为信号:
AI 响应后的行动时间:用户在收到 AI 输出和下一个操作之间花费的时间,揭示了其参与的性质。对复杂输出的快速干净接受表明真正的决策委托——用户阅读了它,理解了它,然后继续。长时间停留后接受可能表明仔细评估(好),或者用户在覆写之前重读输出(不好)。长时间停留后拒绝表明 AI 在失败前产生了错误的信心。
修订循环深度:初始 AI 响应后的后续提示数量是首次响应质量的代理指标。单次提示→单次接受→任务完成的模式与提示→部分接受→重新提示→编辑→重新提示→编辑的模式本质上不同。后一种模式表明 AI 在第一次尝试时没有可靠地达到目标。它正在产生表面参与——每次重新提示都是一个交互事件——同时实际上需要比没有 AI 辅助完成任务更多的总用户工作量。
对新手程序员使用 Copilot 的定性研究记录了接受率仪表盘完全不可见的模式。用户会逐字输入 Copilot 的建议,而不按 Tab 键正式接受它——在 7 名参与者中观察到 14 次。在仪表盘中:零次接受。在现实中:用户在词语层面与建议进行交互。接受建议后立即花费 40 分钟调试结果的用户显示为"高参与度"。调试成本是不可见的。
自动化偏差问题(以及为何它是镜像)
第二种失效模式在标准指标中看起来与安静放弃相同:自动化偏差,即用户盲目接受 AI 建议而不管质量如何。
一项对使用 AI 诊断支持的医生的研究发现,高 AI 信任度的医生接受了 26% 的错误 AI 诊断。对 731 名参与者完成迷宫求解任务的研究发现,增加正确决策的财务奖励降低了过度依赖——不在乎结果的用户自动接受;有利益的用户实际上进行了评估。在临床病理学中记录到 7% 的自动化偏差率,即使 AI 提高了整体诊断性能。
自动化偏差和安静放弃是产生相同仪表盘数字的行为对立面。一组点击是因为 AI 在为他们思考;另一组点击是为了让 AI 离开他们的路。两者都被登记为"已接受"。
区分它们的唯一方法是知道输出是否正确,以及用户的决策是否因 AI 辅助而改善或退化。这需要测量结果,而非事件。
真正有效的方法:测量下游任务完成率
与真实 AI 价值相关的行为信号在 AI 交互本身的下游。收到 AI 建议的用户是否实际完成了任务?他们是否更快地完成了?他们输出的质量是否改变了?
对于 AI 客服,信号是遏制率:问题是否在没有人工升级的情况下解决?原始对话量不是信号。AI 支持工具上的高对话量可能意味着用户正在高效地获得答案,也可能意味着用户因为 AI 不断失败而将同一个问题重新表述六次。
对于 AI 编码工具,信号是 AI 生成的代码在下游发生了什么——有多少被流失,有多少通过了代码审查,它与 bug 引入率的相关性如何。Faros 的研究发现 PR 合并量(一个常报告的指标)会积极误导,因为瓶颈转移到了审查:98% 的 PR 合并量增长 ,91% 的每个 PR 审查时间增长。
对于 AI 写作工具,信号是 AI 文本在最终产物中的存活率,而非接受率。测量方法是留存组分析:维护一个没有 AI 功能访问权限的并行用户队列,并比较两组之间的任务完成率、质量指标和完成时间。这比事件追踪更难实施,但它是唯一能捕捉 AI 是否对结果具有因果责任而非只是在结果发生时在场的方法论。
实际仪器差距
大多数 AI 产品团队正在测量:
- 建议接受率
- 功能调用计数
- 会话时长
- DAU/MAU
- 开发者自我报告的满意度
这些都无法区分真正帮助用户的 AI 功能和用户已经学会绕过的 AI 功能。
真正能告诉你发生了什么的信号:
- 覆盖率(编辑 + 拒绝 / 总计)从接受率中单独分离出来
- 接受建议的 AI 输出与最终产物之间的编辑距离
- 修订循环深度——每次初始 AI 交互的后续提示数量
- 有无 AI 辅助的下游任务完成率
- 留存组比较——没有 AI 功能访问权限的用户群
最后一项是唯一能建立因果关系的。其他都是相关性。
如果你基于 34% 的接受率构建定价、SLA 或工程优先级,而你没有测量这些接受中有多大比例存活到最终产物,那么你是在一个听起来像信号但实际上在测量按钮点击的数字上构建的。
安静放弃模式很容易被忽略,因为它产生了产品团队被训练监控的所有参与度指标。用户没有在抱怨。他们只是系统性地绕过了你为他们构建的功能,一路上礼貌地点击着正确的按钮。
- https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- https://www.faros.ai/blog/ai-software-engineering
- https://www.faros.ai/blog/lines-of-code-metric-ai-vanity-outcome
- https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality
- https://arxiv.org/html/2501.13282v1
- https://arxiv.org/html/2412.17321v1
- https://mixpanel.com/blog/ai-product-analytics-measuring-ai-features/
- https://cloud.google.com/transform/gen-ai-kpis-measuring-ai-success-deep-dive
- https://www.glean.com/blog/metrics-ai-decision-impact
- https://chartmogul.com/reports/saas-retention-the-ai-churn-wave/
- https://a16z.com/state-of-consumer-ai-2025-product-hits-misses-and-whats-next/
- https://fortune.com/article/why-do-thousands-of-ceos-believe-ai-not-having-impact-productivity-employment-study/
- https://writer.com/blog/four-ai-failure-modes/
- https://arxiv.org/html/2509.08514v1
- https://arxiv.org/html/2410.12944v1
- https://getdx.com/blog/measure-ai-impact/
