过去大半年，我在公众号里陆陆续续写了很多篇关于本体论、本体建模和 AI 原生应用的文章。单看每一篇都只解决一个小问题，串起来其实是一条完整的线。

这条线是：从西方哲学的本体论出发，经过抽象建模，遇到 Palantir，琢磨对象行为规则，想通事件驱动的闭环，纠结过推理范式，最后落到本体模型驱动的 AI 原生应用、数据分析和知识库。这篇文章是一次阶段性总结。

一、本体论的核心思想：世界由什么构成，遵循什么规律

要谈本体论，绕不开西方哲学。整个哲学体系简单概括，就是本体论和认识论两大分支。

本体论研究两个关键的东西。一个是整个宇宙事物本身的本质构成，能不能形而上地进一步抽象；另一个是宇宙事物的类型、规则和规律究竟是什么样。本体论回答"是什么"，认识论回答"我怎么知道"。这两条路径合起来，才构成人类认识世界的完整方式。

早期古希腊哲学里两者是分离的。到了近代，培根用科学归纳法完善了形式逻辑，本体论和认识论才走向结合。再到康德的十二范畴，本质上是用逻辑做纽带，把两边统一起来。

我讲深度思考时反复说过一句话：深度思考的核心就是空间加时间加逻辑。逻辑不能单独存在，它一定依附在事物上面，依附在一定的空间和时间上面。

从这条脉络里可以引出一个对后面所有内容都至关重要的判断：事物不是一个静态的东西，研究事物一定要去研究它的动态特征、行为特征，以及事物和事物组成要素之间的关系。

一个合同不只是一组字段。它会被录入、被审批、被开票、被收款，它在不断产生行为，不断与其他对象发生关系。

所以我一直强调，本体不是一张静态的数据模型，而是对象、行为、规则三者交织而成的动态整体。哲学上还有一组命题值得提一句，就是"存在本身"和"存在者"的区分。巴门尼德是本体论的奠基者，海德格尔是集大成者，他把真理理解为"解蔽"。

翻成我们做系统的话就是：存在不是一堆静态属性，而是一个持续发生的过程。这跟我们做软件的直觉是一致的——对象不是字段的集合，对象的价值在于它能做什么、会被什么改变。

二、从知识图谱到本体模型：两阶段的认识论过程

进入工程之前，需要把知识图谱和本体模型的关系讲清楚，这是很多人混淆的地方。

知识图谱主要处理的是实例层的数据，也就是 RDF 三元组那套东西；而 Schema 层才是 TBox，对应 OWL、OWL2 这些形式化本体语言。

我在自己的实践里得出了一个可能有点反直觉的结论：本体建模不会对实例层单独建模。实例层不存在单独建模的问题，只涉及实例数据的存储问题。第二个结论是，本体论建模本质上是一个两阶段的认识论过程。

第一阶段，是从现实世界到知识图谱。我们观察一个业务域，把其中的实体、关系、活动识别出来，形成一张描述"有什么、怎么连"的网络。这一步偏归纳、偏经验。

第二阶段，是从知识图谱到本体模型。我们在结构之上进一步抽象，补上行为、规则、事件、场景，把隐藏在经验和代码里的动态语义显性化出来。

从图谱到本体，正是从静态存在走向动态生成的那一跃。很多人谈本体论一直在谈"本体是什么"，却很少谈"我们怎么形成一个本体"。

而后一个问题，才是认识论和方法论的问题，也恰恰是更重要的问题。

三、本体建模真正解决的业务问题

讲完本体是什么，必须回答一个更现实的问题：它到底解决了什么业务问题，带来什么价值。不回答这个，前面所有抽象都是空中楼阁。

先说根子上的痛点。传统 IT 系统建设分两类：一类是偏事务处理的 OLTP 系统，比如 CRM、SRM、ERP、MES；另一类是偏分析决策的 OLAP 系统，比如数据仓库、BI、数据中台。

这两类系统的建设天生就是割裂的。分析类系统和业务执行类系统之间没有办法有效衔接，这是困扰行业很多年的老大难问题。

