FAQ 的写法：从工单原话到可执行答案

一篇好 FAQ 不是把功能说清楚，而是让一个着急的人照着做完，并且知道自己做对了没有。

一、十六个人问同一件事，十六种问法

周屿的订阅制写作工具有一个「导出为 Markdown」的功能。上个月他收到十六张相关工单，问法各不相同：「导出后图片没了」「怎么导出全部文章」「导出的文件打不开」「能不能批量导出」「导出在哪里」。

他写了一篇 FAQ，标题叫「导出功能说明」，正文讲文件格式、支持哪些元素、存储位置，四百多字。上线后，同类工单降到十一张——只降了三成。他把文章发给一位提问的用户看，对方回了一句：「我搜的是『图片丢失』，没搜到你这篇。」

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

问题不在内容，在入口。用户不会用你的功能名去搜，他会用自己看到的现象去搜。FAQ 的第一稿不该由作者写，而该由工单原话拼出来。

二、从工单原话到问题清单

先把同一主题的工单放在一起，逐张摘出「用户自己说的那句话」，不要改写，不要翻译成功能术语。

合并同义问法是第一步。 十六张工单通常只能提炼出五到七个真问题。合并的依据是「解决动作是否相同」，而不是「措辞是否相似」。两张工单措辞差很远，但都指向「图片路径」，就是同一个问题。

保留用户的原词作为别名。 「图片没了」「图片丢失」「图片不显示」都该出现在文章里，或者放进搜索别名表。用户搜的是自己的词，不是你的标题。

不要从功能列表倒推问题。 按功能写，你会写出「导出功能说明」；按工单写，你会写出「导出的图片去哪里了」。前者完整，后者有用。

三、三段式：结论、步骤、失败之后

每篇 FAQ 的正文只需要三段，顺序固定。

第一段给结论，并且写清适用条件。 一句话回答「是/不是/取决于」，然后补一句「仅适用于 2.3 及以上版本」或「仅管理员可见」。用户读到第一段就该知道这篇是不是他要的。

第二段给步骤，一步一个动作。 每步以动词开头，写清点哪里、看到什么。步骤里不要解释原理，原理放到文末的「为什么」小节，或者干脆不写。

第三段给失败处理。 列出最常见的两个失败原因与对应的检查动作，最后给出口：「仍未解决」按钮或支持邮箱。

结论段不要用「可能」「建议」。 「可能是网络问题」等于没说。要么给出确定答案，要么明确写「取决于你的存储设置，分两种情况」，然后分情况写。

步骤数量控制在三到七步。 超过七步，说明这件事本身不适合自助，应该考虑做成产品内引导，或者直接交给人工。

失败处理要具体到检查项。 「检查网络」太笼统；「打开设置 → 存储，确认已连接云盘」才是可执行的检查。

四、可执行性检查与二次工单

写完之后，用四条标准逐篇过一遍。四条全过才算可发布。

「找一台干净环境走一遍」是最容易被跳过的一步。 作者的浏览器里登录着管理员账号、装着插件、缓存着旧版本，照着写出来的步骤往往漏掉「需要先切换到管理员视图」这种前提。

标题测试要用真人，不要自测。 你自己知道功能叫什么，所以觉得标题很清楚；找一个只用过两次的用户，让他说出会怎么搜，通常能得到完全不同的句子。

可执行性检查要记录结果，不能只在脑子里过。 一篇一篇打勾，没过的写清哪一条没过，下一版才有对照。

FAQ 上线后，真正的验收指标不是浏览量，而是「同一问题的二次工单有没有下降」。

本例先写 20 条，覆盖上一月工单里重复次数最高的主题。写作成本按每条 30 分钟计：

20 条 × 30 分钟 = 600 分钟 = 10 小时 × 60 美元/时 = 600 美元

写作顺序按工单量排，不按文章长短排。 先写覆盖工单最多的五条，再写其余；第一批上线四周后再动第二批，免得一次改太多，无法判断哪一条真的起了作用。

