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