举个我反复用的例子。我在 BI 里发现库存周转率严重异常，理想是一年周转 12 次，现在只有 8 次。作为管理者，我更想追溯到底是什么行为导致了这个下降。

传统 BI 或数据中台根本回答不了这个问题。因为底层只有数据模型，没有形成数据背后的行为和规则模型，它只能告诉你结果和计算公式，讲不清来龙去脉。

这里要讲一个关键词：回写。在数据这边发现的问题、做出的决策，能够动态地变更或回写到业务系统里去，这就叫回写。

用供应链中断讲透它。一个核心材料因供应商原因出现一两个月的交付中断，在 BI 里就是一个预警，传统做法是通知供应链主管，然后他人工分析、人工调整。

在本体论建模的思路下，这个交付中断会触发一个事件，进入本体模型的消息管道。本体模型底层本身就有供应链计划优化调度的模型，融合了供应商、物料、合同、订单、交期和各类约束规则。

它拿到关键物料交期延误的消息后会自动计算，给出一个决策：可能是把某个客户订单往后延，也可能是引入新的关键合作伙伴供应商。然后调用回写接口把决策写回业务系统，业务主管只需要审核一下最终建议。

这就是回写的分量。它意味着本体论第一次真正打通了 OLAP 到 OLTP 的路线，实现了数据分析到业务执行行为之间的穿透，这在传统情况下根本做不到。

还有一个更隐蔽的问题，是设计态到运行态的行为与规则丢失。

数据模型往往落地到数据库表里，相对容易理解、容易看见。但行为和规则模型在代码里，大部分时候是看不到的，它被打包进了编译产物。

它们没有消失，只是变得不可见、不可追溯了。这造成一个深远的后果：当我们事后想追溯一个数据结果背后的业务逻辑时，几乎无从下手。本体论要做的事情之一，就是把这些被埋藏在代码里的行为和规则重新显性化出来，最终解决"知其然又知其所以然"的问题。

再说一个更贴近人的判断：经验在系统外。当前很多 IT 系统最终提供的，仅仅是决策之后的表单化录入。

比如供应链系统里有替代物料维护、调货补货、安全库存设置这些功能。但当一个关键物料供货中断时，究竟该引入替代物料、该调货，还是该调整安全库存？这个问题靠的是系统外的人员经验。

真正衔接场景和系统功能的，中间还有一段重要的分析、思考和决策过程，这段原来一直靠有经验的人来完成。所以 AI 加本体要解决的，正是场景问题到系统功能之间的分析和决策。

最后一个价值点是数据治理。我做过不少数据项目，也常被问：AI 时代的数据治理该怎么做。我的回答始终是一句话——数据治理一定是业务驱动的。

所以我的建议是找到关键业务场景切入，比如预算管控一体化、研发全生命周期管理，从一个能落地的场景倒推需要什么数据标准。因为在端到端流程贯通过程中，常常出现业务断点，而这些断点背后大部分都是数据原因导致的。

真正上升到公司级的数据问题，往往都是影响跨系统、端到端流程的问题。而本体模型，恰恰是承接这种业务驱动治理的最佳载体。

四、本体建模：对象、行为、规则三要素与十一大模型

理解了价值，下一个问题是：到底怎么把一个业务建成本体。我最先成型的是一套基于 OBR 思想的可视化建模方法。

OBR 就是对象、行为、规则。落到软件建模上，对象本体回答"存在什么"，行为本体回答"能做什么"，规则本体回答"什么必须成立"。三者缺一不可。

我借鉴过 MBSE 可视化建模，也想起过 ARIS 底层的 EPC 事件流程链画法，但真正想要的，是一种弱化业务流程、突出对象行为规则三者核心关系的建模图。

为什么要弱化流程？因为这正是本体建模和传统流程建模最根本的区别。流程会天天变，但对象和它们之间的引用关系相对稳定。

我给这套方法定了几条核心原则：对象是第一性的，先定义存在什么对象，再定义行为；行为改变对象状态，每个行为必然导致至少一个对象的状态变化；规则是不变式，无论何时何地永远成立；对象链即流程。

