知识库文档数量增长后，靠个人习惯维护版本和有效期会越来越吃力：同一份制度存在多个版本、负责人离职后文档无人更新、过期内容仍被当作依据。本文按“创建—评审—发布—定期更新—过期归档—删除与恢复”六个阶段，给出各阶段的管控规则设计方法，包括状态命名、必填字段、责任人、动作和退出标志，并说明如何按文档类型分级管控。文中也会结合ONES Wiki的文档与空间管理能力，说明这些规则在知识库工具中如何承载。
要点总览（TL;DR）
- 把文档生命周期拆成创建、评审、发布、定期更新、过期归档、删除与恢复六个阶段，每个阶段用进入条件、必填字段、责任人、动作、退出标志五要素定义规则。
- 按文档类型分级管控：制度类必须评审、固定复核周期并保留归档；操作类简化评审、缩短复核周期；参考类可免评审、按需更新。
- 用元数据字段承载规则，负责人、文档类型、密级、有效期、关联业务对象设为必填，字段缺失时拦截提交与发布。
- 到期提醒指定对象和时间，超期未处理要有默认处置，例如标记过期、退出默认检索排序或转入归档候选。
- 删除采用软删除加保留期，删除前做关联检查，保留期内由知识库管理员负责恢复并记录原因。
先定阶段与状态：生命周期规则的骨架
设计生命周期规则的第一步，是把文档从产生到消亡的过程拆成有限个阶段，并为每个阶段起一个可操作的状态名。状态名要能直接对应一个动作，例如“待评审”意味着有人需要提交评审，“已过期”意味着有人需要决定更新还是归档。状态过多会让维护成本上升，六个阶段对应六到八个状态通常够用。
每个阶段的规则由五个要素组成：进入条件（满足什么才能进入该状态）、必填字段（该状态下必须填写或已存在的元数据）、责任人（谁负责推动该阶段完成）、动作（在该阶段要执行的操作）、退出标志（满足什么条件才算完成并进入下一状态）。五要素齐全，规则才能被系统校验，也才能被交接。
| 阶段 | 建议状态命名 | 进入条件 | 必填字段 | 责任人 | 核心动作 | 退出标志 |
|---|---|---|---|---|---|---|
| 创建 | 草稿 | 确定文档主题与用途 | 负责人、文档类型、密级、有效期、关联业务对象 | 文档负责人 | 填写元数据、完成初稿 | 提交评审或直接发布 |
| 评审 | 待评审 / 评审中 | 草稿提交评审 | 评审人、评审截止时间 | 评审人 | 审阅内容、留下意见 | 评审通过或退回 |
| 发布 | 已发布 | 评审通过或免评审 | 生效日期、适用范围 | 知识库管理员 | 发布生效、通知相关人 | 文档对外可见可用 |
| 定期更新 | 待复核 / 已复核 | 到达复核周期或内容变更 | 复核记录、下次复核日期 | 文档负责人 | 核对内容、更新或确认有效 | 确认有效或产生新版本 |
| 过期归档 | 已过期 / 已归档 | 超过有效期未复核 | 归档原因、归档日期 | 文档负责人、知识库管理员 | 标记过期、移入归档区 | 文档退出常用检索范围 |
| 删除与恢复 | 已删除（可恢复） | 确认无保留价值 | 删除原因、删除人、保留期 | 知识库管理员 | 软删除、到期清理 | 保留期结束或恢复 |
管控强度应按文档类型分级。制度类文档涉及规则依据，通常需要评审、固定复核周期和归档保留；操作类文档强调时效，复核周期可以更短，评审可简化为负责人确认；参考类文档管控最轻，可免评审、按需更新。分级的意义在于把审批资源集中在高风险文档上，避免所有文档走同一套流程导致入口拥堵。
创建与评审阶段：把入口和把关规则写清楚
创建阶段的管控目标是让每份文档一进入知识库就带有可追溯的元数据。建议将以下字段设为必填：负责人（对内容有效性负责的个人，而非部门）、文档类型（决定后续管控强度）、密级（决定可见范围）、有效期或下次复核日期、关联业务对象（如关联的制度编号、项目、产品线）。字段缺失时不允许提交评审或发布，这是入口规则能否执行的关键。
评审触发条件按文档类型设定。制度类、对外发布类、涉及合规与安全的文档必须评审；操作类文档可由负责人提交、指定一名同行评审；参考类文档可免评审，由负责人直接发布。评审人应在提交时指定，避免“待分配”状态长期挂起。评审意见需要留痕，记录在文档的评审记录中，包含意见内容、提出人和处理结果。
| 文档类型 | 是否必须评审 | 评审人指定方式 | 通过标准 | 不通过处理 |
|---|---|---|---|---|
| 制度类 | 必须 | 由部门负责人指定，至少一名业务相关方 | 全部评审人同意，意见已闭环 | 退回草稿，修改后重新提交，保留原评审记录 |
| 操作类 | 建议 | 文档负责人指定一名同行 | 评审人确认可执行 | 退回草稿，负责人修改后重提 |
| 参考类 | 可免 | 不适用 | 负责人自检 | 不适用 |
评审不通过时，文档回到草稿状态，评审意见保留在记录中，负责人修改后重新提交。重提规则应明确：同一文档重提次数不设上限，但每次重提需说明上一轮意见的处理情况，避免评审人与负责人来回空转。评审超时也应有规则，例如超过约定截止时间未处理，提醒评审人并抄送其上级，或允许管理员改派评审人。
发布、更新与过期：让文档保持有效
发布动作决定文档的生效范围和可见对象。发布时应确认生效日期和适用范围，发布后普通编辑权限收回，内容变更需走版本更新流程，由负责人发起、按文档类型决定是否重新评审。这样能避免已发布文档被随意修改，导致读者看到的版本与评审通过的版本不一致。
定期复核是保持文档有效的主要机制。复核周期按文档类型设定：制度类可设为每12个月，操作类每6个月，参考类每12个月或按需。复核动作包括核对内容是否仍准确、关联对象是否仍存在、负责人是否仍在职，完成后更新复核记录和下次复核日期。复核结果只有两种：确认有效，或产生新版本进入更新流程。
| 文档类型 | 建议复核周期 | 到期前提醒对象 | 提前提醒时间 | 超期未处理默认处置 |
|---|---|---|---|---|
| 制度类 | 12个月 | 文档负责人、部门负责人 | 30天 | 标记为“已过期”，保留可查，退出默认检索排序 |
| 操作类 | 6个月 | 文档负责人 | 14天 | 标记为“待复核”，提醒升级至部门负责人 |
| 参考类 | 12个月或按需 | 文档负责人 | 7天 | 转归档候选，由管理员确认 |
到期提醒要指定对象和时间，而不是只发一条广播通知。提醒应包含文档名称、负责人、到期日和可执行的操作入口。超期未处理的默认处置需要事先约定：制度类文档超期后标记过期并退出默认检索排序，但仍可访问；操作类文档超期后提醒升级；参考类文档转入归档候选。默认处置的作用是让规则在无人操作时也能收口，而不是让过期文档无限期停留在“已发布”状态。
在ONES Wiki中，文档以页面形式组织在知识空间内，页面可设置负责人和属性字段，空间可按部门或主题划分并配置成员权限。将复核日期、文档类型等设为页面属性，配合空间内的定期巡检，可以把上述复核与到期规则落到具体的页面和责任人上。规则的具体字段配置需结合团队实际的空间结构设计。
归档、删除与恢复：收口规则与兜底
归档和删除是两种不同处置。归档表示文档不再作为现行依据，但需要保留可查，适用于被新版本替代、业务已结束或超期未复核的制度类文档。删除表示文档不再有保留价值，适用于草稿废弃、重复内容或明确无引用价值的文档。判定条件应写清楚：被新版本替代的旧版本默认归档；被其他文档引用为规范依据的文档不允许直接删除。
归档一般由文档负责人发起、知识库管理员确认，归档后文档移入归档区，退出常用检索范围，但保留访问入口和元数据。删除需要更严格的审批：普通文档由知识库管理员审批，制度类文档需部门负责人确认。删除前应做关联检查，确认文档未被其他文档引用、未作为流程或规范的依据、未在有效期内被频繁访问。
删除采用软删除加保留期的方式。软删除后文档进入可恢复状态，保留期按文档类型设定，例如制度类90天、操作类30天、参考类30天。保留期内由知识库管理员负责恢复操作，恢复后文档回到删除前状态并保留删除记录。保留期结束后执行清理，清理动作应记录删除人、删除时间和删除原因，便于事后追溯。
角色分工与各阶段交付物
规则落到人，才能被执行。文档负责人对内容准确性和有效期负责，是创建、更新、复核的主要执行者；评审人对评审意见负责，在约定时间内给出结论；知识库管理员负责发布、归档确认、删除审批和恢复操作，维护空间结构和权限；部门负责人负责指定评审人、确认制度类文档的归档与删除，并对本部门文档的整体有效性负责。
| 阶段 | 文档负责人 | 评审人 | 知识库管理员 | 部门负责人 | 交付物 |
|---|---|---|---|---|---|
| 创建 | 填写元数据、完成初稿 | — | 维护字段模板 | — | 草稿及完整元数据 |
| 评审 | 提交评审、处理意见 | 审阅并给出结论 | 跟踪超时评审 | 指定评审人 | 评审记录 |
| 发布 | 确认生效范围 | — | 执行发布、配置权限 | — | 发布记录 |
| 定期更新 | 执行复核、更新内容 | 按需复审变更 | 巡检到期文档 | 关注超期升级提醒 | 复核记录、新版本 |
| 过期归档 | 发起归档 | — | 确认归档、移入归档区 | 确认制度类归档 | 归档清单 |
| 删除与恢复 | 提出删除申请 | — | 审批、执行软删除与恢复 | 确认制度类删除 | 删除与恢复记录 |
规则本身的维护也需要明确责任。复核周期、提醒提前量、保留期等阈值由知识库管理员提出调整建议，部门负责人确认后生效，调整记录保留在规则说明中。建议每半年回顾一次规则执行情况，重点看超期文档比例、评审平均耗时和恢复请求数量，据此调整阈值，而不是等规则失效后再整体重写。
一个示例：制度类文档的完整生命周期规则
以下示例演示一份《费用报销管理制度》从创建到删除的规则组合，字段取值和审批节点可按团队实际调整。
创建阶段：文档负责人在知识空间中新建页面，文档类型选“制度类”，密级选“内部公开”，有效期设为12个月后，关联业务对象填写“财务制度”和对应流程编号，负责人填写财务部制度维护人。元数据不完整时无法提交评审。
评审阶段：提交后状态变为“待评审”，评审人由财务部门负责人指定，包括财务主管和一名业务部门代表。评审意见记录在页面的评审记录中，两位评审人确认后状态变为“评审通过”；若有意见未闭环，退回草稿，负责人修改后重提并说明处理情况。
发布阶段：知识库管理员确认生效日期和适用范围后发布，状态变为“已发布”，普通成员只读，内容变更由负责人发起新版本并重新评审。
定期更新阶段：到期前30天系统提醒负责人和部门负责人，负责人核对报销标准、审批流程和关联流程编号是否仍有效，确认后更新复核记录和下次复核日期；若标准调整，则产生新版本进入评审。
过期归档阶段：若超期未复核，文档标记为“已过期”，退出默认检索排序但保留访问；负责人确认被新版本替代后发起归档，管理员确认后移入归档区，形成归档清单记录。
删除与恢复阶段：旧版本归档满保留期后，管理员检查确认无其他文档引用，提交删除申请，部门负责人确认后执行软删除，保留90天；期间如有恢复请求，管理员执行恢复并记录原因。
异常情况需要预设处理规则。超期未复核时，按默认处置标记过期并升级提醒；负责人离职时，由部门负责人在离职交接中改派负责人，未改派的文档在巡检中列为异常，由管理员统一提交改派。这两类异常是文档增长后最常见的断点，规则中写明处理人和处理时限，才能避免文档长期悬空。
上线前的完成检查
规则设计完成后，逐项核对以下检查项，确认规则可执行再上线。
- 状态覆盖：六个阶段均有对应状态，状态之间的流转路径完整，没有文档停留在无责任人的中间状态。
- 字段完整：每个阶段的必填字段已定义，字段缺失时的拦截动作明确，字段模板在知识库中已配置。
- 责任到人：每个状态都有明确的责任角色，评审人、负责人、管理员的指定方式已写入规则。
- 退出标志：每个阶段都有可判断的完成标志，例如评审通过、复核记录更新、归档确认，而不是“处理完成”这类模糊表述。
- 到期与归档：提醒对象、提醒时间、超期默认处置已配置，并经过至少一轮试运行验证提醒能送达正确的人。
- 删除与恢复：软删除、保留期、恢复操作人和审批路径已明确，关联检查在删除前可执行。
- 分级有效：不同文档类型的管控强度有差异，且差异体现在评审要求和复核周期上，而非仅停留在文字说明。
- 调整机制：阈值和周期的调整责任人、确认方式、回顾频率已确定。
试运行阶段建议选取一个知识空间和一类文档先行验证，重点观察到期提醒是否触发、超期处置是否符合预期、恢复操作是否可完成。验证通过后再推广到其他文档类型，规则中的阈值也更容易在真实数据上校准。
常见问题
文档数量不多的小团队，需要一开始就上六阶段全套规则吗？
可以从简化版起步。建议先保留创建、发布、定期更新、归档四个环节，把负责人、文档类型、有效期三个字段设为必填，评审环节只对制度类文档强制。等文档数量增长、出现版本混乱或过期内容被误用时，再补上评审记录和删除恢复规则。规则的价值在于被执行，起步阶段状态和字段越少，越容易坚持。
文档负责人离职或转岗后，其名下文档怎么处理？
在离职或转岗交接流程中加入文档交接项，由部门负责人指定新的负责人，并在知识库中完成改派。规则中应写明交接时限，例如离职前完成改派。巡检时把无负责人或负责人已离岗的文档列为异常，由知识库管理员汇总提交部门负责人统一改派，避免文档长期悬空。
复核周期和保留期这类阈值应该由谁定、多久调整一次？
建议由知识库管理员提出阈值建议，部门负责人确认后生效，调整记录保留在规则说明中。调整频率可以每半年回顾一次，重点看超期文档比例、评审平均耗时和恢复请求数量。如果超期比例持续偏高，说明周期设置过紧或提醒对象不合适，应调整阈值而不是反复催办。
归档和删除的边界怎么判断，什么情况下不能直接删除？
归档用于文档不再作为现行依据但需要保留可查的情况，例如被新版本替代、业务已结束或超期未复核；删除用于草稿废弃、重复内容或明确无引用价值的文档。被其他文档引用为规范依据、仍在有效期内被频繁访问的文档，删除前必须做关联检查，确认无引用后再走审批。制度类文档的删除还需部门负责人确认。
规则上线后怎么验证提醒和超期处置真的生效？
建议选一个知识空间和一类文档先行试运行，观察到期提醒是否送达正确的负责人、超期后状态是否按默认处置变化、恢复操作能否完成。试运行至少覆盖一个完整的提醒周期，验证通过后再推广到其他文档类型。试运行中发现的阈值问题，在推广前完成校准。
