知识库文档数量增长后，常见的问题从“找不到文档”变成“不知道哪份文档还能用”：同一主题存在多个版本，负责人离职后无人更新，过期资料仍被当作依据。解决思路是把文档从创建到归档拆成六个状态——创建、评审、发布、定期更新、过期归档、删除与恢复，为每个状态定义进入条件、负责人、必填字段和完成标志，再借助状态字段、到期提醒和归档规则把流转固化到知识库中。下文按“定类型与字段、定状态动作、定角色、跑通示例、建运行机制、上线核对”的顺序展开，ONES 文档管理可作为承载状态与权限的落地工具之一。
要点总览（TL;DR）
- 把文档生命周期拆成创建、评审、发布、定期更新、过期归档、删除与恢复六个状态，每个状态定义进入条件、退出条件、负责人和完成标志，流程才有可执行的骨架。
- 设计顺序是：先按用途划分文档类型并确定必填元数据，再逐状态写清输入、动作、输出和完成标志，然后分配角色职责，最后用提醒、批量复核和归档清理让规则持续运转。
- 元数据是流转的判断依据：复审周期为空不允许发布，关联项目已关闭的文档在下次复审时进入归档判断，状态字段取值统一才能统计和批量处理。
- 复审到期提醒要设提前量和升级路径，超期未处理升级至部门主管；归档与清理按固定周期执行，执行前公示清单。
- 上线前用检查清单逐项核对状态覆盖、负责人、字段校验、提醒与归档配置、删除审批与恢复演练，任一断点都会让流程停在无人处理的状态。
生命周期管控的核心框架：六个状态与四条规则
生命周期管控的实质，是让每份文档在任何时刻都处于一个明确的状态，并且知道下一步该由谁做什么。六个状态构成主干，四条规则约束流转，状态字段则是把规则写进系统的载体。
六个状态的进入与退出条件如下表所示。进入条件回答“什么情况下文档算进入该状态”，退出条件回答“满足什么才能离开”。
| 状态 | 进入条件 | 退出条件 | 默认负责人 |
|---|---|---|---|
| 创建 | 有人发起文档并填写必填元数据 | 内容完成初稿，提交评审 | 文档负责人 |
| 评审 | 草稿已提交且指定评审人 | 评审通过，或退回修改 | 评审人 |
| 发布 | 评审通过且发布检查项全部满足 | 复审到期，或内容被判定失效 | 文档负责人 |
| 定期更新 | 到达复审周期或触发事件（如流程变更） | 完成更新并重新发布，或确认仍有效 | 文档负责人 |
| 过期归档 | 文档被判定不再适用，或长期未完成复审 | 经审批删除，或恢复为发布状态 | 知识库管理员 |
| 删除与恢复 | 归档文档超过保留期或经审批删除 | 恢复成功，或保留期结束彻底清除 | 知识库管理员 |
支撑这套流转的四条规则分别是：元数据规则，规定每类文档必须填写哪些字段，字段值决定后续走哪条路径；角色规则，规定每个状态下谁有权操作、谁负责推动；时效规则，规定复审周期、保留期和提醒时点；归档与恢复规则，规定归档触发条件、归档后的可见性以及恢复路径。四条规则缺一条，流程就会出现断点，例如只有时效规则没有角色规则，到期提醒发出后无人响应。
状态字段是流程落地的关键。把上述六个状态做成文档上的一个可选字段，配合负责人、复审日期等字段，就能在知识库中按状态筛选、统计和批量处理。字段取值应使用固定选项，避免“已发布”“发布完成”“正式版”混用导致统计失真。
第一步：定义文档类型与必填元数据
不同用途的文档，失效速度和评审要求差别很大，用一套规则覆盖全部文档，要么规范类文档评审过重，要么会议纪要无人复核。设计流程的第一步是按用途划分文档类型，再为每类定义必填字段。
常见的划分方式包括：规范与制度类，变更少但影响面大，复审周期可设为半年到一年；操作手册类，随产品或流程变化，复审周期可设为季度；方案与设计类，与具体项目绑定，项目结束后进入归档判断；会议纪要与周报类，时效性强，可设较短复审周期或到期直接归档。团队可按自身文档构成增减类型，关键是每类都有明确的复审周期和归档去向。
每类文档的必填字段建议包含以下几项：
- 文档负责人：对该文档内容和时效负责的人，须为具体个人而非部门。
- 创建日期与最近复审日期：用于计算复审到期时间。
- 复审周期：按文档类型给出默认值，允许负责人按需调整并说明理由。
- 密级或可见范围：决定发布后的访问权限。
- 关联项目或业务域：便于按项目聚合文档，也便于项目结束时批量触发归档判断。
字段如何决定流转路径，体现在几个具体判断上：复审周期为空或超长的文档不允许发布；密级为受限的文档在评审环节必须增加对应权限的评审人；关联项目已关闭的文档在下次复审时默认进入归档判断而非直接续期。字段命名与取值需要统一，例如状态字段统一使用“草稿、评审中、已发布、待复审、已归档”五个选项，日期字段统一格式，避免同一含义出现多种写法。
第二步：为每个状态设定准入、动作与完成标志
框架确定后，需要把六个状态逐一拆成可执行的动作。每个状态说清四件事：输入是什么、谁做什么、产出什么、什么算完成。
创建
由文档负责人发起，从模板创建可减少字段遗漏。创建时须填写文档类型、负责人、复审周期、密级和关联项目，状态标记为草稿。完成标志是必填字段齐全且初稿内容成形。草稿应默认仅对负责人和协作者可见，避免未完成内容被误引用。
评审
评审人由文档类型决定：规范类文档由部门主管或领域负责人评审，操作手册由实际使用岗位的代表评审。评审意见记录在文档评论或评审记录中，逐条标注处理结果。通过标准应事先写明，例如“无未解决的反对意见，且关键步骤经使用方确认”。完成标志是评审结论明确为通过或退回，退回则回到草稿状态。
发布
发布前检查项包括：必填字段完整、评审结论为通过、密级与可见范围一致、关联项目有效。发布后按密级设置可见范围，状态改为已发布，并记录发布时间和本次复审到期日。完成标志是文档对目标读者可见且状态字段已更新。
定期更新
复审周期按文档类型设定，到期前一段时间发出提醒。负责人收到提醒后做判断：内容需要修改则更新并重新走评审发布；内容仍有效则确认续期，更新最近复审日期。完成标志是复审结论被记录，文档要么重新发布，要么带着新的复审日期继续有效。
过期归档
归档触发条件包括：负责人判定文档不再适用、复审到期后超过宽限期仍未处理、关联项目已关闭且无延续需求。归档后文档移出默认检索范围，但保留在归档区可查，供追溯使用。完成标志是状态改为已归档且归档原因被记录。
删除与恢复
删除须经知识库管理员审批，确认无合规留存要求后执行。保留期按团队要求设定，保留期内删除的文档可从回收站恢复；保留期结束后彻底清除。恢复路径应明确：误删文档由管理员从回收站恢复并还原状态，已归档文档需要重新启用时，恢复为发布状态并重新设定复审日期。
第三步：角色分工与交付物
流程无人推动，通常是因为角色边界模糊。四类角色各管一段，职责不宜重叠。
| 角色 | 主要职责 | 关键动作 | 交付物 |
|---|---|---|---|
| 文档负责人 | 对内容质量和时效负责 | 创建、更新、提交评审、处理复审提醒 | 文档内容、复审结论 |
| 评审人 | 对内容准确性和适用性把关 | 评审、提出意见、给出通过或退回结论 | 评审记录与结论 |
| 知识库管理员 | 维护规则运行和库内秩序 | 配置字段与提醒、执行归档与删除审批、处理恢复 | 归档记录、删除审批单、规则修订记录 |
| 部门主管 | 对管辖范围内的文档体系负责 | 指定负责人、处理角色缺位、参与批量复核 | 负责人名单、复核决议 |
审批权限按动作分配：发布由评审人放行，归档由负责人提出、管理员执行，删除由管理员审批。角色缺位时需要代理机制，例如负责人离职时由部门主管在约定时间内指定接替人，超期未指定则由管理员将该文档列入待复审清单并通知主管。升级机制同样要写明：复审提醒发出后超过宽限期未处理，自动升级通知部门主管。
在工具层面，ONES Wiki 支持为多种角色配置不同的读写权限，可将评审人、负责人和管理员的编辑与审批边界对应到页面权限上；页面组可关联项目，便于按项目聚合文档并判断归档时机。
示例：一份操作手册的完整生命周期
以下为演示情景，用于说明字段填写与流转判断，不代表真实案例。
创建。某团队需要一份《数据导出操作手册》。负责人小李从模板创建页面，填写：类型为操作手册，负责人小李，复审周期三个月，密级为内部，关联项目为数据平台二期，状态为草稿。初稿完成后提交评审。
评审。评审人指定为实际使用该功能的运营同事小张。小张在文档中提出两条意见：导出步骤缺少权限申请前置说明；截图与当前界面不一致。小李修改后再次提交，小张确认通过，评审记录中标注两条意见均已处理。
发布。发布前检查：字段完整、评审通过、密级为内部且可见范围设置为数据平台相关人员。状态改为已发布，复审到期日设为三个月后。
定期更新。三个月后提醒发出。小李核对后发现导出界面改版，步骤需要调整，于是更新内容并重新走评审发布，复审到期日顺延。第二次到期时内容无变化，小李确认续期，仅更新最近复审日期。
过期归档与恢复。数据平台二期结束后，该手册对应的功能下线，小李将文档标记为不再适用，管理员执行归档并记录原因。半年后旧功能因兼容需求短暂恢复，管理员将文档从归档区恢复为发布状态，重新设定复审日期，供临时查阅。
第四步：用提醒、复核与归档规则让流程持续运转
规则设计完成后，靠人工记忆维持运行不可持续。需要把提醒、复核和清理做成固定节奏。
复审到期提醒应提前发出，提前量按复审周期长短设定，周期短的提前一周，周期长的提前两周到一个月。提醒对象首先是文档负责人，超期未处理再升级至部门主管。提醒内容应包含文档名称、到期日和建议动作，减少负责人重新查找信息的成本。
定期批量复核建议按月或按季度组织。管理员导出待复审和已超期文档清单，按部门分发，部门主管在固定时间窗口内组织负责人集中处理。批量复核的好处是把分散的提醒变成有截止时间的集体动作，避免个别文档长期悬置。
归档与清理按固定周期执行，例如每季度一次：将超期未复审且无延续需求的文档归档，将超过保留期的已删除文档彻底清除。执行前应公示清单，给负责人最后一次申辩机会。
流程运行需要观察几个数据点：过期未复审文档数量及其占比、平均复审处理时长、归档文档数量与被恢复次数、删除审批的平均耗时。这些指标能反映规则是否过严或过松，例如过期未复审数量持续偏高，可能是复审周期设置不合理或负责人负担过重。
规则本身也需要修订机制。建议每半年回顾一次文档类型划分、复审周期默认值和提醒提前量，根据运行数据调整，修订记录由管理员留存。ONES Wiki 记录所有页面版本并支持查看与回滚，规则文档自身的变更也可追溯；页面模板库可把标准字段和结构固化到模板中，减少每次创建时的重复填写。
完成检查：流程上线前的核对项
上线前逐项核对以下清单，全部满足再正式推行。
- 六个状态是否覆盖团队全部文档类型，每类文档是否都有对应的复审周期和归档去向。
- 每个状态是否都有明确的负责人角色，且负责人为具体个人而非部门。
- 元数据字段是否必填、取值是否统一，状态字段选项是否互斥且完整。
- 复审提醒是否已配置，提醒对象、提前量和升级路径是否明确。
- 归档规则是否已配置，归档后文档的可见范围是否符合预期。
- 删除是否有审批环节，保留期是否明确，恢复路径是否经过一次演练。
- 角色缺位时的代理与升级机制是否写入规则文档。
- 是否安排了上线后的首次批量复核时间和运行数据回顾周期。
清单中任何一项无法确认，都意味着流程存在断点。例如提醒已配置但升级路径未定，超期文档就会停留在无人处理的状态。上线后第一个复核周期结束时，用运行数据做一次复盘，再决定是否调整周期和字段，流程才算真正进入稳定运行。
常见问题
文档数量不多时，也需要完整的六个状态和角色分工吗？
可以按规模裁剪，但裁剪的是环节的正式程度，不是环节本身。文档量少时，评审可以由负责人直接请一位同事确认，不必设固定评审人名单；批量复核可以并入季度例会；归档和删除可由同一人兼任。需要保留的是每个状态有明确负责人、有复审日期、归档后仍可查这三件事，否则文档增长后仍要回头补规则。
复审到期后负责人一直不处理，流程上应该怎么兜底？
在规则里预设两级兜底：提醒发出后超过宽限期仍未处理，系统或管理员将文档列入超期清单并通知部门主管；再超过一个约定周期，由管理员按规则将文档转入过期归档，归档原因记录为“复审超期未处理”。这样文档不会长期停留在已发布状态被继续引用，负责人也可以在归档后申请恢复并重新设定复审日期。
归档和删除的边界怎么划，哪些文档必须保留？
归档表示文档不再作为现行依据，但保留可查，用于追溯历史决策和旧流程；删除表示文档不再需要保留。涉及合同、审计、合规留存要求的文档，应在归档时标注保留期限，到期后经管理员审批再删除。删除前确认无留存要求，保留期内可从回收站恢复；保留期结束后彻底清除。团队应把不可删除的文档类型写进规则，避免执行时逐份讨论。
状态字段和复审提醒在知识库工具里怎么落地？
把六个状态做成文档上的固定选项字段，配合负责人、复审日期、关联项目等字段，就能按状态筛选和批量处理。ONES Wiki 支持为多种角色配置不同的读写权限，可将评审人、负责人和管理员的编辑与审批边界对应到页面权限上；页面组可关联项目，便于按项目判断归档时机；页面模板库可把标准字段和结构固化到模板中，减少创建时的字段遗漏。复审提醒的具体配置方式需以实际产品环境为准。
流程上线后，用什么数据判断规则是否合理？
重点看四个指标：过期未复审文档数量及占比、平均复审处理时长、归档文档数量与被恢复次数、删除审批平均耗时。过期未复审数量持续偏高，通常说明复审周期过短或负责人负担过重；恢复次数偏多，说明归档判断过于激进。建议每半年结合这些数据回顾一次文档类型划分、复审周期默认值和提醒提前量，并把修订记录留存。