每篇都要能被单独搜到。 标题、首段与至少一个小标题里出现用户的原词，用户从搜索结果直接进入时才不会迷路。

抽检 10 条，8 条四条检查全过，合格率 8 ÷ 10 = 80%。两条不合格的分别是标题用了功能名、步骤缺前置条件，返工各 20 分钟，合计 40 分钟。

二次工单率要看四周窗口。 上线后第一周的数据不可信，因为老用户还没遇到问题；等到第四周，比较「同主题工单数 ÷ 总工单数」的变化，才有意义。

一次没降不代表写错。 可能的原因有四种：文章没被搜到（入口问题）、文章被搜到但没读（标题问题）、读了但没照做（步骤问题）、照做了但失败（内容错误）。四种原因对应四种修法，不能统一归结为「再写详细一点」。

20 条是一个批次的上限。 一次写太多，质量会掉，而且没法判断哪一类内容真正有效。写完一批，观察四周，再决定下一批写什么。

五、行动清单与复算验收

先摘原话，再合并问题，最后才动笔。顺序反了，你会写出二十篇「功能说明」。

• 导出最近一个月同一主题的全部工单，逐张摘出用户原话。
• 按「解决动作是否相同」合并，得到五到七个真问题。
• 为每个问题写一句用户会搜的标题，并记录三到五个别名。
• 按结论、步骤、失败三段式写正文，首段写清适用条件。
• 在一台干净环境里照着步骤走一遍，记录卡住的位置。
• 补齐「仍未解决」出口，确认两次点击内可达。
• 抽检 10 条，按四条标准逐条打勾，记录不合格项。
• 上线四周后比较同主题工单占比，判断是否真的下降。

验收标准：任意一篇 FAQ，只看标题与首段就能判断是否适用于自己，照着步骤能在干净环境里做完，失败后两次点击内能找到人。

使用边界与实操验收

本文只处理「从工单原话到一篇可执行 FAQ」的转化，不涉及帮助中心的整体结构、排查树、搜索排序与界面内微文案。

界面里的即时提示不归本文。 按钮旁的一句话、报错气泡、空状态文案，属于产品内微文案，已有专门文章；本文处理的是应用之外、可被搜索到的长答案。

FAQ 不是越长越好。 一篇 FAQ 能解决一个问题就够了。把五个问题塞进一篇，标题会变得模糊，搜索也命中不了。

涉及退款、隐私与消费者权益的回答，只写「怎么申请」与「需要哪些材料」，不要替用户判断他是否符合条件。 具体口径以你的条款与所在地法规为准，必要时请专业人士复核。

关键参考与核验范围

核验日期：2026-10-25。以下链接仅作为公开文档入口，用于核对面向任务写作与简明表达的通用原则，本文未逐条引用其内容。

• Google 技术写作课程 ：用于核对面向任务、以动词开头的步骤写法。
• Plain Language 写作指南 ：用于核对结论前置与短句表达的一般原则。

引用口径。 本文只借用两份材料的写作原则：先给结论、一步一个动作、用用户能懂的话。文中的 16 张工单、20 条 FAQ、600 分钟与 8/10 全部来自教学假设，与上述材料无关。

核验范围。 核验的是「原话提取 + 三段式 + 四条检查」这套流程是否仍然可操作，不是比对某个写作工具或模板库。工具会变，检查项不变。

如何自行复核。 挑一篇你现有的 FAQ，只看标题和首段，问自己「一个没看过产品的人能不能判断这是不是他要的」；如果不能，先改这两处，再看工单。

系列导航

• 上一篇：帮助中心的结构：按任务组织，不按功能组织
• 下一篇：故障排查树：症状、检查与出口
• 回到目录：一个人的自助支持：帮助中心、排查树与工单减少
• 相关阅读：微文案：按钮、报错与空状态怎么说