网站营销团队项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a4a7d6eca858.html
📄
网站营销团队项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度不按“文件数量”定，而按“下一次决策是否还需要它”定。项目结束后，把文档分成三层即可——结论与口径层永久保留，过程证据层保留到下一次同类决策完成，草稿与中间导出层在确认无人依赖后清理。下面用一个假设情境把判断过程写清楚。
先看一个假设情境：前提变了，粒度就该变
假设某网站营销团队刚结束一轮站点改版项目，交付了内容结构调整、页面模板更新和一批落地页。项目验收时一切正常。三个月后，业务方向调整：原来主推的产品线收缩，新的重点转向另一类服务，同时负责对接的运营同事离职，接手的人只拿到一个共享文件夹。
这时团队面对的问题不是“文档多不多”，而是“新接手的人能不能只靠这些文档，判断当初为什么这么改、哪些结论还有效、哪些已经过期”。粒度太粗，接手人要重新问一遍所有人；粒度太细，文件夹里塞满中间稿，反而找不到关键判断。所以粒度必须跟着前提变化走。
三层粒度：什么永久留、什么限期留、什么可以清
把历史文档按用途分层，比按文件类型分类更实用。
- 结论与口径层（永久保留）：项目目标、最终决策、页面命名与URL规则、内容归属规则、关键指标的统计口径。这一层的作用是让后来者知道“当时定的是什么”，不需要重新推导。
- 过程证据层（限期保留）：方案对比、评审记录、测试结论、数据快照。保留期限建议绑定“下一次同类决策”——如果一年内还会做同类改版，就留到那次改版结束；如果业务方向已经不再涉及，就可以到期清理。
- 草稿与中间导出层（确认后清理）：多版本草稿、临时导出、重复备份、个人工作文件。清理前只需确认一点：没有任何在跑的流程或对外承诺依赖它。
这三层的划分标准是“是否影响下一次判断”，而不是“是否看起来重要”。很多团队把草稿留得最久，恰恰是因为舍不得删，而不是因为真的会用。
判断粒度是否够用的三个可观察信号
不需要等到出问题才复盘粒度。以下三个信号出现任意一个，就说明当前粒度不合适。
- 接手人反复追问同一件事：说明结论层缺了关键口径，需要补的是“为什么这么定”，而不是把所有过程文件翻出来。
- 同一份数据出现两个版本且无法判断哪个有效：说明过程证据层缺少时间标记和失效说明，需要给每份证据标注适用时段。
- 清理时没人能确认某文件是否被依赖：说明文档缺少归属人，粒度再细也无法安全清理。此时应先补归属，再谈保留期限。
这三个信号都指向同一个动作：给文档补上“适用前提”和“负责人”。做完这一步，保留期限才有判断依据，清理也不再靠猜。
一个可执行动作：给每份文档加一行适用前提
具体做法很简单。在每份保留文档的开头加一行说明，包含三项：这份文档在什么前提下有效、由谁负责确认、下一次复核时间。例如：
适用前提：站点仍以A类服务为主推方向；负责人：运营对接人；复核时间：下次业务方向调整时
加完这一行后，会发生两个变化。第一，清理时可以直接按“前提是否还成立”判断，不必逐份打开阅读；第二，接手人看到前提已经失效，就知道该文档只能作为历史参考，不能直接沿用其中的结论。这一步的结果会直接影响下一步：前提仍成立的文件继续按原粒度保留，前提已失效的文件降级为参考件，只保留结论层，过程证据层到期清理。
什么时候该收紧、什么时候可以放宽
粒度不是越细越安全，也不是越粗越省事，取决于两个条件。
- 该收紧的条件：项目涉及对外承诺、合规要求或跨团队交接，且接手人不具备原项目背景。此时结论层要写得更完整，过程证据层保留期限应覆盖整个承诺周期。
- 可以放宽的条件：项目为内部试验性质，未对外承诺，且原团队成员仍在岗。此时只需保留结论层和关键数据快照，草稿和中间导出可以在验收后直接清理。
判断的落点始终是同一个问题：下一个需要做同类决策的人，能不能只靠留下的文档做出判断。能，就说明粒度够了；不能，就补结论层，而不是把所有过程文件都堆回去。
