FAQ沉淀模板要便于检索和复用，关键在记录粒度和字段分组：以“一问一答一条记录”为单位，用表格承载，字段围绕检索定位、内容主体、来源证据、维护状态四组展开。问题标题写成用户会搜索的原话，答案先给结论再给步骤，并注明适用条件，条目才容易被搜到、被直接引用。
要点总览（TL;DR）
- FAQ沉淀模板以“一问一答一条记录”为单位，用表格承载，字段按检索定位、内容主体、来源证据、维护状态四组排列。
- 问题标题写成用户会搜索的原话，关键词补充同义说法和常见错写，答案先给结论再给步骤，并注明适用条件。
- 必填字段建议为问题标题、关键词、所属模块、标准答案、适用条件、状态六项，其余字段按团队阶段选填。
- 条目按季度复核，产品版本发布后对相关模块集中复核；被取代的条目改为已下线并指向替代条目，保留原记录。
- 模板字段调整时保留旧表结构一个周期，新增字段先选填后转必填，优先补齐高频复用条目。
可复制空白FAQ沉淀模板
下面这张表可以直接复制到文档或表格工具中使用。每条FAQ占一行，一行只记录一个问题及其对应答案。表头下方保留若干空行，复制后按实际条目逐行填写即可。
| 问题标题 | 关键词 | 所属模块 | 适用版本 | 标准答案 | 适用条件 | 操作步骤 | 来源（工单/复盘） | 提出人 | 确认人 | 确认日期 | 状态 | 复用次数 | 最近复核日期 | 替代条目 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表格按四组字段从左到右排列：前四列是检索定位，中间三列是内容主体，随后四列是来源与证据，最后四列是维护状态。复制到表格工具后，可以把每组字段用不同底色区分，填写时不容易漏项。
每个字段的作用与填写口径
字段设计的目标只有两个：让需要的人搜得到，让搜到的人能直接用。每个字段都对应其中一个目标，填写时按下面的口径执行。
| 字段名 | 所属分组 | 作用 | 填写口径 |
|---|---|---|---|
| 问题标题 | 检索定位 | 决定条目能否被搜到，也是复用时最先被看到的内容 | 写成用户实际会搜索的原话，包含对象和动作，例如“导出报表时提示权限不足怎么办”，避免写成“权限问题说明”这类内部命名 |
| 关键词 | 检索定位 | 补充标题覆盖不到的同义说法和常见错写 | 列3–6个词，用逗号分隔，覆盖同义词、简称、用户口语和常见错别字，例如“导出失败,报表导出,权限报错” |
| 所属模块 | 检索定位 | 支持按业务范围筛选，缩小检索范围 | 填写团队已有的模块或功能名称，与产品结构或工单分类保持一致，不临时造词 |
| 适用版本 | 检索定位 | 避免把旧版本答案套用到新版本 | 填写答案对应的产品版本或生效时间段；跨版本通用的写“通用”，有版本差异的写清范围 |
| 标准答案 | 内容主体 | 复用时直接引用的正文 | 先给一句结论，再展开说明；控制在能独立看懂的长度，不依赖上下文 |
| 适用条件 | 内容主体 | 说明答案在什么前提下成立 | 写清角色权限、环境、配置前提或例外情况，例如“仅管理员可操作”“仅限私有部署环境” |
| 操作步骤 | 内容主体 | 把答案落到可执行动作 | 按顺序编号，每步一个动作，写清入口位置和预期结果；纯概念类问题可留空并在答案中说明 |
| 来源（工单/复盘） | 来源与证据 | 追溯答案出处，判断可信度 | 填写工单编号、复盘文档名称或链接标识，能定位到原始记录即可 |
| 提出人 | 来源与证据 | 记录问题由谁提出，便于回访 | 填写姓名或工号，与团队通讯录一致 |
| 确认人 | 来源与证据 | 标明答案经过谁审核，区分个人经验与团队结论 | 填写对答案负责的人，通常是该模块的负责人或技术支持 |
| 确认日期 | 来源与证据 | 判断答案的新旧程度 | 填写审核通过的日期，格式统一为年-月-日 |
| 状态 | 维护状态 | 控制条目是否对外可用 | 使用固定取值，如“草稿、已确认、待复核、已下线”，不写自由文本 |
| 复用次数 | 维护状态 | 识别高价值条目和长期无人使用的条目 | 每次被引用或转发时加1，可由填写人手动更新，也可在复用时顺手记录 |
| 最近复核日期 | 维护状态 | 触发定期复核 | 填写最近一次确认内容仍有效的日期，复核后更新 |
| 替代条目 | 维护状态 | 处理条目被新答案取代的情况 | 填写新条目的标题或编号；条目下线时保留此字段，指向新条目，避免旧链接失效后无处可查 |
检索定位类字段解决“搜不搜得到”，内容主体类字段解决“搜到后能不能直接用”，来源证据类字段解决“敢不敢信”，维护状态类字段解决“过没过期”。四组字段缺一组，模板在长期使用中都会出问题：缺检索字段靠记忆找条目，缺来源字段无法判断对错，缺维护字段则旧答案长期混在新答案里。
哪些字段必填、哪些可以选填
全部字段都填会增加沉淀成本，导致没人愿意记录。建议先确定一组必填字段保证条目可用，其余字段按场景补充。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 问题标题 | 必填 | 没有标题条目无法被检索，也无法被引用 |
| 关键词 | 必填 | 标题难以覆盖所有说法，关键词是提升命中率的主要手段 |
| 所属模块 | 必填 | 条目积累到几十条以上时，按模块筛选是主要查找方式 |
| 标准答案 | 必填 | 模板的核心内容，缺失则条目没有复用价值 |
| 适用条件 | 必填 | 不写条件容易把特定场景的答案误用到其他场景 |
| 状态 | 必填 | 区分草稿与已确认，避免未审核内容被直接引用 |
| 适用版本 | 选填 | 产品版本迭代频繁、答案存在版本差异时填写；内部流程类问题可省略 |
| 操作步骤 | 选填 | 操作类问题填写；概念解释、政策说明类问题可省略 |
| 来源（工单/复盘） | 选填 | 来自真实工单或复盘的问题建议填写；日常主动整理的条目可省略 |
| 提出人 | 选填 | 需要回访提问者时填写 |
| 确认人 | 选填 | 有明确审核流程的团队填写；小团队可由记录人自行确认 |
| 确认日期 | 选填 | 与确认人配套使用 |
| 复用次数 | 选填 | 条目数量较多、需要识别高价值内容时启用 |
| 最近复核日期 | 选填 | 建立定期复核机制后启用 |
| 替代条目 | 选填 | 仅在条目被取代或合并时填写 |
按团队阶段可以选择两档填写方式。轻量档只填六个必填字段，适合刚开始沉淀、条目少于五十条的团队，先把记录习惯建立起来；完整档在必填基础上补齐来源、确认人、确认日期和复核字段，适合多人协作、条目跨团队复用的场景。两档使用同一张表，轻量档留空的列不影响后续补填。
完整填写示例：一条FAQ从提出到可复用
下面是一条已填写的FAQ记录，演示各字段如何配合。示例为演示情景，内容按模板口径编写。
| 字段 | 填写内容 |
|---|---|
| 问题标题 | 导出报表时提示“权限不足”怎么处理 |
| 关键词 | 导出失败,报表导出,权限报错,导出没反应 |
| 所属模块 | 报表中心 |
| 适用版本 | 当前线上版本，历史版本处理方式不同 |
| 标准答案 | 该提示表示当前账号没有报表导出权限，需要由管理员在角色配置中开通“报表导出”权限，开通后重新登录即可生效。 |
| 适用条件 | 仅限使用角色权限管理的账号体系；个人试用账号默认具备导出权限，不会出现该提示。 |
| 操作步骤 | 1. 管理员进入角色配置页面；2. 找到提问者所属角色；3. 勾选“报表导出”权限并保存；4. 提问者退出后重新登录；5. 再次执行导出，确认提示消失。 |
| 来源（工单/复盘） | 工单 #2317，同类问题一周内出现三次 |
| 提出人 | 示例：客服组同事 |
| 确认人 | 示例：报表模块负责人 |
| 确认日期 | 2025-03-12 |
| 状态 | 已确认 |
| 复用次数 | 6 |
| 最近复核日期 | 2025-03-12 |
| 替代条目 | 无 |
这条记录的写法有几个要点。问题标题用了用户的原话“导出报表时提示权限不足怎么处理”，包含对象“报表导出”和现象“权限不足”，用户按现象搜索时容易命中；关键词补充了“导出失败”“导出没反应”等口语说法，覆盖标题没有出现的表达。标准答案第一句直接给结论，说明提示的含义和解决方向，后面才展开操作。适用条件单独列出，把“个人试用账号不受影响”这个例外写清楚，避免答案被套用到不适用的账号上。来源字段记录了工单编号和出现频次，说明这个问题值得沉淀；确认人和确认日期让复用人知道答案经过谁审核、什么时候有效。
复用这条FAQ时，客服可以直接把标准答案和操作步骤发给提问者，不需要重新组织语言；新同事遇到同类工单，按关键词搜索即可找到，不必再问一遍模块负责人。复用次数每被引用一次加1，累计较高的条目在后续复核时优先检查。
模板的调整与长期维护方法
模板落地后，字段和条目都需要随团队规模调整。调整的依据是实际使用中暴露的问题，而非字段越多越好。
字段增删的判断依据
出现以下情况时考虑增加字段：某类信息反复出现在答案正文里、复用人每次都要额外追问，例如“影响范围”“关联配置项”，可以把它提为独立字段；检索时经常需要按某个维度筛选，而现有字段无法支持，可以补充分类字段。出现以下情况时考虑删减字段：某字段连续三个月无人填写或无人查看，说明它没有进入实际工作流，可以合并进其他字段或移除。每次调整只改一到两个字段，改完观察一个复核周期再决定下一步。
定期复核与过期条目的处理
建议按条目状态设定复核节奏：已确认条目每季度复核一次，产品版本发布后对涉及该模块的条目集中复核一次。复核时检查三件事：答案是否仍然正确、适用条件是否变化、操作步骤的入口是否还在原位置。复核后更新最近复核日期；内容已失效但仍有参考价值的，状态改为“待复核”并注明失效原因；完全被新方案取代的，状态改为“已下线”，在替代条目字段指向新条目，原记录保留不删除，避免历史链接失效。
重复或相近条目的合并规则
检索时发现两条以上条目回答的是同一个问题，按以下顺序处理：先比较问题标题，保留更接近用户搜索原话的那条作为主条目；把其他条目的关键词并入主条目，确保原来能搜到的说法仍然能搜到；其他条目的状态改为“已下线”，替代条目指向主条目。如果两条答案存在条件差异，例如不同角色或不同版本，不合并为一条，而是在主条目中分条件说明，或保留两条并在各自标题中写明条件。
模板版本变更时的迁移做法
模板字段调整时，保留旧表结构一个周期，新增字段先以选填方式加入，等存量条目逐步补齐后再转为必填。迁移时优先补齐高频复用条目，低频条目可以按需补填。模板本身标注版本号和生效日期，团队内说明本次变更的字段和原因，避免不同人按不同版本填写造成混乱。
FAQ条目通常来自工单、复盘和日常答疑，承载这些条目的文档需要支持按模块组织、全文检索和版本回溯。ONES Wiki 提供树形结构的页面组织和全局搜索，可用于按模块归档FAQ条目并支持检索；页面模板库支持一键创建制式化文档模板，便于把上述表格固化为统一格式；页面版本记录支持查看与回滚，复核修改后可以追溯变更。条目来源若记录在工单或项目任务中，ONES Wiki 可与 ONES 的项目、任务等场景结合使用，使文档与项目工作保持关联。具体模板字段的固定方式和检索匹配效果，建议在团队实际环境中试用后确定。
常见问题
FAQ条目数量还很少时，有必要一开始就填满全部字段吗？
不必。条目少于五十条、团队刚开始建立记录习惯时，按轻量档只填六个必填字段即可：问题标题、关键词、所属模块、标准答案、适用条件、状态。这六项保证条目能被搜到、能直接引用、能区分是否经过确认。来源、确认人、确认日期、复用次数、最近复核日期等字段可以先留空，等条目跨团队复用或建立复核机制后再补填。同一张表支持两档填写，留空的列不影响后续补齐。
同一个问题在不同版本或不同角色下答案不一样，应该拆成多条还是写成一条？
看差异是否影响操作。如果不同角色或不同版本的处理步骤完全不同，拆成多条更清晰，并在各自的问题标题中写明条件，例如“管理员如何开通报表导出权限”“普通成员导出报表提示权限不足怎么办”。如果只是前提条件不同、操作路径一致，保留一条，在适用条件字段中分条件说明，避免条目数量膨胀。拆分后的条目要在关键词上互相区分，防止搜索时同时命中多条而无法判断用哪条。
条目被新方案取代后，直接删除旧记录可以吗？
不建议直接删除。旧条目可能已经被转发到聊天记录、邮件或工单回复中，删除后原链接失效，复用人找不到答案也找不到替代说明。建议把状态改为“已下线”，在替代条目字段指向新条目，原记录保留。这样按旧关键词搜索时仍能命中，读者看到下线状态和替代指向后可以转到新条目。完全无参考价值且从未被引用的草稿条目，可以按团队约定清理。
复核时怎么判断一条FAQ该更新、该合并还是该下线？
按三个检查项判断：答案是否仍然正确、适用条件是否变化、操作步骤的入口是否还在原位置。内容基本正确但入口位置变了，更新操作步骤并刷新最近复核日期；内容仍然有效但和另一条回答同一问题，按合并规则保留更接近用户搜索原话的主条目，把其他条目的关键词并入后下线；方案已被新做法取代，改为已下线并指向替代条目。复核后统一更新最近复核日期，便于下一轮按时间筛选。
FAQ条目分散在工单、复盘文档和聊天记录里，怎么集中承载并支持检索？
先确定一个统一的承载位置，把条目按所属模块归档，再逐步把散落的问答补录进去。ONES Wiki 提供树形结构的页面组织和全局搜索，可用于按模块归档FAQ条目并支持检索；页面模板库支持一键创建制式化文档模板，便于把FAQ表格固化为统一格式；页面版本记录支持查看与回滚，复核修改后可以追溯变更。条目来源若记录在工单或项目任务中，ONES Wiki 可与 ONES 的项目、任务等场景结合使用，使文档与项目工作保持关联。具体模板字段的固定方式和检索匹配效果，建议在团队实际环境中试用后确定。
