甘肃网络公司：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7f67b93c3d60.html
📄
甘肃网络公司：项目结束后历史文档需要保留到什么粒度
结论先给：多数甘肃网络公司交付的网站与推广项目，历史文档应保留到“能独立复现一次决策”的粒度，而不是保留到“能重新做一遍项目”的粒度。前者通常包括需求变更记录、上线版本说明、关键配置与账号归属说明；后者会把过程稿、中间素材、重复沟通记录全部留下，成本高且检索困难。但这个结论有一个明确的反例：如果合同约定了后续维护期、二次开发义务或验收争议尚未关闭，粒度就必须上调到可追溯每一次变更责任的程度，否则一旦出现故障或纠纷，你无法证明当时是谁改了什么。
为什么“能复现一次决策”比“保留全部过程”更实用
项目结束后，文档的真实使用场景通常只有三类：接手的人想知道某个页面或功能为什么是现在这样；运维的人想知道某次改动动了哪些配置；发生争议时双方想确认某个需求是否被确认过。这三类场景都不需要完整过程稿，只需要决策点、变更结果、责任人、时间四个要素齐全。
反过来，如果按“全部保留”执行，常见结果是文件夹体积膨胀、命名混乱、旧版本覆盖新版本。真正需要时找不到，等于没保留。所以粒度标准不是“越多越安全”，而是“每一份留下的文档，都能回答一个具体问题”。
可以按四层来定粒度，而不是按文件类型
按文件类型分（图片、文档、表格）没有决策价值。更可操作的是按文档在项目中的角色分层：
- 决策层：需求确认书、验收单、变更说明。这类必须长期保留，因为它们定义“做了什么、为什么这么做”。
- 结构层：站点结构说明、栏目规划、推广账户结构说明。保留最终版即可，中间讨论稿可清理。
- 配置层：域名解析记录、服务器环境说明、统计与推广账号的归属和权限说明。保留最终生效版本，并注明生效时间。
- 素材层：设计源文件、中间图片、文案草稿。只保留最终上线使用的版本，过程稿在验收后清理。
这样分的直接好处是：清理时你知道哪些不能动，交接时你知道先看哪一层。
一个反例：维护期未结束就按最低粒度清理会出问题
假设某项目验收后进入六个月维护期，团队按“只留最终版”清理了配置变更记录。维护期内客户提出某功能异常，排查时发现需要确认三周前是否调整过某项设置，但记录已被清理。此时只能靠记忆或重新测试推断，排查时间明显拉长。
这个反例说明：维护期、质保期、二次开发约定，是粒度上调的触发条件。只要这些条件存在，配置层和决策层的变更记录就应按时间顺序保留，而不是只留最终版。反过来，如果项目已彻底结项、无后续义务、无争议，且交接已完成，那么清理素材层和结构层中间稿是合理的。
怎么判断清理是否安全：看证据，不看感觉
清理前可以用一组可核对的信号来判断，而不是凭“应该没人看了”这种直觉：
- 交接是否已完成，接手方是否确认能独立处理日常运维。
- 合同中的维护、质保、二次开发条款是否已到期或已履行完毕。
- 是否存在未关闭的验收异议或付款争议。
- 账号与域名归属说明是否已单独存档，且不依赖某个人在职。
如果前三条都是“是”，第四条已落实，那么按四层粒度清理是安全的。如果其中任何一条是否定的，就先不要清理配置层和决策层。这个判断动作本身会产生结果：确认安全后再清理，能减少后续返工；确认不安全而暂停清理，则避免了一次可能无法补救的信息丢失。
下一步动作：先做一次文档分层盘点
具体动作是：把现有项目文档按上面四层归入四个文件夹，对每一层标注“保留期限”和“责任人”。盘点完成后，你会得到两个直接结果：一是能立刻看出哪些层缺文档，缺的那层就是下次项目要补的交付项；二是清理范围被限定在素材层和结构层中间稿，不会误删决策层和配置层。这个结果会直接影响下一份合同的交付清单怎么写，而不是停留在“文档要保存好”这种无法执行的说法上。
