ONTAO 理论体系 · 第十一篇：存量改造方法论

📍 所属层：企业运行本体层 · 工程实践——怎么落地——改造存量系统四步法

本体论怎么落地？改造现有系统，不是新建系统。
这一篇回答"怎么用 Ontology 改造现有系统"——已运行多年、数据/代码/AI 资产全在的存量系统（brownfield）改造路径。

一、核心命题

存量改造不是推倒重来，是"显式化 + 结构化 + 接入"。 把已经在运转的业务认知，从人脑和代码里搬进本体。

第六篇六步协议隐含的是绿地接入（greenfield）——从零建模。但绝大多数真实场景是存量系统：数据库几百张表、代码几十万行、规则散落各处、AI 已接入但只是工具。它们不是没有本体，是本体散着——散在表结构里、散在代码 if 里、散在专家的脑子里。存量改造 = 把这些散落的本体收拢、显式化。

二、存量 vs 绿地

一句话：绿地是"画地图"，存量是"把真实地形抄成地图"——地形已经在那，抄错才是风险。

三、存量改造四步法

第 0 步 盘库    盘点现状：表/规则/文档/AI资产 → 现状认知清单
第 1 步 显式化  规则从代码搬进本体（先搬不改）      ★ 灵魂步骤
第 2 步 选链接入 选 1 条决策链，AI 接入（第六篇协议）
第 3 步 演化回填 机制层演化 + 治理层回填（第九/五篇）

第 0 步：盘库（存量版更重）

• 数据库 schema：哪些表在真实读写 → 世界已经承认的实体
• 代码里的规则：散落的 if / 引擎 / 校验 → 待显式化的规则
• 已有文档与 AI 资产：skills / memory / 纪律文件
• 产出：现状认知清单——"世界现在已经被描述成什么样"

第 1 步：显式化 ★（存量改造的灵魂）

把散在代码里的规则搬进本体。关键纪律：先搬不改——显式化阶段行为零变化，规则只是搬家。风险从"改代码"降级为"写文档"，可审计、可回滚。

代码 if  →  本体规则（行为不变，只是规则有地方住了）
引擎逻辑 →  动作定义（触发器不变，只是动作有名字了）
数据字典 →  属性定义（口径/来源/消费方 → 深度2）

第 2 步：选链接入

复用第六篇六步协议的第 2-5 步：选 1 条决策链（高频/昂贵/多人判断）→ 定权限 → AI 接入 → 验证闭环。

第 3 步：演化回填

第九篇机制层演化（系统自己动）+ 第五篇治理层回填（人主导改规则）——存量系统一旦本体显式化，就能从"自动化"走向"认知演化"。

四、显式化三原则

1. 先搬不改：显式化阶段行为零变化——这是存量改造敢做的底气
2. 沿链定义：只对决策链上的对象/规则定义到深度 2（防数字孪生，第二篇）
3. 从事实表反推：数据库里真实读写的表 = 世界已经承认的实体——本体从事实表长出来，不是从概念长出来

服务陷阱的警示（外部验证）：Palantir 行业共识——"如果部署需要大量定制化人工工作，你就是带 logo 的咨询公司"（services trap）。存量改造的"先搬不改"正是防这个：规则先搬进本体（写文档，可复用），而不是每次都人肉定制（写代码，只活一次）——搬一次，复用 N 次；定制一次，只活一次。

五、存量改造与三端对齐

本体定义 = 代码实现 = 线上现实   三者永远一致

存量系统是"现实先于本体"——本体是事后显式化，所以验证方向是反的：

本体写完后，用三端对齐检查本体描述是否与现实一致。不一致 = 本体文档错了（不是现实错了）。

这解决了显式化的最大恐惧："我怎么知道抄对没有？"——拿现实对账。

六、与拾光传媒的对照（第一个存量改造案例）

现状盘点

改造路径

① 规则显式化：扣量/同步/风控规则搬进本体（先搬不改）
② 选 1 条链：候选"供应商数据异常处置"（高频/昂贵/多人判断）
③ 事件链建模：sync_log → 本体事件（第九篇 L4 的前提）
④ 验证：AI 能说清"世界现在什么样 + 该怎么办"

判定：拾光传媒是存量改造的完美样本——世界状态真实存在，缺的只是显式化和接入。

七、一句话总结

存量改造 = 把已经运转多年的业务认知，从人脑和代码里搬进本体——先搬不改、沿链定义、从事实表反推。
不是推倒重来，是让系统第一次"知道自己是谁"。