知识审核清单要能直接用于发布把关，至少应包含五类信息：使用对象与时点、分阶段检查项、每项的通过标准、证据与负责人、阻断项与完成条件。它适合知识条目从草稿进入待审、再发布上线的场景，重点检查内容质量与发布条件；知识使用成效评估、页面权限共享设置不在本文清单范围内。清单条目要能回答“完成了吗”，而不是停留在“注意准确性”这类建议。
要点总览（TL;DR）
- 知识审核清单至少包含五类信息：使用对象与时点、分阶段检查项、每项通过标准、证据与负责人、阻断项与完成条件。
- 按提交前、评审中、发布前三个阶段分配检查项，分别由提交者、评审人、发布人使用，避免重复勾选或漏检。
- 通过标准要写成可观察的事实，例如“引用链接可打开且与正文表述一致”，并区分必过项与建议项。
- 每个检查项注明证据形式和确认角色，多人评审时写明确认顺序，让审核结论可追溯。
- 事实错误、来源缺失、敏感信息未处理、责任人空缺等阻断项未关闭时不得发布，清单随条目归档。
谁在什么时点使用这张审核清单
一张审核清单通常由三类角色使用：提交者、评审人、发布人。三者介入的时点不同，检查重点也不同。提交者使用清单做提交前自检，确认内容完整、来源可查；评审人使用清单做内容复核，判断事实、口径和合规表述是否成立；发布人使用清单做发布前放行，确认分类、版本、责任人和复审安排已经落实。把角色和时点写进清单，能避免同一张表被所有人重复勾选，也能让每个环节知道自己要交付什么。
清单还应与知识条目的状态对应。草稿阶段主要使用提交前检查项，待审阶段使用评审检查项，已发布前使用发布前检查项。状态变化时，清单的填写责任随之转移，未完成的条目不应随状态推进被跳过。下表给出一种常见的对应关系，团队可按自身流程调整节点名称。
| 使用角色 | 介入时点 | 对应条目状态 | 主要动作 |
|---|---|---|---|
| 提交者 | 提交评审之前 | 草稿 | 完成自检，补齐来源、适用范围和关联材料 |
| 评审人 | 评审过程中 | 待审 | 逐项复核事实、术语、敏感信息，记录评审意见 |
| 发布人 | 发布操作之前 | 待发布 | 确认分类标签、版本、责任人和复审日期，执行放行 |
在ONES中承载这类流程时，知识条目可以放在Wiki页面组中维护，页面组关联项目后，需求与文档能够互相对应，便于评审人找到条目对应的业务背景。评审过程中的意见可以通过页面注释和评论留下反馈，减少审核结论只存在于聊天记录里的情况。
分阶段检查项：提交前、评审中、发布前各查什么
分阶段检查项是清单的主体。每个阶段只列该阶段能够判断的条目，避免把评审人的判断提前压给提交者，也避免发布人重复核对内容细节。以下条目可作为起点，团队可结合知识类型增删，但保留“可勾选、可判断”的写法。
提交前检查项
- 标题能准确概括条目主题，读者只看标题即可判断是否与自己的问题相关。
- 摘要或首段说明了适用对象、适用场景和主要结论，未出现与正文矛盾的表述。
- 适用范围与失效条件已写明，例如适用的产品版本、流程阶段或组织范围。
- 关键事实、数据和结论标注了来源，引用材料可访问，引用内容与正文表述一致。
- 文中使用的术语与团队既有口径一致，首次出现的缩写已给出全称。
- 关联的文档、需求或项目已添加，读者可以顺着条目找到上下文。
评审中检查项
- 事实与数据已逐条核对，引用的数字、日期、名称与来源一致。
- 结论有依据支撑，推测性内容已标明为判断或建议，未写成确定事实。
- 同一概念在全文中使用同一术语，未出现前后口径不一致。
- 涉及客户信息、个人信息、内部价格或未公开计划的内容已处理或移除。
- 合规表述已检查，未出现绝对化承诺或超出授权范围的表述。
- 评审意见已逐条回应，未采纳的意见记录了理由。
发布前检查项
- 分类与标签已按知识库目录规则填写，读者能通过导航或检索找到条目。
- 关联文档与版本号已确认，条目引用的材料处于有效状态。
- 责任人已指定，复审日期已填写，到期后有人负责更新或下线。
- 发布范围已确认，条目放置在正确的页面组或目录下。
- 标题、摘要和正文在发布预览中显示正常，无残留的编辑标记或占位内容。
每项检查的通过标准怎么写才可判断
通过标准决定清单能否被真正执行。写法上，用可观察的事实描述合格状态，让不同的人看到同一项时能得出相同判断。例如“引用来源可访问且与正文一致”可以核验，“内容准确”无法核验；“复审日期已填写且不晚于十二个月后”可以核验，“定期复审”无法核验。通过标准还应区分必过项与建议项：必过项未满足即不能发布，建议项用于提升质量，可在记录理由后放行。
| 检查项 | 合格写法 | 无法判断的写法 |
|---|---|---|
| 来源标注 | 关键结论后附来源链接，链接可打开，内容与正文表述一致 | 来源充分、引用规范 |
| 适用范围 | 首段写明适用产品版本或流程阶段，并列出至少一个不适用情形 | 适用范围清晰 |
| 术语一致 | 同一概念全文使用同一名称，缩写首次出现时给出全称 | 术语使用规范 |
| 敏感信息 | 文中不含客户名称、个人联系方式、未公开价格，或已做脱敏处理并有记录 | 注意保密 |
| 责任人 | 责任人字段填写到岗位角色，复审日期为具体日期 | 有人负责维护 |
写通过标准时，可以按“看什么材料、满足什么条件、由谁判断”三个要素组织一句话。条件要具体到可以当场检查，判断人要与该阶段的角色一致。对于确实需要主观判断的条目，例如可读性，可以给出最低要求，如“首段不超过三句话并说明结论”，把主观要求转成可观察的形式。
证据与负责人：每项由谁确认、看什么材料
审核结果要可追溯，每个检查项都应说明证据形式和确认角色。证据是评审人判断的依据，也是后续复查时还原结论的材料。常见证据包括原文链接、评审记录、页面评论、截图、版本号和关联文档编号。证据不必复杂，但要能让未参与评审的人看懂当时依据了什么。
负责人按角色填写，例如“内容提交者”“领域评审人”“知识库管理员”“发布负责人”，不直接写人名。人员变动时，角色仍然对应到具体岗位，清单可以继续使用。多人评审时，需要写明确认顺序：先由领域评审人确认事实与口径，再由合规或安全角色确认敏感信息，最后由发布人确认发布条件。每一步的确认结果留在条目评论或评审记录中，形成可查的顺序痕迹。
| 检查项 | 证据形式 | 确认角色 | 留痕方式 |
|---|---|---|---|
| 来源与引用 | 原文链接、引用段落截图 | 内容提交者初核，领域评审人复核 | 条目内附链接，评审记录注明核对结果 |
| 事实与数据 | 数据来源、版本号、对照文档 | 领域评审人 | 评审意见逐条回应 |
| 敏感信息 | 脱敏前后对照、处理说明 | 合规或安全角色 | 处理记录附在评审记录中 |
| 分类与标签 | 目录规则、页面组位置截图 | 知识库管理员 | 发布前检查记录 |
| 责任人与复审日期 | 条目属性字段截图 | 发布负责人 | 发布记录中保留字段值 |
ONES Wiki支持记录页面版本并查看、回滚，评审人可以用版本记录对照修改前后的差异；成员可以在线添加注释和评论，把确认意见留在条目旁边。页面模板库可以用于把审核清单做成制式模板，提交者新建条目时直接套用，减少每次重新组织检查项的工作。
阻断项与完成条件：哪些不通过就不能发布
阻断项是清单中未通过即不得发布的关键条目。典型阻断项包括：关键事实或数据存在错误；核心结论缺少来源且无法补充；敏感信息未处理；责任人空缺或复审日期缺失；条目分类错误导致读者无法找到。阻断项应在清单中单独标记，评审人发现后直接退回，不进入发布环节。把阻断项与普通建议项混在一起，容易让发布人在“差不多可以”的判断中放行有风险的条目。
有条件放行适用于影响可控的情形，例如某条建议项未满足但已记录理由和补审计划。放行时需要写明补审责任人和补审日期，并在到期前完成复核。阻断项一般不适用有条件放行；确因业务紧急需要先发布，应由发布负责人和领域评审人共同确认风险范围，记录临时处理方式，并设定短期补审节点。
清单整体判定为通过，需要满足三个条件：所有必过项已勾选并有对应证据；阻断项全部关闭；发布前检查项由发布人确认完毕。完成后的清单随条目归档，作为该版本发布的审核记录。条目后续修改时，按修改范围重新执行相关阶段检查，避免旧清单覆盖新版本。ONES的AI研发管理方案强调基于权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；这一思路与审核留痕的要求一致，具体到知识审核场景时，仍以团队实际配置的流程为准。
常见问题
知识审核清单和知识库运营指标是什么关系？
两者关注的对象不同。审核清单管的是单条知识在发布前是否达到质量与合规要求，判断依据是内容本身和发布条件；运营指标关注知识发布后的使用情况，例如访问、检索命中、更新频率等。清单通过只说明条目可以发布，不能说明它被用得好。团队可以把审核记录作为运营分析的输入之一，但不必把访问量之类的指标塞进发布检查项，否则会让评审人在发布前承担无法判断的任务。
条目发布后做了小修改，需要重新走完整审核吗？
按修改范围决定。改动只涉及错别字、格式或链接替换，且不改变结论和适用范围时，可以由条目责任人自行核对后更新，并在版本记录中注明改动内容。改动涉及事实、数据、结论、适用范围或敏感信息时，应重新执行评审中与发布前检查项，由原评审角色确认。团队可以在清单里加一条判断规则：修改是否影响读者依据该条目做决定，影响则重审，不影响则记录后更新。
多人评审时意见不一致，清单上怎么记录？
清单本身记录的是检查结果，不承担争论过程。建议在条目评论或评审记录中写清分歧点、各方依据和最终结论，清单上只填最终判定和确认角色。若分歧涉及阻断项，例如某段数据是否准确，应由领域评审人给出结论并附证据；无法达成一致时，提交给更高一级的评审角色裁定，裁定结果同样留痕。这样清单保持简洁，追溯时仍能还原判断过程。
小团队也需要这么细的清单吗？
可以按风险裁剪。小团队或低风险知识条目，可以合并评审中与发布前检查项，保留来源核对、敏感信息、责任人和复审日期这几项必过内容，建议项适当减少。高风险内容，例如对外发布或涉及合规表述的条目，仍建议保留分阶段检查。裁剪的原则是：阻断项不能省，证据和确认角色不能省，其余条目按条目影响范围增减。
审核清单放在哪里维护比较合适？
放在团队日常写知识条目的同一工具里最省事，提交者新建条目时能直接套用模板，评审意见也能留在条目旁边。ONES Wiki 提供页面模板库，可一键创建制式化文档模板，成员可以在线添加注释和评论进行反馈，页面版本支持查看与回滚。团队可以把清单做成模板，随条目一起归档，复查时按版本对照修改前后的差异。
