搜索优化服务项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /efc125017f3a.html
📄
搜索优化服务项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度不由“项目结束了”决定，而由这些文档未来是否还要支撑同一批页面的持续维护决定。如果站点仍由原团队运营、页面结构基本不动，保留到“能复现一次改动决策”的粒度即可；如果站点要交接、改版或迁移，则要保留到“新人能独立判断某个页面为什么长这样”的粒度。前者可以精简，后者必须完整。
一个常见矛盾：文档越全，反而越没人看
项目收尾时经常出现两种相反的做法。一种是把所有过程稿、会议记录、草稿版本全部归档，结果文件夹庞大、命名混乱，接手的人翻半小时也找不到关键结论。另一种是只留最终报表和交付清单，看似干净，但半年后页面流量下滑，没人说得清当初为什么选这个栏目结构、为什么删掉那批旧链接。
这两种做法都不算错，问题在于它们默认了同一个前提：文档的用途只有一种。实际上，历史文档至少要承担两类用途——证明交付完成和支撑后续决策。粒度该定在哪，取决于你更需要哪一类。
两种解释：是“留得不够”还是“留得不对”
当团队觉得历史文档没用时，通常有两种解释，需要分开判断。
解释一：留得不够。关键决策没有留下依据。比如只记录了“调整了标题写法”，却没记录调整前后的对照、判断标准和影响范围。这种缺失会在下一次改版时暴露：新人只能凭感觉重做一遍，甚至把已经验证过的错误方案再试一次。
解释二：留得不对。信息其实都在，但组织方式跟使用场景脱节。过程稿按日期堆叠，而维护者需要的是按页面或按栏目查找。结果就是“有文档等于没文档”。
区分这两种解释的证据很直接：让一个没参与项目的人，仅凭归档材料回答一个具体问题，例如“这个栏目页的正文结构为什么从列表改成了分栏”。如果他找不到任何依据，是留得不够；如果他能找到相关材料但花了很长时间才定位，是留得不对。这个测试比主观评价“文档全不全”更可靠。
按后续用途决定粒度：三个层次
与其争论“要不要留”，不如按后续用途把粒度分成三档，对号入座。
- 决策级（最粗）：只保留影响页面长期形态的结论，例如栏目划分、主要模板结构、重要页面的定位变化。适合站点稳定、原团队继续维护的情况。
- 改动级（中等）：在决策级之上，保留每次重要改动的前后对照和判断依据。适合站点仍在迭代、但不需要整体交接的情况。
- 交接级（最细）：在改动级之上，保留可复现的操作路径和取舍理由，让新人能独立接手。适合改版、迁移或团队更换。
一个假设的例子：某站点项目结束后，运营团队不变，只是日常更新内容。此时保留决策级文档就够，过程稿可以只留最终版。但如果三个月后要换服务方，就需要在交接前把粒度补到交接级，否则新方只能从零重建判断。
具体动作：先做一次“可复现性”抽查
不要一次性整理全部文档，那样成本高且容易半途而废。更实际的动作是：从历史文档中随机挑三个已完成的页面改动，尝试仅凭归档材料复现“为什么这样改”。
结果会直接决定下一步。如果三个都能复现，说明粒度足够，可以只做命名和目录整理。如果有一个复现不了，就针对那一类改动补充依据，而不是全量重做。如果三个都复现不了，说明问题不在粒度，而在文档根本没有记录判断过程，这时要优先补的是决策依据，而不是增加文件数量。
需要提醒的是，文档保留量下降、归档请求减少，都不能单独证明粒度已经合适。也可能是没人再查、或者查询入口太隐蔽。判断粒度是否够用，最终要看接手者能否独立做出下一个决策，而不是看文件多少。
保留时最容易忽略的两类内容
在确定粒度时，有两类内容经常被漏掉，却恰恰是后续最需要的。
第一类是被否决的方案及原因。只留最终方案，会让后人重复提出已经排除过的思路。第二类是改动之间的依赖关系，例如某次结构调整依赖了另一处模板变更。缺少这层关系，单独看每个改动都合理，合起来却无法解释页面现状。
因此，即使选择最粗的决策级粒度，也建议至少保留这两类信息的一句话说明。它们占用的空间很小，却能显著减少后续的重复判断。
什么情况下应当主动提高粒度
如果出现以下任一前提变化，就应当把粒度从决策级提升到改动级或交接级：站点准备改版或迁移、服务方或主要维护人更换、页面结构将要大范围调整、或者同一批页面需要多人协作维护。反之，如果站点稳定、维护人不变、页面形态长期不动，维持较粗的粒度是合理取舍，不必为了“完整”而堆积无用过程稿。
粒度定得合适，历史文档才会在真正需要的时候发挥作用，而不是变成项目结束后谁也不看的负担。
