扬中SEO服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /23d6fa151ca3.html
📄
扬中SEO服务：项目结束后历史文档需要保留到什么粒度
保留粒度应取决于文档将来会被谁使用、用来解决哪类问题。对多数扬中SEO服务项目，建议把文档分成三层：结论层长期保留，过程层保留可复现的关键节点，原始层按需保留并设定期限。全部留会拖慢检索，全部删会让下一次改版、迁移或交接失去依据。
先按用途分层，而不是按文件类型一刀切
判断粒度时，先问三个问题：这份文档未来是用于追溯决策、复现操作，还是排查异常。三种用途对应不同保留深度。
- 追溯决策：保留结论、依据、时间点和决策人，不必保留全部中间稿。
- 复现操作：保留能重跑一遍的配置、字段映射、规则说明和版本号。
- 排查异常：保留异常发生前后的对照样本，但样本要标注采集条件和时间。
如果一份文档同时承担三种用途，优先拆开保存，而不是把粒度统一拉高。统一拉高的结果是关键结论被埋在大量过程文件里，检索成本反而上升。
结论层长期保留，过程层只留可复现节点
结论层包括：站点结构变更记录、栏目与模板的对应关系、重定向规则的最终版本、内容批量调整的范围说明。这些文档体量小、复用频率高，适合长期保留，并在每次大改动后更新版本说明。
过程层容易失控。假设一个项目做了三轮栏目调整，每轮都留下完整的抓取日志、草稿和临时表格。半年后要查“某个栏目为什么被合并”，真正有用的往往只是每轮的变更说明和最终生效版本。此时可以把过程层压缩为：每轮一份变更说明、一份生效配置、一份差异对照。原始日志按保留期限处理，过期后只留摘要。
这里有一个实际动作：在项目收尾时，让执行人把过程文件按“是否影响下一次复现”打标。影响复现的进入长期目录，不影响的进入临时目录并设定清理时间。这个动作的结果会直接决定下一次交接时需要翻多少文件，也决定异常排查时能否快速定位到当时的配置。
原始样本不能单独作为判断依据
抓取量、请求量或某项统计归零，常被当作“处理正确”的证据，但这并不成立。归零还可能来自采集口径变化、过滤规则调整、日志轮转、访问限制或统计工具本身的中断。保留原始样本时，必须同时保留采集条件、过滤规则和对照样本，否则这些数据在未来会被误读。
因此，原始层的保留粒度建议是：保留能说明“当时在什么条件下得到这个结果”的最小集合。缺少条件说明的裸数据，长期保留的价值很低，反而容易在新项目中制造错误结论。
改写还是退出：三种常见取舍
项目结束后，历史文档通常面临三种处理方式，各自适用前提不同。
- 保留并标注适用范围。适用于文档结论依赖特定站点结构、特定内容类型或特定阶段目标的情况。标注边界后，下一次可以快速判断能否复用。
- 改写为通用说明。适用于结论本身可迁移，但原始表述绑定了旧项目细节的情况。改写时只保留判断逻辑和适用条件，去掉一次性数据。
- 退出长期目录。适用于文档只服务于已结束的一次性操作，且没有追溯或复现需求的情况。退出不等于删除，可以先移入临时目录，设定期限后再处理。
三种方式的选择依据不是文档新旧，而是未来是否还有人会基于它做决定。如果没有人会基于它做决定，保留粒度再细也没有意义。
一个假设例子：栏目合并后的文档处理
假设某站点在项目中将三个栏目合并为一个，并设置了重定向。收尾时留下四类文件：合并方案讨论稿、重定向规则最终版、合并前后的页面清单、合并期间的抓取日志。
按上面的分层，重定向规则最终版和页面清单属于结论层，长期保留；合并方案讨论稿只保留最终决策说明，其余过程稿退出；抓取日志保留一段有代表性的对照样本，并注明采集时间和过滤条件，其余按期限清理。这样处理的结果是：下一次改版时能直接查到当时的重定向逻辑和影响范围，而不必在大量讨论稿中翻找。
如果未来出现重定向异常，页面清单和规则版本能提供比对基准，抓取日志的对照样本能说明当时是否已经出现异常。缺少任何一层，排查都会退回到猜测。
收尾时至少要做的动作
在项目结束阶段，建议完成三件事：给每份保留文档写明用途和适用边界；把过程文件按是否影响复现分类；为临时目录设定清理时间并记录判断人。这三件事不需要额外工具，但会显著影响下一次接手时的效率。
粒度没有统一标准，判断标准是未来使用者能否据此做出正确决定。能支撑决定的信息保留，不能支撑决定的压缩或退出，这就是项目结束后历史文档保留的基本尺度。