"对象链即流程"这一条特别重要。合同对象和开票对象之间的映射、开票对象和收款对象之间的映射，本身就间接体现了对象流转，你不需要专门画流程图。

行为建模里有一个我特别在意的设计选择：规则不塞进对象的方法里，而是独立出来成为一等公民。

传统对象建模里其实没有"规则"这个独立的东西。比如合同对象有"合同保存"方法，方法里会调用完整性校验、预算校验等多个规则，规则被淹没在方法里，既不可见也不可复用。独立出来之后，规则可以被多个行为引用。比如合同税率合规校验规则，既可以被"合同录入"引用，也可以被"开票录入"引用，一处定义、多处复用。

这套解耦带来的最大好处是灵活组装。新的业务场景分为若干步骤，每一步可以调用底层已有的行为去组合，每个行为又可以引用已定义好的规则。

业务千变万化，但底层的对象、行为、规则是相对稳定、可以穷举的。这也引出我对建模核心的判断：整个建模的核心不是业务场景，不是流程，而是对象。

讲完静态的组织方式，还有一个动态问题没解决：这些对象之间怎么联动起来形成闭环。我的答案是引入事件驱动架构。

比如录入一个销售合同，最终落到合同对象上，填充属性，调用合同保存方法，方法里再调用合同校验、交期承诺检查等规则，成功后返回。但销售合同录入和采购订单录入这两个独立功能之间，并没有发生什么直接关系。而在一个大本体里，它们之间存在着相当复杂的相互约束，传统 OOP 实现到"保存成功"就结束了。

本体建模怎么实现闭环？还是物料供货延期的例子。数据保存成功后，一定会触发一个"供货延期"事件。

这个事件进入消息流管道，触发相应的规则，比如合同校验、交期承诺检查、销售合同交期是否需要调整。规则执行完，需要变更合同的关键属性，于是调用回写接口自动完成调整。

我把这条链路总结成一句话：逆向闭环——事件到规则、规则到行为、行为到回写 API、回写 API 到更新数据。它刚好是正向"实现业务功能"过程的一个逆向。

说到规范本身，它不是一开始就完整的，它经历了一个明显的迭代生长过程。

最早我基于合同管理场景，让 AI 把需求浓缩为四个元模型文件：对象、行为、规则，加上业务场景和流程模型。第二次迭代增加了主体模型、异常补偿模型，并且改用 YAML 更精确地定义本体，替代原先较为粗糙的 Markdown。

再往后一路走到 V6，形成了十一个模型的完整版：M1 对象模型、M2 行为模型、M3 规则模型、ME 事件模型、M4 场景模型、M5 主体模型、M6 流程模型、M7 查询统计与报表模型、MU UI 模型、MM 对象数据表映射模型、MI 接口模型。

每个模型可以用一句话说清职责：M1 定义"是什么"，M2 定义"做什么"，M3 定义"为什么"，ME 定义"如何传播"，M4 定义"怎么编排"，M5 定义"谁能做"，M6 定义"怎么走"，M7 定义"怎么看"，MU 定义"在哪儿操作"。

这十一个模型在架构上也是分层的：L0 持久化映射层、L1 领域对象层、L2 原子能力层、L3 解耦决策层、L4 编排协同层、L5 集成边界层、L6 交互入口层。主体模型作为横切层贯穿 L1 到 L6，查询统计模型作为读模型旁路。

模型拆开了就必须有纪律。参照完整性约束归对象模型，业务规则归规则模型；原子行为归行为模型，编排逻辑归场景模型；角色定义归主体模型，数据权限推导用规则表达；查询统计独立建模，不污染写模型。

还有一条很实用的判断：一条规则被两个以上行为引用，才值得独立出来。建模顺序上，我建议先把对象和角色定下来，再抽规则，然后定义行为，接着构建事件链，再做场景编排，最后标注非功能约束。

最后是这套规范的输入输出面。输入有四个路径：从零构建 IT 系统、已有数据库的逆向建模、源代码逆向工程、非结构化文档的知识抽取。

