seo工作室：项目结束后历史文档需要保留到什么粒度，先把“一份资料”拆成三层，再决定留哪层
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b55d6d02d6ef.html
📄
seo工作室：项目结束后历史文档需要保留到什么粒度，先把“一份资料”拆成三层，再决定留哪层
结论：保留“能独立复现当时决策”的粒度，而不是保留所有过程文件。对多数seo工作室项目，这意味着每个已上线页面或每批改动保留一份决策记录、一份最终版本、一份关键数据快照；中间草稿、重复导出、聊天截图可以按批次合并或删除。判断标准只有一个：换一个人接手，能否在不联系原执行人的情况下解释“当时为什么这么做、做了什么、结果如何”。
先把“一份资料”拆成三层，再决定留哪层
拿起你手上任意一个已交付页面，把它拆成三层：决策层、成品层、过程层。决策层是关键词取舍理由、页面意图、内链安排、上线时间；成品层是最终标题、描述、正文、结构化数据；过程层是草稿、会议记录、多轮修改稿、临时表格。粒度争议几乎都出在过程层——它数量最大，但复现价值最低。
可执行动作：给这三层各设一个保留期限，而不是给整个项目设一个笼统期限。决策层和成品层跟随页面生命周期，只要页面还在线就保留；过程层按批次保留到下一次重大改版，之后压缩成一份变更摘要。这样做的结果是，你的文档总量会随页面数量线性增长，而不是随修改次数爆炸式增长，后续检索成本可控。
两种做法成立的条件不同，不要混用
做法一：按页面保留全量版本。成立条件是页面数量少、单页改动频繁、且改动之间需要精确对比（例如同一页面反复调整标题与结构）。代价是存储和检索成本高，接手人容易在多个版本间迷失，误把废弃草稿当成现行方案。
做法二：按批次保留摘要加最终版。成立条件是页面数量多、改动以批量上线为主、单页差异不影响后续判断。代价是丢失中间试错细节，如果某次改动效果异常，你只能看到“改了什么”，看不到“为什么排除其他方案”。
选择依据不是团队规模，而是“未来是否会追问排除项”。如果业务方经常问“为什么不用另一个方向”，就必须在决策层里保留被排除选项及原因，哪怕过程层已经删除。这属于低成本高回报的保留项。
用一个假设例子走完处理流程
假设你手上有一批去年上线的服务页，共四十个，期间做过三轮标题调整。第一轮是上线初稿，第二轮是统一加地域词，第三轮是回退部分地域词。现在项目结束，你要决定保留粒度。
- 先标记页面状态：仍在线的、已下线的、已合并到其他页面的。已下线页面只需保留决策层和下线原因，成品层可只留一份快照。
- 对仍在线的页面，保留第三轮的最终版本作为成品层，把前两轮合并成一条变更记录，写清改动范围、时间和回退原因。
- 对已合并页面，保留原地址、合并目标、合并时间，这三项缺一不可，否则后续排查流量归属时无从对照。
- 把过程层的多轮草稿压缩为一份摘要，注明“详细草稿已按批次清理”，避免接手人误以为资料缺失是管理疏漏。
这个流程的实际影响是：你放弃了对每一轮措辞的逐字追溯，换来了可检索的变更脉络。下一步如果出现流量异常，你可以先定位到具体批次，再决定是否需要恢复更细的记录——而不是一开始就面对一堆无法判断先后的文件。
判断粒度是否够用的三个检验动作
不要凭感觉说“差不多够了”，用三个动作检验：
- 交接检验：让未参与项目的人只看文档，复述某个页面的当前方案和最近一次改动原因。说不清，说明决策层缺失。
- 回滚检验：假设要退回上一版，文档能否指出上一版是什么、何时被替换。指不出，说明成品层版本链断裂。
- 归因检验：某页面数据变化时，文档能否区分“改动导致”和“同期其他因素”。区分不了，说明缺少时间戳或同期改动记录。
三个检验中任何一个失败，就补对应那一层，而不是整体提高保留粒度。整体提高粒度是最省思考但最费成本的做法，通常不必要。
哪些内容可以明确不保留
重复导出文件、未采用的草稿、即时沟通中的零散截图、与最终方案无关的中间表格，这些在决策层和成品层完整的前提下可以清理。但有两类例外必须留下：一是被明确否决的方向及否决理由，二是涉及外部依赖的记录，例如某次改动依赖第三方数据或接口状态。前者防止后人重复试错，后者在外部条件变化时是唯一的解释线索。
需要提醒的是，抓取量或请求量归零、报表某列空白，都不能单独证明文档处理正确，它们也可能来自统计口径调整、工具更换或页面本身下线。保留粒度是否合适，仍要回到上面三个检验动作，而不是看某个数字是否好看。
最终建议：以页面为单位建一份决策记录，以批次为单位建一份变更摘要，过程层定期压缩。这样既不会在项目结束后留下一堆无法判断价值的文件，也不会在需要解释历史决策时无据可查。粒度服务于复现能力，不服务于文件数量。
