文档保留规则、归档策略和删除策略经常被放在同一套制度里讨论，却回答着不同的问题。保留规则规定文档必须留存多久、由谁批准提前处置；归档策略决定文档何时退出日常使用、以什么状态存放；删除策略则规定满足哪些条件后可以清除，以及清除前后如何核验留痕。本文按这三条线索梳理定义、边界与衔接方式，帮助判断一份文档当前该保留、归档还是删除。
要点总览（TL;DR）
- 文档保留规则回答“至少留到什么时候、谁有权提前处置”，是留存义务的约束底线；归档策略回答“何时退出日常使用”，是状态迁移；删除策略回答“满足什么条件可以清除”，是终点动作。
- 三者在生命周期中先后衔接：先按保留规则确定留存期限，使用频率下降后按归档策略转入低频访问区，保留期满且确认无审计、引用等约束后才进入删除评估。
- 归档不等于删除：归档后的文档仍然存在、可检索、通常可恢复，并继续受保留期限约束；删除进入清除流程，软删除可恢复，彻底删除不可逆。
- 冻结（只读锁定）与归档的区别在位置，版本留存与文档保留的区别在对象；版本清理只处理历史版本，不等于删除文档。
- 落地时用字段承载保留期限与到期提醒，让归档动作同步改变状态与权限，删除前保留评审记录与操作留痕，形成可追溯的处置链条。
一句话说清三者的关系
保留规则是约束底线，归档是状态迁移，删除是终点动作。三者串起来，构成文档从活跃使用到最终处置的完整链条。
具体来看，它们各自回答一个不同的问题：
- 文档保留规则回答“这份文档至少要留到什么时候、谁能决定提前处置”。它关注的是留存义务，来源可能是合同约定、审计要求、行业监管或内部制度。
- 归档策略回答“这份文档什么时候退出日常使用、转入低频访问区”。它关注的是使用状态的变化，文档本身仍然存在，只是不再出现在日常协作的主路径上。
- 删除策略回答“这份文档在什么条件下可以被清除、清除前要经过哪些核验”。它关注的是终点处置，是生命周期中最后一步。
在时间顺序上，一份文档通常先进入活跃使用，再依据保留规则确定留存期限；使用频率下降后按归档策略转入归档状态；保留期满且确认无其他约束后，才进入删除评估。三者的关系可以概括为：保留规则划定“不能早于何时处置”的红线，归档策略提供“退出活跃但尚未处置”的中间状态，删除策略执行“可以处置之后”的清除动作。归档不等于删除，删除也不能绕过保留期限。
文档保留规则的定义与边界
文档保留规则是一组关于留存义务的规定，核心是回答“留多久”和“谁有权改变这个期限”。它通常按文档类型、业务归属和合规要求分别设定，例如合同类文档留存至合同终止后若干年，项目结项文档留存至项目关闭后若干年，审计相关记录按监管要求留存。
一条完整的保留规则一般包含三个要素：
- 适用对象：规则覆盖哪些文档类型、哪些业务场景。对象划分越清晰，执行时越不容易漏判或误判。
- 保留期限：从哪个时间点起算、保留多长时间。起算点需要明确，例如以文档创建日、项目结项日还是合同终止日为准。
- 到期处置方式与审批：期限届满后是进入评估、延长保留还是允许清除；提前处置需要谁批准、留下什么记录。
保留规则有明确的边界。它规定留存义务，不规定文档存放在哪个目录、以什么状态存放、由哪个团队日常维护。这些属于归档策略和目录治理的范畴。它也与内容审核、研发基线管理分工不同：内容审核关注文档内容是否准确、是否可发布；研发基线管理关注需求、版本、变更等研发资产的一致性；保留规则关注的是文档作为记录需要保存多久。三者可能作用于同一份文档，但判断依据和责任人不同。
归档策略与删除策略各自解决什么问题
归档策略和删除策略都发生在文档生命周期的后段，但机制和触发条件完全不同。归档改变的是文档的使用状态，删除改变的是文档的存在状态。
归档策略：退出活跃，仍然可查
归档策略的核心是状态迁移。触发时点通常与业务节点相关，例如项目结项、合同履行完毕、文档连续一段时间无人访问。触发后，文档从日常协作区转入归档区，常见变化包括：编辑权限收紧为只读、从默认搜索结果中降权或单独归类、保留检索入口以便需要时调取。归档通常具有可恢复性，业务需要时可以申请恢复为活跃状态。需要强调的是，归档后的文档仍然受保留规则约束，归档不是处置，只是换了一个存放和使用方式。
删除策略：满足条件后的清除
删除策略的核心是终点处置。它的前置条件通常包括：保留期限已满、没有未结的审计或法务需求、没有被其他文档或流程引用、经过规定的审批或核验。删除本身还可以分层次：软删除是将文档移入回收站或待清除区，在一定期限内可以恢复；彻底删除则是不可逆的清除。删除策略需要明确这两层的界限、各自的保留时长以及谁有权执行彻底删除。删除是保留期满且无其他约束后的处置结果之一，另一条路径是延长保留。
| 对比维度 | 归档策略 | 删除策略 |
|---|---|---|
| 解决的问题 | 文档何时退出日常使用 | 文档何时可以被清除 |
| 触发条件 | 业务节点或使用频率下降 | 保留期满且无审计、引用等约束 |
| 文档状态 | 仍然存在，转为低频访问 | 移入待清除区或彻底清除 |
| 可恢复性 | 通常可申请恢复为活跃 | 软删除可恢复，彻底删除不可逆 |
| 与保留规则的关系 | 仍受保留期限约束 | 必须在保留期满后执行 |
容易混淆的相邻概念：归档、删除、冻结与版本留存
实际执行中的误操作，很多来自把相邻概念当成同一件事。下面这组对照可以帮助区分各自的判断标准。
| 概念 | 作用对象 | 核心变化 | 是否可逆 |
|---|---|---|---|
| 归档 | 文档整体 | 退出活跃使用，转入低频访问区 | 通常可恢复为活跃 |
| 删除 | 文档整体 | 移入待清除区或彻底清除 | 软删除可恢复，彻底删除不可逆 |
| 冻结（只读锁定） | 文档整体 | 禁止编辑，但仍处于日常访问位置 | 可解冻 |
| 版本留存 | 文档的历史版本 | 保留修改记录，供追溯与回滚 | 版本可查看、可回滚 |
归档与删除的差别在于可访问性和可恢复性：归档后的文档仍能被检索和调取，删除则意味着进入清除流程。冻结与归档的差别在于位置：冻结只是锁定内容不再修改，文档仍在日常协作区；归档则是整体迁移到低频访问区，通常同时伴随权限收紧。版本留存与文档保留的区别在于对象：版本留存管理的是同一文档的历史版本，文档保留管理的是文档本身要不要留、留多久。版本清理只删除过期的历史版本，不等于删除文档，两者不能互相替代。
一个具体例子：一份项目结项文档的处置过程
以下为演示情景，用一份项目结项文档说明三者如何先后衔接。
某项目完成验收并结项，项目组整理出一份结项报告和若干过程文档。第一步，按照保留规则确定留存年限：结项报告属于项目记录，制度规定自结项日起留存五年；过程文档中部分属于一般工作稿，留存两年。第二步，结项后文档从项目活跃空间转入归档区，编辑权限收紧为只读，项目成员仍可通过搜索找到并查阅，需要补充说明时由文档负责人申请临时恢复编辑。第三步，五年期满后，文档进入删除评估：确认没有未结的审计需求、没有被其他文档引用、没有法务保全要求，经文档负责人和知识管理员确认后移入待清除区，再经过一段观察期后彻底清除。
这个过程中有三个常见误解需要纠正。其一，把归档当删除：归档只是退出活跃使用，文档仍然可查，提前按删除处理会丢失记录。其二，把删除当归档：删除进入的是清除流程，软删除阶段尚可恢复，彻底删除后无法找回，不能把删除当作“先收起来再说”。其三，认为到期即自动清除：保留期满只是解除了留存义务，是否清除还要经过引用检查、审计确认和审批，到期与清除之间隔着一次评估。
把规则落到文档管理流程中的衔接方式
规则要真正起作用，需要落到文档管理系统的字段、状态和操作记录上。可以从四个方面衔接。
- 用字段承载保留期限：按文档类型设定保留期限和起算日字段，到期前设置提醒，让负责人提前判断是延长保留还是进入处置评估。字段值应来自制度，而不是每次临时填写。
- 让归档对应明确的状态和权限：归档动作应同时改变文档状态字段和访问权限，例如状态标记为“已归档”、编辑权限收回、检索入口保留。状态与权限同步变化，才能避免“标了归档却还能随意改”。
- 删除前留下评审记录：删除评估的结论、参与人、确认时间应作为操作记录保存，与文档关联。软删除与彻底删除分两步执行，观察期内保留恢复通道。
- 用操作留痕支撑追溯：谁在什么时候归档、恢复、申请删除、批准删除，都应有记录可查，便于事后审计和制度修订。
在工具层面，ONES Wiki 记录所有页面版本，支持随时查看与回滚，并支持为多种角色配置不同的读写权限，可用于承载归档时的权限收紧；误删除的页面可以从回收站恢复。文档通过页面树组织，配合搜索功能，归档后的内容仍可被检索到。需要说明的是，按文档类型配置保留期限、到期提醒以及自动归档状态流转，属于制度设计层面的安排，具体承载方式需结合组织实际使用的系统能力确认。对于研发资产类的留存与基线管理，ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，与知识文档的保留规则分属不同管理对象，不宜混用同一套期限标准。
常见问题
保留期限已满，文档是否会自动被删除？
保留期满通常只意味着留存义务解除，并不直接触发清除。到期后一般还要经过一次处置评估：确认没有未结的审计或法务需求、没有被其他文档或流程引用、经过规定的审批，才会进入删除流程。把“到期”和“清除”当成同一个动作，容易误删仍有引用价值的记录。制度设计上更稳妥的做法是到期前提醒负责人，由其在延长保留与进入处置评估之间作出判断。
文档已经归档，还需要遵守保留规则吗？
需要。归档改变的是文档的使用状态和存放位置，留存义务并不因此消失。归档后的文档仍处于保留期限内，不能因为“已经收起来了”就提前清除。反过来，归档也不延长保留期限，期限的计算仍按保留规则确定的起算点和年限执行。执行中常见的偏差是把归档区当成可以随意清理的角落，这与保留规则相冲突。
软删除和彻底删除应该如何划分权限？
软删除是把文档移入回收站或待清除区，在一定期限内可以恢复；彻底删除是不可逆的清除。两者风险不同，权限也宜分开：软删除可以开放给文档负责人等日常角色，彻底删除则应限定在少数管理员，并要求有评审记录。观察期的长度、谁有权在观察期内恢复、谁有权提前结束观察期，都应在删除策略中写明，避免出现“谁都能清空回收站”的情况。
版本留存和文档保留是一回事吗？
两者管理的对象不同。版本留存管理的是同一份文档的历史版本，目的是保留修改记录、支持追溯与回滚；文档保留管理的是文档本身要不要留、留多久。清理过期历史版本属于版本治理，文档本身仍在；删除文档则影响整份记录。实际执行中需要分别设定规则，不能用版本清理替代文档处置，也不能因为文档要长期保留就无限堆积所有历史版本。
在知识库工具中落地这套规则，重点看哪些能力？
可以重点看三类能力：一是能否用字段记录保留期限和起算日，并在到期前提醒；二是归档动作能否同步改变文档状态与访问权限，同时保留检索入口；三是删除前后的评审与操作能否留下记录，软删除与彻底删除能否分步执行。以 ONES Wiki 为例，它记录所有页面版本，支持随时查看与回滚，并支持为多种角色配置不同的读写权限，误删除的页面可以从回收站恢复，这些能力可用于承载归档时的权限收紧与删除后的恢复通道。按文档类型配置保留期限、到期提醒与自动归档状态流转，属于制度设计层面的安排，具体承载方式需结合组织实际使用的系统能力确认。
