跳到主要内容

没有人正确衡量的 AI 功能采用曲线

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

为什么传统指标对 AI 功能说谎

DAU 告诉你有多少人打开了一个页面。它没有说明该页面上的 AI 输出是否有用。一个触发 AI 建议、阅读后皱眉、然后手动输入自己答案的用户仍然被计为活跃用户。一个看到 AI 生成的摘要、完全跳过它、直接滚动到原始数据的用户仍然被记录为一次会话。

会话时长更具欺骗性。对于传统功能,更长的会话通常与参与度相关。对于 AI 功能,更长的会话可能意味着相反的情况。一个花十分钟编辑 AI 生成草稿的用户可能在与输出搏斗,而不是从中受益。一个在三十秒内接受草稿然后继续前进的用户产生了更短的会话,但提取了更多的价值。

这种逆转让团队措手不及。微软关于 Copilot 365 推广的内部数据显示,最初参与度最高的组织——第一个月 60% 的活跃用户——到第三个月经常降至 30%。这个峰值是好奇心,不是采用。与此同时,GitHub Copilot 自己的指标显示,开发者实际接受的代码补全建议只有约 30%。其余 70% 被生成、展示然后丢弃。如果你只跟踪"收到建议的用户",你就在把 70% 的浪费和 30% 的价值一起计算。

真正重要的指标

真正的 AI 采用体现在大多数分析管道默认不捕获的行为信号中。三个类别最为重要:

编辑接受比。 当用户收到 AI 输出时,他们怎么处理?完全接受、轻微编辑、大幅改写,还是完全丢弃?这四个类别的分布比任何激活指标都能告诉你更多。一个健康的 AI 功能显示大多数是轻微编辑——用户足够信任输出将其作为起点,但会根据自己的上下文进行优化。一个大多数用户要么盲目接受要么完全丢弃的功能在每种情况下都有不同的问题:盲目接受意味着用户停止了审查(危险),高丢弃率意味着功能没有在交付价值(浪费)。

功能绕过率。 这是遇到 AI 功能并主动选择手动路径的用户百分比。如果你的产品提供 AI 生成的提交信息,而 65% 的用户每次都点击"自己写",那就是绕过。如果你的搜索栏显示 AI 建议的查询,而大多数用户忽略它们自己输入,那也是绕过。这个指标是煤矿中的金丝雀——它在 DAU 下降之前就会上升,因为用户在停止访问页面之前就停止了信任该功能。

覆盖时间。 当用户确实覆盖 AI 输出时,他们多快这样做?一个看到 AI 建议后立即开始输入自己版本的用户已经认定该功能不可靠。一个阅读建议、停顿然后修改的用户实际上在考虑输出。展示和覆盖之间的延迟是信任的代理指标。亚秒级的覆盖意味着用户甚至没有阅读 AI 生成的内容。

新鲜感悬崖:区分好奇心和承诺

每个 AI 功能都遵循一个可预测的采用曲线,它看起来与传统 SaaS 采用的 S 曲线完全不同。以下是实际发生的情况:

第 1-2 周:新鲜感峰值。 所有人都尝试该功能。使用指标看起来非常出色。高管把仪表盘转发给董事会。这个阶段对预测长期采用毫无意义。

第 3-6 周:幻灭期下降。 得到糟糕结果的用户停止尝试。得到尚可结果的用户忘记该功能的存在。DAU 下降 40-60%。这是大多数团队恐慌的时候,要么砍掉功能,要么加倍内部推广。

第 7-11 周:习惯养成窗口。 微软的研究表明,开发者大约需要 11 周时间才能充分实现 AI 编码工具的生产力收益。熬过幻灭期下降的用户现在正在建立心智模型——AI 什么时候有帮助,什么时候没有。他们发展出选择性信任——在某些任务中使用该功能,在其他任务中绕过它。

第 12 周以后:真正的采用平台期。 这是唯一重要的数字,它通常远低于新鲜感峰值。Jellyfish 2025 年跨工程组织的数据发现,GitHub Copilot 和 Cursor 等工具在度过初始流失期的用户中实现了 89% 的 20 周留存率。但"度过初始流失期的用户中"这个限定词承载着巨大的意义——分母在留存率稳定之前已经大幅缩小。

陷阱在于在峰值时衡量并宣布胜利,或在下降时衡量并宣布失败。任何单一快照都无法告诉你什么。你需要完整的曲线。

构建埋点架构

捕获这些行为信号需要大多数团队默认不会构建的埋点。以下是管道的样子:

