社区问答怎样整理成可持续维护的 FAQ
先合并相同的求助意图，再按适用条件拆分答案；一条 FAQ 应让读者知道结论、前提、操作和继续阅读的位置。
先识别读者要完成什么
FAQ 的价值是减少重复查找，而不是把热帖标题排成一列。整理者应先读完问题及有效回复，用一句话写出提问者想完成的任务。例如“图片为什么太大”和“怎样把教程插图压小”可能都指向控制图片体积；“上传后看不清”则可能指向清晰度，两者不能只因都出现“图片”就合并。
开始时不必覆盖所有讨论。选择一个边界明确的小主题，收集其中的重复问题，记录原问题、实际意图、适用环境和已有答案。原帖若没有交代环境，就把这一项记为待补充，不把某条自信的回复当作已经验证的通用结论。
合并同义问题，拆开不同条件
以下为虚构教学例子：一个资料整理小组有六条关于图片的提问，其中三条询问体积、两条询问文字可读性、一条询问版权说明。可以先建立三个候选问题，而不是建立六条近似 FAQ。整理时保留常见说法作为别名，正文仍使用清楚、完整的问句。
当答案依赖使用场景时，应在条目内列出分支。仅用于屏幕阅读的截图与需要打印的示意图，完成标准可能不同。无法用两三句说明清楚的差异，可以拆成相邻条目并相互链接；不要让一个“如何处理图片”问题承载所有细节。
- 同一个目标、相同的前提和操作路径：合并为一条。
- 目标相同但条件不同：保留一个入口，明确列出条件分支。
- 只是词语相似、目标不同：分别建条目，使用相关链接连接。
让一条答案具备五个字段
把最直接的结论放在第一段，再给出适用条件和具体操作。读者只看摘要时应能做出初步判断，继续阅读时应能找到完整依据。对无法确定的内容，写清“目前材料未说明”，比悄悄补全更有利于后续维护。
| 字段 | 应回答的问题 | 检查方式 |
|---|---|---|
| 简明回答 | 我现在应该怎么做？ | 开头能否直接回应标题 |
| 适用条件 | 什么情况下成立？ | 是否写清对象、环境与限制 |
| 操作步骤 | 按什么顺序完成？ | 是否说明每步的结果 |
| 依据与关联 | 为什么这样判断？ | 能否回到相关讨论或教程 |
| 复核触发 | 何时需要重新检查？ | 是否写清变化或失效信号 |
保留分歧，建立维护入口
讨论中出现相反答案时，先核对各自条件，再判断是否真有冲突。若两种办法都能在不同情境下成立，就把选择条件写进 FAQ；若证据不足，就标记为待核对，并提供原讨论的阅读位置。整理并不意味着必须把所有分歧压成一个答案。
为每条 FAQ 指定稳定编号或地址，修订答案时尽量保留入口。维护记录可以只写变更范围、原因和影响，例如“补充适用于手机截图的步骤；原打印场景说明继续保留”。FAQ 变长后，按任务分类建立目录，避免不断加条目却找不到入口。
发布前做一次陌生读者检查
请一位未参与原讨论的读者按照答案描述完成任务，或由整理者隔开原帖重新阅读。检查是否出现没有定义的缩写、缺失的前置步骤、无法定位的“上面那张图”。这些问题往往比语言是否漂亮更影响使用。
常见误区是把高赞回复直接复制成答案、只保留结论而删掉条件，以及把所有 FAQ 都写成一样长。答案长度应服从问题难度；简短问题可以直接回答，复杂问题则用摘要连接独立教程。
相关问答
问题只出现过一次，能进入 FAQ 吗？
可以，但应看它是否代表稳定、常见的任务障碍。出现次数是线索，不是唯一标准；重要的前置条件或容易误解的概念也值得收录。
FAQ 与教程需要重复完整内容吗？
不需要。FAQ 先给结论和适用条件，再链接到教程的对应章节；教程保留完整操作和例子，二者承担不同阅读任务。