加新数据前先清旧：沉淀的纪律

沉淀一条新决策不算完工。旧数据没清，新旧两套规则同时存在，迟早被引用错的那一套打脸。加数据先清旧，是纪律，不是选择题。

我不写代码，但我每天靠一群 AI 替我跑公司，所有规则、方向、定位都靠"沉淀文件"管着。早期我以为写下新决策就万事大吉，结果 AI 时不时翻出半年前的旧版本当真，照着执行——新旧打架，引用出错。后来我把"清旧"写成了沉淀流程里的硬步骤：加新的那一刻，必须同步扫掉冲突的旧的。这套纪律拆给你看。

真实场景：只加新 vs 加新即清旧

同样是"沉淀一条新决策"，两种做法的结局完全不同。

环节	只加新（埋雷思维）	加新即清旧（纪律思维）
落盘新决策	写下新版本就收工	写下新版本，同步建一份冲突排查清单
处理旧版本	旧文件原封不动留着	全栈扫一遍，找出所有跟新版本冲突的旧内容
标记	默认归档，不做任何标识	旧内容显式标"已废弃·禁用"，而不是默默藏起来
验收	自己说"沉淀完成"	独立核查，确认旧数据真的不再被引用

我自己踩过最深的一次：拍了一条新战略，AI 当场报告"全部接入，完成"。我追问了一句"跟它冲突的旧数据清干净了吗"，重新排查才发现——新的接进去了，旧的一个没动。十几处旧版本还在原地等着被引用。所谓"完成"，其实只做了一半。

为什么会这样：新旧并存的连锁反应

根因只有一句：写新数据是"加法动作"，清旧数据是"减法动作"，而人和 AI 都天然只爱做加法。新的写完很有成就感，旧的没人想回头碰。于是冲突就这样留了下来。

冲突类型	留着旧版本会发生什么
定位/方向冲突	AI 一会儿按新方向、一会儿按旧方向干活，对外口径自相矛盾
规则/标准冲突	两套规则同时"有效"，执行时按哪套全凭运气
引用断点	别处的文件还指向旧版本，新版本成了孤岛，搜不到也用不上
对外可见冲突	旧文案、旧报价没清，被真实客户或同事照着执行，直接翻车

这是一条因果链：旧数据没清 → 新旧两套同时存在 → 哪套被引用全看运气 → 引用错的那一刻才暴露 → 而暴露往往发生在最不该出错的地方（客户面前、对外交付时）。一句话：沉淀新数据 ≠ 完工，不清旧数据 = 永远冲突。

更隐蔽的一点是，"默默归档"不等于"清旧"。把旧文件挪进归档夹，它还可能被搜到、被翻出来当真。真正的清旧，是给旧内容打上显式的"已废弃"标记，让任何人——包括 AI——一眼就知道这条不能再用。

你该怎么做

把"清旧"焊进你的沉淀流程，让每次加新都自带收尾动作：

1. 落盘新决策的同一时刻，建一份冲突排查清单，列出新版本的核心要点。
2. 全栈搜一遍旧数据，凡是跟新版本冲突的，逐条记下位置和原文。
3. 给冲突分级：对外可见或马上要执行的先处理，轻度的批量改，推翻核心的留给你本人拍板。
4. 处理旧内容时，给作废的版本打显式"已废弃·禁用"标记，别只做默默归档。
5. 修好所有指向旧版本的引用，确认新版本不是没人指向的孤岛。
6. 收尾时独立核查一次：旧数据是否真的不再被引用，而不是凭一句"完成了"过关。

提示：判断清得干不干净，问一句就够了——"现在如果有人随手翻，会不会翻到旧的还当真？" 答案是"会"，就还没清完。

---

我是阿浩，30 岁、不懂代码，从 0 到开公司用了 8 个月，靠一群 AI 协同岗位替我把活干完。"加新数据前先清旧"这条纪律，是我用一次次"自报完成、实则一半"换来的——沉淀不是写下来就好，是写下来、清掉旧的、再确认没人会引用错。想看我用什么工具把这群 AI 跑起来，去 wutuobangai.com；想跟着我 16 周从 0 搭起自己的 AI 系统，去 forms.wutuobangai.com。