没人用的 AI 功能：团队为何交付了无人采用的能力

一家中型项目管理公司的产品副总裁，花了三个季度的工程团队路线图来构建 AI 助手。上线六个月后，每周活跃使用率只有 4%。问她为什么要做：「竞争对手发布了一个，董事会问我们什么时候跟上。」这是一个用产品战略包装起来的恐慌决策——而且这种情况现在到处都是。

4% 不是个例。一个客户成功平台在四个月后，AI 生成通话摘要的采用率是 6%。一个物流 SaaS 添加了 AI 路线优化建议，点击率 11%，实际操作率 2%。一个 HR 平台推出了 AI 政策问答机器人，火了两周，然后跌落至 3% 后趋于平稳。这个规律已经稳定到可以命名了：发布 AI 功能，眼看它被忽视，十八个月后悄悄下线。

默认的解释是 AI 不够好。有时确实如此。但更多时候，模型没有问题——用户压根就没找到这个功能。

为什么 AI 功能的发现比传统功能更难

传统功能是可导航的。用户可以打开菜单，看到一个新选项，然后点击它。功能的存在从 UI 上一目了然。AI 功能从三个方面打破了这个模式。

第一，它们天然依赖情境。能帮你撰写跟进邮件的 AI 助手，只有在你结束一次销售通话、盯着冷掉的收件箱时才有用。在错误的时机呈现——在引导流程中，在第一次打开应用时的工具提示里——它就变成了噪音。用户关掉它，再也看不见。

第二，它们是嵌入式的而非独立的。传统软件在可见的地方添加功能：一个新按钮、一个新标签页、一个新菜单项。AI 能力通常是对已有功能的增强——让搜索更智能，让自动补全更有帮助，让摘要内联显示。用户感觉不到改变，只是隐约觉得产品好了一点，却不明白发生了什么，也不知道可以主动触发它。

第三，首次使用前需要更高的信任门槛。点击一个新的菜单选项风险很低。让 AI 起草邮件或生成报告感觉像是一种承诺。没有见过社会证明、没有建立对 AI 行为心理模型的用户，往往会直接跳过 AI 功能，而不是尝试一下。

不起作用的发现方法

产品团队在推出 AI 能力时通常会用三套标准剧本，但三套都表现不佳。

更新日志和发布公告只能触达一小部分用户——通常不超过 5% 的活跃用户会阅读更新日志。构建这个功能的工程师会看，关注公司 Twitter 的核心用户会看。真正会受益于这个功能的普通用户，永远看不到。

通用引导流程在注册或第一次使用时推送 AI 功能，而此时用户还没有足够的情境来理解他们为什么需要它。一个还没做过 AI 要自动化的手动任务的新用户，对功能价值毫无参照。工具提示被关掉，引导教程被跳过，功能被埋起来。

工具提示和 UI 高亮因为同样的时机问题而失效，加上横幅盲视效果更糟。用户已经学会忽略不在任务路径上的 UI 元素。围绕 AI 按钮的闪烁圆圈，在首次接触后几天内就被当作装饰过滤掉了。

常见的失败模式：发现被设计成一次性事件，而不是行为驱动的过程。你发布功能，你宣布它，然后希望用户碰巧发现它。大多数人不会。

真正驱动 AI 功能激活的因素

实现 AI 功能 20%+ 激活率的团队，有几个共同规律。

从用户行为触发发现，而不是从上线时间触发。 呈现 AI 功能的正确时机，是用户展示出 AI 可以满足的意图时。如果你的 AI 能总结长线程，在线程达到一定长度阈值时展示摘要选项——而不是在引导流程中。如果你的 AI 能生成初稿，在用户打开空白文档后停顿时提供它——而不是在第三次登录时。这需要行为遥测和埋点，但回报是功能恰好在有用的时候出现。

将 AI 能力嵌入关键路径，而不是旁路。 GitHub Copilot 之所以激活率高，是因为它直接出现在编辑器里，内联，就在开发者写代码的地方。没有菜单需要导航，没有面板需要打开。功能就在流程里。如果你的 AI 能力需要用户导航到他们本来不会去的地方，无论模型多好，采用率都会很低。

用同伴信号代替产品公告。 用户相信同事发现有用的东西。呈现匿名使用数据——「你的 143 位队友用这个来准备销售电话」——比功能号召更有说服力。如果你有用户级权限，展示具体的同名同事在使用某功能更有效。同伴验证能处理让首次使用感觉有风险的信任赤字。

