让 AI 照着业务需求自己生成软件，难的不是写代码

AI 写代码已经不稀奇。更难的问题是：能不能让 AI 直接照着业务需求，生成一整套能跑起来、还能跟着业务演进的系统？一位深耕企业系统架构多年的资深架构师花近一年研究这件事， 9 月做了一次复盘。他把结论压成一句话：把业务语义从"给人看的文档"变成"机器能执行的规范"，是让 AI 接手软件的那根杠杆。话音刚落他就泼了盆冷水，这条杠杆只在很窄的一类场景里使得上劲，而且它说"校验通过"的时候，不代表事情真对了。

传统 IT 有个老毛病。系统分两类：干活的事务系统， CRM 、 ERP 、 MES 这些；看数的分析系统，数仓、 BI 、数据中台。这两类天生割裂，分析系统看到的和业务系统做的，中间接不上。

他反复用的一个例子：在 BI 里发现库存周转率异常，本该一年周转 12 次，眼下只有 8 次。管理者更想知道是哪个行为把这个数拉下来的？传统 BI 答不上来，它底层只有数据模型，没有行为和规则模型，只能给出结果和一个计算公式，讲不清来龙去脉。

把这层隔膜捅破的，是他反复强调的一个动作：回写。作者举的另一个例子是供应链交付中断，某个核心材料因供应商原因断供一两个月，在 BI 里就是一条预警，传统做法是通知供应链主管，剩下靠人调整。按本体建模的思路，这条中断会触发一个事件，进入模型的消息管道。管道底下本就铺好了供应链模型，供应商、物料、合同、订单、交期和约束规则都在里头。它拿到"交期延误"的消息后自动计算，给出决策，可能是把某张客户订单往后延，也可能引入新供应商，再调用回写接口把决策写回业务系统，主管只审核建议。按作者的说法，这是本体模型第一次接通从分析到执行的路线，让数据分析穿透到业务行为，传统架构下做不到。

还有一类损失更隐蔽：数据模型落地到数据库表里看得见，可行为和规则写在代码里，被打包进编译产物，看不见也追不着，事后想查一个数据结果背后的业务逻辑，几乎无从下手。

它到底怎么建？ 作者把一套系统拆成三样东西：对象、行为、规则。对象回答"存在什么"，行为回答"能做什么"，规则回答"什么必须成立"。原则定得很硬：对象是第一性的，先定对象再定行为；每个行为必然改变至少一个对象的状态；规则是不变式，无论何时何地都得成立；还有一条他格外看重，"对象链即流程"——合同对象和开票对象、开票对象和收款对象之间的映射，本身就体现了对象流转，不必专门再画流程图。

这里有个关键设计：规则不塞进对象的方法里，而是独立出来当一等公民。传统写法是"合同保存"方法内部去调完整性校验、预算校验，规则被淹没在方法里，既看不见也不能复用。独立出来后，一条规则能被多个行为引用。比如合同税率合规校验，合同录入要调它，开票录入也要调它，一处定义、多处复用。作者给了条判断标准：一条规则被两个以上行为引用，才值得单独拎出来。联动靠事件驱动：数据一保存就触发事件，事件进管道触发规则，规则跑完要改对象属性，就调用回写接口。作者把这条链总结成"逆向闭环"：事件→规则→行为→回写接口→更新数据。

往上再走一步，就是 AI 原生应用。 出发点是，能不能用一种比代码更接近业务语义的中间语言描述一套系统的全部知识，再让 AI 照着它生成应用？传统开发的摩擦点就在翻译损耗：业务专家用自然语言说意图，开发者翻译成代码，歧义和理解偏差全出在这一段。本体模型就是那套中间语言，担着三重角色：它是业务建模的载体，业务专家跟 AI 对话就能把本体写成 YAML ，不需要会编程；它是程序生成的基础， AI 读这份 YAML ，自动生成数据库建表语句、接口骨架、权限策略、 AI 工具 Schema ，每行代码都带溯源标签；它还是 AI 推理的知识底座，运行时把语义加载进注册表，作为提示词里的结构化知识。三个角色是同一主张的延续：业务语义变成可执行规范，既能供人生成，也能供机器运行。

落地拆成四个阶段：需求探索阶段，"我要一个合同管理系统"这种话信息密度太低， AI 会先追问，合同有哪些核心属性？一个付款阶段能开几次票？然后是本体建模，生成对象、行为、规则、场景，用树和知识图谱两个视图让业务方确认；再做交互原型，用户用自然语言调布局，但这一阶段只能改 UI ，要是提"再加个审批流程"， AI 必须提示这是需求变更、得退回第一阶段；最后是编程交付， AI 生成代码并自动部署。一句话：自然语言进， AI 原生应用出。走完这一路，卡点还是那句老话，能不能把业务讲成机器能执行的规范。

但边界必须说够。 作者泼的冷水最狠：本体论正在被捧成无所不能的神话，离开具体场景去谈，就是水里的月亮。他用两条轴划了四个象限，算法能不能提前固定，结果能不能容忍置信度。算法明确、又要精确结果的场景，本体几乎无关，规则能提前写死的，写代码就行，用不着大模型去"推理"。场景会变、但仍要精确结果的（销售合同，差一分钱都不行），本体只能起辅助编程的作用。主场只剩一个：算法无法提前固定、又能容忍一定置信度、需要动态分析和溯因推理的场景。此外还有门槛：模型够不够复杂、有没有大量对象关联和复合规则、有没有高质量数据撑着。

三条边界也得记牢。一是别指望本体解决数据质量问题，恰恰相反，数据质量直接决定后面推理的效果，地基是流沙，上面的动态推理也站不稳。二是企业私有的业务经验如果不显性化，就想用一个本体模型替代核心业务专家，作者的原话是"瞎扯淡"。三是本体校验通过不等于事实正确：它只说明相对当前这套本体，答案是完整且一致的；本体本身缺了、过时了或者错了，校验照样放行错误答案。

他还记录过一次电商分析： GMV 从 522 万掉到 251 万，订单数掉了六成，客单价反而涨了两成多，只看客单价会误判。他还逐行审查自己分析系统的代码，发现精确算法和模糊推理的边界被混在了一起。他的结论是，把这类任务交给大模型，这是把百分之百可靠的操作降级成了概率操作。所以他立了三条底线：相关性不许当成因果；没触发异常的场景正常结束，只有异常场景才做深度下钻；不确定的推断必须带上"可能""初步判断"这类限定语。

收尾回到主张。 作者的判断是，我们可能正站在一场软件范式结构性转变的门口。这场转变在弥合三个鸿沟：业务语义与代码实现之间的翻译鸿沟，传统 UI 操作与用户真实意图之间的表达鸿沟，静态软件架构与动态业务演进之间的适应鸿沟。而本体模型是这场转变的核心杠杆，按他的定性，它是可执行的语义规范，而不是一份静态文档。他对这套东西的评价却很克制：它"有清晰的核心主张、有若干原创设计，远没有被充分验证"，还列了一串没想清楚的问题，深层推理的可靠性边界、置信度怎么量化、"完整"怎么可测量、自己的真实增量在哪。

所以这件事值得记住的，是它敢把边界写在明面上。一份规则写得再漂亮，说"校验通过"也只是说"相对我自己没矛盾"，离"事实正确"还有一段距离。先想清楚自己卡在哪一象限，比急着替代业务专家要重要得多。作者自己给的收尾是：用"可评测"替代"逻辑可判定"，用"可追溯"替代"形式化保证"，并主动接受那份不确定性。