公司网络推广网站：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1f420c7f8625.html
📄
公司网络推广网站：项目结束后历史文档需要保留到什么粒度
没有统一粒度，只有与用途匹配的粒度。项目结束后，文档通常分三类处理：能支撑后续运维和追责的保留到可复现程度，只服务当时决策的压缩成结论摘要，过程性草稿和重复版本可以退出。判断标准不是文档多少，而是三个月后另一个人能否凭它回答“当时改了什么、为什么改、现在怎么回退”。
先按用途分层，而不是按文件类型保留
同一批项目文档里，价值差异极大。可按三个层次划分：
- 可复现层：上线配置、页面与模板改动记录、重定向规则、跟踪代码与转化目标设置、数据源和字段说明。这些直接决定后续能否还原或迁移，建议保留到能独立操作的程度。
- 可追溯层：需求确认、验收标准、变更原因、责任人确认记录。保留结论和关键分歧即可，不必保留每一轮讨论。
- 可退出层：中间草稿、重复截图、已被取代的旧版方案、内部试排的排期表。确认无引用关系后即可清理。
分层的好处是避免“全留”造成检索困难，也避免“全删”导致后续接手只能靠猜。实际动作：在项目收尾时给每份文档打一个用途标签，标签决定保留期限和保留形态，而不是由文件后缀决定。
保留、改写、退出各自成立的前提
三种处理方式不是按重要性排序，而是按条件成立：
- 原样保留成立的前提是：该文档未来会被直接执行或核对，且脱离原始上下文仍可读懂。例如重定向规则清单、转化目标配置说明。若文档依赖某次口头确认才能理解，就不满足这个前提。
- 改写压缩成立的前提是：原始过程冗长，但结论和依据仍需留存。典型做法是把多轮讨论压成一页决策记录，写清结论、依据、被否方案及原因。改写后应标注它替代了哪些原始文件，否则会出现两个版本互相矛盾。
- 退出清理成立的前提是：确认没有对外承诺、没有未结责任、没有其他文档引用它。清理前先做一次引用检查，比直接删除更稳妥。
如果团队对某份文档归属哪一类有分歧，说明分歧点其实是“它未来会不会被用到”，而不是文档本身重要不重要。把这个问题转成可核对的项目：列出可能的使用者、使用场景和触发时间，三者都为空时才进入退出候选。
把分歧转成可核对的清单
多角色对同一事实理解不同，常见于“当时是否改过某页面”“这个数据口径是谁定的”。解决办法不是继续讨论，而是把争议落到可核对的条目上：
- 写下争议的具体事实，一句话，不含评价。
- 指出能证明该事实的最小材料：某份变更记录、某次验收确认、某段配置说明。
- 确认该材料是否存在、由谁持有、是否在保留范围内。
- 若材料不存在，把结论改为“无法核实”，并记录当前实际状态，而不是补写一份看似完整的说明。
这一步的实际结果是：原本争论“谁记错了”，会转为“缺哪份材料、要不要补录”。补录的内容应标注为事后整理，与当时的原始记录区分开，避免后来者误以为它是同步产生的。
一个假设例子：粒度不同，后续成本不同
假设某项目结束后半年，运营发现部分旧链接需要重新指向。若保留的是完整重定向规则清单，接手人可直接比对现状，几十分钟内定位差异；若只保留一句“做过链接调整”，则只能重新爬取、逐条推断，成本明显上升。反过来，若保留的是几十版页面草稿，而缺少最终规则清单，检索时间增加却仍无法回答关键问题。这个对比说明：粒度应跟着“未来要回答的问题”走，而不是跟着文件数量走。
需要说明的是，保留粒度再细也不能单独证明处理正确。例如某项统计归零，可能是清理了跟踪代码，也可能是数据源变更、统计口径调整或采集延迟。看到归零先核对配置和口径，再决定是否回退，而不是直接认定是删除文档造成的。
收尾时确认三件事再结束项目
- 可复现层文档是否已独立成篇，不依赖聊天记录或某个人在场。
- 改写后的决策记录是否标注了替代关系，避免新旧版本并存。
- 退出清理是否做过引用检查，并留下清理清单，说明删了什么、依据是什么。
完成这三步后，文档粒度就与后续使用场景对齐了：该细的地方能复现，该简的地方不拖累检索，该退出的不占位置。若项目还有未结的对外承诺或待验收事项，先不要执行退出清理，等责任结清后再处理，顺序反了会让后续核对失去依据。
