SEO服务：项目结束后历史文档需要保留到什么粒度，先看验收单：它决定文档的最小保留粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bc5a9feed2d1.html
📄
SEO服务：项目结束后历史文档需要保留到什么粒度，先看验收单：它决定文档的最小保留粒度
结论是有条件的：如果项目结束后你仍可能接手同一站点的下一轮优化，历史文档至少应保留到“能独立复现一次关键决策”的粒度，即保留结论、依据和影响范围，而不是保留全部过程稿。如果站点即将下线、域名不再续费或团队整体转移且无人接手，这个结论失效，可以只留交接摘要。下面用可核对的证据帮你判断自己属于哪种情况。
先看验收单：它决定文档的最小保留粒度
最省事的判断起点不是文档目录，而是项目验收单或结项确认记录。如果验收单里写明了改动过的模板、URL规则、结构化数据字段或重定向规则，那么这些条目对应的历史文档必须保留到可复现粒度。反之，验收单只写了“完成站内优化”这类笼统描述，说明当时也没有把交付物固定下来，此时补留全部过程稿意义有限，优先补齐的是结论清单。
可复现粒度通常包含三样东西：改了什么、为什么改、影响哪些页面或模板。缺少第三样，下一轮接手的人无法判断改动是否与其他规则冲突，只能重新排查。
反常现象：文档越全，接手时反而越慢
很多团队结项时把会议记录、多版草稿、聊天截图全部归档，结果下一轮接手的人先花大量时间分辨哪版是最终版。这是与直觉相反的地方：保留量增加并不等于可复现性提高。证据在于，如果同一决策存在多个互相矛盾的版本，且没有标记生效版本和生效时间，检索成本会超过重做成本。
区分两种解释的方法是做一次抽查：随机取三条已归档的改动记录，看能否在十分钟内找到对应的生效版本和影响范围。能，说明粒度合适；不能，说明问题不是保留太少，而是缺少版本标记。此时的动作是给每份保留文档加一个状态字段，例如“已生效”“已废弃”“待确认”，并记录生效日期。做完这一步，再决定是否删除重复稿。
按接手可能性分档，而不是按文件类型分档
更实用的分档依据是“谁会再来动这个站点”：
- 同一团队继续维护：保留结论、依据、影响范围，过程稿可删。下一轮改动频繁，需要的是快速判断冲突，而不是回溯讨论过程。
- 移交给外部或新同事：在上一档基础上，补充术语说明和模板对应关系。接手人缺少站点背景，结论脱离上下文后容易被误用。
- 站点下线或不再维护：只留一页交接摘要，写明做过什么、遗留什么风险。此档不必保留过程稿。
假设一个例子：某站点结项后半年内计划改版导航。若历史文档只留了“调整过内链结构”这一句，改版时无法判断哪些链接规则是有意为之，只能全部重查；若留了改动清单加影响页面范围，就能直接对照新导航判断哪些规则需要迁移。这个例子只说明比较方法，不代表任何真实项目的效果。
用一次检索测试决定删还是留
具体动作是：在结项后一周内，让不参与原项目的人按文档回答一个具体问题，例如“某个模板的标题规则为什么是现在这样”。记录他找到答案所需的时间和是否找到。如果他能在合理时间内定位到结论和依据，说明当前粒度够用，可以删除重复过程稿；如果他只能找到讨论记录却找不到结论，说明需要补一份结论索引，而不是继续保留更多原始材料。
这个测试的结果会直接影响下一步：检索顺畅，就把删除重复稿列入结项收尾；检索受阻，就先把结论索引补齐，再谈精简。注意，检索耗时长短受文档命名习惯影响，不能单独用来证明保留粒度正确或错误。
会使结论失效的反例
如果项目结束后你无法确认站点是否还会被改动，例如所有权归属未定、预算未批、接手方未确定，那么“保留到可复现粒度”这个结论暂时失效。此时应保留全部材料并标记待定，直到归属明确后再按上面的分档精简。提前删除在归属不明时风险最高，因为一旦需要追责或排查，缺失的记录无法补回。
把上面的判断落成一步：先翻出验收单，圈出其中可核对的交付条目，再对每条问一句“下一轮改动时，别人能否只靠这份文档复现当时的决定”。能，就保留结论层；不能，就补影响范围再归档。这个动作做完，保留粒度自然就定了。
