研发FAQ从零建设，先定三条规则：条目按“一个可独立检索、可独立回答的问题”切分；每条FAQ设唯一维护人，按问题域归属指派；审核发布采用技术准确性与表达规范双人复核，并约定复审周期。本文按粒度、责任人、审核发布、与文档和工单的衔接顺序展开，适用于正在建立FAQ机制的研发团队。
要点总览（TL;DR）
- 条目粒度以“一个可独立检索、可独立回答的问题”为切分单位：标题能判断相关性、答案只围绕一个疑问、一次阅读能读完，三条缺一即拆分或合并。
- 责任人按问题域归属指派，每条FAQ设唯一维护人，由对应模块或技术域一线骨干担任；另设FAQ管理员负责去重、分类、格式与节奏，技术结论由领域评审人裁定。
- 审核发布采用双人复核：维护人提交并附问题来源与适用条件，领域评审人确认技术准确性，管理员确认表达规范与是否重复，两项通过才发布并登记复审日期。
- 复审周期按内容稳定性区分，与版本强相关的随版本复审，操作类按季度、通用概念类按半年；失效条目标注下线并指向替代条目，避免引用断链。
- 问题从工单、群内重复提问和复盘中收集并初判，FAQ与正式文档分工互引，同一问题只保留一处完整答案，其余位置做摘要和跳转。
研发FAQ从零起步：先定粒度、责任人与发布三条规则
FAQ建设最容易失控的地方，是条目越写越多、越写越长，最后没人说得清哪条有效、由谁负责。把治理规则先定下来，再开始收问题，后续维护成本会低很多。三条规则分别解决“写成什么样”“谁来管”“怎么算发布”三个问题。
条目粒度规则。以“一个可独立检索、可独立回答的问题”为切分单位。判断标准有三条：读者能否只凭标题判断这条FAQ是否与自己的问题相关；答案是否只围绕一个疑问展开；答案能否在一次阅读内读完。三条中有一条不满足，就考虑拆分或合并。
责任人归属规则。每条FAQ有且只有一名维护人，由该问题所属模块或技术域的一线骨干担任。另设一名FAQ管理员，负责去重、分类、节奏和格式把关。维护人对内容正确性负责，管理员对整体秩序负责，两者不重叠。
审核发布规则。维护人提交后，由领域评审人确认技术准确性，由管理员确认表达规范与是否重复，两项都通过才发布。发布时同时登记复审时间，到期由维护人确认内容是否仍然有效。
从零推进建议按以下顺序进行，每一步都有明确产出：
- 划定问题域清单。按系统模块或技术方向列出FAQ将覆盖的范围，产出问题域列表，作为后续指派维护人的依据。
- 收集首批问题。从近三个月的工单、群内提问和复盘中提取高频疑问，产出去重后的问题池。
- 按粒度规则试写20至30条。由各问题域维护人撰写，产出首批样稿，用于校准粒度标准是否可执行。
- 跑通一轮审核发布。用样稿验证双人复核流程是否顺畅，产出流程中暴露的问题清单并修订规则。
- 确定复审周期并进入常态运营。产出带维护人和复审日期的FAQ目录。
条目粒度怎么切：一条FAQ回答一个问题
粒度是FAQ质量的第一道关口。条目过粗，读者要在长文里找答案；条目过细，同一主题碎成十几条，检索和维护都变难。判定方法可以落成一张可逐项核对的清单。
单条FAQ的边界判定
用四个问题检验一条FAQ是否切得合适：标题是否是一个具体疑问句；答案是否只解释一个机制、一个操作或一个判断依据；答案中出现的其他疑问是否已单独成条；读者是否需要读完其他条目才能理解本条。前两项为“是”、后两项为“否”时，粒度基本合适。
过长与过短条目的处理
答案超过一屏仍讲不完，通常说明混入了多个问题。处理方式是保留主问题作为条目，把分支疑问拆成子条目，并在主条目中列出子条目的标题作为导航。答案只有一两句话且脱离上下文无法理解，说明切得过细，应合并到上位问题中，或补充适用场景后再独立成条。
问题与答案的对应关系
标题写读者会搜索的说法，答案第一句直接给结论，随后再给依据、步骤或例外条件。避免标题写“XX模块说明”而答案讲三个不相关的问题。标题与答案不对应，是FAQ检索失效的常见原因。
版本与场景信息的挂载
研发FAQ的答案往往与版本、环境或配置相关。凡答案存在适用条件，就在条目固定位置标注适用版本、适用环境或前置条件；条件变化时，这条信息就是复审的触发点。没有适用条件的条目也明确写“通用”，避免读者猜测。
拆分示例：一条“构建失败怎么排查”的FAQ，如果答案覆盖依赖缺失、权限不足、缓存污染三类原因，应拆为三条独立FAQ，另加一条“构建失败排查入口”作为导航条目，分别指向三条子条目。
责任人怎么定：唯一维护人与领域评审人
FAQ没人负责，就会在版本迭代后悄悄过期。责任人划分的核心是让每条FAQ都能追溯到具体的人，同时避免一个人承担全部内容。
| 角色 | 指派依据 | 主要职责 | 交付物 |
|---|---|---|---|
| 唯一维护人 | 问题所属模块或技术域的一线骨干 | 撰写条目、保证技术正确、按复审周期确认有效性 | 条目正文与复审结论 |
| 领域评审人 | 该技术域的资深成员或模块负责人 | 审核技术准确性，判断结论是否有适用条件遗漏 | 评审意见与通过结论 |
| FAQ管理员 | 知识管理或研发效能角色，通常一人 | 去重、分类、格式规范、发布节奏与目录维护 | 分类目录、发布记录、重复条目处理结果 |
唯一维护人的指派依据是问题域归属，而非行政层级。一个问题域可以有多名维护人分管不同子方向，但每条FAQ只能有一名维护人，避免出现问题时互相等待。领域评审人可以与维护人不同人，也可以在同一问题域内由更资深的成员担任；团队规模较小时，评审人可跨问题域复用，但不应由维护人自己评审自己的条目。
FAQ管理员的职责边界需要说清：管理员负责秩序，不负责技术结论。遇到技术争议，由领域评审人裁定；管理员只在格式、重复和分类上做退回处理。
责任人变更要有交接动作：原维护人移交条目清单与未结复审项，新维护人确认接收后在条目上更新责任人，管理员同步目录。人员离职或转岗时，其名下条目应先完成一轮有效性确认再移交，避免把过期内容原样转手。
审核发布怎么走：双人复核与复审节奏
审核发布流程的目标是让每条FAQ在发布前经过两类检查，发布后有明确的失效处理方式。流程本身不宜过长，否则维护人会绕过流程直接发在群里。
提交与复核的分工
- 维护人提交条目，附上问题来源（工单编号、提问记录或复盘出处）与适用条件。
- 领域评审人检查技术准确性：结论是否正确、步骤是否可复现、例外条件是否写全、是否与现有文档冲突。
- 管理员检查表达规范：标题是否为具体疑问、答案是否先给结论、是否与已有条目重复、分类与标签是否正确。
- 两项检查均通过后发布，登记发布人与复审日期；任一项不通过则退回维护人，退回意见需写明具体修改点。
检查项与通过标准
| 检查维度 | 检查项 | 通过标准 |
|---|---|---|
| 技术准确性 | 结论、步骤、适用条件 | 评审人可按步骤复现，条件与结论对应 |
| 表达规范 | 标题、结构、长度 | 标题为具体疑问，答案首句给结论，一次可读完 |
| 唯一性 | 与已有条目的关系 | 无重复条目，或已合并并保留跳转说明 |
| 可追溯 | 维护人与复审日期 | 两项信息完整登记 |
复审周期与失效下线
复审周期按内容稳定性区分：与版本强相关的条目随版本发布复审，操作类条目按季度复审，通用概念类条目可按半年复审。复审结论只有三种：继续有效、更新后有效、失效下线。失效条目不下接删除，而是标注失效并指向替代条目，避免外部引用断链。连续两个周期无人认领的条目，由管理员提交问题域负责人重新指派或下线。
与文档、工单衔接：问题从哪里来、答案往哪里去
FAQ不是孤立的知识载体。问题从工单和日常提问中来，答案又要能回到工单和文档中去，形成闭环，才能避免同一问题反复解答、同一内容多处维护。
问题来源的收集
固定三个来源：工单系统中的高频问题、研发群内的重复提问、复盘记录与文档评论中的疑问。收集时先做初判：属于一次性环境问题的不入FAQ；属于高频、短平快、有明确答案的入FAQ；属于成体系、需要完整背景的，转入正式文档。初判结论记录在问题池中，便于回溯。
与正式文档的分工
稳定、成体系、需要完整上下文的内容沉淀为正式文档；高频、短平快、以问答形式被检索的疑问沉淀为FAQ。两者互相引用：FAQ答案中涉及完整设计说明时链接到文档，文档中列出相关FAQ入口。分工标准写进规则，可以减少同一内容在两处各写一遍的情况。
反哺文档与工单的路径
FAQ条目在复审中如果发现答案已扩展成体系化内容，应升级为文档，原条目保留摘要并指向文档。工单处理人在答复用户后，若判断该问题具有复用价值，可提交FAQ候选，由对应问题域维护人认领。这条路径让FAQ的内容来源持续有输入，而不是建库时集中写一批后长期停滞。
避免重复维护的做法
指定唯一内容归属：同一问题只在一个地方有完整答案，另一处只做摘要和跳转。管理员在发布前做重复检查，发现重复时合并而非并存。条目更新时同步检查引用它的文档和工单模板，避免出现答案已改、引用处仍是旧结论的情况。
在工具承载上，FAQ条目的收集、撰写、评审与发布需要文档协作和任务流转两方面的支持。ONES Wiki 可用于集中沉淀研发文档与项目知识，支持页面树组织、版本记录与按角色配置读写权限；其与项目、任务等场景结合使用，便于把FAQ候选作为工作项跟踪、把成稿沉淀为文档页面。团队可将问题池建成工作项列表，评审与复审作为状态流转，成稿发布在Wiki页面中，使条目责任人和复审日期随页面版本可查。
示例：一个研发FAQ条目的完整流转
以下为演示情景，用于说明规则如何串起来，不代表特定团队的真实数据。
问题来源与初判。某团队在近一个月工单中发现，“测试环境部署后接口返回鉴权失败”被反复提问六次。管理员将其放入问题池，初判为高频、有明确答案，进入FAQ候选。
条目撰写与粒度控制。维护人最初写的标题是“测试环境鉴权问题汇总”，答案覆盖配置项、令牌有效期、网关白名单三类原因。按粒度规则拆分：主条目改为“测试环境部署后接口鉴权失败如何排查”，答案首句给出最常见原因，三类原因各拆为子条目，主条目列出子条目导航。每条标注适用环境为测试环境、适用版本区间。
责任人指派与复核。该问题归属部署与鉴权方向，维护人为该方向一线骨干，领域评审人为模块负责人。评审人确认三类原因的排查顺序与实际一致，补充了令牌过期这一例外条件；管理员确认标题为具体疑问、与已有条目无重复、分类正确，随后发布并登记季度复审。
发布后复审与更新。下一版本发布后，网关配置方式调整，维护人在复审中更新子条目步骤，主条目结论保持不变。原步骤作为历史版本保留在页面版本记录中，工单模板中引用的FAQ链接指向更新后的条目，答复口径随之统一。
完成检查：FAQ治理机制是否跑通
机制是否建立，不看FAQ数量，而看规则能否被稳定执行。以下清单可逐项核对，全部为“是”时，说明治理机制基本跑通。
| 检查项 | 核对内容 | 判定标准 |
|---|---|---|
| 粒度规则可判定 | 随机抽取十条FAQ，按粒度清单复核 | 十条均满足单问题、可独立检索、一次可读完 |
| 责任人覆盖完整 | 核对问题域清单与维护人对应关系 | 每个问题域均有维护人，每条FAQ有唯一责任人 |
| 审核有明确标准 | 抽查近期发布记录 | 每条均有技术评审与格式检查记录，退回意见具体可执行 |
| 复审机制在运行 | 查看复审日期与结论 | 到期条目均有复审结论，失效条目已标注并指向替代条目 |
| 来源有持续输入 | 查看问题池近一个月的新增 | 工单与提问中有候选持续进入问题池并被初判 |
| 与文档工单闭环 | 抽查FAQ与文档、工单的引用关系 | 同一问题只有一处完整答案，引用处链接有效 |
核对中若发现某类问题反复退回，通常说明粒度规则或检查项需要修订，此时应更新规则而不是放宽执行。团队规模与问题域划分不同，维护人和评审人可由同一批人兼任，但唯一维护人与复核分离这两条应保留，它们是FAQ长期可用的基础。
常见问题
团队规模小，维护人和评审人能否由同一人兼任？
可以兼任，但同一条FAQ的维护人与评审人应保持分离，避免自己评审自己的条目。团队规模较小时，一名资深成员可以同时担任多个问题域的评审人，也可以兼任FAQ管理员；此时需要把“撰写”和“复核”两个动作在流程上分开，例如维护人提交后隔一轮再评审，或由另一名成员做交叉复核。唯一维护人与复核分离这两条建议保留，它们是条目在版本迭代后仍可追溯的基础。
一条FAQ的答案涉及多个版本，应该合并成一条还是按版本拆开？
先看各版本的处理方式是否一致。如果结论和步骤相同，只在适用条件上不同，合并为一条并在固定位置标注适用版本区间即可，复审时以版本变更为触发点。如果不同版本的操作步骤或结论存在实质差异，按版本拆成独立条目，并在标题或标签中写明版本，主条目保留导航和差异说明。拆分后要检查检索体验：读者应能从标题直接判断哪条适用于自己的版本。
工单里已经答复过的问题，如何判断值不值得转成FAQ？
用三个条件做初判：问题是否在近一段时间内重复出现、答案是否短平快且有明确结论、答案是否不依赖特定的一次性环境。三条都满足的进入FAQ候选，由对应问题域维护人认领；属于成体系、需要完整背景的转入正式文档；属于一次性环境问题的留在工单中，不入FAQ。初判结论记录在问题池里，便于后续回溯为什么某条没有入库。
FAQ发布后长期没人复审，机制上怎么兜底？
把复审日期作为条目必填信息，到期未处理的条目由管理员汇总提交问题域负责人。兜底规则可以设为：到期后先由维护人确认，连续两个周期无人认领的条目，由管理员提交负责人重新指派或下线。下线时标注失效并指向替代条目，保留历史引用可查。复审结论只保留继续有效、更新后有效、失效下线三种，避免出现“待定”状态长期挂起。
FAQ和正式文档内容重叠时，应该保留在哪一边？
按内容形态分工：稳定、成体系、需要完整上下文的内容以正式文档为完整答案所在；高频、短平快、以问答形式被检索的疑问以FAQ为完整答案所在。同一问题只在一处保留完整答案，另一处做摘要并链接过去。FAQ在复审中如果发现答案已扩展成体系化内容，升级为文档，原条目保留摘要和跳转。管理员在发布前做重复检查，发现重复时合并而非并存。