输出有五种交付形态：IT 应用、Skills 技能包、MCP Server 能力接口、数据分析结果与报告、知识问答。一句话概括，本体建模规范是灵魂，Harness 技术底座是骨骼，而真正的行业经验体现在提示词、指导书和开发规范里面。

五、本体驱动的 AI 原生应用

本体建好了，能编辑、能可视化了，接下来的构想就更大了：能不能让 AI 从这套语义知识里，自动派生出可运行的应用。

这个构想始于一个根本问题。能不能用一种比代码更接近业务语义的中间语言，描述一个软件系统的全部知识，然后让 AI 基于它生成应用。

传统软件开发的核心摩擦在于翻译损耗。业务专家用自然语言描述意图，开发者把它翻译成代码，这个过程充满歧义、反复沟通和理解偏差。

大模型的出现让一种新可能浮现：如果软件的业务语义被精确形式化，AI 能不能同时扮演两个角色——在建造期把语义翻译成代码，在运行期把用户意图翻译成系统行为。而本体模型恰好就是那套"比代码更接近业务语义的中间语言"。它同时承担三重角色。

第一重是业务建模载体。业务专家通过自然语言对话与 AI 协作生成本体 YAML，不需要编程能力，只需要业务领域知识。

第二重是程序生成基础。AI 读取本体 YAML，自动生成数据库 DDL、接口骨架、权限策略、AI 工具 Schema 等程序产物，每一行代码都带溯源标签。

第三重是 AI 推理知识底座。运行期本体语义被加载进运行时注册表，作为大模型构建提示词上下文的结构化知识来源。

这三重角色串成一个三层飞轮。

第一层是语义建模层，包含语义对话引擎、本体抽取引擎和模型协作工作台。

第二层是模型驱动生成层。它不是通用代码生成器，而是严格遵循本体语义的定向生成器：数据层从对象模型派生数据库 Schema，服务层从行为模型派生接口骨架和事件接入，权限层从主体模型派生策略，交互层从场景模型派生意图路由和轻 UI 组件。

第三层是 AI 原生应用运行层。它重新定义了人机交互的主路径：自然语言意图是主交互方式，传统 UI 界面退为辅助性的数据呈现和操作确认。

围绕这套架构，我定了六条设计原则：本体优先、血缘可追、语义驱动、两端分离、推理分级、渐进可信。

其中"推理分级"这条最重要。高频、确定性强的逻辑，在建模时预编译成确定性规则由规则引擎执行；大模型推理只用于低频、高复杂度、需要语义判断的场景。

落到具体实现，我把从需求到应用的全过程拆成了四个阶段。

阶段一是需求确认和探索。业务专家用自然语言描述需求，比如"我需要一个合同管理系统，支持开票和收款跟踪"。

这句话信息密度很低，存在大量隐含假设。引擎不会直接生成模型，而是主动追问：合同有哪些核心属性？一个付款阶段能开几次票？谁有权录入、谁有权关闭合同？

阶段二是本体建模。引擎基于澄清后的语义，自动生成对象、行为、规则、场景等元文件，并以树结构加知识图谱双视图呈现给业务专家确认。

阶段三是应用交互原型。AI 基于本体模型和 UI 建模规范生成可交互原型，用户可以用自然语言调整布局、字段和交互流程。

这里有一条我很强调的约束：阶段三只能调整 UI 层面的东西。如果用户提出"我还需要一个合同审批流程"，AI 必须提示这是需求层面的变更，需要回退到阶段一。

为什么定这条约束？因为它守护的是单一真相源原则。需求的问题必须在需求阶段解决，本体的问题必须在建模阶段解决，不能在下游阶段偷偷改上游的东西。

阶段四是 AI 编程实现与持续交付。AI 基于前三阶段的产物生成完整代码并自动部署，最终交付一个可在浏览器运行的 AI 原生应用。

把四个阶段连起来看，就是这套范式的全貌：自然语言进，AI 原生应用出，本体模型是贯穿始终的语义脊梁。这条路怎么走，我做过一次路径决策，比较了三条路线。

路径 A 是从本体直接生成完整源代码，语义保真度最高，没有平台锁定，但需要自建权限、工作流、缓存、门户这些基础能力。

