公司网站设计：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /11dc12c115aa.html
📄
公司网站设计：项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度由“下一次可能修改它的触发条件”决定，而不是由文档数量决定。如果网站上线后仍会定期改版、换人维护或对接新渠道，文档应保留到可重建结构与内容关系的程度；如果站点进入长期冻结期，保留到能解释现状和恢复关键配置即可，过程稿可以清理。
先判断触发条件，再决定留多细
文档粒度不是越细越安全。真正需要回答的是：未来什么情况下会有人翻出这份文档。常见触发条件有三类，对应不同的保留深度。
- 仍会迭代：半年内可能新增栏目、调整导航或改版首页。此时文档要保留到“结构关系”级别，包括栏目层级、页面模板对应关系、组件复用规则。
- 只做小修：一年内只改文案、换图、调联系方式。保留到“操作说明”级别即可，说明内容在哪里改、改完影响哪些页面。
- 基本冻结：站点作为展示窗口长期不动。保留到“现状快照”级别，记录当前结构、关键配置和恢复方法，过程稿可退出。
先写清触发条件，再决定留什么。否则容易把大量中间讨论稿当成资产长期保存，真正有用的结构说明反而缺失。
保留、改写、退出：三种处理各自的适用前提
历史文档的处理不是全留或全删，而是按用途分流。
保留：结构说明与配置依据
适用前提是未来会有人接手维护，且接手者不参与过原项目。这类文档要能回答“这个页面为什么长这样”。保留内容包括栏目结构图、模板与页面类型对照、导航和链接规则、表单或交互组件的用途说明。粒度到“能据此重建页面关系”即可，不必保留每一次像素级调整。
改写：散落在聊天和邮件里的决策
适用前提是决策依据只存在于对话记录中，没有进入任何正式文档。这类内容应改写成一页“决策记录”，说明当时选了什么、放弃了什么、限制条件是什么。改写时只留结论和理由，不复述讨论过程。这样做的代价是需要人工整理，但收益是交接时不必翻遍历史消息。
退出：过程稿与已失效版本
适用前提是同一内容已有最终版，且旧版不再被任何页面引用。线框图草稿、被否定的配色方案、临时占位文案可以退出。退出前确认两点：没有页面仍在调用旧资源，没有对外承诺依赖旧版本。满足这两点，清理不会影响现状解释。
一个假设例子：同样上线，为什么保留深度不同
假设两家公司都用同一套流程完成网站设计。A 公司计划每季度更新案例栏目，并可能接入新的内容渠道；B 公司上线后只保留展示页，两年内不打算改动。
A 公司应保留到模板与内容类型的对应关系，并记录新增栏目时的操作路径。这样下一次迭代时，新接手的人能判断新页面该用哪个模板，而不是重新猜结构。B 公司只需保留当前栏目清单、关键配置说明和恢复步骤，过程稿可以退出。两者保留深度不同，不是因为项目质量差异，而是因为后续触发条件不同。
这个例子说明：粒度选择应服务于“下一次动作”，而不是追求文档完整感。
可执行动作：用一次检索验证粒度是否够用
判断保留粒度是否合适，可以做一个具体动作：假设半年后有人要新增一个栏目，只允许查阅现有文档，看能否回答三个问题——新栏目放在哪个层级、用哪类页面模板、需要同步更新哪些导航或链接。
如果三个问题都能从文档中找到依据，说明粒度足够。如果只能回答其中一部分，说明缺少结构关系说明，应补充模板对照或层级规则。如果完全无法回答，说明文档停留在过程记录层面，需要改写为结构说明。
这个动作的结果会直接影响下一步：能回答，就可以清理过程稿；不能回答，就先补结构文档，再决定哪些旧稿退出。清理不是目的，让下一次修改有据可依才是。
保留粒度需要写明的适用条件
任何粒度方案都有前提。文档保留策略应注明适用条件：站点是否仍会迭代、是否有固定维护人、是否依赖外部服务配置。条件变化时，粒度也应重新评估。例如原本冻结的站点突然要改版，原先只保留现状快照就不够，需要补充结构关系说明。
同时要避免一个常见误判：把访问量下降或抓取异常当作文档处理正确与否的证据。这些现象可能来自渠道变化、内容调整或外部环境，不能单独证明保留粒度合适。粒度是否够用，仍应以“下一次修改能否顺利执行”为判断依据。
把触发条件、处理方式和验证动作写进同一份交接说明，历史文档才不会在项目结束后变成无人敢删、也无人会用的堆积物。
