📍 WDQWDWQD987AAAAA:216.73.217.106
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /97b07f056769.html
📄

公司官网制作项目结束后历史文档需要保留到什么粒度

结论是：保留粒度不按“文档类型”一刀切，而按“重做成本”分档。凡重建一次需要重新访谈、重新确认或重新走审批的内容，保留到可复原决策依据的粒度；凡能由代码、设计源文件或服务商后台直接再生成的内容，留索引即可。一个项目里两种粒度并存，是正常状态。

先分清两种条件：可再生成与不可再生成

判断粒度前，先对每份文档问一句：删掉它之后，下一次改版要付出什么代价。

• 可再生成：页面文案的最终版本、图片切图、样式表、部署脚本、表单字段清单。这些从线上站点、代码仓库或设计源文件都能反推，保留索引和版本号就够。
• 不可再生成：栏目结构的取舍理由、导航层级的讨论记录、法务或合规对某句表述的修改意见、多轮评审中被否决的方案。这些一旦丢失，下次改版就要重新开一轮会，成本远高于存储成本。

假设一个项目共产生 120 份文档，其中约 30 份属于第二类。把 120 份全部长期保存，检索时噪音大；只留 10 份结论，半年后没人说得清某个栏目为什么被砍。合理做法是：30 份按决策档案保留，其余按索引保留。

按项目规模调整：小样本成立，规模化后会出现例外

一个只有五六个页面的官网，所有文档加起来可能不到 20 份，全部保留并不会造成负担，此时不必细分粒度。但同一个做法照搬到多语言、多子站、多轮迭代的项目，就会失效。

规模变大后，例外通常来自三处：

1. 多人协作产生重复版本。同一份需求文档出现 v3、v3-最终、v3-最终确认三个文件，保留全部等于没有版本管理，应只留被实际执行的那一版，并在文件名或提交记录里标明生效日期。
2. 跨团队依赖。如果设计、开发、市场分属不同团队，某一方的中间稿可能被另一方引用，此时“只留最终稿”会切断追溯链，需要把被引用的中间稿一并保留。
3. 合规与审计要求。涉及资质展示、价格表述、隐私条款的项目，修改痕迹本身可能需要在规定期限内留存，这类文档的保留粒度由外部要求决定，不适用上面的成本判断。

一个可执行的分档动作

把文档按下面三档归位，动作本身就能暴露哪些内容其实没必要长期保存：

• A 档：决策档案。保留原始版本加修改说明，保留期限与站点生命周期一致。内容包括需求确认记录、结构方案对比、合规意见。
• B 档：交付物索引。只保留最终文件加一份清单，说明每个文件对应线上哪个页面或哪个模块。清单比文件本身更重要，因为它是下次改版的入口。
• C 档：过程稿。评审中途的截图、临时排期表、内部沟通记录，项目验收后可按内部规定清理，清理前确认没有 A 档内容混在其中。

执行后如果发现 B 档清单无法回答“某个页面为什么这样组织”，说明 A 档归集不全，需要回头补记，而不是把 C 档全部留下当保险。这个反馈会直接决定下一轮项目要不要在启动时就约定归档责任人和归档节点。

保留期限怎么定，不必追求统一

统一规定“所有文档保存三年”看似省事，实际既浪费检索成本，也可能在合规场景下不够。更实际的做法是分两段：站点仍在运行期间，A 档随站点保留；站点下线或整体改版后，A 档再保留一个完整迭代周期，用于对比新旧结构的差异原因。B 档随交付物走，交付物被替换时同步更新索引。C 档按最短期限处理。

需要提醒的是，文档保留数量下降、归档目录变空，都不能单独说明归档策略正确。也可能是责任人离职、目录被误删或存储迁移丢失。判断依据应是：随机抽取一个已下线页面，能否在 A 档和 B 档中还原它的结构理由和对应文件。