知识库里的过期文档，处置方式取决于它今天还有没有参考价值、内容是否仍然准确、组织是否负有留存义务。内容仍准确但适用场景已结束的，更新后保留或归档；内容已失效但需要留痕的，归档并标注失效原因；内容错误、重复且无留存义务的，按审批流程删除。把“识别—判定—处置—复核”固定成流程，并明确每类文档的负责人和留存期限，才能避免过期内容继续被检索到、被误用。
要点总览（TL;DR）
- 过期文档先看三个维度：内容是否仍准确、是否还有参考价值、组织是否负有留存义务，再决定更新、归档还是删除。
- 内容主体有效但局部滞后的走更新，修订后重设复审日期；已不适用但需留痕的走归档，标注失效原因与替代文档；内容错误、重复且无留存义务的走删除，删除前审批并备份。
- 流程按“识别—判定—处置—复核”四步运行，每步都有输入、动作、输出和完成标志，按季度或半年执行一轮。
- 文档负责人做内容判定，知识库管理员执行归档与删除并维护记录，业务审核人审批归档与删除，三类交付物汇入同一份处置记录。
- 处置完成后用检查清单核对：判定记录完整、归档可检索、删除有审批与备份、更新有版本、复审周期已设定、无主文档清零。
先判定：过期文档分三类处置
“过期”只说明文档超过了设定的复审日期或适用场景已经变化，并不直接等于该删除。判定时同时看三个维度：内容准确性，即文档描述的方法、参数、流程是否仍与当前实际一致；参考价值，即是否还有人需要查阅它理解历史决策或旧版本行为；留存义务，即合同、审计、合规或内部制度是否要求保留该文档及其版本。三个维度组合后，落到更新、归档、删除三类动作。
更新适用于内容主体仍有效、只是部分信息滞后的文档。典型情况是操作步骤基本可用，但截图、联系人、系统入口或参数需要替换。更新后文档回到有效状态，并重新设定复审日期。归档适用于内容已不再适用于当前业务，但仍有查阅或留痕价值的文档，例如已下线系统的操作手册、已完成项目的方案记录。归档时保留原文，标注失效原因、失效时间和替代文档。删除适用于内容错误会误导读者、与其他文档重复、且组织没有留存义务的文档。删除前需确认没有外部引用依赖，并保留审批记录。
| 判定维度 | 更新 | 归档 | 删除 |
|---|---|---|---|
| 内容准确性 | 主体准确，局部信息滞后 | 内容已不适用于当前场景 | 内容错误或严重误导 |
| 参考价值 | 当前仍被使用，需要继续维护 | 有历史查阅、追溯或培训价值 | 无查阅需求，或已被其他文档完整覆盖 |
| 留存义务 | 无特殊要求 | 合同、审计、合规或制度要求留痕 | 确认无留存义务 |
| 处置动作 | 修订内容，更新版本，重设复审日期 | 移入归档区，标注失效原因与替代文档 | 提交审批，备份后删除 |
判定时容易出现的偏差是把“很久没访问”直接当成删除依据。访问量低可能说明文档入口太深、搜索不到，也可能说明它只在特定阶段被需要。访问数据应作为线索，最终结论仍要回到内容准确性和留存义务。另一个偏差是只由文档作者一人判断，作者离职或转岗后文档无人认领，过期状态会长期悬置。判定环节需要明确责任人，这一点在角色分工部分展开。
处置流程：从识别到复核的四步操作
把判定规则变成固定动作，关键是每一步都有输入、动作、输出和完成标志，避免“想起来才清理”。流程按季度或半年运行一次，文档量大时可以按月分批处理。
第一步：识别过期文档
输入是知识库的文档清单、每篇文档的复审日期、最近访问记录和关联项目状态。动作是筛出三类候选：复审日期已过的文档；关联项目已结项或系统已下线的文档；长期无访问但仍在对外提供入口的文档。输出是一张待处置清单，包含文档标题、负责人、过期原因和关联对象。完成标志是清单中的每篇文档都有明确负责人，没有无主文档。
第二步：做出判定
输入是待处置清单和判定表。动作由文档负责人核对内容准确性，确认是否存在替代文档，再判断是否负有留存义务；涉及删除或归档的，提交业务审核人确认。输出是每篇文档的判定结论和理由，理由要具体到“系统已于某月下线”“参数已由新版本替代”这类事实，避免只写“已过期”。完成标志是清单中每篇文档都有结论，且删除、归档项已获得审批。
第三步：执行处置
更新的动作是修订正文、替换截图与链接、更新版本说明，并在文首或属性中记录本次修订时间和下次复审日期。归档的动作是把文档移入归档目录或标记为归档状态，在文首注明失效原因、失效日期和替代文档链接，同时保留原有版本记录。删除的动作是先导出或备份待删文档及其版本，再执行删除，并在处置记录中登记审批人、删除时间和备份位置。完成标志是三类动作都在系统中留下可查的状态或记录，归档文档仍可被检索到。
第四步：复核与记录
输入是处置记录和更新后的知识库。动作是抽查归档文档是否标注清楚、删除文档是否有审批与备份、更新文档是否重新设定了复审日期；同时确认没有文档在处置后处于“无人负责”的状态。输出是一份本轮处置小结，记录处理数量、各类处置占比和遗留问题。完成标志是小结归档，遗留问题有责任人和处理时限。
角色分工与各环节交付物
过期文档处置最容易卡在“谁来拍板”。把职责拆成三个角色，每个角色只对一类判断负责，流程才能稳定运行。文档负责人最了解内容，业务审核人对业务影响和合规要求负责，知识库管理员负责操作与记录。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 文档负责人 | 核对内容准确性，提出更新、归档或删除建议，完成更新修订 | 判定理由、修订后的文档、新的复审日期 |
| 知识库管理员 | 维护文档清单与复审日期，组织定期识别，执行归档与删除操作，维护处置记录 | 待处置清单、归档目录、处置记录、备份记录 |
| 业务审核人 | 审批归档与删除，确认留存义务和替代文档是否充分 | 审批意见、留存期限要求 |
文档负责人应由熟悉该文档所描述业务的人担任，并在文档属性中登记，人员变动时同步移交。知识库管理员不替负责人做内容判断，只对流程完整性和记录质量负责。业务审核人可以按文档类型分工，例如操作手册由对应系统负责人审核，合同相关文档由法务或合规角色审核。三类角色的交付物最终汇入同一份处置记录，便于后续审计和复盘。
当知识库承载在 ONES Wiki 中时，这些角色动作有对应的承载点：文档实时同步并记录所有页面版本，支持随时查看与回滚，更新和归档时不必担心覆盖原内容；误删除的页面可从回收站恢复；权限控制支持为不同角色配置读写权限，便于把归档区设为只读、把删除操作限定在管理员范围；树形结构与全局搜索让归档文档仍可被检索到。复审日期提醒、自定义文档状态和删除审批是否支持，需以实际产品版本核验，流程设计上可以先用手工清单和定期会议补足。
示例：一份过期操作手册的处置过程
以下为演示情景，用于说明判定与处置如何落地，不代表真实客户案例。某团队知识库中有一份《旧版订单系统操作手册》，复审日期已过八个月，最近半年访问量很低。手册对应的订单系统已于三个月前下线，新系统上线后另有一份《新订单系统操作手册》。
按判定表逐项核对：内容准确性方面，手册描述的是已下线系统的菜单和流程，与当前操作不一致；参考价值方面，仍有少量历史订单查询和旧数据核对场景需要参考旧系统字段含义；留存义务方面，财务对账制度要求保留旧系统操作说明以备追溯。三项组合的结论是归档，而非更新或删除。更新没有意义，因为系统已不存在；删除则违反留存要求。
处置动作由文档负责人执行：在手册文首添加说明，写明“对应系统已于某月下线，仅供历史查询参考”，并链接到新系统手册；知识库管理员将文档移入“已下线系统”归档目录，保留原有版本记录；业务审核人确认归档结论和留存期限。处置记录中登记了判定理由、审批人、归档日期和替代文档。可迁移到其他文档类型的规律是：系统或项目结束后，先看是否还有追溯需求，有则归档并写清失效边界，没有则进入删除审批；仍在使用的文档则走更新，并重新设定复审日期。
完成检查：处置是否到位
一轮处置结束后，用下面的清单逐项核对，确认流程闭环而不是只完成了“清理动作”。
- 判定记录完整：每篇过期文档都有判定结论和具体理由，没有只写“过期”或“无用”的空泛记录。
- 归档可检索：归档文档仍在知识库中可被搜索到，文首标注了失效原因、失效日期和替代文档。
- 删除有依据：删除项均有审批记录，删除前已备份，备份位置可查。
- 更新有版本：更新后的文档保留了修订记录，版本说明写清改了什么。
- 复审周期已设定：更新后保留的文档和新增文档都设定了下次复审日期，并有负责人。
- 无主文档已清零：待处置清单中的每篇文档都能对应到具体负责人。
- 遗留问题有归属：本轮未处理完的文档记录了责任人和处理时限。
检查中发现的问题应回到对应步骤修正，而不是在清单上打勾了事。连续几轮都出现同类问题，例如归档文档总被再次误用，说明归档区的入口和标注方式需要调整，可以在下一轮流程中一并优化。
常见问题
文档访问量很低，是不是就可以直接删除？
访问量低只能作为线索，不能单独作为删除依据。访问少可能说明文档入口太深或搜索不到，也可能说明它只在特定阶段被需要，例如旧系统下线后的历史订单核对。判定时仍要回到内容准确性和留存义务：内容错误且无留存义务的才进入删除审批；仍有追溯价值的应归档并标注失效边界。
归档和删除的审批应该由谁来做，能不能由文档负责人自己决定？
建议把内容判断和处置审批分开。文档负责人最了解内容，负责提出更新、归档或删除建议并写明理由；归档与删除涉及留存义务和对外引用，应由业务审核人确认，例如操作手册由对应系统负责人审核，合同相关文档由法务或合规角色审核。知识库管理员只对流程完整性和记录质量负责，不替负责人做内容判断。
归档后的文档还需要继续维护吗？
归档文档不再随业务变化更新，但需要保持可检索、标注清楚。归档时在文首注明失效原因、失效日期和替代文档链接，并保留原有版本记录。如果后续出现新的追溯需求，或替代文档本身发生变化，应重新评估归档说明是否仍然准确，必要时补充说明，而不是让归档区变成无人查看的角落。
一轮处置做完，怎么判断流程真的闭环了？
用检查清单逐项核对，而不是只看清理数量：每篇过期文档是否有具体判定理由，归档文档是否仍可搜索到并标注失效原因，删除项是否有审批和可查的备份位置，更新文档是否保留修订记录并重设复审日期，待处置清单中是否还有无主文档。检查发现的问题应回到对应步骤修正；同类问题连续出现，说明归档区入口或标注方式需要调整。
在 ONES Wiki 中承载这套流程，哪些环节可以直接落地，哪些需要额外配置？
ONES Wiki 会实时同步并记录所有页面版本，支持随时查看与回滚，更新和归档时不必担心覆盖原内容；误删除的页面可从回收站恢复；权限控制支持为不同角色配置读写权限，便于把归档区设为只读、把删除操作限定在管理员范围；树形结构与全局搜索让归档文档仍可被检索到。复审日期提醒、自定义文档状态和删除审批是否支持，需以实际产品版本核验，流程设计上可以先用手工清单和定期会议补足。
