网络推广服务商，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ebc7a71a29a9.html
📄
网络推广服务商，项目结束后历史文档需要保留到什么粒度
保留粒度应由“未来谁可能因为什么原因重新打开这份文档”决定，而不是由文件是否占空间或项目是否结项决定。一个可操作的判断标准是：能独立回答一次追问的最小单元，就值得保留；只能帮助当时执行、离开上下文就无意义的中间产物，可以退出。下面按保留、改写、退出三种处理展开，并给出把分歧转成可核对项目的方法。
先区分三类文档，再谈保留到什么程度
历史文档大致分三类：承诺类（合同附件、确认邮件、验收单、变更记录）、依据类（关键词与页面映射、投放结构、素材版本、数据口径说明）、过程类（草稿、临时截图、内部讨论、重复导出的中间表）。承诺类通常按原样长期保留，因为它是双方对同一事实的共同底稿；依据类保留到能复现结论即可；过程类除非牵涉争议，否则可以退出。
粒度不是“全留”或“全删”的二选一。同一份投放报表，可以保留结构说明和口径定义，删掉每日重复导出的原始行；同一批素材，可以保留最终上线版本和版本号，删掉反复微调的中间稿。判断依据是：没有它，未来的人还能不能把当时的结论重新推一遍。
保留、改写、退出的适用前提
保留：当文档承担“对同一事实的共同理解”
如果多个角色对“当时到底承诺了什么”存在不同记忆，这类文档应原样保留，包括时间、版本、确认人。改写反而会破坏证据链。适用前提是：该文档可能被用于对账、续约、追责或交接。此时保留粒度到“可核对”即可，不必保留全部聊天记录，但确认节点不能少。
改写：当原文档只服务于当时的执行节奏
过程类文档往往包含大量只有当事人能看懂的缩写和临时命名。如果它承载了可复用的方法，就值得改写成一份脱离上下文的说明，例如把“这批页面为什么这样分组”写成规则描述。改写的前提是：原始细节不再重要，结论和判断依据才重要。改写后原稿可以退出，但要在说明里注明它替代了哪些文件。
退出：当文档无法独立回答任何追问
草稿、重复截图、已被最终版覆盖的中间稿，通常属于这一类。退出的前提是：它们既不承担承诺，也不承载可复用依据，且没有争议风险。需要提醒的是，某项统计归零或某个文件长期没人打开，并不能单独证明它该删；也可能只是还没到需要它的时间点。退出前应确认没有未结的验收或对账事项。
把分歧转成可核对的项目
当团队对“保留到什么粒度”意见不一时，不要停留在“留着也没坏处”这类判断上，而是把分歧拆成可以逐条核对的项目。一个假设例子：甲认为某份关键词表应完整保留，乙认为只需保留分组规则。可以这样转成核对项——
- 这份表未来可能被谁打开：接手优化的人，还是只做对账的人？
- 打开后要回答的问题是什么：某个词当时为什么归到这一组，还是某个词当时排在第几位？
- 如果只留分组规则，这个问题还能不能回答？
- 如果答案是否定的，需要补的是规则说明，还是原始表本身？
逐条核对后，分歧往往从“留不留”变成“留哪一层”。这一步的实际动作是：为每份争议文档写一句“未来追问”，再判断现有粒度能否回答它。能回答就退出原稿，不能回答就保留或改写。这个动作的结果直接决定下一步——需要补写说明的，先补说明再退出原稿；说明也补不出来的，说明这份文档的复用价值有限，可以整体退出。
一个最小可用的粒度约定
如果不想逐份讨论，可以先用一个约定起步，再按实际情况调整：承诺类保留原件与确认记录；依据类保留结论、口径、版本号三样，原始明细按需导出而非长期堆放；过程类只保留最终上线版本。这个约定的假设是，未来最常发生的追问是“当时为什么这样定”和“当时上线的是哪一版”，而不是“当时的每一行原始数据是什么”。
约定落地后，需要指定一个存放位置和一份索引，说明每类文档放在哪里、保留到哪一层、由谁负责在结项时整理。索引本身也应保留，否则文档虽然还在，接手的人仍然找不到。粒度是否合适，可以在下一次交接时检验：如果接手的人能在不询问原执行者的情况下回答常见追问，说明粒度够用；如果频繁需要找人补背景，说明该保留的说明层被删掉了。
结项时先做一次“未来追问”核对
项目结束不是清理的起点，而是核对粒度的节点。把承诺类、依据类、过程类分开处理，对承担共同理解的文档原样保留，对只服务当时节奏的文档改写为可复用说明，对无法回答任何追问的文档退出。真正需要避免的不是留多或留少，而是留下了一堆无法回答追问的文件，却删掉了唯一能说清口径的那一页。
