阳光SEO服务项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ad3c96955588.html
📄
阳光SEO服务项目结束后历史文档需要保留到什么粒度
结论先给：如果这份文档未来还要用于接手、复现或争议核对，就保留到“能独立重跑一次判断”的粒度；如果只是过程留痕，保留到“能说明当时为什么做这个决定”即可。前者通常要留下原始数据、判断依据和改动前后对照，后者只需留下结论、日期和责任人。粒度定得太细，维护成本会压过价值；定得太粗，一旦出现排名或流量异动，你无法区分是策略失效、执行遗漏，还是外部环境变了。
先分清哪些文档承担“复现”职责
判断粒度，先看文档未来被谁使用。承担复现职责的，是那些离开原执行人也能重建动作的文件：关键词映射表、页面改动清单、内链调整记录、结构化数据变更、以及每次改动对应的原始数据快照。这类文档要保留到可核对的最小单元，例如某次标题改写，要能查到旧标题、新标题、生效日期和当时的目标页面。
不承担复现职责的，是会议纪要、聊天记录、临时排期表。它们只需要保留结论和决策理由，不必逐条留存讨论过程。一个实用的分界是：如果一个问题需要重新做一次同样的判断，缺了这份文档会不会导致判断结果不同？会，就保留细粒度；不会，就压缩成摘要。
一个反直觉现象：文档越全，复盘反而越难
很多团队默认“留得越多越安全”，但实际复盘时常见相反结果：资料堆满，关键判断却找不到。原因是过程文件没有分层，原始导出、中间稿、最终稿混在一起，检索成本高于重新判断的成本。此时文档数量增加，并没有提高可核对性。
要区分两种解释：一种是文档确实缺失关键字段，另一种是文档齐全但缺少索引。前者需要补粒度，后者需要补结构。可核对的证据是——随机抽三次改动，看能否在五分钟内定位到“改了什么、为什么改、改前数据是什么”。三次都失败，问题在结构；只有涉及原始数据的那些失败，问题才在粒度。
按用途分三档保留，而不是一刀切
可以按下面三档处理，避免全部细存或全部清空：
- 决策档：保留目标、假设、采用方案、放弃方案及原因。适合所有项目，长期保留。
- 执行档：保留改动清单、生效时间、责任人、涉及页面或目录。适合需要交接或复现的项目，保留到下一次大改版。
- 证据档：保留原始数据导出、抓取结果、改动前后对照。只在争议核对、效果归因或合规要求下保留，并注明采集时间和口径。
假设某项目结束后，你只留了决策档，三个月后发现某目录流量下滑。你只能知道当时“调整了内链”，却无法确认是否漏改、是否按计划生效。这时需要回到执行档补查；如果执行档也没有，就只能重新采集当前状态，而无法还原改动前状态。这个动作的结果直接决定下一步：能还原，就做前后对照；不能还原，就先把当前基线记录清楚，再决定是否重做调整。
什么情况下这套粒度会失效
一个明确的反例是：项目涉及多团队并行改动，且没有统一变更日志。此时即使每份文档都保留得很细，也无法拼出完整时间线，因为同一时间点可能有多个动作叠加。粒度再细，也不能替代“统一变更编号”这一层。遇到这种情况，先补一份跨团队变更索引，再谈保留到多细，否则证据档只会变成互不关联的碎片。
另外，如果项目结束后页面已被整体替换或站点迁移，历史文档的复现价值会快速下降。此时保留重点应从“重跑动作”转向“解释决策”，粒度可以适当放宽，但迁移前后的映射关系仍要保留，否则后续无法判断异动来自迁移还是策略。
下一步动作：先做一次抽样核对
不要先定规则再执行，先抽三次历史改动做核对。每次记录：能否找到改动前后状态、能否找到判断依据、能否找到责任人。三项都能找到，说明当前粒度够用；缺哪项，就只补哪一档。补完后重新抽一次，确认新档位能被检索到，而不是只被存下来。这样定出的粒度，才是由实际使用需求推出来的，而不是凭感觉设一个“越全越好”的标准。
