文档归档的做法可以拆成一条可执行的链路：先划定范围、确定判定人和触发时点，再按统一规则核对引用、补全元数据、变更状态、移入归档区并收敛权限，最后用可检索性、可追溯性和权限三项检查验收，并纳入定期复核。本文聚焦知识文档生命周期末端的归档动作；研发资产基线归研发配置与基线管理，内容审核归知识审核与发布，不在本文展开。
要点总览（TL;DR）
- 归档前先定三件事：按内容过期、被替代、项目结束、长期无更新四类条件划定范围，由文档负责人提出、领域负责人确认，用定期清理与事件触发两种方式启动。
- 单份文档按五步操作：核对引用与替代关系、补全元数据、变更状态并冻结编辑、移入归档区并收敛权限、保留版本历史与原始链接指引。
- 角色分工固定为提出、确认、执行、使用四类，两次移交都要留记录，争议文档由领域负责人裁定。
- 归档是否合格用可检索性、可追溯性、权限三项检查判断，存在在用引用、元数据缺失或权限未收敛时不得视为完成。
- 归档后按季度或半年抽查归档区，处理误归档与遗漏，并把结果反馈到归档规则中。
归档前先定三件事：范围、判定人和时点
归档不是把旧文档随手挪走，而是一次有判定依据的状态变更。启动前先把三件事写清楚，后续操作才有统一口径：哪些文档进入归档、谁有权拍板、什么情况下触发。
按文档类型与状态划定归档范围
建议用四类条件圈定候选文档，满足其一即可进入归档评估：
- 内容过期：文档描述的流程、制度或产品能力已经失效，继续保留会误导读者。
- 被新版本替代：同一主题已有新版文档承接，旧版仅剩历史参考价值。
- 项目结束：项目结项后，过程性文档不再需要日常维护，但需保留以备追溯。
- 长期无更新：超过约定周期（例如12个月）无人维护、无人访问的文档，进入复核清单。
同时要明确排除项，避免把仍在使用的资料误归档：仍在被引用的参考文档、研发基线资产、处于待审核状态的内容，都不应进入归档流程。研发基线资产按配置管理规则处理，待审核内容应先走完审核与发布流程。
明确判定角色与触发方式
判定采用两级确认：文档负责人提出归档建议并说明理由，领域或团队负责人确认。前者最了解文档的使用情况，后者对领域内文档的整体有效性负责，两级确认可以降低误归档概率。
触发方式分两种，配合使用效果更稳：
- 定期批量清理：按季度或半年拉取长期无更新的文档清单，集中评估。
- 事件触发：项目结项、版本替换、制度废止等事件发生时，同步发起相关文档的归档。
这一节的产出是一份《归档范围与触发规则说明》，写清四类归档条件、三类排除项、两级判定人和两种触发方式。规则确定后，后续操作按同一口径执行，减少逐份讨论的成本。
归档操作步骤：从状态变更到移入归档区
规则确定后，单份文档的归档按五步推进。每一步都说明输入、动作、输出和完成标志，便于不同人执行时保持一致。
步骤一：核对当前版本与替代关系
输入：待归档文档及其关联文档清单。动作：确认文档当前版本是否为最新，是否已有新版本文档承接同一主题；检索站内引用，确认没有在用文档、流程或页面依赖它。输出：一份引用核对记录，注明替代文档（如有）。完成标志：无在用引用，或引用方已完成替换。
步骤二：补全元数据
输入：文档现有属性信息。动作：补齐标题、负责人、归档原因、归档日期、关联文档五项字段。归档原因写具体，例如“被《接口说明V2》替代”，而不是笼统写“过期”。输出：字段完整的文档属性。完成标志：五项字段无空缺，归档原因可被他人理解。
步骤三：变更状态并冻结编辑
输入：元数据完整的文档。动作：将文档状态变更为“已归档”，同时冻结编辑权限，防止归档后内容被继续修改。输出：状态为已归档的文档。完成标志：文档状态显示为已归档，普通成员无法编辑正文。
步骤四：移入归档区并收敛权限
输入：已变更状态的文档。动作：将文档移入归档区或归档目录，按领域或年份组织目录结构；权限调整为只读，敏感文档进一步缩小可见范围。输出：位于归档区、权限为只读的文档。完成标志：文档在归档区可被定位，非授权人员无法编辑，敏感内容仅对约定范围可见。
步骤五：保留版本历史与原始链接
输入：归档后的文档。动作：确认版本历史完整保留；对原位置留下的链接或入口，补充指向归档文档或替代文档的说明，避免读者遇到失效跳转。输出：版本历史可查、链接有指引的归档文档。完成标志：从原入口进入时能看到明确去向，历史版本可回溯。
在工具承载上，ONES Wiki 记录所有页面版本并支持随时查看与回滚，支持为不同角色配置读写权限，页面树可用于组织归档目录结构。归档状态与归档区的具体设置方式，以实际配置界面为准。
角色分工与各环节交付物
归档涉及提出、确认、执行、使用四类角色。把每个角色的动作和交付物固定下来，可以避免出现“有人提、没人确认”或“状态改了、目录没迁”的悬空环节。
| 角色 | 主要动作 | 交付物 | 交接节点 |
|---|---|---|---|
| 文档负责人 | 提出归档建议，核对在用引用，补全元数据 | 归档申请与引用核对记录 | 提交给领域负责人确认 |
| 领域或团队负责人 | 确认归档判定，处理争议文档 | 确认意见 | 确认后移交知识库管理员执行 |
| 知识库管理员 | 变更状态、迁移目录、收敛权限、维护归档区结构 | 归档完成的文档与目录记录 | 执行完毕后通知文档负责人复核 |
| 归档后的使用方 | 按需检索归档内容，必要时申请调阅 | 调阅申请或使用反馈 | 反馈至知识库管理员，作为复核输入 |
交接的关键在于两次移交：文档负责人把申请交给领域负责人，领域负责人把确认结果交给管理员执行。每次移交都应有记录，争议文档由领域负责人裁定，避免在管理员环节反复退回。
一个完整示例：旧版接口说明文档的归档
以下为演示情景，用于说明替代关系与跳转处理这两个关键动作，不代表真实客户案例。
背景：某系统接口升级到V2版本，团队编写了《接口说明V2》，旧版《接口说明V1》仍留在知识库中，部分新成员检索时先看到旧版，按旧参数调试导致返工。
判定：文档负责人核对后发现，V1仅被两份历史项目周报引用，当前无在用流程依赖，于是提出归档建议，注明替代文档为《接口说明V2》。领域负责人确认后同意归档。
操作：负责人补全元数据，标题改为《接口说明V1（已归档）》，归档原因填写“被《接口说明V2》替代”，归档日期按实际执行日填写，关联文档指向V2。管理员将状态改为已归档，冻结编辑，移入“接口文档—历史版本”目录，权限调整为只读。版本历史保留，原V1页面顶部补充一行指引：“本文档已归档，最新接口说明请查阅《接口说明V2》。”
结果：新成员检索“接口说明”时仍能命中V1，但页面顶部指引会将其导向V2；历史项目周报中的引用链接打开后能看到归档说明，不会误用旧参数。
可迁移的规律：替代关系要在元数据和页面指引中同时体现，只改状态不写去向，检索命中后读者仍可能误用；只写指引不改状态，文档仍可被编辑，归档就不彻底。两个动作需要一起完成。
归档完成检查：三项验收与定期复核
归档是否合格，用三项检查判断。任一项不通过，都不应标记为完成。
| 检查项 | 检查内容 | 通过标准 | 常见阻断项 |
|---|---|---|---|
| 可检索性 | 在知识库中搜索文档标题与关键词，确认归档文档仍能被命中 | 可搜到，且页面内有替代文档指引 | 移入归档区后搜索不到，或命中后无去向说明 |
| 可追溯性 | 查看版本历史、归档原因、归档日期、关联文档 | 版本历史完整，元数据字段无缺失 | 归档原因笼统、日期空缺、关联文档未填 |
| 权限 | 检查归档区权限与敏感文档可见范围 | 归档区为只读，敏感文档访问范围已收敛 | 仍可编辑，或敏感内容对全员可见 |
三项检查中，存在在用引用、元数据缺失、权限未收敛任一情况时，文档不得视为归档完成，应退回对应步骤处理。检查可由知识库管理员执行，文档负责人复核确认。
归档不是一次性动作，还需要维护机制。建议按季度或半年抽查归档区：检查是否有误归档的文档需要恢复，是否有应归档而未归档的文档被遗漏，归档目录结构是否仍然清晰。抽查结果反馈到归档规则中，规则随使用情况调整。ONES Wiki 的全局搜索可覆盖多种内容类型，附件内容也能被搜索触达，回收站支持恢复误删除页面，可作为归档后检索与纠错的辅助手段；归档内容是否默认纳入搜索范围，以实际配置为准。
常见问题
文档归档后还需要保留多久，什么时候可以彻底删除？
保留期限取决于文档的追溯需求和所在领域的合规要求，本文不给出统一年限。可执行的做法是：在归档元数据中记录归档原因与归档日期，按文档类型约定保留期，例如制度类、合同类通常需要更长保留期，过程性项目文档可按项目追溯周期设定。到期后先复核是否仍有引用或调阅需求，确认无需求再进入删除流程，删除前保留一份清单备查。
文档被误归档了，怎么恢复？
恢复动作与归档动作对称：先把状态从已归档改回正常状态，恢复编辑权限，再移回原目录或合适位置，并在元数据中注明恢复原因和日期。如果归档时原链接已改为指向归档区，恢复后要同步把链接改回。ONES Wiki 支持从回收站恢复误删除页面，可作为误删场景的补救手段；误归档属于状态与目录问题，按上述步骤处理即可。
归档文档还能被搜索到吗，会不会影响日常检索结果？
归档的目的之一是保留可追溯性，因此归档文档通常仍应可被检索到，但需要在页面内给出替代文档指引，避免读者误用。如果归档内容量大、干扰日常检索，可以把归档区放在独立目录下，检索时按目录范围过滤。ONES Wiki 支持多种类型搜索，附件内容也能被搜索触达；归档内容是否默认纳入搜索范围，以实际配置为准。
团队规模小、文档量不大，还需要这么完整的归档流程吗？
可以按比例简化，但三个环节建议保留：判定谁提出、谁确认；归档时写清归档原因和替代文档；归档后做一次可检索性与权限检查。文档量小时，定期清理的周期可以拉长，角色也可以由同一人兼任提出与执行，确认环节仍建议由另一位负责人承担，以降低误归档概率。流程简化的底线是归档后读者能找到替代内容、文档不再被随意修改。
归档和内容审核、研发基线管理怎么区分，边界在哪里？
归档处理的是知识文档生命周期末端的失效与留存，动作是状态变更、目录迁移和权限收敛。内容审核与发布处理的是文档对外可用前的质量把关，研发资产基线归研发配置与基线管理，按配置管理规则处理版本与基线。一份文档如果还在待审核状态，应先完成审核与发布再判断是否需要归档；研发基线资产不进入本文的归档流程。
