通化网络服务，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28a1cb07585b.html
📄
通化网络服务，项目结束后历史文档需要保留到什么粒度
结论先说：如果网站还要继续运营，历史文档至少保留到“能独立解释一次变更”的粒度，即需求、方案、上线记录和验收结论四类齐全；如果项目彻底终止且不再续费域名与服务器，可以降到“只留合同、结项说明和最终源码包”。判断标准不是文档越多越好，而是未来有人接手时，能否只靠文档回答“为什么这样改、改前是什么样、谁确认过”。
两种粒度各自成立的条件
第一种是“过程粒度”，保留需求讨论、修改记录、版本对比、测试反馈和上线时间。它成立的条件是：站点仍在运营、后续还要迭代、或者甲方内部有多个部门共用这套网站。代价是整理和存储成本高，且需要有人持续维护目录结构，否则半年后就找不到对应版本。
第二种是“结果粒度”，只保留最终方案、上线版本、验收单和交接说明。它成立的条件是：项目已经验收、短期内不会大改、接手的服务方明确且沟通顺畅。代价是一旦出现争议，比如某个页面为什么被删、某次跳转为什么失效，只能靠回忆或重新排查。
两者不是对错关系。真正要问的是：下一次变更由谁发起、由谁执行。如果执行方还是原班人马，结果粒度通常够用；如果执行方可能换人，过程粒度更稳妥。
判断保留粒度的三个依据
- 变更频率：过去半年改动少于两次，结果粒度够用；每月都有调整，过程粒度更省事。
- 接手方是否独立：接手方需要自己看懂结构，就必须有方案说明和上线记录，不能只给一个压缩包。
- 是否存在对外承诺：页面内容、服务说明、备案信息涉及对外表述时，保留修改前后的对照记录，比只留最终版更有用。
这三条里，只要有一条指向“会换人”或“会被追问”，就应把粒度提高一档。反过来，如果三条都指向“内部自用、改动少、原班人马”，压缩到结果粒度是合理取舍，不必为了齐全而齐全。
一个可执行的动作：先做一次“接手演练”
假设一个场景：项目结项三个月后，新来的运营要改首页一处服务说明，但他没参加过原项目。此时把最终源码包和验收单交给他，看他能否在不问原负责人的情况下完成三件事——找到该段文字所在的页面文件、判断这段文字是否影响其他页面、确认改完后由谁验收。如果三件事里有两件卡住，说明当前粒度不够，需要补的是方案说明和页面与文件的对应关系，而不是把所有聊天记录都翻出来。
这个动作的结果会直接影响下一步：演练通过，就按结果粒度归档并封存；演练不通过，就把缺失的那一类文档补上，再重新演练一次。补文档时优先补“页面与文件对应表”和“变更原因说明”，这两类最常被用到，也最难靠源码本身还原。
保留粒度落到具体文件时的例外
有几类内容不适合按统一粒度处理。涉及账号、密钥、后台入口的信息，不应随项目文档长期留存，应单独移交并设定保管责任人；涉及第三方平台提交记录的材料，保留提交时间和结果即可，中间草稿没有长期价值；涉及报价和合同变更的文档，按合同约定期限保留，不因项目结束而自行缩短。
另外，如果站点已经停止运营但域名仍在续费，建议至少保留最终版本快照和一份文字版结构说明。原因很实际：域名重新启用时，重新建站的成本通常高于翻出一份旧结构说明。这条不适用于彻底放弃域名的情况。
归档时最容易被忽略的一步
确定粒度后，还要写一份归档说明，放在文档目录的第一层。它不需要长，但要写清三件事：这批文档对应哪个时间段的项目、按什么粒度整理、谁负责后续调取。没有这份说明，粒度定得再合理，接手的人也不知道该从哪里看起。归档说明本身也应随文档一起移交，而不是留在原负责人的本地电脑里。
最终判断可以简化成一句话：文档粒度是否合适，取决于下一个打开它的人能不能独立完成一次小改动。能，就停在这个粒度；不能，就补到能为止。