路径 B 是转换导入低代码平台，启动快、基础能力即用即得，但转换是有损压缩，而且损耗恰好发生在最有价值的地方。事件、规则、异常补偿、权限条件这些信息，在低代码平台的元模型里根本没有对应的容器。

路径 C 是把低代码平台的底层元数据升级为本体模型，构建双引擎运行时：传统 UI 引擎加 AI 意图引擎。本体即元数据，没有双套维护，可以渐进演进。

我倾向于路径 C。低代码平台不会消亡，但它必须从"应用开发平台"重新定位为"业务语义基础设施"。

还有一个更轻的落地形态：元技能。它不是面向某一个固定业务场景的技能，而是一个"技能生成器"，三段式是需求探索、本体建模、领域技能生成，产物是另一个可安装、可运行的领域技能。

这种方式的核心价值在于，把"业务理解"从一次性文档变成可执行资产。而支撑它的架构思想，就是正交分解。

六、本体驱动的数据分析与经营推理

本体在数据分析上的价值，最早是从一个具体的挫败感开始的。

我最早做 ChatBI，把表结构、字段定义全喂给 AI，结果它还是答非所问。用户问"收货准时率"，AI 答成"发货准时率"。

问题出在哪？传统元模型只有"骨架"没有"灵魂"。这就像给 AI 一本字典，但没有教它如何造句。

于是我做了一次元模型重构，把单层的数据字典扩展成七层：领域术语词典，让 AI 说人话；静态数据模型，解决数据存储；过程模型，回答数据怎么产生；指标推理模型，回答数据怎么用；呈现约束模型，约束数据怎么展示；上下文感知，理解弦外之音；元模型治理，让系统越用越聪明。

核心判断只有一句：不仅告诉 AI 数据"是什么"，还要告诉 AI 数据"从哪来""到哪去""为什么"。

到了真要跑经营分析的时候，我把架构收敛成一个三层公式：确定性计算，加语义锚定，加开放推理。

第一层是确定性计算。SQL 只允许 SELECT、强制 LIMIT、禁止 DDL 和 DML，配合同环比、3σ、RFM、ABC 这些统计算法，只负责算数，不负责解释和因果。

第二层是语义锚定。本体模型提供实体、指标口径、业务规则、分析场景和数据映射，负责把"业务语言"翻译成"数据语言"。

第三层是开放推理。大模型做模式识别、因果推断、策略建议，输出必须带置信度标注，思维链流式可见，引用的每个数字都可溯源。

所以本体的定位发生了变化。它不再试图做推理，而是为推理提供一个可信的语义基础设施。从这个角度说，它既是语义锚点，也是一本翻译词典。

这个定位的调整，来自一次很痛的自我审查。我逐行审查了分析系统的代码，发现一个根本性的架构混淆：精确算法和动态模糊推理的边界被混在一起了。

这里有一句话我想强调：把这类任务交给大模型不是"智能化"，而是"概率化"——把一个百分之百可靠的操作，降级成了概率性操作。

所以三层分离是必须的。精确层负责"是什么"，动态层负责"为什么"和"怎么办"。能由 SQL、数学公式和明确规则完成的判断，坚决不调用大模型。

分析推理过程的约束，我还专门做了一套规范化流程，核心思路是把关键指标一对一映射成分析场景。

场景用统一编号管理，比如 GMV 异常波动分析、有效订单数异常、客单价异常、退款率异常、活跃用户下降、复购率异常、用户流失、类目结构异常、转化率异常、漏斗异常，每个场景独立成篇。

每个场景下要写清楚五件事：原因树、异常判定规则、取数 SQL、交给大模型的输入包、建议方向。场景生命周期也是固定的：数据就绪检查、数据采集、异常判定、归因拆解、综合推理与建议。

还设计了一棵大模型介入决策树。先判断能否由明确公式或规则完成，能就不调用；再看是否缺数据，缺就先补查；最后看是否需要语义理解、假设比较和综合归因。

有三条底线是不容商量的：相关性不得认定为因果；未触发异常的场景正常结束，只有异常场景才做深度下钻；不确定的推断必须使用"可能""初步判断"这类限定语。

