公司网站策划：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e135b9172a27.html
📄
公司网站策划：项目结束后历史文档需要保留到什么粒度
保留粒度不应按“文件新旧”决定，而应按“这个文档还能不能支撑下一次决策”决定。对多数公司网站策划项目，建议把历史文档分成三层：结论层长期保留，过程层保留到下一次改版验收，素材层按权利期限保留。下面以你手上某个具体文件为例，说明怎么落到可执行的处理方案。
先判断这份文档属于哪一层
拿一份文件问三个问题：它是否记录了最终决定？它是否解释了为什么这样决定？它是否只服务于当时的执行动作？
- 结论层：信息架构定稿、栏目职责说明、转化路径决策、验收标准。这些是下一次改版或交接的起点，应长期保留，并标注版本与生效日期。
- 过程层：会议记录、方案对比稿、被否掉的首页草图、评审意见。它们解释“为什么没选另一条路”，价值在于避免重复讨论，但只在当前架构仍生效时有意义。
- 素材层：临时文案、活动页切图、外包交付的中间稿、测试数据。它们只服务于当时的执行，保留期限由版权、合同或活动周期决定。
如果一份文档同时具备两层属性，以更高一层为准，并在文件名或目录说明里注明它为什么被留下。
结论层保留到什么程度才算够用
结论层不是留一份最终稿就够了，关键是留下“可被重新解释的最小集合”。一份合格的结论层文档应能让没参与项目的人回答：这个栏目为什么存在、它服务哪类访问者、它的成功标准是什么、改动它会牵动哪些页面。
假设你手上有一份栏目职责说明，里面只写了“关于我们：介绍公司”。这属于不可用粒度，因为半年后没人知道它该放团队、资质还是发展历程。把它改写成“关于我们：承接品牌信任，承接从首页跳转的首次访问者，需包含可核验的资质信息入口”，这条就变成了可长期保留的结论。动作是补写决策理由，结果是下一次改版时可以直接判断新需求是否该塞进这个栏目，而不是重新开一轮争论。
一个可操作的检验方法：把结论层文档交给没参加项目的同事，让他复述网站结构。如果他只能复述栏目名，不能复述栏目之间的关系，说明粒度还太粗。
过程层什么时候可以清理
过程层最容易堆积，也最容易误删。判断标准不是时间，而是“当前架构是否还成立”。
如果下一次改版已经推翻了原来的信息架构，那么支撑旧架构的方案对比稿、评审记录，其解释力已经失效，可以只保留一份复盘结论，其余清理。反过来，如果架构没变，只是换了视觉或文案，那么当初为什么这样分栏的记录仍然有效，应继续保留。
清理前先做一次抽样：随机抽三份过程文档，看能否用它们回答“当时为什么否掉另一个方案”。如果三份都答不上来，说明这批文档已经退化成素材，可以按素材层规则处理。这个动作的结果会直接决定你是整批清理还是只清一部分，而不是凭感觉删。
素材层的保留期限由什么决定
素材层不要按“以后可能用得上”保留。它涉及三类约束：合同约定的交付物归属、图片或字体的使用授权、活动本身的存续周期。
假设某次活动页使用了外包拍摄的图片，授权只覆盖该活动。活动结束后，这组图片继续留在项目目录里，并不会自动获得新的使用权利。此时合理的处理是：保留活动页的最终截图和文案定稿（结论层），把原始图片按授权到期时间清理或移出常用目录。结果是后续有人想复用这组图时，会先看到授权提示，而不是直接从旧目录拿来用。
如果合同或授权文件本身也放在这个目录，它应归入结论层长期保留，因为它决定了素材能不能用。
把规则写成一次就能执行的动作
不要停在“分三层”的原则上。给每个目录加一个说明文件，写清三件事：这一层保留多久、由谁在什么触发条件下清理、清理前需要确认什么。
- 为结论层文档统一命名，包含栏目或页面对象与生效日期，避免用“最终版”“新版”这类无法排序的词。
- 为过程层设置触发条件，例如“信息架构变更验收后”或“项目复盘完成时”，而不是“每季度清理一次”。
- 为素材层标注授权来源与到期时间，到期前由指定角色确认是否续用。
执行一次后检查结果：如果清理后仍能回答“为什么这样设计”和“改动会牵动什么”，说明粒度合适；如果连基本结构都说不清，说明结论层留得太少，需要从过程层回捞关键决策记录。这个检查结果决定下一轮清理是收紧还是放宽，而不是继续沿用同一套标准。
