企业级 AI 能力发现问题

你发布了 AI 功能。你将其内置于产品中。你编写了帮助文档。然而，六个月后，你最资深的企业用户仍然在将文本复制粘贴到 ChatGPT 中，以完成你的功能原本就能原生实现的事情。这不是培训问题。这是一个可发现性（discoverability）问题，也是当今企业软件中 AI 投资浪费最普遍的来源之一。

这种模式已有详尽的记录：49% 的员工表示他们在工作中从不使用 AI，74% 的公司难以从 AI 部署中扩大价值。但有趣的失败模式并不是那些明确抵制的后期采用者，而是那些每天打开你的产品、却从未意识到原本值得他们付费的 AI 功能就潜伏在光标一键之遥处的活跃用户。

空白画布问题

传统软件有菜单、工具栏和图标。用户打开文档处理器时，各种功能入口（affordances）是清晰可见的：加粗、斜体、表格、拼写检查。他们不需要想象什么是可能的；界面会告诉他们。生成式 AI 完全打破了这种模式。

一个聊天框是史上功能密度最高的 UI 界面，但同时也是在传达“它能做什么”方面表现最差的。空的提示词（prompt）字段同时传递了无限的可能性和零方向。对 AI 新用户的研究一致发现，他们会倾向于对界面进行最显而易见和字面意义上的解释：如果它看起来像搜索框，他们就搜索；如果它看起来像消息框，他们就发消息。他们不会为了发现那些没有理由去期待的深度而进行实验。

这就是空白画布问题。通过增加文档或让帮助中心可搜索是无法解决这个问题的。用户不会为了发现自己不知道的功能而去浏览帮助中心。他们是通过在特定的语境下、在能从中受益的时刻遇到这些功能来发现它们的。

企业用户还有额外的约束：他们是时间紧迫的专业人士，使用工具是为了完成工作，而不是为了学习新软件而乐于探索的探险者。除非产品能为他们消除认知负荷，否则他们会理智地避开功能发现过程中的认知负担。

为什么产品内发现优于培训

企业软件的直觉是通过培训来解决采用率问题：入门视频、午餐分享会、内部倡导者、认证计划。这些在边缘环节有所帮助，但无法解决核心问题，因为它们与相关的时刻脱节了。

用户在周一的培训课程中学习了总结功能。到了周四，当他们埋头于一份 40 页的文档并需要使用它时，他们想不起那场培训。他们没有围绕该功能养成习惯，因为他们还没有使用过。学习在强化的使用场景出现之前就已经衰减了。

相反，有效的方法是在意图产生的时刻显露功能。当用户将一大段文本粘贴到文档编辑器中时，这就是建议“总结这段文字”的时机。当用户写了一封很长的支持回复时，这就是提供语气调整的时机。当用户打开一个带有自定义过滤器的仪表盘时，这就是向他们展示可以提出自然语言问题而不是构建过滤器链的时机。

这在 UX 设计中并不是什么新见解，但在 AI 产品中却一直投入不足。在这些产品中，团队将 90% 的精力花在模型上，而只有 10% 的精力花在决定用户是否能找到它的界面上。

功能层面的渐进式披露

渐进式披露（Progressive disclosure）是解决界面复杂性的标准方案：先显示简单选项，随着用户深入参与再揭示高级选项。这在传统软件中有效，在 AI 中也有效，但实现方式有所不同。

对于 AI 功能，披露层级如下：

• 第 0 层：功能不可见。不知道它存在的用户无法使用。
• 第 1 层：被动指示器显示功能可用。一个闪烁图标、一个 “AI” 徽章、或者出现在输入框下方的建议操作。
• 第 2 层：在高度相关的时刻出现未经请求的建议。系统推断语境并呈现具体、明确的操作。
• 第 3 层：交互式提示或内联示例向用户展示如果他们使用该功能，输出会是什么样子。
• 第 4 层：用户明确参与并进入完整的 AI 交互。

大多数产品直接从第 0 层跳到第 4 层，期望用户通过文档或口碑传播自行发现。而获得强劲采用率的团队会在第 1 层到第 3 层上投入重金。

GitHub Copilot 在 IDE 语境下做得很好，因为第 1 层被植入了开发者的现有工作流中——当你打字时，虚影文本（ghost text）会自动出现，让你无法忽视这一功能。发现是通过使用发生的，而不是通过教育。Slack 的 @ 提及模式也达到了类似的效果：功能出现在用户已有的工作流中，发现成本几乎为零。

产品内示例注入

具体示例是提升 AI 功能可发现性的最高杠杆投资。不是文档示例，也不是帮助中心示例，而是嵌入在用户使用点 UI 界面中的示例。

这种机制之所以有效，是因为 AI 能力在抽象状态下很难描述，但通过具体案例却很容易理解。“总结文档”的可操作性不如看到当前屏幕上打开的特定文档的三句摘要。 “生成客户外联邮件”的可操作性不如看到你正在查看的潜在客户记录的草稿邮件。

有几种实现模式值得研究：

