百度推广服务项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c3084c711623.html
📄
百度推广服务项目结束后历史文档需要保留到什么粒度
结论先说：不要按“全部保留”或“只留结案报告”二选一，而应按“可复核事实”保留。能独立回答“当时改了什么、依据是什么、谁确认过、结果如何”的最小证据包，应当长期保留；过程草稿、重复导出、中间命名版本可以定期清理。粒度以“换一个人能否复现判断”为界，而不是以文件数量或存储成本为界。
矛盾现象：同一份结案，三个人说出三种事实
项目结束后常见一种分歧：运营记得“账户结构大改过”，设计记得“只换了落地页”，财务记得“预算没有执行完”。三人都不是撒谎，而是各自保留的文档切片不同。运营手里有账户调整记录，设计手里有页面版本，财务手里有结算单，但没有一份共同承认的主线文档把三者串起来。此时争论的其实不是记忆，而是文档粒度不统一。
这类分歧在百度推广服务里尤其容易发生，因为交付物天然分散：账户结构、关键词与创意、落地页、数据报表、沟通记录分属不同角色。如果结案时只交一份总结，后续任何一方追问细节，都会发现缺少可核对的原件。
两种解释：是“留得不够”，还是“留得太杂”
第一种解释是留得不够。关键调整只存在于聊天记录或某人本地电脑，人员一变动就断链，于是每次复盘都要重新猜测。第二种解释恰恰相反：留得太杂。文件夹里有几十个命名相似的表格和截图，没人知道哪份是最终确认版，反而增加了核对成本。两种解释指向相反的动作，一个要补，一个要删，所以必须先区分。
区分证据可以看一个信号：当新接手的人提问时，团队是“找不到”，还是“找到太多但不知道信哪个”。前者说明粒度不足，后者说明粒度失控。另一个信号是争议能否被一份文档终结。如果每次讨论都要重新拉群回忆，说明缺少权威版本；如果每次都要逐份比对多个文件，说明版本没有收敛。
可长期保留的最小证据包
建议把保留对象分成三层，而不是笼统地“留档”。
- 事实层（长期保留）：最终确认的账户结构说明、投放范围与预算口径、关键调整清单（含调整前后对比）、结案数据口径说明、双方确认的验收记录。这一层回答“发生了什么”。
- 依据层（长期保留）：支撑关键决策的报表快照、落地页最终版本、重要沟通结论。注意是“结论”而非全部聊天，保留能证明判断依据的那部分。这一层回答“为什么这么做”。
- 过程层（定期清理）：中间命名版本、重复导出、临时截图、未采用的方案草稿。这一层只在项目进行中有用，结案后按约定周期清理即可。
判断一份文件属于哪一层，可以问：删掉它之后，半年后的人还能不能解释当时的关键动作？能，就归过程层；不能，就归事实层或依据层。
一个假设例子：用“复核测试”定粒度
假设某项目结案六个月后，新负责人需要判断“是否要沿用原来的账户结构”。他手上只有结案报告，报告写着“结构已优化”。这句话无法支撑决定，因为不知道优化前后的差异、优化针对的问题、以及当时的数据口径。于是他只能重新翻账户，成本很高。
如果保留了一份“结构变更对照表”，列出调整前后的分组逻辑、调整原因和对应时间段，他就能在半小时内判断是否沿用。这个假设说明：粒度的标准不是文件多不多，而是能否支撑下一个具体决定。动作上，可以在结案时做一次“复核测试”——让没参与项目的人只看留存文档，尝试回答三个问题：改了什么、依据什么、结果如何。答不上来的部分，就是需要补的粒度；答得过于依赖某份临时文件的部分，就是需要收敛的版本。
把分歧转成可核对的项目
如果团队对粒度仍有分歧，不要继续争论“应该留多少”，而是把分歧转成一次可核对的动作：共同列出未来最可能被追问的五个问题，再检查现有文档能否回答。能回答的，标记为已覆盖；不能回答的，指定责任人在结案后一周内补齐并标注版本与确认人。这样得到的粒度是需求驱动的，而不是拍脑袋定的。清理过程层文件时同样如此：先确认事实层和依据层已经完整，再删除重复件，避免把唯一证据误删。
最终要接受一个现实：粒度不可能一次定死。项目类型、协作人数、后续是否延续投放都会影响保留范围。可行的做法是把上述三层结构写进结案流程，每次结案时按同一套问题检查一遍，让保留标准随项目变化而调整，而不是靠个人习惯决定。
