大多数产品团队将 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 字以下的单语言散文中表现最好”比“这不支持多语言或超长文档”更实用。约束条件相同，但认知负荷不同。前者告诉用户可以期待什么；后者只是让他们走开。
在使用功能前阅读过具体局限性的用户，提交“这行不通”工单的比例大幅降低。剩下的工单往往是更高质量的信号：文档未能预料到的实际边缘案例，这些反馈可以随着时间的推移不断改进局限性说明。
内置于 UX（以及文档）中的置信度透明度 AI 的输出并非非黑即白的正确或错误 —— 它们处于一个置信度光谱（confidence spectrum）上。当你的功能呈现出一个高确定性或低确定性的答案时，用户需要知情。“我对这个答案有 45% 的把握”应该改变用户对其采取行动的方式；“我有 94% 的把握”也同样如此。
这对文档的影响有两个方面。首先，如果你的产品显示了任何置信度指标 —— 概率百分比、颜色编码的确定性级别、明确的“高/中/低”信号 —— 你的帮助内容就需要解释如何解读它们。用户不会凭直觉就意识到黄色徽章意味着 AI 的把握较小。其次，更重要的一点是，如果你的产品根本不显示置信度信号，那么你的文档就要承担更多的责任。你必须在能力文档中更明确地说明哪些输入类型能稳定产生高质量结果，以及哪些输入类型需要用户进行额外的验证。
导致最糟糕支持体验的模式是：一个 AI 功能在没有任何提示答案可能错误的情况下，自信地给出了错误答案。当发现错误时，根据这些答案采取行动的用户会提交工单 —— 并且他们理所当然地感到沮丧，因为产品没有给他们任何知情的途径。即使在缺乏产品内指标的情况下，通过记录置信度边界，这也是一个可以解决的问题。
概率性行为示例（展示差异性） 最有效的预期管理发生在用户投入工作流之前。一个展示相同输入产生三个略有不同输出的 60 秒演示视频，在预期对齐（expectation alignment）方面比解释 AI 具有概率性的三个段落更有效。
这听起来有悖常理。展示差异性（variance）似乎会动摇用户的信心。但在实践中，情况恰恰相反：预先看到差异性演示的用户不会提交“它给了我一个不同的答案”的工单，因为他们已经知道这是正常的。而那些在完全不知情的情况下，第一次在生产环境中看到差异的用户，会将其视为故障。
为此编写的文档格式可以非常轻量：一个简短的示例部分，展示针对相同输入的两到三个输出，并附上一条简短说明，指出变异是预料之中的，以及当用户想要引导至特定风格或格式时该怎么做。这对于涉及摘要、生成或分析的功能尤为重要 —— 只要输出空间很大且用户偏好各异的地方都适用。
“何时使用，何时升级”的决策逻辑 许多 AI 支持工单源于“升级问题”：AI 生成了一些内容，用户不确定是否正确，而文档没有为他们提供下一步该做什么的指导。因为无处可去，他们只能提交工单。
优秀的 AI 文档包含关于何时信任输出、何时独立验证以及该功能何时根本不是正确工具的明确指导。这并不是承认弱点 —— 这是一种真正建立信任的专业指导。如果用户知道“对于监管文件，务必让人类审核 AI 摘要”，他们就会在其他事情上信任 AI，并且不会针对那些他们本就知道需要额外审查的情况提交工单。
这里的格式可以是一个简单的决策树，或者是一个简短的“何时使用/何时不使用”部分，位置应放在主要功能描述的末尾，而不是埋在另一篇文章中。
为什么截图和静态操作指南是一种隐患 除了概念上的不匹配，还存在维护问题。AI 功能的更新频率比传统软件更高。模型变更、能力扩展和行为微调的周期可能超过文档更新的节奏。当 UI 适应新的模型能力时，一篇带有“按钮”截图的帮助文章就会变得不准确。当功能增加了中间状态时，编号的步骤序列就会失效。
如果将假设静态行为的文档框架应用于 AI 功能，会产生复合技术债。每次更新都会产生文档滞后，在此期间，遵循旧指南的用户会感到困惑 —— 并提交工单。
实际意义在于：AI 文档的结构应该设计为在产品变化时能“平稳退化”（degrade gracefully）。与其记录特定的 UI 状态，不如优先描述行为和意图。能力展示库（Capability galleries）比分步指南更耐用。描述行为模式（如“在处理 X 时往往较吃力”）的局限性章节在模型更新后依然准确，即使具体的失败率发生了变化。
优秀文档与工单量之间的反馈闭环 这里存在一个大多数团队都没有闭合的、可衡量的反馈闭环。支持工单包含了关于文档缺失的详细信号：用户尝试错误使用了哪些能力、哪些失败模式让他们感到意外、哪些边缘情况在没有警告的情况下被触发。这些信号很少能以结构化的节奏流回文档团队。
那些做好了 AI 文档的团队往往会每季度根据帮助内容审查工单主题。支持队列中最常见的 20 个 AI 相关查询几乎总是对应于能力展示库的缺失、局限性的遗漏或差异性文档的缺乏。用文档填补这些空白比解决同等数量的工单更快、更省钱。
这就是支持分流计算（support deflection arithmetic）：每一个被编写良好的局限性章节或能力展示库所阻止的工单，都是一个不需要人工介入的工单。在大规模运营中，这个数学题的结论极具说服力。
先构建什么 如果你从零开始构建 AI 文档，杠杆率最高的投资是一个针对每项 AI 功能的“能力库与局限性说明”——而不是重新设计的帮助中心，不是新的文档平台，也不是聊天机器人。一篇清晰的“这在 X 场景下表现良好，但在 Y 场景下不行”的文章，可以预防最常见的一类 AI 服务工单。它还设定了预期框架，使后续的所有文档编写变得更加容易。
第二项投资是差异性文档：明确承认输出结果会有所波动，并提供相关示例，让这种波动看起来是正常的而非系统故障。仅这一项改动，就能显著降低 AI 功能的工单升级率。
在这两项基础工作完成后，其他部分——置信度透明度指南、决策逻辑、工单升级路径——将构成一个更完整的版图。但核心比大多数团队想象的要简单：告诉用户你的 AI 功能是用来做什么的，告诉他们它不是用来做什么的，并向他们展示差异性就是它的运作方式。几乎所有其他内容都是由此延伸而来的。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
