关键词排名优化服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2c4e32cedc5a.html
📄
关键词排名优化服务：项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度应按“能否独立复现一次决策”来定，而不是按文件新旧或数量。建议至少保留三层——原始数据快照、变更记录、决策说明；其余中间稿、重复导出和临时分析文件可以清理。判断标准是：换一个人接手，能否在不联系原执行人的情况下，解释某个页面为什么被改、改前是什么状态、改后观察到了什么。
为什么小项目里“全留着”没事，规模化后就成了问题
这个矛盾很常见：单个站点或少量页面的优化项目，历史文档全量保留几乎不产生成本，找东西也快。但当成批页面、多个批次、多轮迭代叠在一起后，同样的做法会出现例外——目录里同名文件、同日期版本、同一份数据的多个导出格式混在一起，反而没人能判断哪份是当时真正生效的版本。
此时“文件都在”不等于“信息可查”。真正影响交接和复盘的，不是总量，而是关键决策链是否完整。规模越大，越需要把保留粒度从“存全部过程”转向“存可复现结论的节点”。
两种解释：是保留太多，还是保留得不对
面对“文档太乱、找不到依据”的现象，通常有两种解释，指向的动作完全不同。
- 解释一：保留过度。大量中间稿、重复截图、临时表格挤占了检索路径，真正有用的记录被淹没。如果是这种，清理冗余即可改善。
- 解释二：保留错位。文件数量未必多，但缺少把“数据—判断—动作”串起来的说明，导致有数据也读不懂。如果是这种，清理反而会丢掉仅有的线索。
两者都会表现为“查不到”，但成因相反。把第二种误判成第一种，清理时会删掉唯一能解释变更的记录；把第一种误判成第二种，则会继续堆积无用文件。
能区分这两种解释的证据
可以做一个抽查：随机挑三个曾经调整过的页面，尝试只靠现有文档回答三个问题——改动前该页的状态是什么、当时基于什么观察做了改动、改动后下一次判断依据是什么。
- 如果三个问题都能答上，只是找文件花时间，说明是保留过度，问题在组织方式。
- 如果三个问题里有任何一个答不上，尤其是“为什么改”答不上，说明是保留错位，缺的是决策说明而非文件数量。
这个抽查的假设是：文档原本用于交接或复盘。如果文档从未打算被别人使用，结论不适用。另外要注意，某段时间数据波动或记录缺失，不能单独证明保留策略对或错——它也可能只是当时没有采集，或采集口径变了，需要结合变更记录一起看。
按粒度分层：哪些必须留，哪些可以清
可以按下面的层次决定去留，而不是按文件夹一刀切。
- 必须长期保留：每次改动的对象（页面或模板标识）、改动前后的关键状态、改动时间、以及一句可读的决策理由。
- 建议保留：支撑该决策的原始数据快照，注明采集口径和时间范围，便于日后复核。
- 可定期清理：中间稿、重复导出、已被最终版取代的草稿、无说明的临时分析文件。
一个具体动作：先给现有文档加一份索引，每条记录写清“对象、时间、改动、理由、数据出处”。做完这一步后，再回头看哪些文件没有被任何索引条目引用——这些通常就是可以清理的部分。索引本身也成了判断粒度的依据：如果某类文件长期不被引用，说明它不必进长期保留层；如果某类信息频繁被查却总找不到，说明它需要补进必须保留层。
规模化时的边界：别把单站经验直接照搬
单个站点跑通的保留习惯，不一定适用于多站点、多批次并行的场景。边界主要在两处：一是命名和索引规则需要在项目开始前统一，事后补建成本高；二是决策说明的详细程度要随参与人数增加而提高，否则同一份记录在不同人眼里含义不同。判断是否越界，可以看交接时是否需要反复口头补充——如果需要，说明当前粒度对规模化场景偏粗。
最终落点仍是那句话：粒度服务于复现决策，而不是服务于存档数量。能答清“为什么改、改前怎样、改后看什么”，就是够用的粒度。
