网络推广公司，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9bf658d703e2.html
📄
网络推广公司，项目结束后历史文档需要保留到什么粒度
保留粒度不以“全部留”或“只留结案报告”二选一，而按文档能否支撑下一次独立复现来分层。能复现一次投放或改版的证据保留到可操作粒度，只用于汇报的中间稿保留到可引用粒度即可，其余过程稿在项目验收后清理。
矛盾现象：文档越全，复用反而越慢
不少团队在项目结束时把工作群、云盘、邮件附件整包归档，理由是“以后可能用得上”。半年后接手的人打开归档，发现同一份素材有五个版本、命名只差日期，反而要花时间判断哪份是最终版。另一种做法是只留一份结案PPT，结果下一次做同类渠道时，连当时用的落地页结构、素材尺寸和排期节奏都找不到，只能从头试。
两种做法都自称“保留历史”，但一个把检索成本转嫁给未来，一个把重建成本转嫁给未来。粒度问题本质是：你希望未来的接手者付出检索成本，还是重建成本。
两种解释：留全是为了防丢失，还是为了免责
第一种解释是防丢失。项目里确实存在不可再生的信息，比如一次投放的实际排期、素材版本与渠道反馈，删掉就无法还原当时的决策依据。这类内容留全是合理的。
第二种解释是免责。部分文档的存在只是为了证明“我做过这一步”，例如反复修改的会议纪要、内部对齐的中间稿。它们对复现没有直接帮助，保留它们更多是流程留痕需要，而不是执行需要。区分这两种动机，决定了哪些文档该留到操作级、哪些留到结论级。
区分证据：看这份文档能否独立回答“当时为什么这样做”
可以用一个假设例子来比较。假设某网络推广公司为一个客户做了三个月的搜索与内容推广，结束后手上有：渠道排期表、素材源文件、每周数据截图、结案报告、群聊记录。如果下一位接手者要复现同类项目，他需要的是排期逻辑、素材规格、数据口径和结论依据，而不是群聊里的临时讨论。
- 保留到操作级：排期表（含渠道、时间、预算分配逻辑）、素材源文件与规格说明、数据口径定义。这些缺失后无法重建。
- 保留到引用级：结案报告、关键结论、异常处理记录。它们用于快速理解，不用于直接执行。
- 可清理：重复的中间稿、已被最终版覆盖的草稿、纯通知类消息。保留它们只会增加检索噪音。
判断标准不是文件大小或数量，而是：删掉它之后，接手者能否在不询问原执行人的情况下完成一次同类操作。能，就说明它不属于必须留到操作级的内容。
一个实际动作：先做删除测试，再决定归档层级
具体动作是：在项目验收后，挑一份你打算归档的文档，假设它已删除，然后让未参与该项目的人尝试回答“当时这个渠道为什么选这个时间段”。如果他答不出来，这份文档需要保留到操作级；如果他能从结案报告里找到依据，这份文档可以只留引用级或清理。
这个动作的结果会直接影响下一步：删除测试通过的内容，进入轻量归档，只保留结论与索引；删除测试不通过的内容，进入操作级归档，并补一份命名规范，确保未来能按项目、渠道、日期定位。这样做的代价是验收期多花一次判断时间，收益是后续检索不再依赖原执行人的记忆。
适用条件与边界
这套粒度划分适用于项目制交付、人员可能变动的场景。如果项目仍在延续、客户随时可能追问执行细节，操作级保留范围应扩大到当前活跃渠道。如果涉及合同约定或合规要求，保留范围以约定为准，不因检索效率而缩减。粒度选择没有统一标准，但每次归档前做一次删除测试，比事后争论“该不该留”更省成本。
