淮南网络公司：项目结束后历史文档保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5a4aab5a31b2.html
📄
淮南网络公司：项目结束后历史文档保留到什么粒度
结论先说：多数项目结束后，历史文档应保留到“能独立复原一次决策和一次交付”的粒度，而不是把过程稿全部留档。判断标准是——如果三个月后有人问“这个页面为什么这样改、当时依据什么”，你能不能用现有文档在半小时内回答。能，就可以精简；不能，就说明粒度还不够。
两种条件下，保留粒度完全不同
第一种条件：项目是常规企业站建设或改版，交付物包括页面结构、栏目规划、表单和基础内容。这类项目结束后，保留粒度可以降到“结论层”——保留最终上线的页面清单、栏目结构说明、关键页面的内容来源、表单字段与接收方式、以及一份变更记录。中间的设计稿、被否掉的方案、零散的沟通截图，可以只留最终版和一次关键修改的说明。
第二种条件：项目涉及持续运营、多轮迭代或客户自己接手维护。这时粒度要提高一档，保留“决策层”——每次改版的原因、当时对比过的选项、谁确认的、上线时间、以及对应的页面版本。原因是后续接手的人需要知道“为什么现在是这样”，而不是只知道“现在是什么样”。
一个可区分的信号：如果项目结束后，客户方有专人负责后续内容更新，粒度要偏细；如果后续维护仍由服务方承担，粒度可以偏粗，因为服务方自己知道来龙去脉。这个判断不依赖项目大小，而依赖“谁在半年后需要读懂这些文档”。
一个假设例子：半小时复原测试
假设某企业站上线四个月后，市场部发现“产品中心”的某个分类页转化明显低于其他页。此时需要回答：这个分类页当初为什么这样排、有没有做过结构对比。如果文档里只有最终页面截图，没有当时的栏目结构说明和变更记录，就只能重新猜。如果保留了“栏目结构说明 + 一次结构对比记录 + 上线确认时间”，就能在半小时内定位到原因，并判断是内容问题还是结构问题。
这个测试的动作是：随机抽一个已上线页面，让不参与该项目的人尝试回答“它为什么长这样”。如果对方只能回答“因为当时就这么定的”，说明粒度不足；如果对方能说出依据和替代方案，说明粒度合适。测试结果直接决定下一步是补充归档还是停止整理。
保留粒度可以按三层划分
- 结论层：最终上线的页面、栏目、表单、内容来源、上线时间。适用于常规交付、后续由原服务方维护的项目。
- 决策层：结论层内容 + 每次关键改版的原因、对比选项、确认人和变更记录。适用于客户接手维护、或有多方协作的项目。
- 过程层：决策层内容 + 中间稿、被否方案、完整沟通记录。只建议在合同有明确要求、或项目本身涉及复杂合规审查时保留。
多数淮南本地企业站项目，停在决策层就够。过程层保留越多，后续检索成本越高，反而容易让接手的人迷失在旧文件里。一个实际动作是：项目收尾时，把过程层文件单独放一个“归档-不用于日常查阅”的目录，日常只开放结论层和决策层。这样做的结果是，后续维护时默认看到的是有效信息，减少误用旧稿的概率。
例外：这些情况必须保留更细
如果项目涉及支付、会员、表单收集个人信息，或页面内容涉及资质、价格、承诺类表述，保留粒度要覆盖到“当时依据什么材料写的、谁审核的”。这不是为了复盘，而是为了在出现争议时能说明来源。此时过程层里的审核记录、确认消息不能删。
另一个例外是：项目结束后短期内可能再次改版。如果已知三个月内会有第二轮调整，保留粒度应维持决策层以上，避免第二次改版时重新梳理历史。判断依据是“下一次改版是否已经排期”，而不是“这次项目做得好不好”。
实施动作与后续影响
具体做法可以分三步。第一步，项目结束前由执行人列一份“保留清单”，写明哪些文件进入结论层、哪些进入决策层、哪些只归档。第二步，由不参与执行的人做一次半小时复原测试，抽一个页面验证能否回答“为什么这样”。第三步，根据测试结果调整清单：答不出的补决策层记录，答得出的把多余过程稿移出日常目录。
这个动作的结果会直接影响下一次改版的启动成本。如果测试通过，下一次改版可以直接从决策层文档开始，不需要重新访谈和翻聊天记录；如果测试不通过，说明当前粒度不足，下一次改版前需要先补一次历史梳理，否则容易重复已经否定过的方案。保留粒度不是越细越好，而是刚好能支撑下一次决策。
