推广服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /510ca35f6944.html
📄
推广服务：项目结束后历史文档需要保留到什么粒度
结论先给：保留粒度由“下一轮动作是否需要它”决定，而不是由文档厚度决定。建议把历史文档分成三层：结论层永久保留，依据层按争议周期保留，过程层到期清理。判断某个文件属于哪一层，用“三个月后是否还会有人拿它做决策”这一个问题就能筛掉大部分冗余。
先拿一个真实文件做分层测试
打开你手边任意一份推广服务项目文档，比如一份投放结案报告或素材版本说明。不要先问“要不要留”，先问三个可核对的问题：
- 它是否被别的文档引用？被周报、复盘或下一轮需求书引用过的，属于依据层。
- 它记录的是结论还是过程？“最终采用A方案”是结论，“A方案第三版改过按钮颜色”是过程。
- 它能否被一句话替代？能用一句话写清且不丢信息的，原文可清理，把这句话并入结论层。
这三问的结果直接决定动作：被引用且含结论的进永久层；被引用但只含过程的进定期层；既不被引用又不能一句话概括的，通常是当时的沟通快照，保留价值最低。
为什么“全留”反而增加出错概率
一个与直觉相反的现象是：文档留得越全，下一轮项目越容易用错数据。原因是历史文件夹里同时存在草稿、中途版本和最终版，检索时命中的往往是命名更早、上传更早的那一份。此时“找不到文件”和“找到了旧文件”是两种完全不同的失败，后者更难发现。
要区分这两种解释，可以做一个可核对的检查：随机抽三份历史文档，看它们的文件名是否包含版本标识和日期。如果三份中有两份无法从文件名判断新旧，问题就不是“资料不够”，而是“粒度没有分层”。这时正确的下一步不是继续归档，而是先补一层命名与索引规则，再决定清理范围。
三层保留粒度的具体划分
结论层：长期保留
包括最终投放结论、验收标准、双方确认的交付范围和结算口径。这一层的判断标准是“换一个人接手也能据此复现决策”。建议每份控制在一页以内，用纯文本或通用格式保存，避免依赖某个特定工具的打开环境。
依据层：按争议周期保留
包括支撑结论的数据表、素材版本记录、渠道对照说明。保留时长取决于业务是否需要追溯，例如涉及结算核对或效果争议的，保留到核对周期结束；纯参考性质的，保留一个完整业务周期即可。到期前做一次抽查，确认结论层已能独立成立，再执行清理。
过程层：到期清理
包括中间沟通记录、被否定的方案、临时截图。这一层最容易膨胀，也最少被真正复用。清理时不要逐份判断，按批次处理：先确认该批次对应的结论层文档存在，再整批删除。
一个假设例子：用动作结果决定下一步
假设某推广服务项目结束后，团队把全部文档原样保留。三个月后新项目启动，成员检索到一份标注模糊的旧版素材说明并直接沿用，导致素材规格与当前渠道要求不符，返工两天。
如果换成另一条路径：结项时只把“最终素材规格与确认日期”写入结论层，过程版本统一移入带到期日的临时目录。三个月后检索命中结论层，规格直接可用；若确需查过程，再按日期进入临时目录。两条路径的差别不在文档数量，而在检索时默认命中的是哪一层。
这个例子的用途是说明比较方法：把“检索命中正确文档所需的时间”和“因用错版本产生的返工”作为两个可观察指标，而不是凭感觉判断保留多少合适。
把规则落到下一次结项动作
下一次推广服务项目结项时，先做一步：在归档前为每个文件夹标注层级和到期日，只对结论层写一句话摘要。这个动作的结果会直接影响后续清理——有了摘要，依据层和过程层到期后可以放心删除；没有摘要，任何删除都会显得冒险，最终又退回全留状态。
如果清理后检索量或访问量出现下降，不要直接判定为清理过度。更常见的合理解释是：原本被频繁打开的正是那些过程文件，而它们本就不该承担决策依据的角色。此时应检查结论层摘要是否写清，而不是恢复全部历史文档。
