百度代理商项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c631eca7c8b2.html
📄
百度代理商项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度不取决于文档数量，而取决于“下一次接续这个项目时，谁需要凭它做出判断”。如果后续只做常规续费或小幅调整，保留到可追溯的决策与配置粒度即可；如果账户、站点或主体可能更换接手方，就要保留到能独立复现当前状态的粒度。下面用一个假设情境把取舍条件写清。
假设情境：一次代理商交接后，文档粒度被重新定义
假设某企业此前由一家百度代理商负责账户与站点维护，合同到期后改为自行运营，只保留少量投放。项目结束时手上有三类材料：月度报告、账户配置截图、历次调整记录。此时“保留到什么粒度”不是问存多久，而是问：新接手的人能否在不联系原团队的前提下，判断某个设置为什么是现在这样。
如果答案是否定的，说明粒度太粗；如果能凭文档直接复现并解释，粒度就够。这个判断标准比按年份或按文件数量划线更可靠，因为它直接对应下一次决策场景。
两种成立条件：常规续接与主体更换
条件一：业务主体、账户归属、负责人都不变。此时历史文档主要服务于对比和复盘。保留到“月度汇总 + 关键调整说明”这一层通常够用。具体动作是：每个季度把当季的调整动作、动作原因、观察到的变化写成一页说明，与原始报告放在同一目录。这样下一步做预算或结构微调时，能快速找到上一次同类动作的依据，而不必翻全部原始记录。
条件二：账户、站点或对接人至少有一项会变。此时文档要承担交接功能，必须保留到“可独立复现”的粒度，包括账户结构层级、命名规则、转化目标定义、站点与账户的对应关系。动作是：在交接前做一次“盲测”——让没参与过项目的人只看文档，回答“当前主要转化目标是什么、对应哪些页面、哪些设置是刻意保留的”。答不上来的部分，就是要补的粒度。
用一组可区分原因的证据判断粒度是否足够
不要用“文档很多”当作粒度足够的证据。更有效的证据是下面这几项能否被独立回答：
- 某个设置是历史遗留还是当前有意为之，文档里有没有说明；
- 同一个指标在不同月份口径是否变化过，变化原因是否记录；
- 站点改动与账户调整的先后顺序能否对应上；
- 接手方按文档操作后，结果与文档描述是否一致。
如果只能回答其中一部分，说明粒度停在“结果层”，还没到“决策层”。这时应优先补齐决策层说明，而不是继续堆原始截图。
一个短例：删掉原始截图后，哪些内容必须留下
假设为了控制存储，决定清理大量账户截图，只保留文字说明。此时判断标准是：文字能否替代截图支撑下一次判断。可留下的是结构层级、命名规则、转化目标定义、关键调整的时间与原因；可以清理的是重复的界面截图和已被后续版本覆盖的中间状态。清理后要做一次核对：随机抽一个当前设置，看能否仅凭留下的文字说清它的来源。若不能，说明清理过度，应恢复对应说明而不是恢复全部截图。
这个动作的结果会直接影响下一步：如果核对通过，后续可以按同一规则继续精简；如果核对失败，说明粒度底线还没确定，应先停止清理，把决策层说明补全再继续。
把粒度写成可执行的保留规则
综合来看，可以按三层来定：第一层是结果数据，按需保留；第二层是决策记录，即每次调整的动作、原因、预期，建议长期保留；第三层是配置与结构说明，在主体或接手方可能变化时必须保留到可复现程度。三层不必同时最细，但第二层不能省，因为它决定了第三层是否被正确理解。
最后要说明的是，请求量、抓取量或某项统计归零，并不能单独证明文档处理正确，它也可能是统计口径变化、工具调整或采集范围变化造成的。判断粒度是否合适，仍要回到“接手方能否独立做出下一步判断”这个标准上，并据此决定是继续精简还是补齐说明。
