制定文档保留规则，核心是把文档类型、保留等级、期限、处置动作和责任人一一对应起来，形成可查表执行的规则。本文按盘点类型、划分等级、明确角色、写入字段、示例填写、试运行检查的顺序展开，帮助团队产出一套能落地、能复核的文档保留规则。
要点总览（TL;DR）
- 制定文档保留规则的核心动作是：盘点文档类型、划分保留等级、确定期限与到期处置、明确角色分工，最后写入文档字段并试运行检查。
- 保留等级控制在三到五级，每级对应明确的期限区间和归档、移交、销毁、续期四类处置动作，销毁与续期需设审批。
- 规则要可执行，需把保留等级、到期日期、责任人、处置状态做成文档元数据字段，并在创建或评审环节完成标注。
- 上线前选一个文档类型较全的部门试运行一个完整周期，观察等级标注完成率和到期处置及时率，再决定是否全量推行。
- 规则本身设季度或年度复核，在组织调整、合规要求变化、新增文档类型时触发更新，重点补上临时文档和责任人交接两类遗漏。
先盘点文档类型，确定保留规则的作用范围
保留规则的第一步是划定范围：哪些文档纳入保留管理，哪些文档由其他机制处理。范围不清，后续的等级和期限就没有稳定的适用对象。盘点时按用途划分文档类型，比按部门划分更容易形成通用规则，因为同一类文档在不同部门的使用周期往往接近。
常见的知识文档类型包括：制度规范类（管理办法、流程文件）、操作手册类（系统操作说明、作业指导书）、会议纪要类、项目过程文档类（计划、周报、评审记录）、培训材料类，以及复盘与经验总结类。每类文档的产生频率和使用周期差异明显，例如会议纪要产生频率高、集中查阅期短，制度规范产生频率低但需要长期可查。
盘点需要区分知识文档与相邻管理对象的边界。研发资产基线（如代码基线、构建产物、配置项）由配置与基线管理机制负责，内容审核与发布流程解决的是文档能否对外可见的问题，两者都不属于保留规则的处理范围。保留规则处理的是知识文档在存续期间保留多久、到期如何处置。
盘点的输出是一份文档类型清单，每类文档记录五项信息：类型名称、主要用途、产生频率、典型使用周期、当前存放位置。这份清单同时是后续等级划分的输入，也是检查规则覆盖是否完整的对照表。
| 文档类型 | 主要用途 | 产生频率 | 典型使用周期 | 当前存放位置 |
|---|---|---|---|---|
| 制度规范 | 约束流程与行为 | 低，按修订节奏 | 长期，随版本更新 | 知识库制度目录 |
| 操作手册 | 指导具体操作 | 中，随系统变更 | 中长期，至系统下线 | 知识库产品目录 |
| 会议纪要 | 记录决策与待办 | 高 | 短期，待办关闭后查阅减少 | 项目空间或部门目录 |
| 项目过程文档 | 支撑项目执行与复盘 | 高 | 中期，项目结束后仍需复盘 | 项目页面组 |
| 培训材料 | 新人培养与技能传递 | 低至中 | 中期，随课程更新 | 知识库培训目录 |
划分保留等级并确定期限与到期处置
保留规则的核心判定逻辑是用等级对应期限和处置动作。等级数量控制在三到五级即可，过多会增加标注负担，过少则无法区分差异。一种常见设计是长期、中期、短期、临时四级，分别对应不同的保留期限区间和到期动作。
期限设定依据通常来自三个方面：业务上仍需要查阅的周期、外部合规或审计要求、实际使用频率。三者冲突时以更严格者为准，并在规则中写明例外审批方式。例如某类合同相关文档业务上两年后很少查阅，但合规要求保留更长时间，就按合规要求设定，同时注明依据来源，便于后续复核时判断是否仍然适用。
到期处置动作应明确为归档、移交、销毁、续期四类之一。归档指移入归档区继续保存但退出日常检索范围；移交指转交其他责任主体保管；销毁指按审批流程删除；续期指经审批延长保留期限。销毁和续期都需要审批，避免到期文档被默认无限期保留，也避免误删仍有价值的文档。
规则表建议包含五个字段：保留等级、适用文档类型、保留期限、到期处置方式、审批人。填写完成后，任何人拿到一份文档，都能通过类型查到等级，通过等级查到期限和处置动作。
| 保留等级 | 适用文档类型 | 保留期限 | 到期处置方式 | 审批人 |
|---|---|---|---|---|
| 长期 | 制度规范、核心操作手册 | 长期保存，随版本更新 | 旧版本归档，现行版本续期 | 部门负责人 |
| 中期 | 项目过程文档、培训材料 | 项目结束或课程下线后保留一定周期 | 归档或移交 | 知识管理负责人 |
| 短期 | 会议纪要、例行报告 | 待办关闭后保留一个较短周期 | 归档，到期后销毁 | 文档所有者提出，部门负责人审批 |
| 临时 | 草稿、一次性通知 | 用途结束后短期保留 | 销毁 | 文档所有者确认 |
明确角色分工与各环节交付物
规则能否运行，取决于每个环节是否有人负责、有交付物可查。角色设计不必复杂，但要覆盖制定、执行、审批三类职责，并让每个角色知道自己交什么。
规则制定者通常由知识管理负责人承担，负责起草规则文档、组织讨论、维护等级表。审批者由部门负责人或合规岗承担，负责批准规则本身以及销毁、续期等例外处置。文档所有者是每份文档的创建人或维护人，负责在创建或评审时标注保留等级与到期时间。归档执行人负责按清单执行归档操作，销毁审批人负责审核销毁申请，两者可以由同一人兼任，但审批与执行应分离。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 知识管理负责人 | 起草与维护保留规则，组织复核 | 规则文档、等级期限表、复核记录 |
| 部门负责人或合规岗 | 审批规则与例外处置 | 规则审批记录、销毁或续期审批单 |
| 文档所有者 | 标注等级与到期时间，发起处置申请 | 等级标注记录、处置申请 |
| 归档执行人 | 按清单执行归档与移交 | 归档清单 |
| 销毁审批人 | 审核销毁申请并留档 | 销毁审批单 |
角色分工要落实到具体人名或岗位，避免只写部门名称。文档所有者离职或转岗时，需要有一条交接规则：由接手人继承文档所有者职责，或由知识管理负责人临时接管，直到指定新所有者。
把规则写进文档字段与操作流程
规则写在制度里只是第一步，要让它可执行，需要把保留等级、到期日期、责任人、处置状态作为文档元数据字段，并嵌入创建、评审、归档的操作流程。字段设计的原则是少而必填，字段过多会导致标注率下降。
建议增加的字段包括：保留等级（从规则表的等级中选）、到期日期（按等级和创建时间推算）、责任人（默认为文档所有者）、处置状态（在用、待归档、已归档、待销毁、已销毁）。其中保留等级和到期日期应在文档创建或首次评审时完成标注，评审环节作为检查点，未标注等级的文档不通过评审。
到期提醒与归档操作的触发方式需要提前约定。可以由知识管理负责人按季度导出到期清单，分发到各文档所有者确认；也可以在知识库工具中设置提醒。ONES Wiki 支持页面版本记录与回滚、按角色配置读写权限，并可通过页面树组织文档、将页面组关联项目，适合承载文档类型目录和归档区；保留等级、到期日期等字段的设置与筛选方式，需结合所选工具的实际能力确认后再写入操作流程。
规则文档本身也应有固定结构，便于执行和复核。建议包含：目的与适用范围、保留等级与期限表、角色职责、到期处置流程（含审批路径）、字段说明、复核周期与更新触发条件。规则文档使用模板库创建，可以保证每次修订结构一致。
示例：一份部门级文档保留规则表
以下示例以一个产品部门的四类知识文档为例，展示规则表如何填写。示例中的期限为演示设定，实际制定时应结合本组织的业务需要与合规要求调整。
| 文档类型 | 保留等级 | 保留期限 | 到期处置 | 责任人 | 判定理由 |
|---|---|---|---|---|---|
| 产品操作手册 | 长期 | 长期保存，随版本更新 | 旧版本归档，现行版本续期 | 产品文档负责人 | 用户和内部支持长期查阅，系统存续期间均需可查 |
| 项目复盘记录 | 中期 | 项目结束后保留两年 | 归档 | 项目经理 | 后续同类项目需要参考，两年后查阅频率明显下降 |
| 周例会纪要 | 短期 | 待办全部关闭后保留六个月 | 归档，到期后销毁 | 会议组织人 | 主要用于跟踪待办，待办关闭后查阅需求低 |
| 临时通知与草稿 | 临时 | 用途结束后保留一个月 | 销毁 | 文档创建人 | 一次性信息，无长期参考价值 |
这张表体现了几个判定要点：期限与用途直接相关，而不是按文档重要程度笼统设定；处置动作区分了归档和销毁，归档保留可查性，销毁释放空间；每类文档都有明确责任人，便于到期时找到确认人。迁移到自己场景时，先替换文档类型，再逐类填写判定理由，理由写不清楚的类型说明范围还需要进一步拆分。
试运行与完成检查
规则定稿后先在小范围试运行，再全量推行。试运行范围建议选择一个文档类型较全、人员配合度较高的部门或项目组，运行一个完整周期，观察两个指标：等级标注完成率（已标注等级的文档数占应标注文档数的比例）和到期处置及时率（按期完成归档或销毁的文档数占到期文档数的比例）。标注完成率偏低说明字段或流程负担过重，及时率偏低说明提醒机制或责任分工需要调整。
试运行结束后，用以下清单逐项检查规则是否可执行、无遗漏：
- 文档类型清单是否覆盖了组织内实际产生的知识文档，临时文档和草稿是否纳入；
- 每个保留等级是否都有对应的期限和处置动作，等级与期限是否一一对应、无空缺；
- 每个角色是否落实到具体岗位或人名，文档所有者离职后的交接是否有安排；
- 元数据字段是否可维护，标注是否在创建或评审环节完成；
- 销毁与续期是否有审批路径，审批记录是否留存；
- 规则文档是否包含复核周期和更新触发条件。
复核周期建议按季度或按年设定，并在组织架构调整、合规要求变化、新增文档类型时触发规则更新。常见遗漏有两类：一是临时文档未纳入规则，导致草稿和一次性通知长期堆积；二是责任人离职后无人接手，到期文档无人确认处置。试运行阶段把这两类问题暴露出来，比全量推行后再补救成本更低。
常见问题
保留期限和合规要求冲突时怎么处理？
以更严格的一方为准，通常是合规要求。比如某类文档业务上两年后很少查阅，但合规要求保留更长时间，就按合规要求设定期限，同时在规则表中注明依据来源和适用条件。这样后续复核时能判断该要求是否仍然适用，避免期限被无依据地延长或缩短。
如果合规要求本身存在解释空间，建议在规则中写明例外审批方式，由合规岗或部门负责人对具体文档作出判定并留档，而不是让文档所有者自行决定。
临时文档和草稿要不要纳入保留规则？
建议纳入，至少单独设一个临时等级。草稿、一次性通知这类文档产生频率高，如果不设规则，容易长期堆积在知识库中，检索时干扰正式文档。临时等级可以设定较短的保留期限和销毁处置，由文档创建人确认后执行。
纳入的方式不必和正式文档一样重，可以只要求标注等级和到期时间，简化审批环节，降低标注负担。
文档所有者离职或转岗后，到期文档由谁处置？
需要在规则中提前写明交接安排。常见做法是由接手人继承文档所有者职责，在交接清单中一并移交文档的等级标注和到期信息；如果暂时没有接手人，由知识管理负责人临时接管，直到指定新的所有者。
试运行阶段可以把责任人离职后的文档单独列出来检查，确认到期时能找到确认人。这一项也是完成检查清单中的必查内容。
保留等级和到期日期这类字段，在知识库工具里怎么落地？
落地方式取决于所选工具。ONES Wiki 支持页面版本记录与回滚、按角色配置读写权限，并可通过页面树组织文档、将页面组关联项目，适合承载文档类型目录和归档区（依据 F1、F2、F5）。保留等级、到期日期等字段的设置与筛选方式，需结合所选工具的实际能力确认后再写入操作流程。
如果工具暂不支持自定义字段，可以先用规则表加季度导出到期清单的方式过渡，由知识管理负责人分发到各文档所有者确认，保证规则先运行起来。
规则运行一段时间后，什么情况下需要修订？
建议设定固定复核周期，按季度或按年检查一次，同时设置触发条件：组织架构调整、外部合规或审计要求变化、新增了原来没有覆盖的文档类型、试运行指标持续偏低。出现这些情况时启动修订，而不是等到规则明显失效再改。
修订时重点核对等级与期限是否仍与业务需要匹配，以及责任人是否仍然在岗。修订后的规则文档保留版本记录，便于追溯每次调整的理由。