给用户一个低风险的首次体验作为默认选项。 你的 AI 功能的第一个输出，应该是用户可以接受、忽略或不后果地关掉的东西。能写草稿让用户删除的 AI，比能直接发送消息的 AI 更安全。能建议标签让用户拒绝的 AI，比能自动分类的 AI 更安全。大幅降低首次使用的感知风险，就能显著降低尝试的摩擦门槛。

AI 功能的渐进式披露

渐进式披露——增量地揭示复杂性而不是一次全部展示——是一个广为人知的 UX 原则。对于 AI 功能，它需要一种特定的实现模式。

从最小可见信号开始：AI 在用户现有工作流程中做一件小而可见的事情，不需要任何操作。一个微妙的内联建议。自动处理的记录数量。在用户正在审查的数据中标记的异常。没有工具提示，没有弹窗，没有引导步骤——只是 AI 默默工作。

第二层与注意到并想要更多的用户互动。一次点击揭示 AI 做了什么、为什么以及还能做什么。这是你解释能力的地方——不是在通用的引导流程中，而是在用户展示出好奇心的时刻。

第三层是为那些已经有过成功体验的用户提供完全访问权限。高级功能、配置选项和进阶模式在这里可以发现——但不是在此之前。

大多数团队遇到的失败模式是：在发布时直接跳到第三层，在用户还没有一次成功互动之前就把他们淹没在能力里。AI 功能需要按顺序赢得信任，而不是一开始就要求信任。

细分问题

大多数团队发现太晚了：「用户」对于 AI 功能采用来说不是一个有用的分析单元。一个被一百家不同公司使用的产品，很可能有一百种不同的激活画像，取决于角色、资历和工作流程。

一个在销售电话中呈现定价情报的 AI 功能，对使用同一产品做库存管理的运营团队毫无意义。向所有人呈现它，对大多数人产生噪音，这会训练用户忽略所有 AI 相关提示，包括那些真正有帮助的。

基于角色和工作流程的细分对于 AI 功能不是可选的——它是让情境化呈现发挥作用的机制。在实施发现触发器之前，工程投入是：弄清楚哪些用户细分具有最高的潜在激活率，专门埋点他们的工作流程，不用无关的提示污染其他群体的体验。

衡量真正重要的指标

功能采用的默认指标是「激活」——用户是否曾经点击过按钮或触发过一次功能。对于 AI 功能，这是错误的信号。

一个尝试过你的 AI 摘要工具一次并得到糟糕结果的用户，在数据中「已激活」，但再也不会使用它。你真正关心的指标是二次激活率：在首次尝试功能的用户中，有多少比例在七天内再次使用？低二次激活率意味着首次体验不够好，无论首次激活率多高。

更有用的 KPI 组合：

• 情境发现率：在用户会受益于该功能的会话中，有多少比例的用户遇到了发现触点？
• 发现到尝试转化率：在遇到触点的用户中，有多少比例尝试了该功能？
• 7 天重试率：在尝试过的用户中，有多少比例回来了？

优化第一个指标是产品和工程埋点问题。优化第二个是 UX 问题。优化第三个是模型质量问题。大多数团队只衡量第二个——这就是为什么他们经常把实际上是工作流程整合失败的发现问题归咎于模型。

更深层的原因：把功能发布当成复选框

AI 功能采用率低的根本原因不是设计问题或工程问题。是决策问题。团队构建 AI 能力，是因为竞争对手宣布了，因为投资人问了 AI 路线图，或者因为技术上可行。真正的用户需求——那种某个用户群体已经在费力地手动完成这项任务的需求——往往是最后才评估的标准。

为满足外部叙事而构建的功能，往往被发布到远离用户实际工作流程的地方。4% 的采用率当然是意料之中的。它们从来就没有围绕用户需求的时刻来设计。

解决方法不是更好的工具提示或更聪明的引导流程。而是在 sprint 开始之前做好功课：识别你的 AI 将要替代的手动行为，理解用户今天在产品流程的哪个地方执行那个行为，并将 AI 能力设计成恰好在那个节点出现。发现不是一个发布步骤。它是几个月前就做出的架构决策。

以这种方式构建 AI 功能的团队——嵌入工作流程、从行为触发、通过同伴信号建立信任——正是那些报告激活率超过 20% 的团队。4% 和 20%+ 之间的差距不是模型质量。是产品纪律。