企业建站外包：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0c673b2c7a96.html
📄
企业建站外包：项目结束后历史文档需要保留到什么粒度
粒度取决于你是否还要为同一套站点做二次开发或迁移。如果后续仍由原外包方维护，保留到“能复现当前线上状态”即可；如果准备换服务商或自己接手，则要保留到“新人只靠文档就能独立部署和排障”。判断标准不是文档多少，而是离开原团队后能否不依赖口头记忆继续运维。
条件一：继续由原外包方维护时，保留到可追溯即可
这种前提下的核心风险是人员变动而非技术断层。你不需要拿到全部源码级注释，但必须能回答三个问题：线上跑的是哪个版本、改过什么、出问题找谁。粒度可以控制在变更记录加关键配置这一层。
- 每次上线保留一份变更说明：日期、改动模块、影响页面、回滚方式。
- 保留当前生效的环境配置清单，如服务器区域、运行环境大版本、依赖服务名称，不必保留明文密钥。
- 保留域名、证书、账号的归属与续期责任人，避免到期无人处理。
实际动作：让外包方在每次交付后补一页变更记录，你方项目对接人归档。结果是下次要查“某页面为什么变了”时，能在几分钟内定位到具体上线批次，而不是翻聊天记录。这一步做完，再决定要不要向源码级文档升级。
条件二：准备换服务商或自建团队时，粒度必须升到可独立部署
一旦维护主体要变，原团队的口头经验就不再可用。此时文档的目标是让一个没参与过项目的人，仅凭文档完成环境搭建、代码部署和常见故障处理。粒度要求明显更高：
- 环境与依赖：运行环境版本、扩展、第三方服务清单，以及各自的作用。
- 部署步骤：从拉取代码到上线的完整顺序，包括构建命令和目录约定。
- 数据与备份：数据库结构说明、备份位置、恢复演练步骤。
- 账号与权限交接：域名、服务器、代码仓库、第三方接口的归属转移。
- 已知问题清单：历史遗留缺陷、临时绕过方案、不建议改动的部分。
这里有个容易忽略的例外：如果站点用了外包方自研的私有框架或封闭组件，文档再全也无法真正独立维护。此时优先级不是补文档，而是在合同或交接阶段确认源码与授权是否可转移。拿不到可转移的源码，文档粒度再细也只是说明书，不是接管能力。
用一份假设例子判断该保留到哪一层
假设站点计划半年后更换服务商。你可以先做一次“盲测”：找一个没接触过该项目的人，只给文档，看能否在测试环境把站点跑起来。若卡在环境依赖或部署顺序，说明粒度不够，需要补到可独立部署；若能顺利跑通，只是不清楚某段业务逻辑的来历，则属于可接受的业务注释缺口，不必强求逐行说明。
这个测试的价值在于把“文档够不够”从主观感受变成可观察结果。测试暴露的缺口，就是你下一步要求原外包方补交的具体清单，而不是笼统地要“全部资料”。
哪些内容不必追求高粒度
不是所有历史文档都值得细留。设计稿的历史版本、已被替换的文案、早期废弃的测试数据，通常只需保留最终版和变更记录即可。把精力集中在能影响上线、恢复和安全的文档上，比平均用力更有效。
需要提醒的是，请求量下降、抓取异常或某项统计归零，并不能单独证明文档处理正确或错误，它们可能有多种解释。文档粒度的判断依据应回到“接手人能否独立完成部署与排障”这个可验证的标准上。
先明确后续由谁维护，再按对应粒度归档；交接前用盲测验证一次，缺什么补什么，这样项目结束后的文档才不会变成一堆无人看得懂的压缩包。
