知识审核记录的价值，在于能回答“谁在什么时候依据什么对哪一版内容做了什么决定”。本文给出一份可直接照着建表或建表单的字段清单，说明提交、审核、退回复审、发布、归档各环节由谁填写哪些内容，并用一条完整示例和一份检查清单，帮助你把审核留痕做到可追溯、可核对。
要点总览（TL;DR）
- 知识审核记录至少覆盖四类信息：对象信息（知识编号、标题、版本号、所属目录、内容摘要）、过程信息（提交人、提交时间、审核人、审核环节、审核意见、审核结论）、依据信息（规范条款、引用来源、修改要求）、结果信息（处置结果、生效版本、发布时间、复查时间）。
- 字段要区分必填与条件必填：对象信息、审核人、审核时间、审核结论、生效版本为必填；规范条款、引用来源、修改要求、复查时间按知识重要度设为条件必填。
- 按提交、审核、退回与复审、发布、归档五个环节分步填写，退回与复审各自成条，形成同一知识条目下的连续记录链，以“知识编号+版本号”与正文版本对应。
- 填写与确认不宜由同一人完成；知识作者、审核人、发布人或知识库管理员、记录维护责任人、抽查人各自承担明确的交付物。
- 发布前用检查清单把关，缺审核人、缺审核结论、生效版本无法对应、退回后无复审记录属于阻断项，未满足不进入发布环节。
一份可用的知识审核记录包含哪些字段
审核记录不必追求字段数量，关键是覆盖四类信息：对象信息说明“审的是哪一版内容”，过程信息说明“谁审的、怎么审的”，依据信息说明“凭什么作出结论”，结果信息说明“最终怎么处置、何时复查”。四类信息合在一起，才能与知识正文版本稳定对应。
字段设计建议区分必填与条件必填。对象信息、审核人、审核时间、审核结论、生效版本属于必填项，缺失任何一项都会让记录失去追溯意义；引用来源、复查安排可按知识重要度设为条件必填，例如对外发布或涉及合规要求的知识条目必须填写依据条款。
| 字段名 | 说明 | 必填/选填 | 示例值 |
|---|---|---|---|
| 知识编号 | 知识条目的唯一标识，用于与正文建立关联键 | 必填 | KB-2024-0137 |
| 标题 | 被审核知识的名称 | 必填 | 客户退款申请处理规范 |
| 版本号 | 本次送审的内容版本，与正文版本一致 | 必填 | V2.1 |
| 所属目录 | 知识在知识库中的分类位置 | 必填 | 客服中心/售后流程 |
| 内容摘要 | 本次修改的主要变化，便于审核人快速定位 | 必填 | 新增超时未退款的处理时限与升级路径 |
| 提交人 | 发起审核的知识作者 | 必填 | 张敏 |
| 提交时间 | 送审的具体日期时间 | 必填 | 2024-06-11 10:20 |
| 审核人 | 实际作出审核结论的人员，多人审核时逐一记录 | 必填 | 李伟（业务审核）、王芳（合规审核） |
| 审核环节 | 当前记录对应的审核阶段 | 必填 | 业务初审 |
| 审核意见 | 具体问题描述与判断理由，避免只写“同意”或“不同意” | 必填 | 时限表述与售后系统配置不一致，需核对后修改 |
| 审核结论 | 通过、退回修改或驳回 | 必填 | 退回修改 |
| 规范条款 | 审核所依据的内部规范、制度或标准条目 | 条件必填 | 《售后服务管理办法》第4.2条 |
| 引用来源 | 内容中引用的外部资料或数据出处 | 条件必填 | 2024年售后系统配置说明 |
| 修改要求 | 退回时列出的具体修改项，逐条可核对 | 条件必填 | 将“3个工作日”改为“2个工作日”，补充升级联系人 |
| 处置结果 | 本条记录的最终处置状态 | 必填 | 修改后复审通过 |
| 生效版本 | 审核通过后正式生效的内容版本 | 必填 | V2.2 |
| 发布时间 | 生效版本对外或对内部开放的时间 | 必填 | 2024-06-14 15:00 |
| 复查时间 | 下次复核该知识有效性的计划时间 | 条件必填 | 2024-12-14 |
需要提醒的是，“审核意见”与“审核结论”应分开记录。意见描述发现的问题和判断依据，结论给出处置动作，两者混写会导致后续复审时无法判断修改是否针对了具体问题。
按审核流程分步填写：从提交到发布的记录动作
字段只有落到具体动作上才会被真正填写。下面按提交、审核、退回与复审、发布、归档五个环节，说明每一步的输入、动作、输出和完成标志。
提交环节
输入是待发布的知识正文草稿。知识作者填写对象信息字段，包括知识编号、标题、版本号、所属目录和内容摘要，并附一份自检说明，写明本次修改范围、已核对的事实来源。输出是一条状态为“待审核”的记录。完成标志是对象信息无空缺、版本号与正文当前版本一致。
审核环节
输入是提交记录和知识正文。审核人逐项阅读内容，填写审核意见、所依据的规范条款或引用来源，并给出审核结论。多人多环节审核时，每位审核人各自留一条记录，注明审核环节。输出是带有明确结论的审核记录。完成标志是审核意见能对应到具体段落或条款，结论为通过、退回或驳回三者之一。
退回与复审环节
输入是退回记录。知识作者按修改要求逐条修改，在复审时保留修改说明，注明每条要求的处理结果。复审人核对修改是否到位，新增一条复审记录，而不是覆盖原审核记录。输出是同一知识条目下连续的审核记录链。完成标志是每条修改要求都有对应的处理说明和复审确认。
发布环节
输入是审核通过的记录。发布人或知识库管理员填写生效版本、发布时间和发布人，确认生效版本与审核通过的版本一致。输出是状态为“已发布”的记录。完成标志是生效版本号、发布时间齐全，且与正文实际发布版本对应。
归档环节
输入是完整的审核记录链。归档时以“知识编号+版本号”为关联键，把记录与知识正文版本绑定，确保后续查看任一版本时能调出对应的审核过程。输出是可检索的归档记录。完成标志是通过知识编号能查到该条目历次审核记录，且每条记录都能定位到具体版本。
在工具承载上，ONES Wiki 的文档会记录页面版本并支持查看与回滚，成员也可以在线添加注释和评论，这些能力可以作为版本留痕和讨论过程的辅助。审核意见、依据条款、结论等结构化字段，仍需要团队约定统一的表单或页面模板来承载，并与正文版本建立对应关系。
角色分工与各自交付物
记录缺项往往源于责任不清。把“谁填什么、谁确认什么”固定下来，比事后补记录更有效。下表按角色列出动作与交付物。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 知识作者 | 提交前完成自检，填写对象信息与修改说明，按修改要求逐条处理 | 提交记录、自检说明、修改说明 |
| 审核人 | 阅读内容，填写审核意见、依据条款与审核结论，复审时确认修改结果 | 审核记录、复审记录 |
| 发布人或知识库管理员 | 核对生效版本，填写发布时间与发布人，完成记录与版本的归档关联 | 发布记录、归档记录 |
| 记录维护责任人 | 定期检查记录完整性，维护字段模板与填写规范 | 模板版本、填写规范说明 |
| 抽查人 | 按周期抽取已发布知识，核对记录与正文是否一致 | 抽查结果与补正通知 |
角色可以兼任，但填写与确认不宜由同一人完成。知识作者自审自发的场景下，至少应保留一名独立审核人的记录，否则审核留痕失去意义。记录维护责任与抽查责任建议分开，前者保证模板可用，后者验证执行质量。
示例：一条知识条目的完整审核记录
以下示例为演示情景，用于说明字段如何组合填写，不代表真实业务数据。
背景：客服中心更新《客户退款申请处理规范》，知识编号 KB-2024-0137，原版本 V2.0，本次修改涉及退款时限和升级路径。
提交记录
提交人张敏于2024-06-11 10:20提交V2.1版本，所属目录为“客服中心/售后流程”。内容摘要写明“新增超时未退款的处理时限与升级路径”。自检说明注明已核对售后系统当前配置，引用来源为2024年售后系统配置说明。
审核记录
业务审核人李伟于2024-06-12给出意见：“文中‘3个工作日’与售后系统配置的‘2个工作日’不一致，需核对后修改；升级联系人未写明岗位。”依据条款为《售后服务管理办法》第4.2条，结论为退回修改。修改要求逐条列出：一是将时限改为2个工作日；二是补充升级联系人的岗位名称。
复审记录
张敏于2024-06-13提交V2.2，修改说明逐条对应上述要求，注明已按系统配置更正时限并补充岗位。李伟复审确认修改到位，结论为通过。合规审核人王芳同日复核引用来源，结论为通过，记录中注明所依据的引用来源。
发布与复查记录
知识库管理员于2024-06-14 15:00发布V2.2，记录生效版本、发布时间与发布人。复查时间设为2024-12-14，用于核对售后系统配置是否再次调整。
从这个示例可以提炼三条填写规律：一是每条意见都指向具体段落或数值，便于核对；二是退回与复审各自成条，形成连续记录而非覆盖；三是生效版本与审核通过的版本号严格一致，复查时间与知识时效性挂钩。
完成检查：审核记录是否合格
检查的目的是在发布前拦住缺项记录。建议把检查项分为阻断项和补正项：阻断项未满足不进入发布环节，补正项允许限期完善。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 字段完整性 | 必填字段无空缺，条件必填字段按知识重要度补齐 | 审核记录表单 | 审核人 |
| 版本可对应 | 记录中的版本号与知识正文版本一致，生效版本可定位到具体内容 | 版本记录与正文对照 | 发布人 |
| 意见与结论一致 | 结论为退回时存在具体修改要求，结论为通过时意见中无未处理问题 | 审核意见与修改说明 | 审核人 |
| 依据可追溯 | 涉及规范要求的内容标注了条款或来源，可回查原文 | 规范条款、引用来源字段 | 审核人 |
| 记录连续性 | 退回、复审、发布记录按时间排列，未被覆盖或删除 | 同一知识编号下的记录链 | 记录维护责任人 |
| 复查安排 | 时效性强的知识已填写复查时间 | 复查时间字段 | 知识作者 |
阻断项建议包括：缺审核人、缺审核结论、生效版本无法与正文对应、退回后无复审记录。出现上述任一情况，记录应退回补正后再进入发布。补正项可包括引用来源表述不完整、复查时间未填等，允许在约定时限内完善，但需登记补正责任人和完成时间。
抽查时可按季度抽取一定比例的已发布知识，核对记录与正文是否一致。发现记录与内容脱节的，除了补正记录，还应回溯流程中哪个环节漏填，调整模板或责任分工，让审核记录持续可用。
常见问题
知识条目修改后重新发布，原来的审核记录需要保留还是替换？
保留，不替换。每次送审对应一条独立记录，修改后重新提交时新增一条记录，并在记录中注明所对应的版本号。原记录继续保留，用于说明上一版为何被退回或为何通过。这样同一知识编号下会形成按时间排列的记录链，查看任一历史版本时都能调出当时的审核过程。若用新记录覆盖旧记录，后续复查将无法判断某次修改是否针对了具体问题。
审核人只写“同意”两个字，算不算合格的审核意见？
不算。审核意见需要描述发现的问题和判断理由，结论才给出处置动作。只写“同意”会让记录失去核对价值：复审时看不出审核人检查了哪些内容，抽查时也无法判断意见与结论是否一致。可行的做法是要求意见指向具体段落、数值或条款，例如指出某处时限与系统配置不一致，并说明依据哪一条规范。内容确实无需修改时，也可以简要写明核对过的范围和确认无误的要点。
多人多环节审核时，审核记录应该怎么组织？
每位审核人、每个审核环节各自留一条记录，注明审核环节和审核人，不合并成一条。例如业务初审与合规审核分别记录意见、依据和结论，时间顺序清晰。合并记录会掩盖某一环节的实际判断，出问题时难以定位责任环节。若同一环节有多人参与，也建议逐一记录，或在一条记录中列明各人意见与最终汇总人。
用文档工具承载审核记录时，结构化字段怎么落地？
文档工具的版本记录和评论可以作为留痕辅助，但审核人、审核结论、依据条款这类结构化字段，通常需要团队约定统一的表单或页面模板来承载。ONES Wiki 的文档会记录页面版本并支持查看与回滚，成员也可以在线添加注释和评论，这些能力可用于版本留痕和讨论过程；结构化审核字段仍需通过模板约定，并与正文版本建立对应关系。具体承载方式建议在实际环境中验证后再固定为团队规范。
复查时间应该由谁填写，没填会有什么影响？
复查时间一般由知识作者在提交或发布环节填写，发布人核对。它标记的是下次复核该知识有效性的计划时间，对时效性强的知识尤其重要，例如依赖系统配置、政策条款或对外承诺的内容。未填写不会让记录立刻失效，但知识可能长期不更新而无人察觉。建议把复查时间设为条件必填：对外发布或涉及合规要求的知识必须填写，其余知识可按重要度约定。
