网站设计外包项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /78685ee8f49c.html
📄
网站设计外包项目结束后历史文档需要保留到什么粒度
结论先说：外包项目结束后，历史文档不该按“全部留着”或“全部清掉”处理，而应按可复原一次决策的粒度保留。也就是说，当未来有人问“这个页面为什么这样设计”“这版样式为什么被替换”“这个功能为什么没做”，你能用留存文档回答到原因和约束，而不只是找到一张过时的效果图。低于这个粒度，文档只剩装饰；高于这个粒度，你会为无用的中间稿付出长期维护成本。
先分清三类文档，保留策略完全不同
外包交付的文档通常混在一起，直接决定保留粒度的是它们的用途，而不是文件格式。可以按下面三类拆开：
- 决策记录类：需求确认、范围变更、验收标准、关键取舍的沟通结论。这类要保留到“谁在什么约束下同意了什么”，粒度偏粗但必须完整。
- 可执行资产类：设计源文件、组件规范、样式变量、部署说明。保留粒度取决于你后续是否还要自己改；如果还要迭代，缺一个变量说明就可能导致改版走样。
- 过程稿类：多轮草图、被否掉的方案、临时截图、会议录屏。这类最容易堆积，也最该设退出条件。
一个实际动作：在验收前让外包方按这三类各建一个目录，并在决策记录里写清每份关键文档对应的版本号。这样做的结果是，后续你要判断某份过程稿能不能删时，不必靠记忆，而是看它是否被决策记录引用。如果没有任何决策引用它，删除的代价通常很低。
出现“文档很多却查不到原因”时，先怀疑粒度错位
有一种与直觉相反的结果：项目结束后文档数量不少，但半年后没人能解释某次改版。常见解释有三种，需要用可核对的证据区分，不能只看文件多少。
- 保留的是结果，不是原因。证据是：能找到最终页面截图，但找不到当时为什么放弃另一版布局的说明。这种情况下增加截图数量没用，要补的是决策记录。
- 保留的是过程，不是结论。证据是：草图和讨论记录齐全，但没有一份被确认的验收口径。此时应把结论类文档单独抽出，过程稿可以降级甚至退出。
- 保留粒度与接手人能力不匹配。证据是：接手的人能看懂设计稿，却看不懂部署步骤或组件依赖。这时要补的是可执行资产说明，而不是继续堆过程文件。
注意，文档检索量下降、某目录长期无人打开，并不能单独证明这些文档该删。它也可能只是当前没有改版需求。判断退出前，至少确认它没有被决策记录引用、也不属于可执行资产。
保留、改写还是退出：三种取舍的适用前提
不必对每份文档都做同样处理，三种动作各有成立条件。
- 保留原样：适用于决策记录和仍在使用中的可执行资产。前提是它们与当前线上版本一致，且有人能读懂。若线上已多次改版而文档未更新，保留原样反而会误导。
- 改写压缩：适用于过程稿里仍有参考价值的取舍。做法是把“为什么否掉某方案”浓缩成一段结论，放进决策记录，然后退出原始草图。前提是你能确认这段结论对后续决策还有约束力。
- 退出清理：适用于未被引用的中间稿、重复截图、临时导出文件。前提是决策记录和可执行资产已经独立完整。退出的结果应当是减少检索干扰，而不是丢掉唯一能解释某次变更的依据。
假设一个场景：外包方交付了十二版首页草图，最终上线的是第七版。如果决策记录里写明“因移动端首屏信息密度限制，放弃前六版的横向卡片布局”，那么前六版草图可以退出，只留这句结论。如果没有这句结论，前六版里恰好包含未来想复用的布局思路，删掉后就只剩猜测。这个例子说明，粒度由“未来是否需要复原判断”决定，而不是由文件新旧决定。
给历史文档设一个可执行的保留下限
与其争论保留多少 GB，不如设一条下限：任何影响过线上版本的决策，都必须能追溯到一份带日期的确认记录。围绕这条下限，可以这样落地：
- 决策记录保留结论、约束和日期，不保留完整聊天记录。
- 可执行资产保留到能独立还原当前版本的程度，包括样式变量和组件说明。
- 过程稿只保留被决策记录引用过的部分，其余在验收后一段时间退出。
- 每份保留文档标注它对应哪个线上版本，避免旧文档被当成现状。
完成这一步后，下一步不是继续加文档，而是定期核对：线上版本变了，对应的决策记录和资产说明是否同步更新。如果不同步，优先修正文档而不是补写回忆。这样，保留粒度才会随着项目演进而保持可用，而不是在项目结束那天就冻结成一份没人敢删、也没人敢信的档案。
