知识库文档从几十篇增长到几百上千篇后，靠个人记忆维护就会失效：同一主题出现多个版本、过期制度仍被引用、离职作者的文档无人接手、误删后找不到恢复入口。解决思路是把文档按创建、评审、发布、定期更新、过期归档、删除与恢复六个阶段管理，为每个阶段设定触发条件、责任人、必填字段和完成标志，再用统一元数据把各阶段串起来。下文给出可直接套用的规则设计方法。
要点总览（TL;DR）
- 把知识库文档划分为创建、评审、发布、定期更新、过期归档、删除与恢复六个阶段，为每个阶段定义进入条件、退出条件、责任人和完成标志，再用负责人、有效期、密级、关联业务对象、版本号五项公共字段把各阶段串起来。
- 创建阶段用模板固化必填字段，评审按密级和影响范围分级设置强度，评审结论只保留通过、修订、驳回三种并对应明确状态，评审记录须留痕。
- 发布后按文档类型分档设定有效期，到期前提醒负责人复审，复审必须做出续期、修订或转归档之一；负责人离职或长期无响应时，提醒升级到上级和知识管理员，超期无人认领转归档。
- 归档保留可查性、删除才真正移除内容，删除按密级分档审批，恢复统一走回收站并回到草稿状态重新确认元数据，归档、删除、恢复、权限变更四类操作纳入审计。
- 上线前先选一类文档试点，逐项核对字段与状态机、责任人、到期提醒与审批路径、全流程走查、审计与恢复能力、规则文档维护责任人六项，全部通过再扩大覆盖范围。
六阶段管控框架：先定状态与字段
生命周期管控的第一步是把文档从产生到退出的过程切成可识别的状态，并约定每个状态由什么条件进入、由什么条件离开。阶段划分过粗，规则就落不到具体动作上；划分过细，维护成本会超过收益。六个阶段是多数知识库在文档数量增长后能够稳定运行的粒度。
各阶段的进入与退出条件如下：
| 阶段 | 进入条件 | 退出条件 | 对应状态 |
|---|---|---|---|
| 创建 | 作者基于模板新建文档，填写必填字段 | 提交评审申请 | 草稿 |
| 评审 | 文档进入评审队列，评审人被指派 | 给出通过、修订或驳回结论 | 待评审 |
| 发布 | 评审通过且发布检查项全部满足 | 文档正式对目标读者可见 | 已发布 |
| 定期更新 | 距有效期到期进入提醒窗口 | 完成续期、修订或转归档 | 待更新 |
| 过期归档 | 文档失效且不再作为现行依据 | 转入归档区，保留检索入口 | 已归档 |
| 删除与恢复 | 归档满保留期或确认无保留价值 | 删除审批通过，或从回收站恢复 | 待删除 |
状态机的主干为：草稿→待评审→已发布→待更新→已归档→待删除。修订场景需要一条回退路径：待更新状态下选择修订，文档回到草稿并生成新版本号，原发布版本保留可查。这条回退路径要在规则中写明，否则修订会把历史版本覆盖掉。
公共元数据字段是贯穿六个阶段的连接件，建议至少包含五项：
- 负责人：对文档内容有效性负责的人，须为在职具体人员，不能只写部门。
- 有效期：文档作为现行依据的截止时间，到期触发复审。
- 密级：公开、内部、受限等分级，决定评审强度和可见范围。
- 关联业务对象：文档服务的流程、系统、项目或制度条款，便于影响分析。
- 版本号：与状态变更绑定，每次修订递增，历史版本可追溯。
字段设计的关键是让每个字段都有下游用途：负责人决定到期提醒发给谁，有效期决定何时提醒，密级决定谁参与评审，关联对象决定文档失效时通知哪些使用方。没有下游用途的字段应删掉，避免填写负担。
在工具层面，状态流转与版本记录需要有承载。ONES Wiki 记录所有页面版本并支持随时查看与回滚，页面组可关联项目，使文档与需求等业务对象互相对应，适合把“关联业务对象”和“版本号”两个字段落到实际页面上。到期提醒、审批流等自动化能力是否满足，需要在选型时按实际产品核验。
创建与评审阶段：谁写、谁审、审什么
创建阶段的管控目标是保证文档一出生就带着完整信息，评审阶段的管控目标是让有判断力的人在文档对外可见之前做出结论。两个阶段合起来构成知识库的入口闸门。
创建时的规则清单：
- 按文档类型选用固定模板，模板中预置必填字段和章节结构，作者只填内容不改结构。
- 负责人、有效期、密级、关联业务对象四项为提交评审的前置条件，缺一项不能提交。
- 草稿默认仅作者和协作者可见，避免半成品被检索到。
- 同一关联对象下已有同主题文档时，系统提示作者确认是新建还是修订，减少重复文档。
评审触发条件按风险分级设定，不必所有文档走同一强度：
| 触发条件 | 评审要求 |
|---|---|
| 密级为受限，或文档对外发布 | 领域负责人评审 + 合规审核人审核，双签通过 |
| 文档影响跨部门流程或关键业务对象 | 领域负责人评审，必要时增加使用方代表 |
| 普通内部操作说明、会议纪要类 | 领域负责人单人评审即可 |
评审角色分工：作者负责按模板成稿并响应意见；领域负责人判断内容是否正确、是否与现行做法一致；合规或知识管理员检查密级、格式、重复度和元数据完整性。评审结论只有三种，且必须对应明确状态：
- 通过：文档转为已发布，记录评审人和评审时间。
- 修订：文档退回草稿，作者按意见修改后重新提交，评审记录保留。
- 驳回：文档不再进入发布流程，状态标记为已驳回并说明原因，避免同一内容反复提交。
评审记录留痕要求写明三件事：谁在什么时间给出了什么结论，依据哪一版内容，附了哪些意见。留痕的作用在文档失效追责和后续复审时体现——复审人可以直接看到上一轮评审关注过什么。
ONES Wiki 提供页面模板库，可一键创建制式化文档模板，把必填字段和章节结构固化到模板中；同时支持为多种角色配置不同的读写权限，可用于区分作者、评审人和普通读者的操作范围。评审结论的强制卡点若需要审批流支撑，应结合产品实际能力确认实现方式。
发布与定期更新：有效期与复审节奏怎么定
文档发布后长期不更新，是知识库失效的主要来源。管控办法是给每篇文档设一个有效期，到期前自动提醒负责人复审，复审必须做出处置结论，不允许文档无限期停留在已发布状态。
发布前的检查项建议固定为五项：评审结论为通过；必填字段齐全且负责人为在职人员；密级与可见范围一致；关联业务对象已填写；文档内引用的其他文档均处于已发布状态。最后一项常被忽略，引用了一篇已归档文档的现行制度，等于把失效内容带进了新文档。
有效期按文档类型分档设定，分档依据是内容变化的速度：
| 文档类型 | 建议有效期 | 到期提醒提前量 | 通知对象 |
|---|---|---|---|
| 制度、规范、流程文件 | 12 个月 | 提前 30 天 | 负责人 + 领域负责人 |
| 操作手册、系统使用说明 | 6 个月 | 提前 15 天 | 负责人 |
| 项目交付类文档 | 随项目结项设定 | 提前 15 天 | 负责人 + 项目经理 |
| 参考性资料、行业摘录 | 24 个月 | 提前 30 天 | 负责人 |
表中的时长是起点值，组织应根据自身内容更新频率调整，并在规则文档中写明调整权限归知识管理员。
复审流程按四步执行：到期前提醒发出；负责人确认内容是否仍然有效；做出续期、修订或转归档三种处置之一；系统记录处置结果和处置时间。三种处置的判定标准要写清楚：内容无需改动、仅延长有效期的选续期；内容有实质变化的选修订，修订后走简化评审；文档已不代表现行做法、但仍有历史参考价值的选转归档。
无人认领文档的兜底处理是规则中最容易被跳过的一环。负责人离职或长期未响应时，提醒应升级通知其上级和知识管理员；升级后仍无响应的文档，由知识管理员统一标记为待更新并限制其在新文档中的引用，超过一个复审周期仍无人认领的，转入归档。兜底规则要事先公布，避免执行时引发争议。
到期提醒的自动化程度取决于所用工具。ONES Wiki 的树形结构与搜索功能便于按空间和目录组织文档、定位待复审内容，但到期自动提醒是否可配置提前量和通知对象，需在选型时核验；若产品暂不提供，可先用定期导出待复审清单、由知识管理员按清单催办的方式过渡。
过期归档、删除与恢复：如何避免误删和失控
文档退出使用后的处置，核心是把“不再现行”和“不再需要”分开处理。归档保留可查性，删除才真正移除内容，两者混用会导致两种失控：该留的被删掉，该清的长期占着检索结果。
归档与删除的判定区别：
- 归档：文档已不代表现行做法，但可能被追溯引用、审计调阅或作为历史依据。归档后内容保留，状态标记为已归档，默认不出现在常规检索和导航中，需要时可通过归档区或带状态条件的检索找到。
- 删除：文档内容错误且无保留价值、重复文档、测试残留等。删除须经审批，进入回收站后按保留期处理。
归档后的可见性策略建议写明三点：归档文档对普通读者默认隐藏，避免被误当现行依据；对审计、合规等角色保持可读；现行文档引用归档文档时给出提示，要求引用方确认。
删除的审批要求按密级分档：受限密级文档删除须经领域负责人和知识管理员双审批；普通文档由知识管理员审批即可。保留期与回收站机制绑定，具体天数以所用产品的实际设置为准，规则文档中应写明“以系统回收站保留期为准”，避免写入无法兑现的承诺。
恢复的规则要写清入口、权限和时限：恢复入口统一为回收站，普通作者只能恢复自己删除的文档，知识管理员可恢复全库文档；超过回收站保留期的删除不可恢复，因此高价值文档在删除前应先转归档而非直接删除。恢复后的文档状态回到草稿，需重新确认元数据后再发布，防止已失效内容被原样恢复上线。
审计记录覆盖归档、删除、恢复、权限变更四类操作，记录操作人、时间、对象和原因。审计记录的价值在争议发生时体现：一次误删是否走了审批、由谁批准、何时恢复，都能从记录中还原。
ONES Wiki 支持从回收站中恢复误删除页面，可作为恢复入口的承载；归档状态、操作审计日志等能力在现有资料中未明确说明，规则设计时应把它们列为选型核验点，并准备人工登记台账作为过渡手段。
角色分工与交付物：把规则落到人
规则能否执行，取决于每个阶段是否有人对输入和输出负责。用 RACI 形式把角色与阶段对齐，可以快速发现无人负责或多人重复负责的环节。
| 阶段 | 作者 | 领域负责人 | 知识管理员 | 合规审核人 |
|---|---|---|---|---|
| 创建 | R | C | A | I |
| 评审 | C | R | A | C（受限/对外文档） |
| 发布 | I | A | R | I |
| 定期更新 | R | A | C | I |
| 过期归档 | C | A | R | I |
| 删除与恢复 | I | C | R/A | I |
R 为执行、A 为最终负责、C 为被咨询、I 为被通知。表中知识管理员在多个阶段承担 A 或 R，实际执行时应控制其工作量，把格式检查、元数据核对等动作尽量前置到模板和字段校验中。
每阶段的输入、动作、输出与完成标志：
- 创建：输入为写作需求与模板，动作为成稿并填字段，输出为草稿，完成标志是必填字段齐全并提交评审。
- 评审：输入为草稿与评审人指派，动作为审阅并给出结论，输出为评审记录，完成标志是三种结论之一落定。
- 发布：输入为通过评审的文档，动作为执行发布检查，输出为已发布文档，完成标志是目标读者可见且元数据完整。
- 定期更新：输入为到期提醒，动作为复审并处置，输出为续期、修订或归档结论，完成标志是处置结果记录在案。
- 过期归档：输入为失效判定，动作为转归档并调整可见性，输出为已归档文档，完成标志是归档状态生效且审计记录生成。
- 删除与恢复：输入为删除申请或恢复请求，动作为审批与执行，输出为删除或恢复结果，完成标志是审批记录与操作记录一致。
跨角色交接用确认动作固定下来：评审通过由领域负责人在文档上留下结论，发布由知识管理员确认检查项，归档由知识管理员执行并通知负责人。交接不靠口头约定，靠状态变更和记录。
例外与豁免的申请路径要单独写明：因业务紧急需要先发布后评审的，由领域负责人书面申请、知识管理员登记，并在约定时限内补评审；有效期需要临时延长的，由负责人申请、知识管理员审批并记录原因。豁免记录本身也应纳入复审范围，防止豁免变成永久例外。
示例：一类制度文档的完整生命周期走查
以下为演示情景，用于说明规则如何串联运行，不代表真实客户案例。假设某组织新增一份《差旅报销管理办法》，密级为内部，关联业务对象为财务报销流程。
创建与评审。作者从制度模板新建文档，填写负责人为财务制度岗、有效期 12 个月、密级内部、关联财务报销流程，提交评审。因文档影响跨部门流程，触发领域负责人评审，财务负责人审阅后给出“修订”结论，指出报销标准与现行系统不一致。作者修改后重新提交，第二轮评审通过，评审记录保留两轮意见。
发布与到期复审。知识管理员执行发布检查，确认引用条款均为已发布状态后发布。11 个月后系统发出到期提醒，负责人复审后选择“修订”，更新报销标准并走简化评审，新版本发布，有效期顺延 12 个月。若该次复审发现制度已被新政策替代，则应选择“转归档”。
复审未通过后的归档。假设第二次复审时负责人判断该办法已被集团统一制度覆盖，选择转归档。文档状态变为已归档，从常规检索中隐藏，审计调阅时仍可读取，原引用该文档的其他制度收到提示，由各自负责人更新引用。
一次误删后的恢复。归档满保留期后，知识管理员发起删除并完成审批。两周后发现审计需要调阅该办法，知识管理员从回收站恢复，文档回到草稿状态，确认元数据后重新发布为历史参考版本，恢复操作记入审计记录。
走查暴露的规则缺口与调整。走查中通常会发现三类问题：一是引用关系没有在归档时自动提示，需要补充“归档前检查被引用情况”的前置动作；二是恢复后直接回到草稿，缺少“恢复原因”字段，应在恢复时强制填写；三是豁免申请没有到期时间，应给每条豁免设定复核日期。把这三项补进规则文档，再进入下一类文档的试点。
上线前的完成检查
规则设计完成后，先选一类文档试点，跑通状态流转与到期提醒，再逐步覆盖全库。上线前逐项核对以下清单，每项给出通过标准：
| 检查项 | 通过标准 |
|---|---|
| 字段与状态机配置完整 | 五项公共字段全部可填可查，六个状态及回退路径在系统中可实际流转 |
| 各阶段责任人已指定 | 试点文档的负责人、领域负责人、知识管理员均有名有岗，无空缺 |
| 到期提醒与审批路径测试通过 | 用测试文档模拟到期，提醒按提前量发出并送达正确对象；删除审批可走通 |
| 试点文档跑通全流程 | 至少一份文档完成创建到归档的完整流转，含一次修订和一次恢复 |
| 审计与恢复能力验证 | 归档、删除、恢复操作均有记录可查，回收站恢复在保留期内成功执行 |
| 规则文档的维护责任人明确 | 规则文档本身指定负责人和复审周期，变更走同一套评审流程 |
清单中任何一项未通过，都应先补齐再扩大覆盖范围。规则文档自身也是知识库文档，应纳入同一套生命周期管理，否则规则会先于文档失效。研发资产基线与内容审核标准细则属于其他管理主题，本文不展开，涉及时按各自规则衔接。
常见问题
文档数量还不多时，需要一次性把六个阶段的规则全部上线吗？
不必。规则的价值随文档数量增长而上升，文档较少时全量上线会带来明显的填写和审批负担。可行的做法是先上线公共字段和创建、评审两个入口阶段，把负责人、有效期、密级、关联业务对象四项填起来；等文档数量增长、开始出现过期制度和重复版本时，再启用有效期提醒与归档规则。分阶段上线的关键是字段先统一，后续阶段才能直接复用已有数据。
有效期到了但负责人判断内容仍然有效，可以直接跳过复审吗？
不建议跳过。到期复审的动作可以简化，但处置结论必须留下记录。内容无需改动时选择续期并顺延有效期，系统记录续期时间和操作人；直接跳过会让文档长期停留在已发布状态，下一次到期提醒失去依据，也无法判断这篇文档是否真的被人看过。若组织希望降低负担，可以把续期做成一次确认动作，但确认本身仍要留痕。
归档和删除的边界在实际操作中怎么把握？
判断标准是这篇文档是否还可能被追溯引用。审计调阅、历史依据、旧流程说明这类文档应转归档，内容保留、默认不出现在常规检索中；内容错误且无保留价值、重复文档、测试残留才走删除。拿不准时优先归档，因为归档可以随时再删除，删除超过回收站保留期后不可恢复。高价值文档在删除前先转归档，是成本较低的保险做法。
负责人离职后，其名下文档的到期提醒应该发给谁？
规则中要预设升级路径：提醒先发给负责人，无响应时升级通知其上级和知识管理员；升级后仍无响应的文档，由知识管理员统一标记为待更新并限制其在新文档中的引用，超过一个复审周期仍无人认领的转入归档。这条兜底规则应事先公布，并在负责人变更时同步更新文档的负责人字段，减少无人认领的情况。
ONES Wiki 能否直接支撑到期提醒和审批流？
ONES Wiki 在版本记录与回滚、角色读写权限、回收站恢复、页面模板库、树形结构与搜索、页面组关联项目方面有明确能力，可承载版本号、关联业务对象、模板约束和恢复入口等规则要素。到期自动提醒的提前量与通知对象、发布与归档的审批流、归档状态与操作审计日志，在现有资料中未明确说明，选型时应按实际产品核验。若暂不具备，可先用定期导出待复审清单、由知识管理员按清单催办，以及人工登记台账的方式过渡。
