网站外包：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /41d59383b9fa.html
📄
网站外包：项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度不按“全部留”或“全删”决定，而按文档是否还能支撑下一次改动来定。判断对象可以是你手里那份《需求确认书》或一张页面原型图——如果半年后要换服务商、改版或排查故障，它能让你不必重新问一遍业务规则，就值得留；如果只是过程性草稿且已被最终版覆盖，可以只留版本索引。前提是：项目已验收、款项结清，且你已拿到源码、数据库和账号的完整控制权。若关键前提变化——比如原外包方不再响应、或业务从展示型转为交易型——保留粒度要整体上调一档。
先拿一份文档做粒度判断
把《需求确认书》摊开，逐条看它是否包含可复用的决策依据：字段含义、页面跳转条件、支付或表单的校验规则、第三方接口的字段映射。这些内容一旦丢失，下次改动就得靠猜。反之，会议纪要里“周五前给初稿”这类排期信息，验收后价值很低。
判断动作：给每份文档标一个用途标签——规则依据、实现依据、过程记录。规则依据和实现依据保留完整版本；过程记录只留最终版和变更摘要。这个动作的结果会直接决定下一步：只有规则依据齐全，你才能把维护工作交给新团队而不必重新梳理业务。
按文档类型定保留粒度
需求与规则类：留到可执行粒度
- 需求确认书、字段说明、权限矩阵：保留最终签字版，以及每次变更的差异说明。
- 原型图与交互说明：保留最终版；被推翻的中间稿只留文件名和日期索引。
- 业务规则例外清单（如某类订单不参与折扣）：必须留，且注明生效条件。
实现与配置类：留到能复现环境
- 数据库表结构与字段注释：保留导出文件，注明导出时间。
- 第三方接口配置说明：保留字段映射和回调地址规则，密钥单独存放，不写进普通文档。
- 部署步骤与环境变量清单：保留到能按步骤重建测试环境的程度。
过程与沟通类：留索引即可
聊天记录、排期表、中间稿截图，验收后只需保留一份目录索引，写明“某类问题在哪个文件里可查”。这样做的理由是：它们的价值在于追溯，而不在于日常使用。若原外包方仍负责维护，索引可再精简；若已更换团队，索引要保留得更细，因为新团队需要靠它定位历史决策。
关键前提变化时，粒度如何调整
变化前：原外包方继续维护、业务规则稳定。此时规则依据留最终版，实现依据留可复现版，过程记录留索引，足够。
变化后：原外包方不再响应，或业务从展示型转为交易型。此时要整体上调：把接口字段映射、权限判断逻辑、历史数据迁移说明都补进规则依据；过程记录中涉及“为什么这样改”的讨论也要保留，因为新团队没有上下文，只能靠文档还原决策链。
一个假设例子：某企业站原本只展示产品，文档只留了页面清单和栏目结构。后来要加在线询价并接CRM，如果当初没留表单字段与CRM字段的映射说明，新团队就得重新确认每个字段含义，工期至少多出一轮沟通。这个例子的数字仅用于说明比较方法，不代表实际项目结果。
落地成一份可移交的文档包
按以下顺序整理，能直接用于移交或自查：
- 建一个总目录，按“规则—实现—过程”分三层。
- 每份文档文件名带版本和日期，例如
需求确认书_v2_20240610。 - 写一页《文档用途说明》，讲清哪份文件回答哪类问题。
- 把密钥、账号恢复方式从普通文档中拆出，单独交接。
- 做一次验证：让不熟悉项目的人只靠文档回答“某个字段为空时页面怎么处理”，答不上来就说明粒度不够。
验证结果决定下一步：能答上来，说明规则依据已到位，可以按现有粒度归档；答不上来，就回到对应文档补字段说明或例外条件，再重新验证。整个过程不需要追求文档数量，只需要保证下一次改动时不必重新问业务方。
