单一事实源——当 AI 做了大部分工作，你靠什么守住一致性
大部分任务已经交给 AI 了，人不参与执行，漂移发生时你根本不知道。第一天就建一份事实源文档——这份你自己维护的、简单的、只读的文档，是所有下游产物的唯一锚点。
问题的本质：漂移发生在你不在场的时候
现在的工作模式是这样的：你提一个需求，AI 帮你写代码、生成配置、创建脚本。项目 A 做完了，项目 B 也做完了，项目 C 也做完了。每个项目 AI 都”按照你的要求”完成了，但你回头一看——三个项目的同类逻辑互相矛盾，命名不一致，配置各不相同。
问题不在于 AI 单次生成的质量，而在于一个更隐蔽的事实：大部分任务由 AI 完成，你作为 human 不参与执行过程。漂移发生在你不在场的时候，所以你无法感知。
更危险的是，当你最终发现漂移时，它可能已经发生了很久了。三个月前的一个会话里，AI 改了一条规则，你当时没有察觉。之后所有基于那条规则的产物都在错误的基础上继续生长。等到你在某个项目里撞上了问题，回头追溯时才发现——根源在三个月前，中间所有项目都受到了影响。没有事实源文档，你甚至无法确定最初正确的版本是什么，只能靠记忆和猜测去回滚。
解决方案：第一天就建事实源文档
这是整篇最重要的一个行动：任何任务启动的第一天，就建一份简单的事实源文档，写清楚你对这个任务的核心规则和约束。
不是等出了问题再补，不是等做完再回头写文档——是第一天，第一次让 AI 帮你干活之前，先把事实源建好。因为你从第一天起就不在场，漂移从第一天就开始。
这份文档有几个关键特征：
- 你是唯一的作者——每一条规则、每一个约束都是你明确做出的决定。AI 不应该自行修改它。
- 它必须简单——简单的东西才容易被完整执行。如果你一开始就把文档写得很复杂，AI 在实现时会更容易”简化”你的意图、跳过某些细节。
- 它是只读的——任何修改必须由你确认和批准后才能执行。一旦 AI 在你不知情的情况下改了这份文档，所有下游产物都会悄悄偏离你的意图。
- 它适用于任何任务——不只是写代码。任何由 AI 辅助完成的任务——生成配置、创建文档、处理数据——都应该在第一天就有一份对应的简单事实源。
为什么？因为 AI 做了大部分工作，而你不在场。 你在会话 A 里定的规则，到了会话 B 可能已经被 AI “优化”掉了。你没法逐行审查每一次输出，所以你需要一个锚点——一份你自己写的、简单的、AI 不敢动的文档——来保证所有下游产物最终都能回到你的意图上来。
具体实现：Knowledge → Skill → Script
这里用一个三层结构来演示这个原则，但它只是众多实现方式中的一种。
| 层 | 是什么 | 职责 |
|---|---|---|
| Knowledge | 你维护的事实源文档 | 定义”是什么”——规范、约束、设计原则 |
| Skill | AI 的指令文件 | 定义”怎么做”——引用 Knowledge，给出实现步骤 |
| Script | AI 的生成物 | 定义”做什么”——调用 Skill 完成具体任务 |
控制流：Knowledge → Skill → Script，其中 Knowledge 由你控制，Skill 由 AI 写，Script 由 AI 生成。
假设你的团队有多个项目都需要创建 release repo。你定义了一份 Knowledge 文档：
# Release Repo 规范
- visibility: public（必须）
- 必须启用 Issues
- 禁用 wiki 和 discussions
- description 来源：config.yaml 的 publish_stage_0 文案
然后你写了一个 Skill，引用这份 Knowledge，按步骤创建 repo 并配置。项目 A 和项目 B 都调用同一个 Skill，结果一致。
当项目 A 跑完后发现 info.yaml 和 config.yaml 的 description 不一致——你不需要去改项目 A 的脚本，而是去修订 Skill，让它统一取 config.yaml。修订时对照 Knowledge 文档：如果 Knowledge 里已经定义了，那是 Skill 实现不够严谨；如果没定义清楚，你先补 Knowledge，再改 Skill。Knowledge 始终是唯一事实源。
为什么不能反过来
有人会想：能不能先有 AI 的生成物，再从中提取规则，最后归纳出事实源？理论上可以，但实践中这条路走不通：
- 生成物是具体的、一次性的，里面混杂了业务逻辑和通用逻辑。
- 从多个生成物里”提取”通用部分，等于在多个副本里找共同点——天然会漏。
- 事实源必须是主动定义的，不是事后归纳的。
正确的方向永远是：先有你定义的事实源，再有 AI 的实现，最后有 AI 的生成物。
核查清单
- 第一天就建事实源文档——在任何任务启动的第一天、第一次让 AI 干活之前，就写好这份简单的事实源文档。
- 在 AI 的指令里写明：事实源文档只读，AI 不得自行修改，任何改动需 human 确认。
- 让 AI 在实现时引用事实源文档，不要内联规则全文。
- 当生成物出现问题时，先检查 AI 的实现是否需要修订，再检查事实源是否需要补充。
- 不同项目或场景的特殊需求，在实现层做参数化或分支逻辑，不要直接改生成物。
- 定期回顾事实源文档，确保它是最新的、完整的、无歧义的。
总结
- 第一天就建事实源文档——漂移从第一天就开始了，你不能等到出问题再补。
- 这个事实源是你唯一能控制的东西——它简单、只读、你亲手维护。AI 的所有产物都回到这份文档来对齐，不符合的都值得检查。
- 事实源是只读的——AI 不得自行修改，任何改动必须由 human 确认批准。否则漂移会发生得悄无声息。
下次开始任何任务时，第一天就建这份文档——把你最核心的一个规范写进去，保持简单，保持只读，让 AI 的所有产物都回到这份文档来对齐。