知识库文档数量增长后，靠个人习惯维护版本很快会失控：同一份制度存在多个版本、过期内容仍被检索到、误删后无人能恢复。制定流程的关键是先定义文档状态和责任人，再为每次状态转换设定触发条件、审批角色和留痕要求。本文按状态机、评审发布、更新归档、删除恢复、角色分工的顺序给出可落地的规则，并用一份操作手册的完整生命周期示范如何运转。
要点总览（TL;DR）
- 先定义草稿、待评审、已发布、待更新、已归档、待删除/已删除六个状态，为每次转换写明进入条件、退出条件、触发人和是否需审批，流程才有可执行的骨架。
- 评审与发布要固定角色和留痕：作者提交、评审人按准确性/完整性/时效性/敏感信息逐项确认、发布批准人确认范围与版本号，并保留发布记录字段。
- 发布后按文档类型设定复核周期，到期由文档责任人给出更新、维持或归档三种结论；归档转为只读并保留检索，同时标注替代文档。
- 删除做成可回退动作：先判断能否归档，确需删除的走申请与管理员审批，执行软删除并保留恢复窗口，保留期结束后再彻底清除。
- 上线前用检查清单核对状态覆盖、责任人、提醒配置和恢复演练，选一个栏目试运行一个完整周期，按复盘结果调整后再推广。
先定状态机：文档从创建到删除的六个状态
状态机是整套流程的骨架。它把“文档现在处于什么阶段、下一步能去哪里、由谁推动”写成明确规则，避免文档长期停留在模糊的中间状态。建议采用六个状态：草稿、待评审、已发布、待更新、已归档、待删除/已删除。
每个状态需要同时定义进入条件和退出条件。进入条件回答“什么情况下文档变成这个状态”，退出条件回答“满足什么条件才能离开”。触发人指发起这次转换的角色，是否需审批决定这次转换是自动完成还是必须经过人工确认。
| 状态 | 进入条件 | 退出条件 | 触发人 | 是否需审批 |
|---|---|---|---|---|
| 草稿 | 作者新建文档或从模板创建 | 作者提交评审 | 文档作者 | 否 |
| 待评审 | 作者提交评审，指定评审人 | 评审通过转已发布；评审不通过退回草稿 | 文档作者 | 是（评审人确认） |
| 已发布 | 评审通过且发布批准人确认 | 到期复核转待更新；判定失效转已归档；发起删除申请转待删除 | 发布批准人 | 是（发布批准） |
| 待更新 | 复核到期或内容被指出过期 | 完成修订并重新评审转已发布；确认仍有效转回已发布；判定失效转已归档 | 文档责任人 | 视修改幅度，重大修改需评审 |
| 已归档 | 长期未更新、业务已下线或被新文档替代 | 业务恢复可申请重新发布；确认无保留价值转待删除 | 文档责任人 | 是（知识库管理员确认） |
| 待删除/已删除 | 发起删除申请并经审批 | 保留期内可恢复为原状态；保留期结束彻底清除 | 文档责任人发起，管理员审批 | 是 |
状态与可见范围要绑定。草稿仅作者和指定协作者可见；待评审对评审人可见；已发布对目标读者范围开放；待更新保持可见但标注复核中；已归档转为只读并保留在检索结果中，标注“已归档”；待删除的文档从常规检索中移除，仅管理员在回收区可见。这样读者看到的内容始终有明确的可信度标记。
自动触发与人工审批要分开设计。到期复核提醒、长期未更新标记、归档后只读锁定适合自动触发；发布、归档确认、删除属于影响面较大的转换，应保留人工审批。规则写进状态流转表后，任何一次状态变化都能追溯到触发人和审批记录。
评审与发布：谁审、审什么、怎么留痕
评审要解决的是“内容是否可信、是否适合对目标读者开放”。把评审从口头确认变成固定环节，需要明确三类角色：作者负责提交完整稿件并回应意见，评审人负责按检查项给出结论，发布批准人负责确认发布范围和版本号。
评审触发条件建议覆盖三种情况：新建文档首次发布、重大修改（涉及结论、流程步骤、责任主体的变更）、周期性复核后的重新发布。文字润色、格式调整等小改动可由作者直接更新，在版本记录中注明即可，不必每次走完整评审。
评审检查项清单可按以下四类组织，评审人逐项确认：
- 准确性：数据、流程步骤、角色名称与现行制度一致，引用的外部信息有出处。
- 完整性：目标读者完成操作所需的前置条件、步骤、异常处理均已写明。
- 时效性：内容对应的业务场景仍然存在，引用的制度、系统版本未过期。
- 敏感信息：不含个人隐私、账号口令、未脱敏的客户数据或内部受限信息。
评审意见的处置要有规则：评审人提出意见后，作者逐条回应“采纳修改”或“说明理由”，全部意见闭环后由评审人给出通过或不通过结论。不通过退回草稿，修改后重新提交，复审范围可限定在修改部分，但结论仍需评审人确认。发布记录应保留以下字段，便于事后追溯：
| 字段 | 说明 |
|---|---|
| 文档标题与编号 | 唯一标识，编号在归档后仍保留 |
| 版本号 | 建议主版本.次版本，重大修改升主版本 |
| 作者与评审人 | 记录提交人和给出结论的人 |
| 发布批准人 | 确认发布范围与版本的人 |
| 评审结论与日期 | 通过/不通过及对应时间 |
| 发布范围 | 可见的读者群体或页面组 |
| 变更摘要 | 本次修改的主要内容 |
发布动作本身要产生可查的记录：版本号写入文档头部，发布记录归档在文档附属信息中，历史版本可查看和回滚。ONES Wiki 记录所有页面版本并支持随时查看与回滚，成员可以在线添加注释和评论，评审意见可以直接落在文档对应位置，减少意见散落在聊天工具里的情况。
更新与归档：用周期复核代替一次性维护
文档发布后最大的风险是悄悄过期。解决办法是按文档类型设定复核周期，由文档责任人到期确认，把“是否需要更新”变成一次有结论的动作，而不是等读者发现问题。
| 文档类型 | 示例 | 建议复核周期 | 复核责任人 |
|---|---|---|---|
| 制度类 | 管理办法、审批规则、权限规范 | 每6个月 | 制度归口部门指定的文档责任人 |
| 操作类 | 系统操作手册、作业指导书 | 每3至6个月，系统版本变更时立即触发 | 业务或系统负责人 |
| 参考类 | 术语表、常见问题、背景资料 | 每12个月 | 知识库管理员或栏目负责人 |
到期提醒要落到具体人。系统在复核到期前若干天提醒文档责任人，责任人确认后给出三种结论之一：更新（内容需要修订，转入待更新并走评审）、维持（内容仍有效，记录复核日期并顺延下个周期）、归档（内容失效，转入已归档）。复核结论和日期写入文档记录，作为下次盘点的依据。
归档判定标准建议明确三条，满足其一即可发起归档：连续两个复核周期未更新且无人确认维持；对应业务已下线或系统已停用；已被新文档完整替代。归档前需确认新文档已发布并建立替代关系，避免读者找不到入口。
归档后的处理策略是只读加保留检索。文档不再接受编辑，保留在知识库中并可被搜索到，页面顶部标注归档状态和归档日期，指向替代文档的链接。这样既清理了活跃内容区，又保留了历史追溯能力。ONES Wiki 的页面组可关联项目，需求与文档互相对应，归档时能同步确认关联需求是否仍在使用，减少误归档。
删除与恢复：把删除做成可回退的动作
删除应当是例外动作而非常规清理手段。发起删除前先判断：业务已下线但可能有追溯需求的，走归档；内容重复且已被替代的，走归档并标注替代关系；确属错误创建、测试内容、含敏感信息必须清除的，才进入删除流程。
删除流程建议包含四步：文档责任人提交删除申请，说明删除原因和影响范围；知识库管理员核对是否存在关联引用、是否有归档替代方案；审批通过后执行软删除，文档移入回收区并从常规检索中移除；保留期结束后由管理员执行彻底清除。删除审批单至少包含以下字段：
- 文档标题、编号与当前版本号
- 删除原因（错误创建、内容重复、敏感信息、业务终止等）
- 影响范围说明（关联页面、引用该文档的需求或流程）
- 是否已有归档或替代方案
- 申请人、审批人、申请与审批日期
- 保留期截止日期与彻底清除执行人
恢复操作要简单到误删后能立即处理。软删除期间，管理员在回收区按标题、删除人、删除时间检索目标文档，确认后执行恢复，文档回到删除前的状态和位置，版本历史一并保留。恢复权限建议只授予知识库管理员，普通成员发现内容消失时向管理员报告，避免多人操作造成混乱。ONES Wiki 支持从回收站恢复误删除页面，可以作为软删除与恢复环节的承载工具；回收站的具体保留期限和彻底清除规则需按实际配置确认，并写入流程说明。
彻底清除需要满足保留期已满、无未结的关联引用、无合规留存要求三个条件，执行前再次确认审批记录完整。涉及个人信息或合同类内容的清除，按组织合规要求保留清除记录。
角色分工与交付物：一张表说清谁在什么时候做什么
流程规则只有落到岗位和产出上才能执行。建议用角色职责矩阵把每个角色在每个环节的动作和产出固定下来，矩阵按“角色×环节×动作×产出”四列展开。
| 角色 | 主要环节 | 动作 | 产出 |
|---|---|---|---|
| 文档作者 | 草稿、待评审、待更新 | 创建文档、提交评审、回应评审意见、执行修订 | 文档初稿、评审回应记录、修订版本 |
| 评审人 | 待评审 | 按检查项逐条确认，给出通过或不通过结论 | 评审意见与结论记录 |
| 发布批准人 | 发布 | 确认发布范围、版本号与变更摘要 | 发布记录 |
| 文档责任人 | 待更新、归档、删除申请 | 到期复核、给出更新/维持/归档结论、发起删除申请 | 复核记录、归档判定、删除申请单 |
| 知识库管理员 | 归档确认、删除审批、恢复 | 确认归档、审批删除、执行软删除与恢复、到期彻底清除 | 归档记录、审批记录、恢复操作记录 |
责任人继承与交接要提前约定。文档责任人离职或转岗时，由所在部门在交接清单中指定接任人，知识库管理员批量更新责任人字段，未指定接任人的文档由栏目负责人暂代，并在下次盘点时确认。评审人和发布批准人按文档所属领域设置，人员变动时同步更新授权名单。
审批权限分级设置可以避免所有审批压在一处：普通参考类文档的发布由栏目负责人批准；制度类和操作类文档的发布由归口部门负责人批准；归档由知识库管理员确认；删除统一由知识库管理员审批，涉及敏感信息的删除增加合规或信息安全角色会签。分级规则写入流程说明，随组织调整定期复核。
示例：一份操作手册走完整个生命周期
以下为演示情景，用于说明各节点的输入、动作与输出，实际执行以组织配置为准。
| 时间 | 节点 | 输入 | 动作 | 输出 |
|---|---|---|---|---|
| 3月1日 | 创建草稿 | 系统升级后的操作步骤说明 | 作者从模板创建文档，填写标题、适用范围、前置条件 | 草稿 v0.1，仅作者可见 |
| 3月5日 | 提交评审 | 草稿 v0.1 | 作者指定业务负责人为评审人，提交评审 | 状态转为待评审 |
| 3月8日 | 评审 | 待评审文档 | 评审人按准确性、完整性、时效性、敏感信息四项检查，提出两处步骤顺序问题 | 评审意见记录 |
| 3月10日 | 修订与复审 | 评审意见 | 作者调整步骤顺序并逐条回应，评审人复审修改部分 | 评审通过结论 |
| 3月11日 | 发布 | 评审通过记录 | 发布批准人确认发布范围为运维团队，版本号定为 v1.0 | 发布记录，状态转为已发布 |
| 9月11日 | 到期复核 | 复核提醒 | 文档责任人核对系统当前版本，发现界面有调整，结论为更新 | 状态转为待更新 |
| 9月15日 | 更新发布 | 修订内容 | 作者更新截图与步骤，评审人确认，发布 v1.1 | 新版本发布记录 |
| 次年3月 | 业务变更 | 旧系统下线通知 | 文档责任人判定手册对应功能已停用，发起归档 | 归档判定记录 |
| 次年3月 | 归档确认 | 归档申请 | 知识库管理员确认已有新手册替代，执行归档 | 状态转为已归档，只读并标注替代链接 |
| 次年6月 | 误删恢复 | 成员报告文档消失 | 管理员在回收区检索到该文档，确认误删后执行恢复 | 文档回到已归档状态，版本历史完整 |
这个示例说明两点：复核结论要落到具体动作，更新就转待更新并重新发布，归档就转只读并建立替代关系；删除与恢复要有可查的操作记录，误删后能快速定位并还原，不影响历史版本追溯。
完成检查：流程上线前要核对的清单
流程设计完成后，先按以下清单逐项核对，再选择一个栏目试运行一个完整周期，确认规则可执行后再推广。
- 状态覆盖：六个状态是否覆盖文档从创建到清除的全部路径，是否存在无法归类或无法退出的状态。
- 流转完整：每个状态转换是否写明触发条件、触发人和是否需审批，是否存在无人推动的转换。
- 责任明确：每份文档是否都有文档责任人，每个评审和审批环节是否都有具名角色，离职转岗的交接规则是否写入。
- 检查项可用：评审检查项是否能被评审人逐条确认，发布记录字段是否足以追溯版本和范围。
- 提醒配置：复核周期是否按文档类型分档设置，到期提醒是否发送到责任人，盘点频率是否确定。
- 归档规则：归档判定标准是否明确，归档后是否只读、是否保留检索、是否标注替代文档。
- 删除恢复验证：删除审批单字段是否齐全，软删除保留期是否配置，恢复操作是否实际演练过一次，彻底清除条件是否写入。
- 权限核对：草稿、待评审、已发布、已归档各状态的可见范围是否与权限配置一致。
试运行一个周期后的复盘重点看四件事：有多少文档在待评审或待更新状态停留超过预期时间，说明审批或责任人环节存在堵点；到期复核的完成率，反映提醒机制是否有效；归档和删除的实际发生量，判断判定标准是否过严或过松；恢复操作是否被实际使用过，验证保留期设置是否合理。根据复盘结果调整周期长度、审批层级和提醒时间，再进入全面推广。
常见问题
文档数量不多时，也要一次把六个状态全部启用吗？
可以从简化版起步，但状态之间的边界要保留。文档量少时，可先启用草稿、待评审、已发布、已归档四个状态，把待更新合并进已发布、用复核标记代替，删除仍走申请与软删除。等文档数量和参与角色增加后，再拆出待更新和待删除状态。关键是每次转换的触发人和审批要求从一开始就写明，避免后期补规则时出现无人认领的转换。
复核到期后责任人一直不确认，流程该怎么处理？
建议设置两级兜底：到期提醒发出后超过约定天数仍未确认，系统自动把文档标记为“待更新”并在页面提示内容待复核；再超过一个宽限期，由栏目负责人或知识库管理员代为确认，结论只能是维持或归档，不能代替责任人做内容修订。同时把逾期未确认的文档列入月度盘点清单，作为流程运行指标跟踪，连续逾期的栏目需要调整责任人设置。
归档和删除的边界怎么判断，哪些情况应该归档而不是删除？
判断标准是“是否还可能需要追溯”。业务已下线、系统已停用、被新文档完整替代的，优先归档：文档转只读、保留在检索结果中、标注归档日期和替代链接，读者仍能查到历史依据。确属错误创建、测试内容、内容重复且无追溯价值，或含敏感信息必须清除的，才进入删除流程。归档前要确认替代文档已发布并建立关联，避免读者找不到入口。
软删除的保留期设多长比较合适，恢复权限给谁？
保留期没有统一标准，可按文档类型分档：制度类和合同类等追溯要求高的设较长保留期，日常操作类可短一些，具体长度结合组织合规要求和存储条件确定。恢复权限建议只授予知识库管理员，普通成员发现内容消失时向管理员报告，由管理员在回收区按标题、删除人、删除时间检索并恢复，文档回到删除前状态且版本历史保留。保留期和彻底清除规则要写入流程说明，并在上线前实际演练一次恢复操作。ONES Wiki 支持从回收站恢复误删除页面，回收站的具体保留期限需按实际配置确认。
评审检查项和发布记录字段需要每个团队自己定吗？
框架可以统一，细项按文档类型调整。准确性、完整性、时效性、敏感信息四类检查项适合作为通用框架，操作类文档可增加步骤可执行性检查，制度类文档可增加与现行制度一致性检查。发布记录字段建议全组织统一，至少包含标题与编号、版本号、作者与评审人、发布批准人、评审结论与日期、发布范围、变更摘要，这样跨部门追溯时口径一致。字段确定后写入模板，减少每次发布临时补充。
