SEO顾问：项目结束后历史文档需要保留到什么粒度，先分清两类历史文档：决策记录与过程素材
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1e3e1e6e73c2.html
📄
SEO顾问：项目结束后历史文档需要保留到什么粒度，先分清两类历史文档：决策记录与过程素材
结论取决于一个前提：这份文档未来是否还要支撑“可复查的判断”。如果项目结束后你仍可能需要解释某个改动为什么发生、当时依据什么数据、谁批准了它，那么保留粒度至少要细到“单次决策可还原”；如果业务方向已经改变、页面已下线、渠道已迁移，且不再有人追问旧结论，那么只需保留结论摘要和交接清单即可。判断标准不是文档多少，而是未来出问题时，能不能凭它复现一次判断。
先分清两类历史文档：决策记录与过程素材
项目结束时的文档通常混在一起，实际价值差别很大。决策记录包括：某次改动的目标、判断依据、影响范围、执行时间和负责人。过程素材包括：中间抓取数据、草稿版本文档、会议记录、临时表格。粒度控制的关键，是把前者留全，把后者留薄。
一个可操作的区分方法是问：如果三个月后有人问“这个栏目为什么被合并”，现有文档能不能在不依赖当事人记忆的情况下回答。能，就说明决策记录粒度够用；不能，就说明缺的是决策层信息，而不是缺更多过程素材。
保留粒度可以按“能否复现一次判断”来定
对多数已有实际业务的项目，建议把历史文档分成三层，而不是笼统地“全部保留”或“只留结案报告”。
- 决策层：长期保留。每次重要改动的目标、依据、结论、执行时间、负责人。这一层是复查的入口，缺失后其他文档基本失去意义。
- 证据层：按需保留。支撑当次判断的关键数据快照、对照页面、审批记录。保留条件是：该结论未来可能被重新讨论，或涉及跨部门责任。
- 过程层：定期清理。中间草稿、重复导出、临时沟通记录。除非涉及合同或合规要求，否则不必长期占用管理精力。
这样分层的实际动作是：在项目结束前，由接手方按上述三层各抽一份样本，尝试还原一次旧判断。如果证据层缺失导致还原失败，就补录关键快照；如果过程层大量存在但从未被调用，就可以进入清理流程。这个动作的结果直接决定下一步：还原成功，说明粒度合适，可以按计划归档；还原失败，说明要回到决策层补记录，而不是继续堆素材。
什么情况下“只留结论摘要”反而更合理
有一种反例会推翻上面的建议：当项目的关键前提已经彻底变化，旧文档的细节不仅无用，还可能误导后续判断。例如业务线整体关停、目标站点已不再运营、渠道策略完全更换，此时继续保留细粒度过程数据，会让人误以为旧结论仍然适用。
判断前提是否彻底变化，可以看三点：旧结论依赖的页面是否还存在；当时的核心指标是否还有业务含义；是否还有人对旧决策负责。三点都不成立时，保留结论摘要、交接清单和必要的合规记录即可，过程素材可以按内部规定清理。这里要注意，请求量或抓取量归零本身不能单独证明“可以清理”，它也可能是统计口径变化、工具调整或短期波动造成的，需要结合上述三点一起判断。
一个注明假设的短例子
假设某业务在项目结束后更换了主要获客渠道，旧站点的内容页不再维护。此时若只保留“某栏目曾因转化偏低被合并”这一句结论，未来有人重新启用该栏目时，就无法知道当时的“转化偏低”是按什么口径、在什么时间窗口下得出的。反过来，如果该站点已整体下线、域名不再使用、也没有合规留存要求，那么保留到“栏目已合并”这一层通常就够。两种做法的分界，仍然是未来是否需要复现判断，而不是文档数量本身。
下一步动作：先做一次还原测试，再决定归档深度
项目结束后不要直接问“留多少”，而是先指定一名不参与原项目的人，随机挑一次旧改动，仅凭现有文档回答三个问题：当时为什么改、依据是什么、结果如何。能答上来，就按现有粒度归档，并标注哪些层可以定期清理；答不上来，就补决策层记录，再重新测试。这个动作的结果会直接改变后续归档范围：测试通过意味着可以收缩过程素材，测试失败意味着要先补关键依据，再谈清理。