这套东西我在两个行业做过验证。电商那边跑了 GMV 异常波动、用户流失、营销 ROI 几个场景，能一路下钻到具体类目、具体渠道、具体 SKU。

有一次真实的探测结果很说明问题。GMV 从 522 万掉到 251 万，订单数掉了六成，客单价反而涨了两成多——这是典型的幸存者偏差信号，只看客单价会得出完全错误的结论。

继续下钻才发现，服装类目占比从 29% 掉到 11.8%，退款率却从 11.8% 降到 1.1%，说明退款已经恢复正常，但占比还在下降，用户信任的恢复有滞后性。

物流场景里我特别在意一件事：经营管理人员通常不接受只有一个最终结论的黑盒工具，尤其当结论会影响定价、班次、网点和客户策略时，过程透明比结果炫技更重要。所以规则模型的作用不是替代大模型，而是为大模型提供可复用、可审计的推理边界。

最后回到闭环。分析完不是终点，本体驱动分析真正的收口是回写。从指标异常追溯到具体行为过程，再给出改进建议，最后把建议回写执行——这条链路才是本体在数据分析上最独特的地方。

七、本体驱动的知识库：从 RAG 到"场景—概念—实体"

知识库这条线，我是从对 RAG 的不满足开始的。

传统 RAG 的逻辑很直接：资料切块、向量化、存入向量库；提问时做一次相似度检索，取回 top-k 片段，塞给大模型归纳成答案。它解决了大模型知识过时和缺乏私有知识这两个硬伤，所以迅速成为主流。

但应用一深入，问题就暴露出来了。检索精度不稳定，一次向量召回容易漏掉关键前提、条件和例外；多跳推理能力弱，问题涉及多层依赖时很难一次命中完整证据链。

这些问题不是调参能解决的，而是结构性的。我有一句话总结得很直接：向量检索擅长语义相近，但不擅长逻辑相关。

比如问 A 对 C 的影响，系统可能召回大量同时提到 A 和 C 的片段，却漏掉"B 是 A 影响 C 的必要条件"这个关键中间环节。缺少这层骨架，模型只能靠语言直觉去补，补出来的就是幻觉。

所以更稳的路径是知识编译：先用大模型从资料中抽取核心场景、概念、实体及其依赖关系，形成一个知识图谱式的元模型，问答时先建立回答框架，再按框架去查原文取证。

我把这套东西整理成"场景—概念—实体"三层。场景层回答"这个问题属于哪类业务问题"，概念层回答"这件事的本质是什么"，实体层回答"具体是哪个对象、哪个工具、哪个案例"。

写作和问答其实走的是同一个流程——问题解析、场景匹配、概念组装、实体调取、原文深挖、结构化输出、反向校验。

最后一步的反向校验尤其重要，它会稳定输出五类建议：新的场景、新的概念、新的实体、需要补全的关系，以及死链。

说到这里，就不得不提一个我修正过的判断。我一度认为应该放弃 RAG，改走纯粹的知识编译路线。后来我把结论收回来了：不是二选一，而是在已有 RAG 之上叠加本体层，做本体双向约束的 Agentic RAG。

本体在这个架构里承担双重角色。前置角色是查询规划器，把自然语言问题转成概念、实体、场景和关系路径，生成子问题和检索计划，约束检索的深度、广度和优先级。

后置角色是质量校验器，校验答案是否覆盖了本体路径上的关键节点，是否符合依赖和约束，不通过就生成校验报告并触发下一轮。

一句话概括分工：本体管怎么查，向量库管查证据，大模型管组织答案。本体从静态知识库，被提升成了过程控制器加质量门禁。

这里有一条边界必须说清楚：本体校验通过不等于事实正确。它只表示相对于当前本体，答案是完整且一致的。如果本体本身缺失、过时或者错误，校验一样会放行错误答案。

除了企业知识库，我还在自己身上做了一次实验。我用本体论建模的思路，把自己从 2014 年到 2026 年的几百篇原创文章做了一次通读和抽取，构建了一套个人思维元模型。

