网页设计外包：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d6791b1b3179.html
📄
网页设计外包：项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度不按“文件多少”决定，而按“下一次改动时是否还需要重新问人”决定。凡是离开外包方后，你自己团队无法在半小时内还原的设计决策、接口约定和素材来源，都应留下可读记录；纯过程稿、重复导出件和已被最终版完全覆盖的中间稿，可以只留版本号与一句话说明。这样做的直接结果是：下次改版或换供应商时，你能自己判断哪些页面能动、哪些结构不能碰，而不是先付一笔重新梳理的费用。
先拿一份你手里的文件做粒度判断
选一个具体对象，比如外包交付的首页设计源文件或一份组件说明。不要先问“要不要全留”，而是逐项问三个问题：这份文件对应线上哪个页面或组件？它记录的是一次性讨论，还是仍然生效的规则？删掉它之后，接手的人能否从别的文件推出同样结论？
如果三个问题里有一个答不上来，说明这份文件目前既不算过程稿，也不算有效文档，只是堆积物。此时的动作是给它补一行归属说明，例如写明对应的页面路径、生效范围和最后确认日期。补完后再判断：能对应线上现状的，归入保留层；只对应某次讨论的，归入可清理层。这个动作会直接减少你后续翻找的时间，也让清理不再靠感觉。
把保留分成三层，而不是“全留或全删”
更可执行的粒度是三层：
- 长期层：最终设计源文件、组件规范、字体与图片授权说明、表单字段与提交去向、页面之间的跳转关系。这些是换人接手时的最低依据，通常应长期保留。
- 中期层：改版前的旧版页面、A/B 两个方向的对比稿、内容替换记录。保留到下一次大改版完成为止，之后可压缩为一份变更摘要。
- 短期层：重复导出图、临时占位文案、会议截图、被否掉的草稿。项目验收后即可清理，但清理前用一页清单记下“曾考虑过什么、为什么没采用”。
三层的区别不在格式，而在“是否仍约束现在的页面”。一份 PNG 导出图如果对应线上正在使用的版式，它属于长期层；一份完整源文件如果对应早已下线的活动页，它只属于中期层。按这个标准分，你会发现需要长期保留的往往比想象中少。
一个假设例子：删掉中间稿之后会发生什么
假设你外包做了一个产品列表页，交付物里有三版布局稿、一份组件说明和最终源文件。验收后你只留最终源文件，删掉前两版和组件说明。半年后要新增一个筛选条件，新接手的人看到源文件里筛选区是空的，无法判断当初是有意留白还是漏做，只能重新设计并可能改动列表结构。
反过来，如果你保留组件说明，并在其中写清“筛选区预留但未启用，字段与后端接口见某份约定”，接手人就能直接沿用。这个对比说明：真正需要保留的粒度是“决策依据”，而不是“设计过程”。上例中，前两版布局稿可以删，但组件说明和一句接口约定不能删。你可以用同样的方法检查自己手里的文件：删掉它，下一个改动者会不会被迫重新做决定？会，就留；不会，就清理。
把清理动作和下一次改动挂钩
文档保留不是一次性任务。更稳妥的做法是把它绑到具体触发点：每次上线新版本后，检查被替换的页面文档是否已降级为中期层；每次更换外包方或内部负责人前，确认长期层文件是否齐全且能打开。触发点比“每季度整理一次”更容易执行，因为你有明确的完成信号。
执行时注意一个前提：保留粒度要和你的实际维护能力匹配。如果团队没有专人维护源文件，保留大量分层目录反而会增加误用旧版的风险。此时应把长期层压缩到最少，并在文件名或说明中标注生效状态。判断标准仍然是同一个：接手者能否不依赖口头解释就继续工作。
需要核对的信息与不需要留意的部分
如果文档中涉及具体外包方提供的账号、授权凭证或第三方素材来源，这些信息需要在使用前核对当前是否仍然有效，不能默认项目结束时的状态一直延续。普通的设计原则、组件命名和文件分层方法则不必附加额外核验步骤，按你自己团队的接手习惯整理即可。
最后检查一遍：你手里那份文件，是否已经写清了它对应哪个线上页面、是否仍然生效、删掉后谁会受影响。这三项补齐，保留粒度的问题就变成了可执行的归档动作，而不是每次改版前都要重新争论的悬案。
