没人用的 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 更安全。大幅降低首次使用的感知风险，就能显著降低尝试的摩擦门槛。