我在介绍它时说过一句话：对象具有行为，行为产生转化，关系构成网络，场景驱动组装。思维体系不只是知识的静态集合，而是一个可操作、可推理、可演进的语义系统。

最后要区分两个容易混淆的概念。知识，是实践后感觉可以重复使用的有用经验的沉淀；技能，是基于场景调取和应用知识解决问题的能力。所以技能等于知识库加提示词工程加上下文管理加 MCP 加最佳实践加案例模板。

八、逆向工程：把埋进代码里的语义捞回来

前面讲到设计态到运行态会丢失行为与规则，那么一个自然的问题就来了：存量系统怎么办？答案是逆向工程。

做逆向之前，我先给自己划了一条边界：本体建模更多是业务建模，逆向的重点是软件需求，而非具体的技术实现。因此具体的类、接口、类方法我不关心。

那要逆向什么？

我的清单是八类：UI、对象、行为、规则、流程、场景、事件、权限。

对象这一块，只逆向持久化实体，并结合代码判断它是不是聚合对象；控制类对象不看，对象自身的参照完整性规则直接内建到对象模型里。

行为这一块，对齐的是界面驱动的操作方法，也就是最小单元的功能用例；规则这一块，只抽取逻辑层独立存在的规则，和对象内建约束分开。

场景这一块最关键。需要完整分析整个项目源代码后，基于数据本身之间的调用顺序和依赖关系，去梳理端到端的业务场景。

比如采购订单依赖采购立项，采购接收依赖采购订单，那么场景自然就是采购立项到采购订单再到采购接收。这个顺序不是我拍脑袋定的，是数据依赖关系决定的。

做法上，我先让 AI 参考本体建模规范，产出一份逆向建模指导书，把整个逆向过程的阶段、方法、检查单要求都定义清楚，再拿这份指导书去处理真实的源代码工程。逆向完成以后，会得到一套覆盖 UI、对象、行为、规则、流程、场景、事件、权限的完整 YAML 本体模型。有了这套模型，就可以很方便地构建知识图谱来总览全局。

逆向这几条路径里，我觉得最有意思的一条是企业架构文档的转换——把 TOGAF 那套规划文档，转成可以运转的本体模型。

我拿一个手机制造行业的架构参考文档做过这件事，七章、七十万字、五十多份 Excel、七十多张 HTML 图。文档虽多，但归纳下来其实就是四类东西：业务对象是名词，业务行为是动词，业务规则是约束，业务场景是端到端流程。转换过程里踩过几个坑值得记下来。一个是属性误拆，对象名里用斜杠连接的"物料/BOM""工厂/车间"其实是两个东西，不该塞在一个名字里。

还有一个是对象合并错误，销售发货单和销售出库单是两个独立对象，前者是履约指令，后者是物权转移凭证，语义不同、系统归属也不同。

再一个是场景里行为引用的命中率问题，154 个步骤只命中了 49 个行为，其余只能保留原文，等后续做语义对齐。

验证方式是按 LTC 顺序一个对象一个对象地走：线索、商机、报价单、销售合同、销售订单、销售发货单、销售出库单、销售发票、客户应收、收款单。走完一遍，链路是通的，说明模型立得住。

立得住的支柱有四根：可追溯、口径一致、规则在前、跨域能通。我还发现了一个意外收获：财务侧那条"三单匹配强制"的规则，和合同、发货、发票一致性是同源的，一套规则在应收和应付两端通用。

再往下走一步，就碰到了领域建模的一个老问题。任何业务领域，其实都有两个维度：横向的端到端流程，和纵向的指标分析。

横向用 UML 或者 DDD 能解决，纵向用数仓和 BI 也能解决，但两者综合起来，恰好是原来没有去解决的问题。

所以完整的本体模型必须包含这两者，并且双向贯通：指标可以下钻到流程节点，流程节点也可以预见会影响哪些指标。

最后我把静态的力导向图谱升级成了"模拟执行"：选一个场景，点下一步，图谱高亮当前步骤涉及的全部节点，并连带显示关联的对象、规则和指标。

我有一个判断：如果一个模型不能拿来模拟，说明它还不够精确。本体模型的完整度在于"能用"，不在于"全"。

