线上推广公司，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8166fb054d47.html
📄
线上推广公司，项目结束后历史文档需要保留到什么粒度
结论先行：项目结束后，历史文档不必全量保留，但必须保留到“能独立解释一个关键决策是怎么做出的”这一粒度。低于这个粒度，未来换人接手或出现争议时无法还原；高于这个粒度，会积累大量重复素材，检索成本反而上升。一个可操作的判断标准是：把文档分成决策记录、执行产物、原始素材三层，决策记录长期保留，执行产物按合同与合规要求保留，原始素材只保留可复用或可追溯的部分。
为什么“全部保留”和“全部清空”都不成立
很多团队在项目收尾时走两个极端。一种是打包所有聊天记录、草稿、截图和中间版本，直接归档，理由是“以后可能用得上”。结果是归档目录里混着十几版方案，没人知道哪一版是最终确认的，下一次启动类似项目时，检索成本比重新做还高。另一种是只留最终交付物，把过程文档全部删除。这种做法的风险在于，当客户或内部质疑“当时为什么选这个方向”时，没有任何依据可查。
两种做法失效的原因相同：它们都没有区分文档的功能。历史文档的价值不在于数量，而在于它能否回答具体问题。能回答“当时预算怎么分配的”“这个素材的授权范围是什么”“这个页面的改动是谁确认的”，就是有效保留；只能证明“我们做了很多工作”，就是无效堆积。
按三层粒度决定保留什么
把项目文档按用途分成三层，每层对应不同的保留期限和粒度。
- 决策记录层：包括需求确认、方案选型理由、预算分配依据、关键节点验收结论、变更记录。这一层建议长期保留，粒度到“谁在什么条件下确认了什么”。不需要保留全部讨论过程，但需要保留最终结论和支撑结论的关键依据。
- 执行产物层：包括最终上线的页面、投放素材、文案终稿、配置参数。这一层按合同约定的交付物清单保留，粒度到“可直接复用或可直接核对的版本”。中间版本除非有特殊合规要求，否则不必全部保留。
- 原始素材层：包括未经剪辑的图片、视频源文件、未整理的调研数据、内部草稿。这一层只保留有再次使用价值或有授权追溯需求的部分。如果素材来自第三方且授权期限已过，继续保留反而可能带来合规风险。
假设一个线上推广项目结束后，团队需要决定是否保留全部聊天记录。按照三层法，聊天记录里如果包含预算调整的确认、素材授权的沟通、验收标准的变更，这些片段应提取到决策记录层；其余日常沟通不必保留。这样做的结果是，归档体积可能减少大半，但关键决策链条完整。
什么情况下上面的粒度标准会失效
如果项目涉及合同纠纷、监管审查或客户明确要求全量留存，那么按功能分层的保留策略就不适用。此时保留粒度不由文档价值决定，而由外部要求决定，需要按法务或合规部门给出的清单执行，不能自行删减。另一个反例是：如果项目结束后短期内可能启动高度相似的续作，且原班人马大部分留存，那么执行产物层的保留粒度可以适当放宽，因为口头上下文还在；但一旦人员变动，这个前提就不成立。
下一步动作：先做一次文档分级，再决定删除
具体动作是：在项目正式关闭前，安排一次文档分级整理，把现有文档按上述三层打标，然后对每一层分别确认保留期限和责任人。这个动作的结果会直接影响下一步——如果分级后发现决策记录层缺失关键确认，说明项目过程中的记录习惯需要调整，下一次项目启动时就应约定决策记录的留存方式；如果分级后发现原始素材层占比过高且无复用价值，就可以按合规要求安排清理，释放存储和检索负担。
保留粒度的最终判断依据不是“以后会不会用到”，而是“如果未来有人问起这个决策，现有文档能不能在不依赖当事人口述的情况下回答”。能回答，就保留到这一层；不能回答，就需要补记或重新评估保留策略。
