淮南建站服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /22f8ea88b604.html
📄
淮南建站服务：项目结束后历史文档需要保留到什么粒度
项目验收后，历史文档不必全量永久保留，也不该只留一份上线截图。可操作的粒度是：与当前站点运行、后续改版和权责追溯直接相关的文档保留到可复现程度；纯过程性沟通和中间稿在约定期后清理。判断标准不是文档多少，而是“下一个接手的人能否只靠它完成一次修改或排查”。
两种条件下，保留粒度完全不同
第一种条件：站点仍在使用同一套程序、同一套栏目结构，且淮南建站服务方仍承担后续维护。此时文档要保留到可复现当前线上状态的粒度，包括最终版栏目结构说明、页面模板与字段对应关系、表单接收与通知配置、域名与服务器指向记录、第三方服务开通项清单。中间稿、旧版设计稿、被否定的方案可以只留最终版加一份变更记录。
第二种条件：项目已交付给客户自有团队，或即将整体改版、更换服务方。此时粒度要提高到可独立接手：除上述内容外，还应保留数据库结构说明、自定义字段含义、定时任务或接口调用清单、部署步骤、回滚方式。原因是接手方没有参与过程，缺一项就可能只能靠猜。
两种条件的分界不是合同金额，而是“后续由谁改、改动频率多高、原班人马是否还在”。若后续半年内无人改动，可按第一种执行；若已确定换人接手，直接按第二种准备，省去二次整理。
判断某份文档该留还是该删
可以用三个问题快速分类：这份文档能否解释线上某一个可见结果？删掉后，下一次修改是否需要重新询问原参与人？它是否记录了对外承诺或费用归属？三个问题有一个为“是”，就保留；全为“否”，归入可清理范围。
- 保留到可复现：栏目与模板对应表、字段字典、表单与通知链路、域名解析与证书到期记录、第三方账号归属、验收确认件。
- 保留摘要即可：会议记录、需求讨论、设计多稿。做法是合并成一份变更日志，写清时间、改了什么、为什么改。
- 可定期清理：临时测试文件、重复导出的中间数据、已作废的旧版页面备份。清理前确认没有唯一副本。
一个假设例子：某站点上线一年后要新增一个报名表单。若字段字典和通知配置还在，接手人半天内可完成；若只剩页面截图，就需要重新反查表单提交到哪里、是否触发邮件，工作量成倍增加。这个对比说明粒度应围绕“下一次改动”设定，而不是围绕“资料齐全”设定。
实施动作：先做一次文档分级，再定保留期限
具体动作是：在项目收尾会上，把现有文档按上面三类打标，形成一份清单，写明每份文档的保留级别和到期处理方式。动作的结果直接影响下一步——清单确认后，才能确定哪些文档放入长期归档、哪些放入定期清理，避免全部堆在一起。
执行时注意两点：一是长期归档的文档要有唯一入口和版本标识，避免同一内容多个副本互相矛盾；二是清理动作要留记录，写明清理了什么、依据哪条约定，防止日后无法解释某份材料为何缺失。
规模化后出现的例外
单个项目按上述粒度执行通常够用，但项目数量增加后会出现例外。例如多个站点共用同一套模板或同一批第三方账号时，文档如果按站点分散保存，就会出现同一配置在多处记录、更新不同步的问题。此时应把共用部分抽成一份公共说明，各站点只记录差异项。
另一个例外是人员变动频繁的团队。原参与人离开后，口头补充的渠道中断，文档粒度需要整体上调一档，尤其是账号归属、部署步骤和回滚方式。反之，如果团队稳定、改动极少，可维持基础粒度，把精力放在变更日志的连续性上，而不是追求文档数量。
需要说明的是，保留粒度没有统一标准，取决于后续维护安排和交接方式。把粒度与“谁接手、多久改一次”绑定，比套用固定清单更可靠。
