公司网站SEO：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8ff7ca954e4e.html
📄
公司网站SEO：项目结束后历史文档需要保留到什么粒度
保留粒度不取决于文档数量，而取决于“下一次有人要复核或接手时，能不能只靠它还原判断”。可执行的做法是分三层：决策层长期保留，执行层保留到下一次大改版，过程层在验收后定期清理。三层界线写清楚，比笼统规定“全部留存三年”更能减少分歧。
先确定保留粒度由谁使用决定
同一份文档，不同角色的用途并不一样。负责人关心的是“当时为什么这样定”，执行者关心的是“具体改了什么”，接手者关心的是“现在能不能照着继续做”。如果只按文件类型归档，就会出现负责人觉得记录够用、接手者却完全看不懂的情况。
把用途写进文档头部，是成本最低的一步。比如在每份记录开头加一行：用途：复核决策 / 复现操作 / 交接背景。这一行的作用不是形式，而是迫使写的人先想清楚谁会读。做完之后，通常会发现大量过程性文件其实只服务于“复现操作”，并不需要长期保留。
三层粒度：决策层、执行层、过程层
决策层记录的是目标、约束和取舍理由，例如为什么选择先处理某类页面、为什么放弃某个方向、当时有哪些限制条件。这类内容无法从结果反推，应长期保留，粒度到“一个决定一条记录”即可，不必附全部讨论过程。
执行层记录的是实际动作和范围，例如改动了哪些模板、调整了哪些内容类型、上线顺序如何。它服务于复核和回滚，保留到下一次结构性改版完成为止比较合理。超过这个节点，页面结构已经变化，旧记录对不上现状，继续留着反而增加误读风险。
过程层包括中间稿、临时截图、未采用的方案、沟通记录。它的价值集中在项目进行期间，验收后就可以按批次清理。判断标准很简单：如果一份材料在决策层和执行层里都找不到对应条目，它大概率只是过程噪音。
保留、改写还是退出：三种取舍的前提
保留适用于决策依据无法重建的情况。前提是这份记录里包含约束条件和被放弃的选项，而不只是结论。只有结论的文档，价值会随时间快速下降，因为没人知道它是在什么条件下成立的。
改写适用于内容仍有参考价值、但表述已经过时的情况。典型动作是把旧记录压缩成“背景 + 结论 + 适用条件”三段，删掉已经失效的操作细节。改写的前提是有人能确认哪些细节确实失效，否则容易把仍有效的约束一起删掉。
退出适用于已被新记录完全覆盖、且不含独立判断的内容。退出的前提是先确认没有其他文档引用它。如果一份旧记录被多处引用，直接删除会造成断链，这时应先更新引用方，再考虑清理。
三种取舍不必对同一批文档统一使用。更常见的做法是按批次处理：决策层保留，执行层改写后合并，过程层退出。
把分歧转成可核对的条目
多角色对同一事实理解不同，往往不是记忆问题，而是各自看到的文档版本不同。与其争论谁记得对，不如把分歧拆成可以逐条核对的问题：这个结论当时有没有前提条件？这个动作有没有对应的验收记录？这条记录现在还有谁在引用？
一个假设的例子：某次改版后，两位同事对“是否调整过某类页面的默认结构”说法不一致。与其翻聊天记录，不如查三层文档——决策层是否有对应决定、执行层是否有改动范围、过程层是否有验收记录。如果三层都找不到，说明这件事当时没有被记录，结论应是“无法确认”，而不是默认某一方正确。这个结果会直接影响下一步：要么补一条说明，要么在下次改版时把这类动作纳入必记清单。
需要提醒的是，文档数量减少、某类文件归零，都不能单独证明清理做对了。也可能只是没人再上传，或者归档路径变了。判断清理是否合理，要看决策层是否仍完整、引用是否仍能对上，而不是看文件总数。
落地时先定一条最小规则
如果暂时无法给全部历史文档分层，可以先定一条最小规则：任何影响页面结构或内容范围的改动，必须留下一条决策层记录，写明背景、结论和适用条件；其余材料按项目节点定期清理。这条规则执行一段时间后，再根据实际出现的分歧点决定是否细化执行层。
粒度定得太细，维护成本会超过文档本身的价值；定得太粗，接手者仍要重新问一遍。合适的界线是：让下一个接手的人不用找到原作者，也能判断当年为什么这么做、现在还能不能沿用。
