百度优化服务项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /559ea864f351.html
📄
百度优化服务项目结束后历史文档需要保留到什么粒度
结论先说：如果这份文档还要支撑下一轮百度优化服务的诊断、交接或纠纷解释，就保留到“能复现判断依据”的粒度；如果只是过程性沟通和中间稿，保留到“能说明做过什么、结果如何”即可。粒度不是越细越安全，而是取决于两个条件——后续是否可能换人接手，以及结果是否需要对外解释。
条件一：后续不换人、不追责，保留到可读摘要即可
当项目由同一批人继续维护，且没有第三方验收或争议风险时，历史文档的作用主要是备忘。此时保留粒度可以压缩为三类：
- 结论层：每轮调整的目标、动作、观察到的结果，一段话说明白。
- 依据层：支撑结论的关键数据截图或导出文件，标注日期和来源。
- 例外层：当时没做、后来补做或明确放弃的事项，写清原因。
这个粒度下，中间讨论、草稿、重复的周报可以合并或删除。判断标准很简单：如果三个月后有人问“当时为什么这么改”，你能否用现有文档在十分钟内回答。能，就够用；不能，说明摘要层缺了关键依据。
条件二：可能换人接手或需要对外解释，保留到可复现判断依据
只要项目存在交接、验收或需要向客户解释结果的可能，粒度就要提高。此时不是保留所有文件，而是保留能重新走一遍判断路径的材料。具体包括：
- 问题定义：当时认为要解决的是什么问题，依据是哪些页面、哪些查询词、哪些日志片段。
- 动作记录：改了哪些模板、哪些内容、哪些内部链接，改动前后的版本对照。
- 结果证据：改动后观察到的变化，以及同期还有哪些其他变动可能影响结果。
- 未采纳方案：讨论过但没做的方案，以及放弃的理由。
这里有一个容易忽略的点：“结果变好”或“结果没变”都不能单独证明某个动作有效。抓取量下降可能是改版导致，也可能是服务器波动或百度自身调整；排名波动可能来自内容更新，也可能来自竞争对手变化。保留文档时，要把这些可能的解释一并记下，而不是只留一个结论。
用一个假设例子说明粒度差异
假设某次百度优化服务中，团队把一批产品页的标题模板从“产品名-公司名”改成“产品名-用途-公司名”，两个月后发现这些页面的点击率上升。如果只保留一句“改标题后点击率上升”，接手的人无法判断这个结论是否可靠。如果保留到可复现粒度，文档里应该有：改动前后的标题对照、改动覆盖的页面范围、同期是否有其他标题或描述改动、点击率数据的统计口径和日期。这样接手的人才能判断：这个变化是标题改动带来的，还是同期其他动作或外部因素带来的。
这个例子是假设的，数字和结论只用于说明保留粒度如何影响后续判断，不代表任何真实项目结果。
实施动作：先定保留级别，再决定删什么
实际操作时，不要先问“哪些文件可以删”，而是先给项目定一个保留级别。动作可以这样展开：
- 项目结束前，由负责交付的人标注每份文档属于“结论层”“依据层”还是“过程层”。
- 结论层和依据层进入长期归档，过程层设定一个短期保留期，到期后合并或清理。
- 归档时给每份文档写一行说明：这份材料能回答什么问题，不能回答什么问题。
这个动作的结果会直接影响下一步：如果归档后发现大量文档只有结论没有依据，说明项目过程中的记录方式需要调整，下一轮百度优化服务就要在动作发生时同步留证，而不是结束后补记。反过来，如果依据层材料过多且重复，说明保留级别定得过高，可以适当合并，降低维护成本。
例外：这些情况需要单独处理
有两种例外不能套用上面的粒度标准。第一种是涉及合同、付款或责任划分的文档，这类材料通常有独立的留存要求，不应按技术文档的粒度删减。第二种是包含个人或客户敏感信息的文档，保留粒度要同时考虑可追溯和最小化，不能为了“以后可能用得上”而长期保留全部原始数据。遇到这两种情况，先确认适用的留存规则，再决定归档范围。
最终判断标准可以归结为一句话：保留的粒度，要能让下一个接手的人在不需要原班人马解释的情况下，独立判断当时做了什么、为什么做、结果可以怎样解释。达不到这个标准，就补依据；超过了这个标准且没有额外风险，就可以合并或清理。
