整站优化服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /118f34cea0b0.html
📄
整站优化服务：项目结束后历史文档需要保留到什么粒度
结论先说：整站优化服务结束后，历史文档不应按“全部保留”或“全部清空”处理，而应按可追溯性分三层——决策依据长期保留，执行过程保留到下一次同类改动验收通过，中间产物和重复版本可以退出。判断粒度是否合适的标准只有一个：当关键前提发生变化时，接手的人能否不依赖原班人马的记忆，重新解释“当时为什么这样做”。
先分清三类文档，保留期限完全不同
整站优化服务的交付物通常混杂着三种性质不同的文档，混在一起讨论粒度只会得出“越多越安全”的假结论。
- 决策类文档：站点结构方案、栏目与模板的取舍理由、URL 规则的确定过程、重定向映射表。这类文档的价值在于解释因果，应长期保留，且必须与最终上线的版本对齐。
- 执行类文档：改版工单、模板替换记录、批量内容调整的批次说明、验收记录。它们的有效期通常到下一次同类改动完成为止，之后只保留结论，过程可以归档压缩。
- 中间产物：草稿方案、被否决的版本、临时导出的对照表、重复的截图。这类文件最容易堆积，也最容易在事后制造误读，除非涉及争议，否则不必长期保留。
粒度失控往往不是因为留得太少，而是因为三类文件没有分开命名和存放，导致真正需要追溯时反而找不到有效版本。
关键前提发生变化时，保留粒度必须跟着变
这是最容易出错的地方。整站优化服务交付时成立的前提，可能在一段时间后不再成立，此时沿用原来的文档粒度会直接误导决策。
如果变化发生在业务范围上——例如新增产品线、退出某个地区市场——原来的站点结构和栏目规划文档就从“决策依据”降级为“历史参考”。此时需要保留的是当时的判断条件，而不是当时的结论。具体动作是：在决策类文档顶部补一段前提说明，写清当时的业务边界是什么，然后把它移入历史区，不再作为当前方案的依据。这样做的结果是，新方案可以独立成立，不必反复解释“为什么和以前不一样”。
如果变化发生在技术栈或模板体系上——例如更换建站系统、重构前端模板——执行类文档的保留周期要缩短。旧工单对新技术栈没有复用价值，继续保留只会让人误以为还有未完成的改动。可操作的做法是：先确认新体系下同类改动已验收通过，再把旧执行文档整体归档，只留一份变更清单说明何时、因何退出。
如果变化只是人员更替，前提并未改变，那么保留粒度不需要调整，但可读性要求会上升。此时应检查决策文档是否写明了判断依据，而不只是记录结果。缺少依据的文档，即便完整保留，也无法支撑接手者做出同类决策。
一个假设例子：怎样判断粒度是否够用
假设某站点在整站优化服务结束后一年，需要再次调整栏目结构。团队翻出当时的文档，发现只有一份最终结构图，没有记录为什么放弃另一种分类方式。
这时会出现两种结果：要么重新做一轮论证，成本等于重复投入；要么直接沿用旧结构，可能延续已经过时的假设。两者都不是因为文档“太少”，而是因为保留的是结论而非依据。
对应的动作是：在这次调整开始前，先补一份前提对照，列出当时与现在的业务差异，再决定旧结构图是继续作为依据，还是转为历史参考。这个动作的结果会直接影响下一步——如果差异集中在业务范围，新方案需要重新论证；如果差异只在执行方式，旧结构图仍可复用，只需更新实现说明。
退出机制要写进交付约定，而不是事后清理
保留粒度的另一半是退出。整站优化服务收尾时，如果没有约定哪些文档在什么条件下可以退出，后续只会不断累积，直到没人敢删。
可行的做法是在交付时给每类文档标注退出条件，例如“本批次执行记录在新方案验收通过后可归档”“本对照表在重定向稳定运行一个周期后可退出”。这里的“稳定运行”需要结合自身监控能力定义，不能套用统一时长。
需要提醒的是，某些指标归零或流量结构变化，并不能单独证明某份文档已经失去价值。抓取量下降可能来自抓取预算调整，也可能来自站点结构简化，还可能是统计口径变化。把这类现象直接当作清理依据，容易误删仍在解释历史的材料。更稳妥的判断是回到文档本身：它是否还在支撑某个当前决策，是否还有人在引用。
最后一步是定期检查引用关系。如果一份决策文档长期无人引用，且其前提已被新文档覆盖，就可以降级为历史参考；如果仍被反复引用，说明粒度还不够，需要补充依据而不是继续保留结论。这个动作的结果决定了下一轮整理是压缩还是补全，也决定了历史文档最终是资产还是负担。
