你的帮助中心在 AI 功能方面缺失了什么（以及为什么用户不断提交工单）

大多数产品团队将 AI 功能的文档视为事后的补救措施——一篇解释按钮在哪里以及点击后会发生什么的帮助文章。接着，支持工单就开始源源不断地涌来。“为什么 AI 这次给我的答案不一样？”“我怎么知道这个结果是否准确？”“昨天还有效，今天就不行了。”这并不是用户在无理取闹。而是他们的心理模型（基于你的文档构建的）与 AI 的实际表现不匹配。

传统的“操作指南”是为确定性软件设计的。而 AI 功能是非确定性的。弥合这一差距不是文案问题，而是结构性问题。适用于设置页面的文档格式，在应用于语言模型时，反而会误导用户。

确定性假设毁掉了一切

每种标准的文档格式——带编号的步骤、截图、“点击这里，然后点击那里”——都隐含着一个隐藏的假设：给定相同的输入，你会得到相同的输出。这个假设是支撑一切的基础。这就是为什么截图可以替代真实的 UI，为什么“执行步骤 1，然后执行步骤 2”能为用户提供可靠的结果，为什么你三个月前写的指南今天依然有效。

AI 功能在每个层面上都打破了这个假设。同一个提示词在不同次调用中可能会返回截然不同的结果。当底层模型更新时，UI 界面也会发生变化。一个以 97% 的准确率处理你的测试输入的功功能，在处理略有不同的输入时，准确率可能会降至 60%——而且没有任何报错，没有任何警告，也没有任何 UI 信号。用户只是得到了一个更糟糕的答案。

关于用户期望的研究表明，无论在哪种人群和背景下，用户始终期望 AI 是“近乎完美”的，或者优于人类的表现。当一个概率性功能产生不一致的结果时，用户不会想“AI 的表现处于正常波动范围内”。他们会认为产品坏了。然后他们会提交工单——并不是因为他们期望一致性是错的，而是因为你的文档从未明确告诉他们波动是正常的。

支持工单问题其实是伪装起来的文档问题。

究竟是什么驱动了 AI 支持工单

当你分析带有 AI 功能的产品的支持队列时，工单类别大致可以分为四个桶：

期望不匹配——“我要求 X，结果得到了 Y。”用户期望 AI 处理它并不擅长的输入类型或边缘情况。如果文档从未说明该功能最适合什么，那么每一次失败都是一个意外。

波动困惑——“昨天还有效，为什么今天不行了？”同样的输入，不同的输出。如果用户没有被告知这是正常的，他们就会将其作为 Bug 上报。

静默失败——AI 生成了输出，但输出是错误的，而且用户无法衡量可靠性。没有置信度指标，没有局限性说明。他们根据错误答案采取了行动，现在需要补救。

能力困惑——用户尝试使用该功能并非为其设计的使用场景。他们无法判断，因为你的文档只描述了能力，而没有界定范围。

投资于“AI 感知”文档模式的公司，其 AI 相关查询的工单拦截率可达 40–60%，而通用支持的行业平均水平约为 23%。这一差距几乎完全来自上述第一类和第四类——即文档本可以在用户使用功能之前就预防的期望不匹配。

你的 AI 文档可能缺失了什么

能力展示库，而非功能描述

传统文档会抽象地告诉用户一个功能的作用：“AI 会总结你的文档。”这在技术上是准确的，但几乎毫无用处。它没有告诉用户他们特定的文档类型是否能很好地被总结，一个 40 页的技术规范是否会与两页的会议记录文件表现不同，或者总结是抽取式的还是生成式的。

“能力展示库”则相反。它不描述能力，而是展示用例匹配：“这在……情况下效果很好，这在……情况下效果不佳”，并根据用户意图进行组织。Google 的实际 AI 用例文档通过功能和结果而非技术架构来组织示例。Devin 的用例库将工程场景映射到实际能力，让从业者在开始之前就能自我评估。

实际要求：对于每个 AI 功能，确定性能最强的三到五个输入类型，性能会下降的两到三个输入类型，以及你应该引导用户转向其他功能的一两个输入类型。明确地记录下来。用户误用功能而提交的每一张工单，都代表了你能力展示库中的一个缺口。

不要把局限性说明埋在免责声明里

在文章底部用 6 号灰色字体写上“此功能可能会产生不准确的结果”，这不叫局限性说明。那是没人会读的法律套话。

AI 功能真正的局限性说明应该是可扫描的、具体的，并放置在用户进入工作流程之前。它会具体指明实际的失效模式：不是“对某些输入可能不太准确”，而是“在混合代码文本上的准确率约为 65%”或“无法可靠地处理带有合并单元格的表格”。要诚实地表述这些——不是作为 Bug，而是作为已知的行为边界。

这里的表述方式很重要。“这在 5000 字以下的单语言散文中表现最好”比“这不支持多语言或超长文档”更实用。约束条件相同，但认知负荷不同。前者告诉用户可以期待什么；后者只是让他们走开。

加载中…