九、边界、滥用和还没解决的问题

讲了这么多，必须回过头泼一盆冷水，否则这篇文章就不诚实了。

本体论正在被捧成一种无所不能的神话，变成了一种能包治百病的灵丹妙药。脱离了具体场景和具体问题去空谈本体论，基本就是水中月、镜中花，看着很美，抓不到手里。

那到底什么场景该用，什么场景不该用？我用两条轴做了一个判断：一条轴是算法能不能提前固定，另一条轴是结果能不能容忍置信度。四条象限一画，结论其实很清楚。

算法明确、又需要精确结果的场景，本体几乎无关，老老实实写代码就够了。如果规则的应用方式是固定的、可以提前写死的，那我直接写代码就好了，根本用不着大模型去"推理"。

场景会变、但依然要求精确结果的，本体只能起辅助编程的作用。销售合同这类系统需要的是精确的算法、精确的结果，差一分钱都不行。

真正的主场只有一个：算法不可提前固定，同时又能容忍一定置信度，需要动态分析和溯因推理的场景。此外还有一道准入门槛——模型是否足够复杂，是否有大量对象关联和复合规则约束，是否有高质量的数据支撑。

还有几条边界必须记住。

不要期望本体论去解决你的数据质量问题。恰恰相反，你的数据质量会直接影响后续基于本体模型的推理效果。地基如果是流沙，上面的动态推理也站不稳。

企业私有业务经验如果不显性化，只想简单建一个本体模型来代替企业核心业务专家，这个本身就是瞎扯淡。

本体模型是需要演进的。自然语言定义写着舒服，但它会随业务演进而漂移，怎么保证本体描述始终和真实业务对得上，这是个工程治理问题。

最后是我自己列出来的、当时还没想清楚的问题：深链推理的可靠性边界在哪里；精确与大规模约束要不要破例引入外部确定性计算；场景层自己会不会变成新的复杂度；上下文塞不下时检索粒度怎么定。

还有三条：方差到底能压到什么水平，因此对于 AI 推理后的置信度必须量化，不能只说一句"会好一些"；"完整"怎么变成可测量的东西；以及我的真实增量到底比别人多在哪。

列完这些问题，我反而对这件事有了一层更冷静的认识。它目前更多还是一个有清晰核心主张、有若干原创设计的体系，远没有被充分验证。

十、写在最后

把这一整条线索收束起来，我想说的其实是一件事：我们可能正站在一场软件范式结构性转变的门口。

这场转变的本质，是在弥合软件开发中长期存在的三个鸿沟。

第一个是业务语义与代码实现之间的翻译鸿沟。从汇编到高级语言，从瀑布到敏捷，从单体到微服务，每一次范式跃迁的本质都是在降低"人的意图"转化为"机器执行"的摩擦成本。

第二个是传统 UI 操作与用户真实意图之间的表达鸿沟。过去是软件为主体，用户削足适履地去适应菜单和表单。AI 原生应用倒转了这个关系，软件第一次开始适应用户。

第三个是静态软件架构与动态业务演进之间的适应鸿沟。业务变更只需修改本体模型，代码和运行时行为自动同步。软件的边界，从此不再由菜单和表单划定，而由业务的语义本身划定。

说到底，本体模型是这场转变的核心杠杆。它不是文档，而是可执行的语义规范；不是静态的需求说明，而是驱动代码生成和运行时执行的、活的知识表示。

它把我从哲学的本体论一路带到了工程的最前沿，而它的根，始终扎在那个朴素的洞察里——事物不是静态的，研究事物要研究它的动态行为和关系。

也正因为如此，我其实对经典本体论不太感冒。经典本体论更多仍然是精确推理、演绎推理；而 AI 加本体更多是动态不确定推理、溯因推理分析。它不是简单地回答"是不是"，而是要回答：问题出来了，我该如何解决、如何决策。

用"可评测"替代"逻辑可判定"，用"可追溯"替代"形式化保证"，并主动接受非确定性这个取舍——这就是我绕了这么一大圈之后，得到的那个朴素而坚定的结论。