安庆SEO服务项目结束后历史文档需要保留到什么粒度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e96d1b19631.html
📄
安庆SEO服务项目结束后历史文档需要保留到什么粒度
结论先说：保留粒度按“能否独立解释一次关键决策”来定，而不是按文件数量或项目阶段来定。对安庆SEO服务这类项目，最低可接受粒度是保留三样东西：改动清单（改了什么页面、什么字段）、判断依据（当时看到的数据或约束）、验证口径（后来用什么指标判断有效）。原始导出文件、过程稿、聊天记录可以删，这三样不能删。下面用一个假设情境把决策过程走一遍。
先看一个假设情境：只有截图和零散导出时怎么定粒度
假设某安庆本地企业做过一轮SEO服务，项目结束时只拿到几份后台截图、一个关键词表和一个未标注版本的页面改动记录。半年后要接手的人问：为什么当时把某批栏目页合并了？如果文档里只有截图，没有“合并前该栏目内容重复度高、且站内没有其他入口指向它”这类判断依据，接手的人只能重新测一遍，或者凭猜测推翻旧决策。这就是粒度不够的典型表现。
反过来，如果当时保留了“改动清单+判断依据+验证口径”三行记录，即使没有原始爬虫导出，接手的人也能判断：这个决策在什么前提下成立，现在前提是否还成立。粒度是否够，取决于它能不能支撑这个判断，而不是取决于文档有多厚。
三个必须保留的粒度层级
第一层：改动清单，精确到URL或模板
至少写清改动对象是具体URL还是整类模板，以及改的是标题、正文结构、内链还是跳转。只写“优化了栏目页”没有用，因为接手的人无法复现范围。这一层的动作是：把改动整理成一份可检索的列表，标注生效时间。结果是后续排查流量变化时，能直接把时间点和改动对上，而不是靠回忆。
第二层：判断依据，记录当时的约束条件
这一层最容易被省掉，却最影响决策。需要保留的是：当时依据的是什么数据（哪怕只是后台某几天的表现）、有什么权限或资源限制、有没有被排除的方案。例如“当时没有权限改服务端渲染，所以只做了前端可见内容调整”，这句话能解释为什么某些问题没被处理。没有它，后来的接手者会误以为当时漏做了。
第三层：验证口径，写明用什么指标判断
写清当时约定看哪个指标、看多长时间、达到什么程度算有效。这里要避免把统计相关当因果：某个指标变化可能来自季节、投放或平台调整，不能单独归因于某次改动。保留口径的意义是让后来的人知道“当时是怎么判的”，而不是承诺结论一定成立。
哪些文档可以降级或删除
- 原始爬虫导出、重复的截图：如果改动清单和判断依据已经覆盖结论，可以只留一份，不必按日期全留。
- 过程稿和未采用的方案：只需在判断依据里提一句“曾考虑某方案但未采用及原因”，正文可删。
- 即时沟通记录：涉及决策结论的部分摘录进判断依据，其余可删。
降级的判断标准是：删掉之后，接手的人是否还能回答“为什么这么改”和“怎么判断有没有效”。两个都能回答，就可以删。
缺少完整数据或权限时的最小动作
如果项目结束时已经拿不到完整后台数据，仍然可以做一件事：写一份“决策备忘录”，逐条列出改动、依据、口径，并明确标注哪些结论是推断而非实测。动作本身不依赖任何工具权限，只需要当时参与的人花时间回忆并交叉确认。结果是一份不完整但可用的交接材料。需要说明的是，这份材料不能用来证明改动有效，也不能推出“没记录的问题就不存在”——它只解决交接可读性，不解决效果归因。
如果连参与人都无法确认，那么最小动作退化为：只记录改动清单，把依据和口径留空并标注“待核实”。这比编造依据更安全，因为后来的人知道哪些地方需要重新验证，而不是被一份看起来完整、实际靠猜的文档误导。
怎么判断粒度已经够用
可以用一个假设测试：把文档交给一个没参与过项目的人，让他回答“如果现在要推翻某个改动，需要先确认什么”。如果他能从文档里找到前提条件，粒度就够；如果他只能反问“当时为什么这么改”，就说明判断依据缺失。这个测试不需要真实交接对象，自己走一遍也能发现问题。粒度定在“能支撑一次独立复核”即可，继续加厚往往只是增加维护成本，并不提高可决策性。
