网站推广外包服务，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1c94fc3095e6.html
📄
网站推广外包服务，项目结束后历史文档需要保留到什么粒度
没有统一粒度，判断标准是文档在“下一次决策”里还能不能独立回答问题。项目结束后，历史文档通常被分成三类处理：保留证据级原件、改写成可复用资产、直接退出。粒度太细会变成无人维护的负担，太粗又会在换服务商、接手团队或复盘时失去判断依据。关键动作是先给每类文档标注“谁在什么情况下会再打开它”，再决定留、改还是删。
先按“再次打开的场景”分类，而不是按文件类型分类
很多人按文件夹整理，结果保留了大量截图和过程稿，真正需要时仍找不到结论。更有效的做法是问一句：这份文档下一次被打开，是为了核对事实、复制做法，还是追溯责任？三种目的对应三种粒度。
- 核对事实：需要原始记录，例如某次调整前后的页面版本、生效时间、执行人。这类要保留原件，不能只留摘要。
- 复制做法：需要步骤和判断条件，例如某类落地页的改写规则。这类应改写成不依赖原执行人的操作说明。
- 追溯责任：需要能证明“当时双方确认过什么”，例如验收记录、变更确认。这类保留签署或确认痕迹，过程草稿可以退出。
如果一份文档无法归入以上任何一类，它大概率只是过程噪音，保留它只会增加后续检索成本。
保留：只有同时满足两个条件才值得留原件
保留原件的门槛可以设得具体一些：它记录了不可再生的判断依据，并且未来存在明确的对照需求。典型情况是推广策略调整前后的数据口径、内容版本对照、以及双方确认过的交付范围。
反过来，以下情况适合退出而不是保留：同一结论的多次中间稿、可从最终版本反推的草稿、以及没有对照价值的临时截图。这里有一个容易忽略的遗漏条件——保留粒度必须和检索方式匹配。如果你只保留了文件，却没有统一的命名和索引，那么保留等于没保留。一个实际动作是：为每个保留项写一行索引，包含主题、时间、对应渠道、以及“下次打开它的触发条件”。做完这一步，你会发现相当一部分文件因为写不出触发条件而被淘汰，这直接缩小了下一阶段的改写工作量。
改写：把依赖个人的文档变成可交接资产
改写的适用前提是：这份经验还会被重复使用，但原执行人可能不再参与。判断信号是文档里频繁出现“按上次那样”“问某某确认”这类指向个人的表述。
改写时保留判断条件，删掉个人化表达。例如把“某次调整后流量回升”改成“当某类页面跳出率偏高时，先检查首屏信息与搜索意图是否一致，再决定是否改标题”。前者是结果陈述，后者是可复用规则。改写后的文档粒度应控制在一个新人能在不追问原作者的情况下执行，超过这个详细度就是冗余，低于这个详细度则无法交接。
需要说明的是，改写不是把过程稿全部重写一遍。只有被判定为“会重复使用”的文档才进入改写队列，其余直接进入保留或退出。
退出：删除前先确认没有对照需求
退出的常见误区是只按时间清理，比如“超过一年就删”。时间不是可靠标准，因为有些对照需求会在换服务商或重新启动推广时才出现。
更稳妥的退出条件是：该文档的结论已经被最终版覆盖，且不存在跨周期对照的需要。假设一个场景：某轮推广用A、B两版落地页做对照，最终只保留B版继续投放。那么A版的过程稿可以退出，但A、B的对照结论和判断依据应当保留，否则下次遇到类似分歧时又要重新试一遍。这个例子说明，退出的是过程材料，不是结论依据。
执行退出前，建议先做一次“反向检索”：假设半年后有人问“当时为什么选B”，现有文档能否回答。能回答，就可以删；不能回答，说明该保留的结论还没沉淀出来，应先补写再删原件。
把粒度决定写成可执行的收尾清单
收尾时按顺序做三件事，每件事的结果都会影响下一步：
- 给每份文档标注再次打开的场景，写不出场景的直接进入退出候选。
- 对保留项建立索引，索引写不完整的退回重新判断，避免留下无法检索的“死档”。
- 对改写项设定交接标准，以“新人能否独立执行”为验收线，达不到就补充判断条件而不是补充过程记录。
这三步完成后，文档粒度自然收敛到“够用且可检索”的范围，而不是靠感觉决定留多少。粒度是否合适，最终要看接手的人能否在不联系原作者的前提下做出下一次决策。
