制定知识写作规范，核心是把“写得好”拆成可判断的条款：先划定管哪些知识、给谁看，再确定结构骨架、语言与格式规则、评审发布责任，最后用样例和检查清单落地，并设定复审节奏。规范应逐条可检查，配套正例与反例，避免只写原则性口号。下文给出一套可直接套用的条款框架、编写步骤、角色分工与验收清单，适合正在从零建立或重整知识写作标准的团队参考。
要点总览（TL;DR）
- 先按知识类型（操作指引、排障记录、方案说明、会议沉淀）划定规范范围与读者，并写明暂不纳入的清单，避免条款泛化。
- 规范至少包含六类条款：适用范围与术语、结构骨架、语言规则、格式规则、评审与发布规则、维护与复审规则，每条都要能判断通过或不通过。
- 编写按五步推进：收集样本、确定骨架、写可判断条款、配正例反例、小范围试用修订，其中条款可判断是质量分水岭。
- 角色上区分规范负责人、领域作者、评审人、知识库管理员，结构评审与事实评审的检查项分开列出。
- 发布前用验收清单逐项自检，发布后以样例库培训新人、定期抽样检查、按知识时效性设定复审周期。
规范先定范围：管哪些知识、给谁看
制定规范的第一步是划定边界。知识写作规范最容易失败的写法，是试图用一份文件管住所有文字产出，结果条款泛化、作者无从对照。可行的做法是先按知识类型分类，再为每类明确读者与使用场景，最后确定本期纳入与暂不纳入的范围。
常见的知识类型可以这样划分：操作指引（教人完成一个具体任务）、排障记录（记录故障现象与处置过程）、方案说明（解释设计思路与取舍）、会议沉淀（记录决策与待办）。每类知识的读者不同：操作指引面向执行者，排障记录面向同类问题的处理者，方案说明面向评审与后续维护者，会议沉淀面向参与者与需要追溯决策的人。读者不同，结构骨架和语言要求也应不同。
| 知识类型 | 主要读者 | 使用场景 | 本期是否纳入 |
|---|---|---|---|
| 操作指引 | 一线执行人员 | 按步骤完成系统操作或业务流程 | 纳入 |
| 排障记录 | 技术支持、运维人员 | 复现与处理同类故障 | 纳入 |
| 方案说明 | 评审人、后续维护者 | 理解设计依据与约束条件 | 纳入 |
| 会议沉淀 | 参会人、决策追溯者 | 查询结论与待办归属 | 暂不纳入，下一期补充 |
| 需求文档、流程制度 | 产品、流程责任人 | 需求定义与制度约束 | 不纳入，由对应规范管理 |
边界划分要写清楚：需求文档的字段设计、流程制度的审批规则由各自体系负责，知识写作规范只约束知识条目的表达方式。把“暂不纳入”的清单也写进规范，可以避免后续争议，也为下一期扩展留出明确入口。
核心答案：规范的六个必备条款
一份可执行的知识写作规范，至少应包含六类条款。每类条款都要写成能判断通过或不通过的表述，而不是“简洁清晰”“逻辑通顺”这类无法验收的描述。
第一类，适用范围与术语定义。写明规范覆盖哪些知识类型、适用哪些团队，并列出术语表与同义词禁用清单。例如统一使用“工作项”而非“任务单”“工单”混用，避免同一概念多种叫法。
第二类，结构骨架。为每类知识规定必备章节。操作指引可采用“标题—目的—前置条件—步骤—结果—参考”；排障记录可采用“现象—影响范围—排查过程—根因—处置—预防”。骨架的作用是让作者知道写什么、评审人知道查什么。
第三类，语言规则。明确人称与时态：操作步骤用祈使句（“点击保存”），结果描述用完成时（“页面已刷新”）；规定句子长度上限、避免双重否定、数字与单位写法统一。语言规则要能落到具体句子，而不是停留在风格偏好。
第四类，格式规则。规定标题层级上限（如不超过三级）、列表与表格的使用场景（并列步骤用有序列表，参数对照用表格）、截图标注方式（编号、脱敏要求、截图与步骤一一对应）。格式统一直接影响检索与扫读效率。
第五类，评审与发布规则。明确谁审结构、谁审事实准确性、发布前的最小检查项、发布时机。评审规则要写清“审什么”，否则评审容易退化为通读一遍。
第六类，维护与复审规则。为每类知识指定责任人、复审周期和失效处理方式。时效性强的操作指引可随产品版本变更触发复审，复盘类记录可设较长周期或不设强制复审；过期条目要标记失效或归档，而不是继续留在知识库中误导读者。
按步骤编写：从骨架到可执行条款
把上述框架写成可执行文本，可以按五步推进。每一步都明确输入、动作、输出和完成标志，避免写到一半失去方向。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、收集样本 | 现有知识条目、读者反馈、高频提问 | 抽取各类型代表性条目，归纳反复出现的表达问题 | 问题清单与样本集 | 每类知识至少有若干条样本，问题按类型归并 |
| 二、确定骨架 | 问题清单、读者使用场景 | 为每类知识写出章节模板 | 分类模板 | 模板章节能覆盖该类知识的主要信息需求 |
| 三、写可判断条款 | 模板、问题清单 | 把语言与格式要求改写成可逐条核对的表述 | 条款清单 | 每条条款都能明确判断通过或不通过 |
| 四、配正例反例 | 条款清单、样本集 | 为每条条款各配一个正例和一个反例 | 样例库 | 作者能对照样例自行修改 |
| 五、试用修订 | 条款清单、样例库 | 选小范围作者按规范写作，收集作者与评审人反馈 | 修订版规范 | 试用期发现的问题已逐条处理并记录 |
第三步是整份规范质量的分水岭。以“截图要清晰”为例，这条无法判断；改成“截图需带编号，与步骤序号对应，涉及账号、手机号等信息须脱敏”，评审人就能逐项核对。再以“步骤要完整”为例，可改为“每个操作步骤包含一个动作动词和明确的操作对象，连续步骤之间不跳步”。条款越具体，执行成本越低。
第四步的正例反例不必长篇，一句话对照即可。例如反例“系统可能会出现异常，注意处理”，正例“若保存失败，页面提示错误码，记录错误码后联系管理员”。试用阶段建议限定在两三类知识、少量作者，重点观察条款是否被误读，修订后再扩大范围。
角色与交付物：谁写、谁审、谁维护
规范能否执行，取决于角色是否清晰。制定与执行过程中通常涉及四类角色，各自交付物和交接节点如下。
| 角色 | 职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 规范负责人 | 统筹条款、维护版本、组织试用与修订 | 规范正文、样例库、版本记录 | 试用前交付条款与样例，修订后发布新版本 |
| 领域作者 | 按模板产出知识条目，自查条款符合性 | 知识条目初稿、自查记录 | 初稿完成并自查后提交评审 |
| 评审人 | 核对结构完整性与事实准确性 | 评审意见、通过或退回结论 | 评审完成后反馈作者修改 |
| 知识库管理员 | 发布、归档、失效标记与权限维护 | 发布记录、失效清单 | 评审通过后发布，复审到期时发起提醒 |
评审环节建议区分两类检查：结构评审看章节是否齐全、步骤是否可执行，事实评审看参数、路径、权限描述是否与当前系统一致。两类检查可以由同一人完成，但检查项要分开列出，避免只看了文字通顺就放行。规范负责人与知识库管理员可以是同一人，但在条目数量较多的团队中分开设置更利于职责落地。
规范落地需要工具承载模板、评审记录与版本历史。ONES Wiki 支持富文本编辑、Markdown 语法和代码块，成员可以在线添加注释、评论；页面模板库可一键创建制式化文档模板；文档实时同步并记录所有页面版本，支持查看与回滚；还可为不同角色配置读写权限。团队可以把分类模板放入模板库，把评审意见留在页面评论中，把版本变更记录在页面历史里，让规范中的结构、评审与复审要求有对应的承载位置。工具选择按组织现有条件决定，不构成统一要求。
示例：一条操作指引按规范写成什么样
以下示例为演示情景：某团队的知识库需要一条“导出月度报表”的操作指引，读者是需要按月提交数据的一线运营人员。
按结构骨架写出的条目如下：
- 标题：导出月度报表
- 目的：将上月业务数据导出为表格文件，用于月度汇总。
- 前置条件：账号已开通报表查看权限；浏览器为受支持版本。
- 步骤：1. 进入“报表中心”，选择“月度报表”；2. 将时间范围设为上月第一天至最后一天；3. 点击“导出”，选择表格格式；4. 在下载列表中确认文件已生成。
- 结果：下载得到一份包含上月全部业务数据的表格文件。
- 参考：报表字段说明、权限申请流程。
语言与格式条款在示例中的体现：步骤使用祈使句，每步一个动作；时间范围写明起止规则，避免“最近一个月”这类歧义表述；标题层级不超过三级；如附截图，需编号并与步骤序号对应，涉及账号信息须脱敏。
常见反例及修改对比：
| 反例 | 问题 | 修改后 |
|---|---|---|
| “在系统里把报表导出来就行” | 缺少入口、时间范围与格式说明，读者无法照做 | 写明菜单路径、时间范围设置与导出格式选择 |
| “如果导出失败，处理一下” | 未说明失败表现与处置动作 | “若提示无权限，按参考中的权限申请流程提交申请后重试” |
| “最近的数据” | 时间口径模糊 | “上月第一天至最后一天” |
完成检查：规范可用性的验收清单
规范定稿前，用以下清单逐项判断。每项都应能明确回答“是”或“否”，回答“否”的条目需要修订后再发布。
- 每条条款都能判断通过或不通过，没有“简洁清晰”一类无法验收的表述。
- 规范覆盖了本期纳入的主要知识类型，每类都有对应结构骨架。
- 每条语言与格式条款配有至少一个正例和一个反例。
- 角色分工写明谁写、谁审结构、谁审事实、谁发布归档。
- 评审节点与发布前最小检查项已列明。
- 复审周期按知识类型区分，失效处理方式已写明。
- 试用阶段的反馈已逐条处理，处理结果有记录。
- “暂不纳入”的范围已列明，与需求文档、流程制度的边界清晰。
这份清单同时可以作为规范负责人的自检工具和评审人的核对依据，减少“规范写完了但没人能判断是否合格”的情况。
让规范持续生效：发布、培训与复审
规范发布只是起点。发布时建议同时给出规范正文、分类模板和样例库，并在版本记录中写明本次变更的条款编号与生效日期，方便作者对照新旧版本。版本记录按条款编号维护，比整篇替换更利于追溯。
新成员培训以样例库为主、条款讲解为辅：让新作者先照着正例写一条，再由评审人按检查清单逐项反馈，比通读规范更容易形成习惯。样例库需要随规范修订同步更新，避免样例与条款脱节。
定期抽样检查是发现执行偏差的主要手段。可以按知识类型抽取一定比例的条目，对照检查清单核对，把反复出现的问题归入两类：条款表述不清的，修订条款；作者理解偏差的，补充培训或样例。抽样结果应回流到规范负责人，作为下一版修订的输入。
复审周期按知识时效性设定：操作指引随产品版本变更触发复审，方案说明在关联系统重大调整时复审，复盘记录可设较长周期。条款修订的触发条件建议写明三类：抽样检查中同类问题反复出现、工具或流程发生变更、读者反馈条目无法使用。触发后由规范负责人组织修订并更新版本记录，确保规范与团队实际写作方式保持一致。
常见问题
团队规模小、只有一两个人写知识，还需要这么完整的规范吗？
可以按比例裁剪，但裁剪的是条款数量，不是可判断性。小团队可先只覆盖操作指引一类知识，保留结构骨架、语言规则、评审与复审四类条款，格式规则和术语表随条目增多再补。角色也可以合并，例如规范负责人兼任评审人和知识库管理员，但“谁审结构、谁审事实”两项检查仍要分开列出，避免只看文字通顺就放行。等知识条目和作者数量增加，再按本文框架补齐其余条款。
规范条款写出来之后，作者仍然按老习惯写，怎么处理？
先区分原因再决定动作。如果是条款表述不清，作者读完后仍不知道怎样算合格，就回到条款本身，把要求改成可逐项核对的表述，并补正例反例。如果是作者理解偏差，用样例库做短培训，让作者先照正例写一条、评审人按检查清单逐项反馈，比通读规范更容易形成习惯。抽样检查中同类问题反复出现，就作为条款修订的触发条件，由规范负责人组织修订并更新版本记录。
操作指引、排障记录、方案说明要用同一套结构骨架吗？
不建议共用一套骨架。三类知识的读者和使用场景不同：操作指引面向执行者，骨架可用“标题—目的—前置条件—步骤—结果—参考”；排障记录面向同类问题的处理者，可用“现象—影响范围—排查过程—根因—处置—预防”；方案说明面向评审与后续维护者，重点在背景、方案取舍与约束条件。可以共用的是语言规则、格式规则和术语表，这些跨类型统一有助于检索和扫读。结构骨架按类型分别设定，规范里为每类各写一份模板即可。
规范发布后，复审周期怎么定才合理？
按知识时效性区分，不必统一周期。操作指引与产品版本强相关，可设定随版本变更触发复审；方案说明在关联系统重大调整时复审；复盘记录时效性弱，可设较长周期或不设强制复审。除固定周期外，建议写明三类触发条件：抽样检查中同类问题反复出现、工具或流程发生变更、读者反馈条目无法使用。触发后由规范负责人组织修订，并在版本记录中写明变更的条款编号与生效日期。
规范里的模板和评审记录放在哪里比较合适？
关键是让模板、评审意见和版本历史有固定的承载位置，作者和评审人不用每次重新找。以 ONES Wiki 为例，页面模板库可一键创建制式化文档模板，团队可以把分类模板放进去；成员可以在线添加注释、评论，评审意见可留在页面评论中；文档实时同步并记录所有页面版本，支持查看与回滚，版本变更可追溯。具体工具按组织现有条件选择，不构成统一要求。
