网站优化外包团队：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1a058406e0e1.html
📄
网站优化外包团队：项目结束后历史文档需要保留到什么粒度
结论先给：保留粒度不按“文档类型”一刀切，而按“这份文档将来会被谁、因为什么原因重新打开”来决定。如果外包关系彻底结束且站内不再依赖旧系统，保留到可追溯结论和交接清单即可；如果站内仍运行对方配置过的结构、模板或数据管道，就要保留到能独立复原和修改的粒度。下面用两种条件展开，并给出判断依据和具体动作。
条件一：旧系统已下线、旧合作关系不再续用
这种情况下文档的价值从“操作手册”降级为“决策凭证”。你不需要保留对方内部的工作过程、草稿、临时截图和逐日沟通记录，但需要保留能回答三个问题的材料：当时改了什么、为什么改、如果出问题从哪里回退。
建议保留的粒度：
- 结论级文档：改版或优化方案的目标、上线范围、最终采用与放弃的选项及理由。
- 交接清单：账号、域名解析、服务器、第三方服务、数据导出位置的归属说明，只写位置和责任人，不写密码明文。
- 回退依据：旧版本备份的存放位置、备份时间点、恢复时需要谁确认。
- 未决事项：对方提出但未执行的风险点，标注“未处理”而非删除，避免后来者误以为已解决。
可以清理的粒度包括：过程性聊天记录、已被最终稿取代的中间版本、与本站无关的通用培训材料。清理前先做一次抽检：随机打开三份准备删除的文档，确认其中没有唯一记录着某个账号、某条规则或某个外部依赖。如果抽检发现唯一信息，就把这条信息摘出来并入交接清单，再删除原文档。这个动作的结果会直接决定下一步：交接清单越完整，后续可删除的范围越大；反之就应整体保留到清单补齐为止。
条件二：站内仍在运行对方搭建的结构或配置
只要旧模板、旧跳转规则、旧数据字段还在生效，文档就不能降到结论级。此时你面对的不是“历史”，而是“没有原作者的现行系统”，粒度必须支持一个不熟悉背景的人独立修改。
需要保留到可复原粒度的内容：
- 结构说明：页面类型、字段含义、模板之间的调用关系，用文字或简单示意图表达即可。
- 规则清单：跳转、规范化、参数处理等规则的触发条件和例外情况。
- 变更记录：每次改动的时间、范围、执行人角色和验证方式。
- 依赖说明：外部接口、定时任务、数据来源，以及它们失效时页面会表现成什么样。
一个注明假设的短例子：假设旧系统里有一条规则，把带特定参数的列表页统一指向主列表页。文档只写“参数页已处理”属于结论级，后来者无法判断新增参数是否该走同一规则；写成“参数 A、B 走跳转，参数 C 保留原页，原因是 C 用于站内筛选”才是可复原粒度。差别不在于字数，而在于下一个人能否不改代码就判断新情况。
用“重开文档的原因”做取舍依据
判断粒度时，可以先列出未来一年内可能重新打开这些文档的三种原因，再倒推需要什么材料：
- 排查异常：需要规则清单和变更记录，结论级文档不够。
- 接手修改：需要结构说明和依赖说明，最好附上验证方式。
- 追责或复盘：需要结论级文档和未决事项，过程记录通常不必保留。
如果三种原因都可能出现，就按最高要求保留；如果只可能出现第三种，结论级即可。这里没有普适的年限标准，因为决定因素是系统是否还在运行、人员是否还记得背景，而不是日历。一个可执行的动作是：在项目结束会议上让接手人当场说出“如果这条规则要改，我会先看哪份文档”。如果对方答不出或指向一份已计划删除的文件，说明粒度定低了，应把该文件移出删除清单。
例外：哪些材料无论条件如何都值得留
有两类内容不受上述条件限制。一是对外承诺与授权记录，例如书面确认过的变更范围、数据使用授权，这类材料涉及责任边界，删除后难以重建。二是不可再生的判断依据，例如当时对比过的两个方案及放弃理由。后者看起来像过程记录，但一旦相关人员离开，这类信息无法从代码或页面反推出来。
反过来，有一类材料即使系统仍在运行也可以精简：对方提供的通用操作教程、与本站配置无关的平台说明。判断方法是看它是否包含本站特有的参数、路径或字段名。不含这些特有信息的，属于可替换资料，不必占用交接文档的主体位置。
最后落到一个顺序上：先确认旧系统是否仍在生效，再列出重开文档的原因，然后按最高要求确定粒度，最后才执行删除。删除动作之后要留一份“已删除清单”，写明删了什么类别、依据什么判断。这样即使后来发现删多了，也能知道缺口在哪里，而不是面对一个无法解释的空目录。
