文档保留规则、归档策略和删除策略经常被放在同一份制度里讨论，实际回答的是三个不同问题：文档要留多久、到期后放到哪里、哪些可以销毁。本文按知识文档的生命周期梳理三者的定义、边界与衔接方式，并说明它们和版本管理、权限管理的区别，帮助判断团队现有规则缺了哪一环。
要点总览（TL;DR）
- 文档保留规则回答“留多久、按什么条件留”，是设定保存期限与到期去向的规则层。
- 归档策略承接继续留存的文档，规定转入归档状态后的可见性、检索与恢复方式；删除策略承接到期销毁，规定可销毁对象、审批权限与留痕要求。
- 三者是同一生命周期上的规则、状态与动作：保留规则给出判断，归档与删除分别承接两条处置分支。
- 三者落地的前提是共用同一套文档分类与元数据口径，否则期限、归档条件与审批层级会互相矛盾。
- 保留期限到期只说明可进入处置流程，是否销毁仍需经过删除策略的评估与审批。
文档保留规则是什么：期限、条件与到期去向
文档保留规则回答的是“这份文档需要保存多长时间”。它按文档类别、业务价值或合规要求设定保存期限，是生命周期管理中的规则层。一条可执行的保留规则通常包含四个要素：适用范围、保留期限、起算时点和到期处置方向。缺少任何一项，规则都难以落地。
适用范围说明规则管哪些文档。常见做法是按文档类别划分，例如合同类、项目结项类、财务凭证类、日常会议记录类分别适用不同期限；也有团队按业务价值分级，把核心知识文档与临时协作文档区分开。范围写得越具体，执行时争议越少。
保留期限是规则的核心数值，通常以月或年为单位。期限长短取决于文档的用途：需要长期查阅的知识文档期限较长，过程性记录期限较短。期限本身应来自业务需要或外部合规要求，而不是凭习惯拍定。
起算时点决定期限从哪一天开始计算，这一点常被忽略却直接影响结果。同一份文档按创建日期起算、按最后修改日期起算、按所属项目关闭日期起算，到期时间可能相差数月甚至更久。项目类文档通常以项目关闭或结项为起算点，合同类文档以签署或履约结束为起算点，日常文档则以最后修改时间为起算点较为常见。团队应在规则中明确每类文档的起算口径，避免同一批文档出现多种算法。
到期处置方向是保留规则输出的结论。规则到期时通常有两种去向：继续留存或进入处置流程。继续留存意味着延长保留期或转入归档；进入处置流程意味着交由删除策略评估是否销毁。只写期限、不写去向的规则，到期后往往无人处理，文档要么被无限期搁置，要么被随意删除。
归档策略与删除策略各自管什么
归档策略处理的是“不再活跃但仍需继续留存”的文档。它规定文档在什么条件下转入归档状态或归档库，以及归档后如何控制可见性、如何检索、如何恢复。归档的核心动作是状态转换：文档从日常协作空间移出，访问频率降低，但内容完整保留，需要时仍可查回。归档后的文档通常设为只读，避免在低关注状态下被误改。
删除策略处理的是“可以销毁”的文档。它规定可销毁对象的范围、审批权限、执行方式和留痕要求。可销毁对象一般包括保留期已满且无继续留存价值的文档、重复或无效的草稿、明确不再需要的临时材料。审批权限回答由谁批准销毁，常见做法是按文档类别设定审批层级。执行方式说明是单份删除还是批量清理。留痕要求则保证销毁动作可追溯，包括销毁时间、执行人、审批记录和销毁清单。
归档与删除是两种不同的处置结果。归档意味着文档继续存在，只是退出活跃使用；删除意味着文档被销毁，内容不再保留。把归档当作删除的委婉说法，或者认为删除前必须先归档，都是对两者边界的混淆。实际制度中可以设计“先归档、后评估删除”的路径，但归档本身不产生销毁效果。
| 维度 | 文档保留规则 | 归档策略 | 删除策略 |
|---|---|---|---|
| 回答的问题 | 留多久、按什么条件留 | 放到哪里、以什么状态保存 | 哪些可以销毁、由谁批准、如何执行 |
| 作用层次 | 规则层 | 状态与存放设计 | 授权与操作规范 |
| 主要输出 | 期限与到期去向判断 | 归档状态、可见性与恢复路径 | 销毁清单、审批记录与执行留痕 |
| 典型执行角色 | 制度制定者与文档责任人 | 文档管理员 | 审批人与执行人 |
三者的联系：一条生命周期上的规则、状态与动作
保留规则、归档策略和删除策略不是三套独立制度，而是同一生命周期上的三个环节：保留规则是上游判断依据，归档策略和删除策略是下游的两条处置分支。
流程上，文档进入生命周期管理后，先由保留规则根据类别、价值和合规要求给出判断：继续保留，或者可处置。判断为继续保留的文档，由归档策略承接，转入归档状态或归档库，按归档规则控制可见性与检索方式。判断为可处置的文档，由删除策略承接，进入销毁评审，按审批权限决定是否执行删除。到期后的衔接方式常见有两种：一种是先归档、在归档状态下继续观察一段时间再评估删除；另一种是到期直接进入删除评审，评审通过后销毁。选择哪种方式取决于文档价值和合规要求，高风险文档更适合前一种。
三者能够衔接的前提是共用同一套文档分类与元数据口径。保留规则按类别设定期限，归档策略按类别决定归档条件，删除策略按类别确定审批层级，如果三处对“项目结项文档”的定义不一致，规则之间就会互相矛盾。团队在制定制度时，应先统一文档分类体系和关键元数据，例如文档类型、所属项目、责任人、创建与关闭时间，再分别编写三份规则。
在工具层面，这套衔接需要文档系统提供分类与元数据管理、状态区分和操作留痕。ONES Wiki 支持通过页面树组织项目文档与知识信息，并提供搜索能力，便于按分类查找文档；页面版本可随时查看与回滚，误删除页面可从回收站恢复；同时支持为多种角色配置不同的读写权限。对于需要长期沉淀的产品需求、技术文档、项目规范、操作说明和复盘记录，这些能力可以承载文档分类、状态区分和访问控制等管理动作。保留期限设置、到期提醒、归档状态与删除审批等环节，需要团队结合自身制度在流程上另行约定。
和版本管理、权限管理的区别
版本管理关注同一份文档的历史版本留存与回溯。它解决的是“这份文档改过哪些内容、能否回到某一版”的问题，作用对象是单份文档内部的版本序列。保留规则关注的是文档整体的存续期限，即这份文档本身还要不要留在系统里。两者作用层次不同：版本再多，也不影响文档整体的保留期限；保留期限再长，也不替代版本记录。ONES Wiki 记录所有页面版本并支持回滚，属于版本管理范畴，与保留期限的判断是两件事。
权限管理关注谁能看、谁能改。它规定不同角色对文档的读写范围，作用贯穿文档的整个存续期。归档策略会改变文档状态与可见范围，例如归档后设为只读、缩小访问人群，但归档策略本身不定义权限体系，而是调用已有的权限机制来实现归档后的访问控制。删除策略中的审批权限同样依托权限管理，但审批权限回答的是“谁有权批准销毁”，与“谁能查看文档”是两个不同的问题。
此外，文档保留规则不负责内容审核与发布，也不负责研发资产基线。内容审核决定文档能否发布、内容是否准确；研发资产基线管理的是研发过程中需要受控的配置项。这些工作各有自己的规则体系，不应与保留期限混在同一份制度里。
一个具体例子与常见误解
以下为演示情景，用于说明三者如何配合，不代表任何产品的实际配置。
某团队规定项目结项文档保留3年，起算时点为项目关闭日期。项目关闭后，文档进入保留期，期间保持正常可查。满3年时，保留规则输出“可处置”结论。团队选择先归档：文档转入归档状态，设为只读，仅项目负责人和文档管理员可查。归档满一年后，文档进入删除评审，由部门负责人审批，审批通过后执行删除，并记录销毁清单、审批人和执行时间。整个过程中，保留规则给出期限和去向，归档策略承接继续留存阶段，删除策略承接最终销毁环节。
常见误解有三类。第一类是把归档当成删除的替代说法，认为“归档了就等于处理完了”。归档只是状态转换，文档仍然存在，仍需按保留规则继续管理。第二类是认为保留期限一到就必须删除。期限到期只说明可以进入处置流程，是否销毁还要经过删除策略的评估与审批，价值仍高的文档可以延长保留或继续归档。第三类是只设期限不设到期去向，规则到期后没有明确的下一步，文档要么被无限期搁置，要么被个人随意清理。补齐到期去向，是让保留规则真正可执行的关键一步。
常见问题
保留期限到期后，文档一定要删除吗？
不一定。期限到期只说明文档可以进入处置流程，是否销毁还要经过删除策略的评估与审批。价值仍然较高的文档可以延长保留期，或者转入归档继续保存。把到期直接等同于删除，会让仍有查阅价值的文档被过早清理。
归档和删除可以合并成一步处理吗？
两者处置结果不同，合并处理会模糊边界。归档是状态转换，文档继续存在，只是退出活跃使用并通常设为只读；删除是销毁，内容不再保留。制度上可以设计“先归档、后评估删除”的路径，但归档本身不产生销毁效果，删除前是否必须归档取决于团队对文档价值和合规要求的判断。
团队规模不大，三份规则都需要单独写吗？
规则可以写在同一份制度里，但三部分内容要分别交代清楚：保留规则写明适用范围、期限、起算时点和到期去向；归档策略写明归档条件与归档后的访问方式；删除策略写明可销毁对象、审批人和留痕要求。小团队可以简化审批层级，到期去向这一项建议保留，否则规则到期后没有明确的下一步。
文档分类口径不统一会带来什么问题？
保留规则按类别设定期限，归档策略按类别决定归档条件，删除策略按类别确定审批层级。如果三处对同一类文档的定义不一致，例如“项目结项文档”在保留规则里包含复盘记录、在删除策略里不包含，就会出现期限已到但审批范围对不上的情况。制定制度前先统一文档类型、所属项目、责任人、创建与关闭时间等关键元数据，三份规则才能衔接。
起算时点为什么会影响保留规则的实际效果？
同一份文档按创建日期、最后修改日期或项目关闭日期起算，到期时间可能相差数月甚至更久。项目类文档通常以项目关闭或结项为起算点，合同类文档以签署或履约结束为起算点，日常文档以最后修改时间为起算点较为常见。规则中不写明起算口径，同一批文档就会出现多种算法，到期提醒和处置评审也难以对齐。
