公司营销方案，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2d9e4f05f3a1.html
📄
公司营销方案，项目结束后历史文档需要保留到什么粒度
结论先给：如果旧项目对应的系统、渠道或合作关系已经确定退出，历史文档保留到“能独立解释一次关键决策”的粒度即可，不必保留全部过程稿；但如果退出决定还可能被推翻，或者同一批内容未来要迁移到新渠道，粒度就要提高到“能复现交付物”的层级。判断标准不是文档多少，而是下一次有人接手时，能否在不联系原执行人的情况下回答三个问题：当时为什么这么做、最终交付了什么、哪些部分还有继续使用的价值。
先分清三类文档，再决定保留粒度
把历史文档按用途分成三类，保留策略会清晰很多。第一类是决策类，包括需求确认、方案选择理由、渠道取舍结论；这类文档即使项目结束也建议保留结论和依据，因为它是后续判断“要不要重启”的唯一线索。第二类是交付类，包括最终上线的页面、投放素材、内容清单、配置记录；如果这些交付物还会被引用或迁移，就保留到可复现的程度，中间版本可以清理。第三类是过程类，包括多轮修改稿、临时沟通记录、废弃草稿；这类文档在项目正式结束后通常只保留最终版和一次关键修改说明即可。
一个实际动作是：先给每份文档打上“决策、交付、过程”三个标签，再按标签决定去留。这样做的结果是，清理时不会误删解释性材料，也不会因为舍不得过程稿而让归档体积失控，下一步的迁移或重启评估就有了明确入口。
退出场景下，粒度可以降到什么程度
当旧系统、旧渠道或旧合作关系确定不再使用，保留粒度可以降到“结论加证据”级别。具体来说，保留最终方案、上线结果、关键数据口径和一次复盘结论；删除重复的中间稿、已失效的排期表和不再维护的素材源文件。这样做的依据是：退出之后，这些文档的主要用途是回答“当初为什么退出”和“有没有遗留资产”，而不是继续指导日常执行。
但这里有一个容易被忽略的条件：如果退出涉及合同、结算或知识产权归属，文档粒度就不能只按内容价值判断，还要保留能对应责任边界的记录。此时保留范围应由实际需要核对的事项决定，而不是由文档新旧决定。
什么情况下低粒度保留会失效
反例很明确：如果同一批内容、同一套配置或同一批素材未来还要迁移到新渠道，低粒度保留就会失效。假设一个旧专题页要迁移到新系统，只保留最终页面截图和一句“已下线”的结论，接手人无法知道原来的栏目结构、跳转逻辑和素材授权范围，迁移成本会远高于当初多留一份配置说明。
因此，判断粒度是否足够，可以做一个假设测试：让一个没有参与过该项目的人，只凭保留的文档，尝试重建一次核心交付物。如果他能重建出结构和关键决策，粒度就够；如果只能知道“做过这件事”，粒度就不够。这个测试不依赖具体工具，也不要求保留全部历史版本。
按保留目的选择归档方式
保留目的不同，归档方式也不同。为了追溯决策，按项目和时间归档，保留结论与依据；为了复用内容，按主题和渠道归档，保留可编辑源文件和授权记录；为了应对审计或结算，按责任事项归档，保留能对应到具体交付和确认动作的记录。三种目的可以并存，但不要用同一套粒度标准处理所有文档，否则要么过度保留，要么关键材料缺失。
- 决策追溯：保留最终方案、选择理由、退出结论。
- 内容复用：保留可编辑源文件、结构说明、授权范围。
- 责任核对：保留交付确认、变更记录、结算依据。
执行时可以先处理决策类文档，再处理交付类文档，最后清理过程类文档。这个顺序的结果是，清理过程中一旦发现某份过程稿其实是唯一能解释决策的材料，可以立即把它提升为决策类保留，而不是等归档结束后再返工。
下一步动作：先做一次可重建测试
不要先问“保留几年”，先做一次可重建测试。从旧项目中挑一个最可能被复用的交付物，让接手人只凭现有文档尝试重建关键部分。如果重建失败，就补回缺失的结构说明或决策依据；如果重建成功，就可以按当前粒度继续清理。这个动作的结果直接决定下一步是扩大保留范围，还是进入正常归档。需要说明的是，文档数量减少、访问量归零或某个旧入口关闭，都不能单独证明保留粒度已经正确，它们只说明使用频率变化，真正要核对的是重建能力和责任边界是否仍然完整。
