AI 协作工程化 07：事实只有一份，知识库、宣讲稿与正式设计如何防漂移
一个团队往往同时拥有需求文档、实现计划、知识库、会议材料和测试报告。它们看起来都在描述同一件事，于是最容易发生的错误是：每份文档都被当作“可以修改事实的地方”。时间一长，同一条业务规则会有三个版本，谁也说不清哪一个有效。
解决办法不是只保留一个文件，而是明确每类材料的职责：谁是事实源，谁是索引，谁是派生阅读模型，谁只记录观察结果。
先建立事实层级
以需求实现为例，可以把常见材料分成四层。
| 材料 | 主要用途 | 是否能改变当前需求事实 |
|---|---|---|
| 正式需求、计划、设计确认 | 定义目标、方案、任务与确认状态 | 能，由 Designer 在流程内维护 |
| Handoff 与台账 | 路由、索引、当前状态 | 仅 Controller 根据 Return 更新 |
| 项目知识库 | 复用稳定业务语义与代码锚点 | 不直接改变当前需求设计 |
| 宣讲稿、测试报告、会议记录 | 面向读者解释或记录观察 | 不能，必须回写权威层才生效 |
核心原则是单向派生：阅读材料可以从事实源生成，测试报告可以引用事实源，知识库可以沉淀经确认的稳定结论；但它们不能反向偷偷修改当前需求。
项目知识库适合做什么
项目知识库解决的是“用户的自然语言如何对应业务规则和代码位置”。它适合存储相对稳定的术语、对象关系、模块职责、代码锚点和已确认的历史决策，帮助新需求快速找到最小上下文。
为了避免“查询顺手就改库”，知识能力最好按读写分离设计：
- Retriever 只读查询，返回答案、失效锚点、知识缺口或重建候选。
- Curator 是唯一写入者，负责把稳定事实原子化、去重、建立别名到业务语义再到代码引用的桥梁。
这种设计类似 CQRS 的思想：读模型为检索优化，写模型为一致性负责。它不需要引入复杂基础设施，也能避免多个人同时把不同理解写回索引。
宣讲材料为什么不是事实源
正式设计通常面向执行与审查，结构严谨但阅读门槛高。为产品、业务和技术负责人准备的宣讲稿，则需要把背景、影响、数据、接口、风险和任务拆分组织成可讨论的表达。
它可以是高质量的阅读材料，却不能成为新的设计事实源。原因很简单：会议中产生的意见可能只是建议，只有回写到正式需求或计划、完成相应确认后，才真正改变了范围和执行依据。
把宣讲稿当事实源，会出现两种漂移：
- 宣讲稿已经改了，开发仍按旧计划实施。
- 会议记录里写着“同意”，但没有人确认它究竟改变了哪条需求、哪个任务或哪个接口。
更好的方式是给宣讲稿建立明确版本基线：它基于哪一版需求、计划和设计确认生成；当这些基线改变时，重新生成或升级版本；历史宣讲稿保留，不静默覆盖。
知识不是一手代码证据
知识库会提高检索效率，但不能替代当前代码、当前配置和本次需求的明确输入。一个代码锚点可能已经移动，一个规则也可能在新需求中被显式修改。因此，使用知识时需要区分三种状态：已确认事实、待验证推断、待确认问题。
这也解释了为什么 Designer 仍需要进行面向当前任务的调查，而不是直接把知识库的答案写入正式设计。知识是导航，代码和明确需求才是本轮证据。
文档漂移的早期信号
| 信号 | 可能原因 | 处理方式 |
|---|---|---|
| 同一术语在不同文档有不同定义 | 缺少权威源或别名关系 | 明确术语 Owner，更新知识条目 |
| 宣讲稿写了新方案，计划没有变化 | 派生材料越权 | 回写正式设计并重新确认 |
| 代码锚点无法定位 | 知识过期 | Retriever 输出维护回交，Curator 更新 |
| 索引条目混入临时讨论 | 写入边界过宽 | 原子化、拆分或标记待确认 |
小结
“事实只有一份”不意味着所有信息只放在一个文件里，而是每一种信息只在一个地方拥有修改权。正式设计负责当前需求事实，Handoff 负责状态，知识库负责稳定语义桥，宣讲稿和报告负责解释与观察。边界清楚后，文档数量增加并不会必然带来混乱。
终篇将把这些机制放回工程现实：高可靠 AI 工作流得到了什么，又为一致性、审计和演进付出了哪些代价。
系列导航：