知识写作规范用来约束知识条目“写给谁、写什么、按什么结构写、写到什么程度算合格”。它通常是一份轻量文档，靠模板、样例和评审清单落地。本文按“定内容—分步编写—角色分工—样例参照—发布检查”的顺序，给出一套可以直接照着做的编写方法，适用于团队建立或修订知识写作规范。
要点总览（TL;DR）
- 知识写作规范要回答四个问题：写给谁、属于哪类知识、按什么结构写、写到什么程度算合格，对应适用范围、结构骨架、必填字段、语言要求、评审更新和样例六部分内容。
- 编写按五步推进：圈定适用知识类型、设计结构与字段、规定语言与示例、写评审与更新规则、用真实条目做样例校准，每步都有可判断的完成标志。
- 规范落地靠模板、样例和评审清单三件套，条款控制在团队能记住和执行的范围内；评审人与作者分离，小团队可设代评审例外。
- 判断规范是否可用看两条：两位作者按规范重写同一条目结构与关键字段一致，评审人依据样例无需额外解释即可给出结论。
- 发布后进入维护状态，知识类型变化或评审反复出现同类问题时由Owner牵头修订，管理员同步更新模板并通知作者。
知识写作规范先定哪几件事
一份可用的知识写作规范，先要回答四个问题：这条知识写给谁看、属于哪类知识、按什么结构组织、达到什么程度算合格。四个问题对应规范的四块核心内容，缺一块，规范就容易变成原则口号，作者看完仍不知道该怎么下笔。
围绕这四个问题，规范的最小内容框架可以拆成六部分：
- 适用范围：明确规范管哪些知识类型，不管哪些。例如管操作指南、故障处理记录、产品说明，不管会议纪要和项目周报。
- 结构骨架：每类知识条目的章节顺序和必备段落，例如操作指南统一为“适用场景—前置条件—操作步骤—结果验证—常见问题”。
- 必填字段：标题、作者、适用版本、更新时间、关联系统或模块等元信息，规定哪些必须填、填什么格式。
- 语言要求：人称、时态、术语用法、步骤句式、示例要求，例如步骤用动宾结构、一个步骤只做一个动作。
- 评审与更新：谁评审、评审看什么、多久复核一次、内容过期由谁处理。
- 样例：至少一份合格条目和一份常见错误写法对照，作为作者和评审人的共同参照。
篇幅和颗粒度需要取舍。规范的目标是让作者能照着写、评审人能照着判，条款数量控制在团队能记住和执行的范围内。经验做法是把规则分成两类：结构、字段这类可以靠模板固化的，写进模板即可，规范正文只做说明；语言风格、合格标准这类需要判断的，才在规范里展开并配样例。条款越多，执行成本越高，越容易停留在文档里无人使用。
按步骤编写：从范围到样例
编写规范本身也是一次知识梳理，建议按五步推进，每步都有明确的输入、动作、输出和完成标志，避免写到一半反复推翻。
第一步：圈定适用知识类型与不适用范围
输入是团队现有的知识条目清单或知识库目录。动作是按用途归类，挑出数量多、复用频率高、写法差异大的类型作为首批适用范围，同时明确写出暂不适用的类型。输出是一张“适用/不适用”清单。完成标志是：任取一条现有知识，能判断它是否受本规范约束。
第二步：设计结构骨架与必填字段
输入是第一步选定的知识类型和若干条现有样例。动作是归纳每类条目共同要回答的问题，形成章节顺序；再从检索、维护、追责的实际需要出发，确定必填字段。输出是每类知识一份结构骨架和字段清单。完成标志是：拿一条空白模板，作者能判断每一节该填什么，没有“不知道放哪”的内容。
第三步：规定语言、术语与示例要求
输入是现有条目中反复出现的表达问题，例如步骤写成一段话、术语中英文混用、只写结论不写条件。动作是把这些问题转成正面要求：步骤一条一个动作、术语首次出现给全称、关键操作配示例或截图说明、涉及版本和环境的写清前提。输出是语言要求条目及正反示例。完成标志是：每条要求都能对应一个可观察的写法，而不是“表达清晰”这类无法判断的表述。
第四步：写评审规则与更新责任
输入是团队的人员结构和知识更新频率。动作是确定评审触发条件（新条目发布、重大修改）、评审关注点（结构完整、字段齐全、步骤可执行、示例有效）、复核周期和过期处理方式，并把更新责任落到具体角色。输出是评审规则和更新机制说明。完成标志是：任何一条知识都能找到它的评审人和维护人。
第五步：用真实条目做样例并校准
输入是规范草案和两三条真实知识条目。动作是让不同作者按规范重写同一条目，比较结果差异，据此修正结构或语言要求中含糊的地方。输出是定稿样例和修订后的规范。完成标志是：两位作者按规范写出的条目，结构和关键字段一致，评审人能依据样例快速判断合格与否。
角色分工与各环节交付物
规范能否执行，取决于每个环节是否有人负责、有明确交付物。常见分工如下表，团队规模较小时可以一人兼多角，但评审与写作尽量分开。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 规范 Owner | 发起编写、组织校准、对规范内容负责 | 规范正文、结构骨架、字段清单、定稿样例 |
| 知识作者 | 按规范撰写和修改知识条目 | 符合结构和字段要求的条目、必要的示例 |
| 评审人 | 按评审清单检查条目质量，给出修改意见 | 评审意见、通过或退回结论 |
| 知识库管理员 | 维护目录与模板、跟踪过期内容、组织定期复核 | 模板更新记录、过期条目处理记录、复核结果 |
在编写阶段，Owner 负责草案，作者提供真实条目作为校准素材，评审人参与试评；发布阶段由 Owner 定稿、管理员上线模板；日常评审由评审人对新条目和重大修改给出结论；更新阶段由管理员按周期发起复核，Owner 判断规范条款是否需要调整。
评审人与作者分离是常见做法，能减少作者自评带来的盲区。小团队可以设例外：由另一位熟悉该知识类型的成员代评审，或对低风险条目采用抽样复核。例外要写进规范，避免因无人可评导致流程停摆。
规范落地时，模板和评审记录需要有承载的地方。ONES Wiki 支持使用模板库一键创建制式化文档，页面模板库可用于创建制式化文档模板；文档实时同步并记录所有页面版本，支持查看与回滚；还可为不同角色配置不同的读写权限。这些能力可以承接“模板统一、版本可追溯、评审人与作者权限区分”这几个动作。评审意见可以先通过页面注释和评论收集，再按团队约定形成通过结论。
一份可参照的规范样例
下面以“系统操作指南”为例，展示规范条目可以写成什么样，团队可据此替换成自己的知识类型。
- 适用类型：面向业务人员的产品功能操作说明。
- 结构骨架：适用场景—前置条件—操作步骤—结果验证—常见问题。
- 必填字段：标题（功能名+动作）、适用版本、作者、更新时间、关联模块。
- 语言要求：步骤用动宾结构，一条一个动作；界面名称与产品实际文案一致；涉及权限或数据影响的操作必须写明前提。
合格写法示例：
“前置条件：账号具有管理员权限。步骤：1. 进入「系统设置」，点击「成员管理」。2. 选择目标成员，点击「停用」。结果验证：该成员状态显示为「已停用」，无法再登录。”
不合格写法示例：
“在设置里把成员停用一下就行，注意权限。”
不合格的原因有三点：缺少前置条件，读者不知道需要什么权限；步骤没有对应到具体界面位置，无法照着操作；没有结果验证，读者无法确认操作是否生效。按规范修改后，条目具备了可执行性和可验证性。
样例的作用是统一判断口径。评审时先对照结构骨架看章节是否齐全，再对照必填字段看元信息是否完整，最后对照合格样例判断步骤是否可执行、前提是否写清。遇到样例未覆盖的新情况，由 Owner 判断并补充进样例，避免每次评审各说各话。
发布前的完成检查
规范定稿前，用下面这份清单逐项确认。每项都能给出“是/否”的判断，全部通过再发布。
- 框架完整性：适用范围、结构骨架、必填字段、语言要求、评审与更新、样例六部分是否齐全；四个核心问题是否都有对应内容。
- 字段与结构可执行：每类知识是否有独立骨架；必填字段是否说明格式；是否存在无法判断该填什么内容的章节。
- 样例与评审规则一致：合格样例是否满足规范全部要求；不合格样例指出的问题是否都能在规范条款中找到依据；评审清单是否与样例判断口径一致。
- 责任与更新落实：每类知识是否有明确评审人和维护人；复核周期是否写明；过期内容的处理方式是否可操作。
- 阻断项：缺少适用范围、缺少样例、评审人未落实，任一项存在即不发布。
- 通过条件：两位作者按规范重写同一条目，结构与关键字段一致；评审人依据样例能在不额外解释的情况下给出结论。
发布后，规范进入维护状态。知识类型变化、评审中反复出现同类问题时，由 Owner 牵头修订，管理员同步更新模板，并把修订内容通知到作者群体。规范的价值体现在日常条目质量上，定期回看评审退回原因，比反复增加条款更能提升执行效果。
常见问题
团队规模很小，评审人与作者无法分开怎么办？
评审与写作分离的目的是减少作者自评的盲区，小团队可以设例外：由另一位熟悉该知识类型的成员代评审，或对低风险条目采用抽样复核。例外要写进规范，明确哪些条目适用、由谁代评、抽样比例如何定，避免因无人可评导致流程停摆。团队扩充后再逐步恢复常规分离。
规范条款越写越多，作者反而不用，怎么控制篇幅？
把规则分成两类处理：结构、字段这类可以靠模板固化的，写进模板即可，规范正文只做说明；语言风格、合格标准这类需要判断的，才在规范里展开并配样例。条款数量控制在团队能记住和执行的范围内，定期回看评审退回原因，用真实问题驱动修订，比反复增加条款更能提升执行效果。
规范发布后，知识类型发生变化或出现新场景怎么处理？
规范进入维护状态后，由Owner牵头判断是否需要修订，管理员同步更新模板，并把修订内容通知到作者群体。建议设定复核周期，例如每半年一次，或在知识类型变化时触发。评审中遇到样例未覆盖的新情况，由Owner判断并补充进样例，避免每次评审各说各话。
规范里的模板和评审记录放在哪里比较合适？
模板需要有统一承载的地方，评审意见也需要可追溯。ONES Wiki 支持使用模板库一键创建制式化文档，页面模板库可用于创建制式化文档模板；文档实时同步并记录所有页面版本，支持查看与回滚；还可为不同角色配置不同的读写权限。评审意见可以先通过页面注释和评论收集，再按团队约定形成通过结论。具体版本与套餐差异以官方信息为准。
规范里的合格标准怎么写才不流于“表达清晰”这类空话？
每条要求都要对应一个可观察的写法。例如把“步骤要清晰”改成“步骤用动宾结构，一条一个动作”；把“写清前提”改成“涉及权限或数据影响的操作必须写明前置条件”。再配一段合格写法和一段不合格写法对照，指出不合格的具体原因，评审时就能对照判断，而不是凭感觉。
