网站SEO服务：项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cec33fdb3697.html
📄
网站SEO服务：项目结束后历史文档需要保留到什么粒度
结论先说：保留到“能独立复现一次判断”的粒度。也就是说，未来换一个人接手，只凭这份文档就能知道当时改了什么、为什么改、依据是什么、结果如何。低于这个粒度，文档等于没留；高于这个粒度，会积累大量无用的过程噪音。下面按保留、改写、退出三类处理展开，并说明各自成立的前提。
先分清三种文档：决策记录、执行记录、原始数据
很多团队把这三类混在一起，导致要么全删，要么全留。可行的做法是分开定粒度。
- 决策记录：某次改动的目标、判断依据、预期影响、负责人。粒度到“一次决策一条”，保留全文。
- 执行记录：具体改了哪些页面、哪些模板、哪些字段。粒度到“可回溯的变更清单”，保留摘要加关键条目。
- 原始数据：抓取结果、日志、导出报表。粒度到“能重跑一次对比”，只留抽样或聚合结果。
一个实际动作：让接手人在不问你任何问题的前提下，仅凭文档复述某次改动的前因后果。如果他卡在“当时为什么这么改”，说明决策记录粒度不够；如果他被几百行原始日志淹没，说明数据层留得太细。
出现反常结果时，文档粒度决定你能不能区分解释
项目结束后最常见的反常现象是：某项指标在改动后不升反降，或者先升后回落。这时文档的作用不是证明你对，而是帮你排除其他解释。
假设某次调整了站内链接结构，结束后三个月，目标页面的自然访问下降。至少存在三种合理解释：一是改动本身有负面影响；二是同期有季节性波动；三是抓取或索引状态发生了变化，与改动无直接关系。要区分它们，文档里必须留下三样东西：改动生效的确切时间点、同期未改动页面的对照数据、以及当时的抓取或索引状态记录。
如果文档只写了“优化了内链”，没有任何时间点和对照，那么指标下降这件事无法归因，只能重新做一次对照观察。这就是粒度不足的直接代价：你得把已经做过的事再做一遍。
反过来，如果文档里连每天的原始日志都留着，但没有任何一句判断说明，那么你同样无法快速区分解释，只是把成本从“重做”换成了“重读”。所以粒度不是越细越好，而是刚好覆盖“区分不同解释所需的最小证据集”。
保留、改写、退出：三种处理各自的适用前提
不是所有历史文档都值得原样保留。按下面三种情况分别处理。
保留原样
适用前提：这次改动涉及站点结构、模板层、重定向规则或索引策略。这类改动的影响周期长，且后续排查往往需要回溯原始判断。保留时确保决策记录完整，执行记录里保留变更前后的关键页面清单。
改写成摘要
适用前提：改动只涉及内容层或单页元素，且已经有明确的结论。做法是把执行细节压缩成一段结论加一条证据，原始清单可以退出。这样既保留了可复现的判断，又不占用后续维护精力。
退出
适用前提：文档记录的是已被推翻的中间过程，且没有任何后续决策依赖它。典型如反复调整同一处文案的多个中间版本。退出前确认一件事：没有任何在跑的改动是基于这份文档做的。如果还有依赖，先解除依赖再退出。
一个可操作的判断动作：对每份文档问一句“如果删掉它，下一次同类决策会不会被迫重新试错”。答案是会，就保留或改写；答案是不会，就退出。
给文档定一个可核对的粒度标准
与其争论“留多少”，不如定几条能被外部核对的规则。以下规则假设团队使用共享文档或版本库，具体工具不限。
- 每条决策记录必须包含日期、目标、依据、预期影响四项，缺一项视为不合格。
- 执行记录以变更清单形式存在，每项能对应到一个可定位的对象，例如某个模板文件或某类页面。
- 原始数据只保留聚合结果或抽样，保留周期与决策记录的保留周期一致，不单独延长。
- 文档中出现的每一个结论，必须能指向至少一条证据；没有证据的判断写成待验证，不写成结论。
这套规则的直接结果是：接手人可以在半小时内判断某次改动是否值得重新审视，而不是花两天读完全部材料。如果做不到，说明粒度标准还停留在“多留点总没错”的阶段，需要回到第一条重新对齐。
什么时候该停止追加文档
文档粒度失控通常不是因为留得太多，而是因为没人决定什么时候停。一个可执行的停止条件是：当某次改动的结论已经被下一次同类改动验证或推翻，且新结论已经写入决策记录时，旧的过程性文档就可以退出。此时保留的不是过程，而是结论和它依赖的那条证据。
换句话说，历史文档的粒度应该随着结论的稳定程度递减：结论越确定，保留越精简；结论仍有争议，保留越完整。判断标准始终是同一个——未来的人能不能只靠这些材料，独立复现一次判断，而不是复现一次操作。
