ONTAO 理论体系 · 第五篇：演化与沉淀理论
本体是活的——版本化、回填、飞轮。
这一篇解决"本体如何不腐烂"，让体系越用越强。
一、核心命题
本体不是建完就死的文档，是随业务生长的活体。 没有演化机制的本体，半年后就是一张过时的地图——而过时的地图比没有地图更危险（AI 依据过时本体行动，后果自负）。
二、本体的生命周期：四阶段
诞生（建模）→ 使用（跑链）→ 反馈（回填）→ 演化（改版）
↑ │
└──────────────────────────────────────┘
| 阶段 | 动作 | 关键纪律 |
|---|---|---|
| 诞生 | 沿决策链建模六要素 | 跑通即停，不全量铺开 |
| 使用 | AI 按本体行动，人按本体审批 | 本体是总索引 |
| 反馈 | 实战发现新规则/缺口 | 记录到回填池 |
| 演化 | 改版本体 → 再改代码 | 先本体后代码（doc-first） |
三、版本化：本体有历史
为什么必须版本化
- 可回溯：规则改错了，能查"之前是什么"
- 可审计：谁在什么时候改了哪条规则（责任可追）
- 可回滚：新规则引发事故，能退回旧版
- 可对比：业务演化前后，本体差异就是组织认知差异的投影
版本化纪律（三端对齐）
本体定义 = 代码实现 = 线上现实 三者永远一致
- 本体文档进 git（本地 = GitHub = 部署）
- 规则变了 → 本体先变 → 代码再变 → 验证对齐
- 任何不一致，视为事故（本体说 A，代码做 B，现实是 C → 必须修复）
版本化粒度
- 整库版本：大版本（如 v1 → v2），业务模式变化时
- 单链版本：小版本（决策链内部规则更新），持续发生
- 规则级变更记录：每次规则改动的 diff 可查
四、实战回填：本体从战斗中学习
回填的定义
把实战中暴露出的隐性规则、规则缺口、模型缺口，写回本体。
回填的三个来源
| 来源 | 例子 | 回填什么 |
|---|---|---|
| 决策复盘 | 一次供应商异常处置，发现"回款差的客户要提前预警" | 新规则/新属性 |
| 事故回溯 | 一次事故发现"某类链接数据异常没触发告警" | 新触发条件/新监控 |
| AI 误判 | AI 建议被否决 N 次，发现规则有边界情形 | 规则补充/权限调整 |
回填的流程（闭环）
实战 → 发现 → 记录（回填池）→ 定期评审 → 改本体 → 改代码 → 验证 → 发布
- 回填池：待处理的规则缺口清单（不立即改，集中评审）
- 评审：人判断"这是通用规律还是单次特例"——单次特例不写死进规则
- 改本体 → 改代码：严格 doc-first 顺序
- 验证：改完跑一遍决策链，确认行为符合预期
回填与"规则膨胀"的对抗
回填的天然风险是规则越积越多，本体越来越复杂。对抗机制：
- 复用优先：新规则能并入旧规则，就不新增
- 特例不入库：单次特例（"这次是因为 X 特殊情况"）不写死
- 定期瘦身：每条规则定期审查——还成立吗？还常用吗？删掉 AI 会变差吗？
- 可判定性门槛：含糊的规则不入库（"重要客户优先"不是规则，"回款≥B且年交易≥X"才是）
五、飞轮模型：项目反哺模板
飞轮的结构
建本体（项目A）→ 跑通 → 提炼模板 → 建本体（项目B，用更好的模板）
→ 更快 → 提炼更多模式 → 循环
两个层次的沉淀
┌──────────────────────────────────────┐
│ 层次一：项目内沉淀 │
│ 决策链跑通 → 规则回填 → 本体演化 │
├──────────────────────────────────────┤
│ 层次二：项目间沉淀 │
│ 项目本体 → 抽象通用模式 → 模板库 │
│ （供应商管理/客户管理/数据管线……） │
└──────────────────────────────────────┘
模板反哺的时机
不是每个项目做完都反哺——当同一模式出现两次以上才抽象成模板：
| 出现次数 | 处理 |
|---|---|
| 1 次 | 留作项目内容，不动模板 |
| 2 次 | 对比两项目，提炼共同结构 → 建模板 v1 |
| 3 次+ | 模板稳定，开始跨项目复用 |
模板的正确用法
- 模板是起点不是终点：新项目从模板出发，但必须按自己的业务裁剪
- 模板只保留结构（六要素框架、决策链解剖、权限层级），不保留内容（具体对象/规则）
- 模板本身也要版本化（templates 也是本体的一部分）
六、数据诚实与单一事实源（跨项目铁律）
演化机制的前提是数据诚实：
| 铁律 | 含义 | 反例 |
|---|---|---|
| 无定义显 0/空 | 没数据就说没数据 | 假装有数据/编造 |
| 单一事实源 | 每个事实只有一个权威来源 | 多处各存一份，对不上 |
| 同刻快照对比 | 对比数据要同一时间点 | 昨天 vs 今天 的"差异"其实是时间差 |
| 时间差 ≠ 数据丢失 | 上游 T+1 属正常 | 误判为事故 |
为什么数据诚实是演化前提：回填依赖"实战真实反馈"。如果数据是假的、口径是乱的，回填的就是垃圾——垃圾回填 → 垃圾规则 → 本体腐烂。
七、本体的腐烂与防腐
腐烂的五个症状
- 过时：规则与线上现实不符（业务变了，本体没变）
- 失配：本体与代码不一致（改了代码忘了改本体）
- 冗余：规则重复/矛盾（历史补丁堆叠）
- 失读：复杂到没人看（数字孪生后遗症）
- 失用：AI 干活不加载本体（体系与执行脱节）
防腐机制
| 症状 | 防腐 | 频率 |
|---|---|---|
| 过时 | 决策链复盘（每次实战后核对） | 持续 |
| 失配 | 三端对齐检查（本体=代码=现实） | 每次变更 |
| 冗余 | 规则定期瘦身 | 每月/每季 |
| 失读 | 可视化抽查（图还能看懂吗？） | 每季 |
| 失用 | 使用率审计（AI 每次行动是否引用本体） | 每月 |
八、本体的终局：组织认知的投影
演化到成熟态，本体不再只是"AI 的地图"——它是整个组织的认知投影：
老板脑子里的规则
老员工的经验
部门博弈的共识
系统里的数据
↓ 全部显性化
ONTAO 本体（唯一事实源）
↓ 演化
组织可共同理解、系统可互相调用、AI 可执行的"组织能力"
判断标准（组织层面）：当"重要客户谁说了算""已成交是不是同一个意思"这类问题，不需要开会就能在本体里查到答案——本体论才算真正建成了。
本篇结论（立论）
- 本体是活体，不是文档：诞生→使用→反馈→演化，循环不止
- 版本化：可回溯、可审计、可回滚；三端对齐（本体=代码=现实）是铁律
- 实战回填：隐性规则从实战长出来；回填池评审 + 特例不入库 + 定期瘦身，对抗规则膨胀
- 飞轮模型：项目→本体→模板→更快的新项目→更多模式；同一模式出现两次以上才抽象模板
- 数据诚实是演化前提：垃圾反馈 → 垃圾规则 → 本体腐烂
- 防腐机制：过时/失配/冗余/失读/失用，各有对应检查
- 本体终局 = 组织认知投影：不需要开会就能在本体里查到"谁说了算"
一句话立论：演化与沉淀理论回答"本体怎么活"——版本化保证历史，回填保证新鲜，模板保证复用，数据诚实保证不腐烂。
下一篇预告：接入理论——怎么实施到项目（六步接入协议）