事件级 AI 交互日志。 每个 AI 建议、生成或推荐都需要发出一个结构化事件,包括:建议了什么、用户对它做了什么(接受、编辑、丢弃、绕过)、用户在行动前花了多长时间、以及如果他们覆盖了建议替代了什么。这不是你标准的点击追踪——它需要将 AI 输出事件与后续的用户行动事件配对。

按 AI 曝光进行群组分割。 根据用户首次接触 AI 功能的时间而不是注册产品的时间来划分用户群组。独立追踪每个群组在新鲜感-幻灭-习惯曲线上的进展。上周开始看到 AI 建议的用户与已经使用了三个月的用户处于根本不同的状态。将他们混合到单个 DAU 数字中会产生一个不描述任何人的指标。

结果归因,而非活动归因。 目标不是知道某人是否使用了 AI 功能。而是知道 AI 功能是否改善了他们的结果。AI 辅助的代码审查是否捕获了手动审查遗漏的 bug?AI 生成的摘要是否使用户免于阅读他们本来会粗略浏览的 50 页文档?这需要将 AI 交互事件链接到下游结果事件——合并率、修订次数、任务完成时间、错误率。

同一用户内的对比基线。 最强大的分析是比较同一用户在类似任务中有无 AI 功能时的行为。如果一个开发者在 Python 中接受 AI 建议但在 Rust 中绕过它们,这以聚合接受率永远无法告诉你的方式展示了你的模型在哪里强、在哪里弱。

真空假说:当好指标隐藏坏结果

Google 2024 年的 DORA 报告揭示了一个反直觉的发现:工程团队 AI 工具采用率增加 25% 对应着交付稳定性下降 7.2%。研究人员称之为"真空假说"——不写样板代码节省的时间立即被调试 AI 生成的错误、重构不符合惯例的代码以及理解生成的代码实际做了什么所消耗。

这是 AI 采用衡量中的最后一个陷阱。即使用户真正采用了该功能——高接受率、低绕过率、稳定留存——对生产力的净影响仍然可能是负面的。生成节省的时间被重新分配到验证上。认知负荷没有减少;它从创造转移到了审查。

这意味着你的埋点需要再增加一层:衡量总任务时间,而不仅仅是 AI 辅助的部分。如果用户在 2 秒内接受了一个 AI 建议但花了 10 分钟验证它,该功能对那个任务的净贡献与接受率指标所暗示的不同。追踪从任务开始到任务完成的完整循环,将 AI 交互作为该循环中的一个事件。

健康的 AI 采用实际上是什么样的

在对所有这些进行埋点之后,你应该期望什么?基于 2025 年到 2026 年大规模部署 AI 功能的组织的数据:

  • 代码建议的接受率在 30-50% 之间,在前 11 周呈上升趋势。持续低于 30% 表明模型与任务不匹配。高于 50% 需要调查——用户可能已经停止批判性审查建议。
  • 习惯养成窗口后绕过率低于 40%。更高的比率意味着该功能没有在用户遇到它的任务中赢得信任。
  • 20 周时留存率高于 80%,在熬过幻灭期下降的用户中。如果你的 20 周留存率低于 60%,该功能有价值交付问题,而不是发现问题。
  • 编辑接受分布偏向轻微编辑(50-60%),其余部分在完全接受(15-25%)和丢弃(15-25%)之间分配。U 形分布——大量完全接受和大量丢弃,很少编辑——表明用户已经分化为"盲目信任"和"完全不信任"。
  • AI 辅助任务的总任务时间改善 15-25%,相对于基线。Jellyfish 的数据显示成熟 AI 采用团队的周期时间减少了约 24%,但这花了几个月才显现,需要初始生产力下降期的解决。

停止衡量活动。开始衡量信任。

AI 功能标准采用指标的根本问题是它们衡量的是与功能的接近程度,而不是从中提取的价值。站在自动售货机旁边的人不等于顾客。看到 AI 建议的用户不等于从中受益的用户。

真正重要的指标——编辑接受比、绕过率、覆盖时间和总任务时间——更难埋点,更难做成仪表盘。它们需要事件级 AI 交互日志、按曝光日期的群组分割,以及将 AI 交互链接到下游结果的结果归因。但它们是唯一能告诉你用户是在采用你的 AI 功能还是仅仅在容忍它直到找到关闭设置的指标。

在你需要之前构建埋点。当你的 DAU 图表开始下降时,信任在几周前就已经失去了。行为信号会告诉你什么时候正在发生——如果你在倾听的话。

References:Let's stay in touch and Follow me for more thoughts and updates