提示词建议气泡（Prompt suggestion pills）：在聊天输入框下方或附近显示的简短示例提示词，针对当前上下文定制。OpenAI 早期尝试这种模式时显示的是通用建议，效果并不理想，因为它们与用户意图脱节。更好的版本会将建议与用户当前的操作挂钩：如果他们在查看 CRM 记录，建议会引用该联系人的姓名和公司。

空状态用例库（Empty-state use-case galleries）：当用户第一次打开某个功能区域时，不要显示一个空的对话框，而是显示一个包含三到五个具体场景及其预期输出的网格。这些既是示例，也是一种含蓄的授权：用户会看到这是一个被官方认可的用例，而不是一次实验。

上下文自动完成建议（Contextual autocomplete suggestions）：当用户开始在提示词字段中输入时，系统会根据当前文档、记录或对话的上下文来补全或优化提示词。这通过演示而非指令，隐性地教授了提示词结构。

关键约束：示例必须足够具体，让用户感到相关，而不是通用到可以应用于任何事物。 “分析此数据”作为建议无法让用户了解分析会揭示什么。而在支持主管查看本月工单仪表板时，提供“从本月工单中识别前三个支持类别”的建议，则是可操作且令人印象深刻的。

上下文激活与工作流集成

采用率最高的 AI 功能不是用户主动导航前往的功能，而是用户在进行原有操作时自然遇到的功能延伸。

这就是为什么集成到现有工作流工具（Slack、邮件客户端、IDE、CRM）中的 AI 功能在企业采用率上始终优于独立的 AI 应用。发现成本几乎为零，因为用户已经在那个环境中了。问题在于 AI 能力是否在该环境中的正确时刻出现。

有效的上下文激活需要两点：探测正确时机和极低摩擦的操作。时机探测问题更难解决。每当用户执行任何操作时都触发 AI 建议会产生噪音，导致用户学会忽略它们。在具有高信号的行为上触发建议——例如粘贴大量文本、打开长文档、输入超过一定字数的消息、在屏幕上停留超过阈值时间——才能产生相关性。

低摩擦操作意味着用户可以通过一次交互接受或拒绝建议。任何需要用户打开新面板、配置设置或导航到不同部分才能看到价值的 AI 功能，无论底层模型有多好，其采用率都会很低。

留存论证

能力发现通常被框架化为一个采用问题，这意味着它在用户参与的前几周最重要。但更重要的框架是留存。

企业级软件的留存是由其嵌入用户工作流的深度驱动的。一个发现并围绕三个 AI 功能养成习惯的用户，其留存率明显高于仅使用产品核心非 AI 功能的用户。发现过程将工具转化为工作流依赖。

数据一致表明：投资于上下文引导和产品内示例注入的 B2B SaaS AI 产品，其激活率在 50–55% 之间，而仅依赖传统引导流程的产品基准激活率为 35–38%。漏斗顶部 15 个百分点的激活率差异，会在一个群体的生命周期中产生巨大的复利效应。

这使得能力发现成为企业 AI 产品团队可以进行的最高杠杆投资之一。模型从一个前沿版本升级到下一个版本，任务质量可能提高 10-20%。而更好的能力发现可以以更小的工程投入，更大幅度地提升激活率和功能覆盖度指标。

实际需要改变的地方

对于构建企业级 AI 功能的工程团队来说，实际的启示如下：

明确映射能力图谱。 在你能根据上下文呈现能力之前，你需要一个清晰的功能分类，用具体的任务术语表达，而不是抽象的能力术语。“总结”不是一个能力分类条目，“将 Slack 会话总结为行动项”才是。

监测可发现性，而不仅仅是使用情况。 大多数产品分析只跟踪功能是否被使用。要跟踪用户是否知道该功能的存在。进行 A/B 测试，观察在关键信号时刻收到上下文建议的用户群是否比对照组更多地使用了该功能。衡量按发现路径拆解的“首次使用时间”。

将建议层作为一等系统来构建。 决定何时呈现 AI 建议、呈现哪个建议以及显示哪个示例的逻辑是真正的产品代码，值得与 AI 功能本身同等的投入。一套永远不变的硬编码通用建议不是建议系统；它只是一个静态工具提示。

将产品内示例视为需要维护的内容。 功能发布时相关的示例会随着产品的演进而过时。建立一个审计和更新示例的流程，使其与功能更新的节奏保持一致。

大多数企业级 AI 功能表现不佳的原因并不是底层模型不足。而是模型能做什么与用户知道可以要求它做什么之间存在鸿沟，且这个鸿沟从未被弥合。缩小这一差距是一个设计和工程问题，而不是模型问题，而且解决它的成本几乎总是比下一次模型升级更低。

---

那 49% 从不使用 AI 的员工并非抵制者。他们是那些打开了对话框，却不知道该输入什么，然后回到了自己已经熟悉的工作流中的用户。能够解决企业 AI 采用问题的产品，将是那些能在这些用户本来可以获益的准确时刻，为他们提供具体的、相关的建议的产品——在他们不得不开口询问之前。