益阳建站服务，项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /196f8aabec52.html
📄
益阳建站服务，项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度不按“文件多少”定，而按“下一次需要还原某个决定时，能不能不靠人回忆”来定。项目结束后的历史文档至少要能支撑三类动作——解释一个页面为什么这样写、找到一次改动的批准依据、在换人接手时重建交付边界。达不到这三件事的粒度就是过细，做不到的就是过粗。
矛盾现象：同一份文档，两边都说“够了”和“不够”
常见情形是：建站方交付了一个压缩包，里面有首页文案、栏目结构和若干截图；客户方市场人员认为资料齐全，技术接手的人却认为无法继续。双方都没有说谎，分歧来自对“文档”一词的理解不同。
一种解释是粒度问题：交付方按“成果物”组织文档，只保留最终状态；接手方需要“过程证据”，要能看到某一版为什么被替换。另一种解释是责任边界问题：交付方认为上线即结束，后续改动属于新需求；客户方认为同一项目的延续，理应能追溯到当初的约定。
这两种解释指向不同的补救动作。如果是粒度问题，补的是版本记录和变更说明；如果是边界问题，补的是验收清单和变更确认记录。先分清是哪一种，再决定保留什么。
能区分两种解释的证据
可以拿一个具体页面做核对，而不是泛泛检查文件夹。假设某产品页在项目中期把主标题从功能描述改成场景描述，然后问三个问题：
- 能否找到改动前的版本，以及改动发生的日期？
- 能否找到提出改动的人，以及当时确认改动的记录？
- 能否说明这次改动是否影响其他页面，比如导航文字或表单提示？
如果第一个问题能答、后两个答不上，偏向粒度问题——保留了结果，没保留依据。如果三个问题都答不上，但双方对“谁该负责记录”有分歧，偏向边界问题。这个核对不需要工具，用现有文件走一遍即可。
需要提醒的是，文件数量多、目录层级深，并不能证明粒度合适。大量截图和重复导出件往往只是让压缩包变大，真正要查一个决定时仍然找不到。反过来，文件很少但每个关键改动都有一条说明，也可能已经够用。
建议保留的三层粒度
把历史文档分成三层，比按文件类型分类更实用。
- 决策层：每个影响用户可见内容的改动，保留一条记录，写明改了什么、为什么改、谁确认。这一层决定文档能不能被接手人理解。
- 结构层：保留最终版的栏目结构、页面清单和链接关系。这一层决定接手人能不能快速定位到具体页面。
- 素材层：保留仍在使用的图片、字体和文案源文件。已经下线的素材可以只留归档说明，不必长期保留全部原始文件。
三层里，决策层最容易被省略，也最影响后续判断。结构层和素材层可以按实际使用频率收缩。
一个可操作的判断动作
项目结束前，让接手方在不询问原项目成员的前提下，尝试完成一次小改动，例如修改某个页面的联系方式区块。记录他卡在哪一步：
- 如果卡在“不知道这个区块归哪个页面管”，说明结构层不够。
- 如果卡在“不知道能不能改、谁批准”，说明决策层不够。
- 如果卡在“找不到源文件”，说明素材层不够。
卡点位置直接决定下一步补什么。这个动作的价值在于把“资料够不够”的争论，变成一次可观察的操作结果。假设这次尝试中接手方顺利完成了改动，但事后发现改错了页面，那问题不在文档缺失，而在页面命名或结构说明有歧义，需要补的是标识规则，而不是更多文件。
保留期限与清理条件
粒度确定后，再谈保留多久。可以按“是否仍会影响线上内容”来判断：仍在上线的页面，其决策记录和结构说明继续保留；已经下线且不再恢复的栏目，保留一份归档说明即可，不必保留全部中间版本。
清理时不要只按时间删除。更稳妥的做法是先确认三件事：没有未完成的改动依赖这批文件、没有正在进行的争议需要它作为依据、接手方已确认现有文档能独立支撑日常维护。三条都满足，再收缩素材层。
最终要留下的不是最全的一套文件，而是一套能让下一个人独立做出正确判断的最小集合。判断标准始终是同一个：不靠回忆，也能还原决定。
