用户把说明书翻到第三页还没找到“怎么导出报表”，你大概率马上会收到一条客服消息。产品说明书最常见的失败方式，就是从功能菜单开始写——功能列得整整齐齐，用户却只想按任务走。AI 能把零散的功能资料整理成说明书，但只有围绕“用户任务”组织、并写清每一步操作后应该看到什么，它才不是功能清单的换皮。
先写用户任务，不先写功能
动笔前先列用户最常完成的任务：创建项目、导入资料、邀请成员、导出结果、恢复误操作。然后把功能放进对应的任务里。一个功能可能服务多个任务，不需要在开头把所有按钮介绍一遍。
产品资料散在会议纪要和群聊里，先用聊天记录转待办清单的方法把已确认的功能捞出来；提示词结构拿不准的，先看AI 提示词完整写法。
一份可用说明书的 6 个模块
- 适用对象：谁在什么场景用，哪些版本或权限适用。
- 开始前准备：账号、权限、文件格式和必要材料。
- 操作步骤：每一步的动作、界面位置和操作结果。
- 完成标准：用户怎样判断任务已经成功。
- 故障排查：现象、可能原因、恢复方法和转人工条件。
- 常见问题：高频疑问、限制条件和不支持范围。
缺了“完成标准”和“故障排查”，说明书写得再细，用户卡住时还是不知道怎么办。
可直接复制的产品说明书提示词
你是一名产品文档编辑。请根据我提供的产品资料，编写一份面向普通用户的使用说明书。说明书按用户任务组织，不按内部功能模块堆砌。 目标用户：[新手/管理员/普通成员] 产品版本：[填写版本和平台] 主要任务：[列出用户要完成的任务] 产品资料：[粘贴已确认的功能、界面名称、权限、限制和故障信息] 请输出： 1. 适用对象和使用场景 2. 开始前准备：账号、权限、材料和支持格式 3. 按任务编写操作步骤：步骤编号、用户动作、操作后应看到的结果、检查点 4. 完成标准：怎样确认任务成功 5. 常见故障：现象、可能原因、恢复步骤、何时转人工 6. FAQ：问题、简短答案、相关任务入口 7. 尚缺资料：无法从现有资料确认的界面、规则或限制 规则： - 只使用已确认的产品资料，不编造按钮、菜单或功能 - 界面名称保持一致，不混用简称 - 每一步只写一个主要动作 - 操作后必须说明用户应该看到什么 - 涉及删除、覆盖、付费或权限变更时增加醒目提醒 - 无法确认时写“待产品人员确认”，不能猜测
示例：导出报表这一步该怎么写
最差的写法是“进入报表页面并导出”——用户照着点完，不知道成了没有。可以执行、可以自检的写法是这样：
- 在左侧导航选择“数据报表”。打开后应看到日期和部门两个筛选项。
- 选择统计日期与部门，确认页面顶部显示的筛选条件与你选的一致。
- 点击“生成报表”，等待按钮旁的状态变为“已完成”。若长时间停在“处理中”，见下文故障表。
- 点击“导出 Excel”。下载后核对文件名里的日期范围，打开后核对记录数量是否等于页面提示的条数。
每一步都写了“应该看到什么”，用户就能自己判断卡在哪一步，而不是一遇问题就找客服。
同一任务的异常处理，别散在文档角落
| 现象 | 可能原因 | 恢复步骤 | 何时转人工 |
|---|---|---|---|
| 提示“无权限” | 账号角色未开通报表权限 | 联系管理员开通“报表查看”权限后重试 | 开通后仍无权限 |
| 状态一直“处理中” | 数据量大或服务繁忙 | 等待 5 分钟后刷新页面 | 超过 30 分钟仍失败 |
| 导出文件打不开 | 浏览器拦截下载 | 检查浏览器下载设置，重新点击导出 | 更换浏览器仍失败 |
| 记录数量对不上 | 筛选条件被重置 | 重新设置筛选后再次生成 | 重复多次仍不一致 |
把异常和正常流程放在一起讲，比在文末堆一个“常见问题”好用得多，用户卡住时能就地找到答案。
故障排查不要写成万能答案
“刷新页面或联系管理员”不算排查。要区分是没权限、文件格式错、网络断了，还是任务还在处理。涉及账号、订单或个人资料时，不要引导用户把敏感信息发到公开渠道。
三个容易踩的坑
- 把“应该”写成“必须”：“导入后应显示成功提示”是预期结果，“必须点击保存”才是强制动作。混用会让用户分不清哪些可选、哪些不做会出问题。
- 遗漏版本号：界面改了、功能加了，说明书还在讲旧版，是客服压力的大头。文首标注适用版本，发布前对着截图核对一遍。
- 只写步骤不写结果：用户照做却不知道成功没有，卡住就来找客服。每步补一句“应看到什么”，问题会少很多。
一个真实的故障排查片段
用户点“生成报表”后按钮一直停在“处理中”，界面没有报错——不是权限、也不是文件打不开，只是数据量大、任务在排队。排查表里对应写着“等待 5 分钟后刷新页面，超过 30 分钟仍失败再转人工”，他照做后刷新，报表正常生成。好的排查章节就是先按现象定位，再给可执行步骤，最后明确什么时候才需要找客服。
发布前验证
- 让一名不了解产品的人按文档完成一次任务，记下他卡在哪。
- 检查界面名称、版本和截图是否一致，别拿旧版界面当配图。
- 确认删除、付费和权限操作都有醒目风险提示。
- 把测试中发现的问题补进 FAQ。
需要通知用户版本变化，可以用AI 邮件生成器整理更新说明；复杂流程先画清楚分支，用AI 思维导图工具梳理任务路径。
说明书的上游通常是产品需求。需求没定清楚就写文档，返工会很惨，可以先参考AI 写 PRD 提示词把验收标准立住；刚起步的话，从AI 新手入门开始最稳妥。
把任务放进真实场景里
例如，用户按说明书第三步操作后找不到按钮，实际是版本和权限不同。这类任务的难点通常不在“让AI写一段话”，而在于先把事实、边界和交付对象理顺。开始前应单独列出已有材料、尚未确认的信息和不能由模型替你决定的事项。没有依据的数字、承诺、人员安排和专业结论一律标记待确认，不用看似完整的句子掩盖信息缺口。
处理时重点抓住这些要素：适用版本、用户角色、前置条件、操作步骤、预期结果、故障和升级入口。先用一小段材料跑通，再扩大到完整任务，能更早发现字段缺失和理解偏差。涉及多人协作时，最好让下一位执行者复述一遍：他从文档里看到了什么、准备先做哪一步、遇到什么情况需要停下。复述不一致，说明文档仍需修改。
先确定输入，再决定交给AI什么
一个常见的失败版本是：只写点击路径不写结果，截图过期，应该与必须混用。它往往表面整齐，实际无法执行。修正时不要只让AI“更专业”，而要指出哪一项事实缺失、哪句话无法验证、哪一步没有责任人或判断条件。每轮只改一类问题，并保留修改前后的差异，后续才能沉淀出稳定做法。
- 事实核对：人名、日期、金额、指标、文件版本和业务规则回到原始材料逐项确认。
- 边界核对：区分已经决定、正在讨论、个人建议和模型推断，不能把四者混写。
- 执行核对：动作写到具体对象、负责人、时间和可观察结果，删掉“持续关注”“及时处理”这类空话。
- 风险核对：敏感数据先脱敏，合同、财务、法律、安全、医疗等结论交给相应专业人员。
交付前用一个简单标准验收：新用户在无口头帮助下完成核心任务，异常场景能找到下一处理动作。再安排一次反例检查，故意输入一条缺日期、缺负责人或相互冲突的材料，看结果是否会明确提示缺口，而不是自行补全。能在正常情况和异常情况下都给出可核对结果，这套做法才算真正可复用。
最后保留三样东西：原始材料、采用的版本和人工确认记录。下一次遇到相似任务，可以复用字段和检查表，但仍要替换当次事实。模板的价值是减少遗漏，不是让所有场景得到同一答案；只要任务目标、读者或约束变化，就应重新检查输入和验收条件。