本体驱动的AI原生应用开发-个人ontology-driven-dev开源项目解读和说明

大家好，我是人月聊IT。今天再次介绍下个人的一个本体驱动的AI原生应用开发项目。这个项目已经开源，具体地址大家可以访问并下载，也欢迎大家fork和star。

https://github.com/sharptoolbox/ontology-driven-dev

用大模型直接生成一套业务系统，今天已经算不上难事。你把一段需求描述丢过去，它能在几分钟里吐出前后端齐全的代码，页面能打开、接口能跑通，第一眼的观感相当唬人。但只要把时间往前推两周，问题就会成串地冒出来，而且往往一个比一个难缠。

需求改了一句话，代码要动哪几处，没有人说得清；数据库里的字段叫一个名字，前端下拉框的选项散在另一个常量文件里，两者之间的语义在任何地方都没有被记录；等到项目走到第二期，需求文档、数据模型和代码已经彻底分成三张皮，谁也说不清哪一份才是对的。这个名叫 ontology-driven-dev 的开源项目，想解决的正是这件事。

一、问题的根子：业务语义从来没有被当成一份资产

问题的根子，不在于模型不够强。真正的原因是，业务语义这件事从头到尾都没有被当成一份可以被机器消费的正式资产来对待。需求是人写的散文，代码是人写的程序，而夹在中间的那一层——业务到底由哪些对象、哪些行为、哪些规则、哪些角色构成——从来没有被沉淀成任何一份确定的东西。缺少了这一层，模型只能凭上下文去猜，于是每一轮生成都是一次重新猜。

更麻烦的是，业务信息里有两类东西的性质完全不同。一类是行业通识，比如合同通常有编号、名称、金额、签订时间，这类内容 AI 完全可以自己补全，补错了也不至于造成真实事故。另一类则高度依赖具体企业的组织架构、管理制度和合规要求，比如合同金额是否含税、某张单据要不要审批、由谁来审批、父对象作废时子对象怎么处理。这类内容一旦被 AI 自行假设，生成出来的就是一个逻辑上就错了的系统。字段命名风格不对无所谓，业务逻辑错了是灾难。

项目由此把整件事拆成三段：需求探索、本体建模、应用构建，并把它做成了一套可以交给 AI 助手执行、开源且可移植的技能包，能在常见的几种 AI 编程工具里跑起来。中间有一条贯穿始终的纪律：AI 可以很快，但每一步的业务真相必须由人拍板，AI 不许替用户假设。

二、需求探索：不问清楚，AI 就只能猜

需求探索是整个方法里最克制的一段，它内部又分成八个子阶段，每个子阶段结束都必须停下来等人确认。阶段零做总体理解确认，复述业务范围、列出业务域和核心对象，先请用户确认边界；阶段一探索业务对象；阶段二梳理业务功能与规则；阶段三专门做跨对象联动识别。

阶段四探索端到端协同流与审批流；阶段五梳理查询统计与固定报表；阶段六确认岗位角色与功能权限；阶段七则是可选的界面原型探索，必须用户先明确说需要，否则不得擅自产出界面内容。这条路径的终态，是一份符合需求编写规范的需求规格说明书。

具体怎么问、问到什么程度，项目做了很细的规定。行业通识类内容 AI 直接给出建议，并标注"以下为系统基于行业通用做法自动补全，请确认是否符合贵司实际情况"，让用户快速扫一眼即可；而依赖企业实际情况的关键信息，AI 必须提问，而且不许只提问不给答案。

项目规定了统一的提问格式，任何问题都要同时给出明确建议、建议理由、其他备选答案，以及快捷回复方式，用户只需要回一句"按 AI 建议"就可以直接通过。这个格式看起来是小事，实际上很关键：它把用户回答问题的成本压到了最低，同时又不让 AI 替用户做决定。

文档里还列了四十七项自检，只有全部通过、并且附录里不残留任何待确认项，这份文档才能被标记为完整、可以进入本体建模阶段。此外还有一份建模输入基线，把对象、行为、规则、角色、流程、报表、界面都按模型的语言整理成确定性输入。第二阶段不是重新理解一遍业务，而是拿着这份基线做翻译。

需求探索里有一个设计特别值得说，那就是规则归属的唯一性。项目明确规定，不是所有规则都进规则模型。只依赖单个属性值的约束，写进属性自带的引用规则，例如"合同总金额必须大于零"，绝不允许为它单独建一条规则；依赖同一对象多个属性、或者聚合内部子实体的约束，进对象级不变量。

只有真正跨对象、跨行为，或者需要被多个行为复用的判断，才进规则模型。这条规定把一个特别常见的坏习惯按死了——为了让模型看起来很完整而到处堆规则，结果是同一条业务判断在三个地方各写一遍，改一个漏两个，久而久之谁也不敢再动它。

另一个设计是把跨对象联动单独拎出来，当作一个强制且独立的阶段。原因很好理解：一句"合同收款完成后如全部收齐则关闭合同"，表面上看是一件事，实际上藏着两个独立对象和一条跨对象因果链。如果不专门拆解，很容易被简化成"收款行为里顺手把合同也改了"。项目的纪律是，行为只操作一个对象，跨对象联动必须通过声明显式建立，条件判断必须引用规则，而规则只做判断、不改状态。

三、七模型本体建模：把业务拆成互相正交的七个面

图片

本体建模阶段的核心，是七个互相正交的模型。它们把业务拆成七个面，每一面单独讨论、单独演进，同一件事不会被写三遍。这里面有一条不可违反的纪律：模型是唯一语义来源，数据库表、接口、菜单、权限、流程与规则，全部都可以回溯到某个确定的模型元素。

第一个模型是对象模型，描述业务世界里存在什么。它用领域驱动设计的语言来组织：聚合根是业务完整性的边界和对外的唯一入口，子实体不能脱离聚合根独立存在，值对象没有标识、靠值判断相等。合同和它的付款条款明细属于同一个聚合，同生共死；合同和开票则属于两个独立聚合，只能通过标识互相引用。

属性的类型体系相当完整，除了字符串、整数、小数、金额、日期、布尔、枚举之外，还专门定义了两类特殊类型：一类表示存储另一个聚合根标识的标量属性，另一类表示值来自数据字典、保存编码而在界面上显示名称。数据字典也在对象模型里定义，字典项保存稳定的编码，界面展示名称，已经用过的项应当停用而不是删除。

第二个模型是行为模型，定义系统能做什么。它最核心的约束是原子性：每个行为只做一件事、只操作一个对象、产生确定性的状态变更。行为分成改变状态的命令和只读的查询两类，触发方式又分用户点击按钮和系统自动触发两种。每个行为都带着前置条件、后置状态变更、需要校验的规则、需要的权限，以及一份联动声明。

这里有一处非常重要的语义分工：行为只回答做什么、改变什么状态，规则只回答条件是否满足，而行为之间的联动关系由联动声明显式表述。规范里有一句话说得非常直接——禁止把"全部收齐时关闭合同"这类条件结论直接写进源行为本身，必须拆成一条关闭校验规则，再加一个目标关闭行为。

第三个模型是规则模型，只处理超出单个对象边界的判断，分验证、计算、推导、转换、风控五类。规则是无副作用的被动组件，一律被行为同步调用，不主动订阅任何东西，也不直接改状态；它的输入输出必须清晰，并且支持独立的版本管理，便于随业务规则的变化单独演进。

第四个是主体模型，解决谁能做什么的问题，以基于角色的访问控制为基础，同时支持基于属性的权限扩展。参与者分为人类用户和系统账户，角色是权限的集合单元并且支持继承，权限粒度细致到行为级，同时携带数据范围和属性条件表达式，控制粒度可以做得相当精细。

第五个是流程模型，承载端到端协同流和审批流两类流程。它有一条硬约束：所有人工活动和审批活动的参与人只能引用角色，不许引用具体的人，也不许填自由文本的岗位名称。流程可以调用行为、规则和子流程，但不得复制这些定义。审批节点的不同结果通过边上的结果标记区分，网关至少两个分支、最多一个默认分支，子流程的调用图不许成环。

第六个是查询统计与报表模型，专门承载跨对象的查询和固定报表，分详情查询、列表查询、统计分析、固定报表四类。它有一条很干净的依赖约束：只与对象模型和行为模型直接发生关系，定义查什么、怎么关联、怎么统计、返回什么，而每一个查询对象必须绑定并且只绑定一条查询行为，两者严格一对一。它不引用规则、角色或流程，查询条件和聚合公式属于查询对象自身的定义，不算规则。

第七个是界面模型，它是入口层，也是追溯层，层级是总体界面、一级菜单、二级菜单、界面、操作功能点。菜单固定两级，一级菜单只做分组、必须至少带一个二级菜单，只有二级菜单关联具体屏幕。界面分单表维护、列表维护、主从表维护、查询列表四类，控件类型由对象属性类型决定，是一套固定映射。

界面模型最精巧的地方在于，它是纯粹的引用层，不重新定义任何语义。它只通过稳定标识引用前面六个模型，不重新定义对象、行为、规则、流程和报表，也不承载配色、字体、像素级布局这些视觉内容。这样一来，用户点哪个按钮、调用哪个行为、操作哪个对象、应用哪条规则、需要哪个权限，这条链路全程都由稳定标识串起来，既可以被机器追踪，也可以被人核对。

七个模型之间还设有强制的一致性门禁：行为模型里由用户触发的行为，必须被至少一个界面操作功能点引用，防止出现没人能触发的孤儿行为；查询模型与行为模型之间的绑定必须双向一致、严格一对一；流程模型引用的角色、行为、子流程必须都真实存在，且子流程调用图无环。这些门禁把模型的自洽性变成了可以被机器反复检查的对象。

四、从模型到系统：开发指导书与技术架构

图片

模型建完，还要落成能跑的系统，这是第三阶段。项目给了一份开发指导书，其中最实用的是一张模型到实现的映射总表：对象模型的聚合根落成主表，子实体落成从表并通过外键关联；命令类行为落成一个事务内的方法，用户触发类行为落成前端的一个按钮；联动声明则落成方法成功之后的同步调用。

规则落成规则引擎的求值逻辑；主体模型落成角色、权限、用户角色这三张系统管理表；流程模型的活动和分支落成一个由节点和边组成的流程定义；查询模型落成查询服务；界面模型落成菜单资源和前端路由页面。这份映射表的价值在于，它让模型里的每一个元素在代码里都有确定的位置，不存在模棱两可的地带。

指导书还规定了四条强制约定。第一条是业务编号自动生成，规则是对象英文别名大写取前三位、再加四位流水号，界面不显示也不可编辑，并且必须在同一事务内生成以免并发重号。第二条是任何业务表除业务字段之外必须追加五个默认字段，界面不显示、写入时自动赋值，删除一律走逻辑删除。

第三条是主从表单的单事务处理：先插入主表拿到主键，再为每个从表行自动写入外键，全部操作在同一事务里完成，任一失败整体回滚。第四条是规则必须完整实现，不允许只建模不落地——属性级引用规则和聚合级不变量在保存时校验，跨对象规则则在行为执行中或联动条件里求值，失败必须给用户明确的中文提示。

指导书最后给出十步标准流水线：写模型、登记清单、生成建表语句、注册数据字典、实现行为与规则、配置角色权限种子数据、配置流程引擎、配置菜单与页面、实现右侧的 AI 对话、最后做全链路联调验收。第九步尤其值得注意——在这个项目里，AI 助理不是可选的装饰，而是每一个由此方法产出的系统的标配。

技术架构文档定义的是这套系统的骨架，选型克制到有点固执：后端用 Python 加 Flask，单体分层、不拆微服务；数据访问直接使用标准库、不引入对象关系映射；前端用 React 加 TypeScript；图表固定用 ECharts；大模型走 OpenAI 兼容协议，地址、密钥、模型标识全部通过界面配置，不写死在任何代码里，换模型只改配置。

架构里有两条原创设计。第一条是本体模型的三重角色：它同时是业务建模的载体、程序生成的基础，以及 AI 推理的知识底座。第三重角色最有意思——同一份模型文件，既用来生成代码，又被喂给大模型当作业务知识的权威来源，从根上解决了"AI 不懂你的业务"这个老问题，它不需要猜，因为语义被显式注入了上下文。

第二条是运行时的语义注册表。系统启动时先把全部模型文件解析进来，在内存里构建一张语义索引，涵盖对象、子实体、数据字典、行为、规则、角色、权限、流程、报表、界面、菜单、数据库白名单等等，供接口层、AI 编排层、前端元数据接口和只读查询控制器共同使用。它是"一份模型、多处消费"的物理落点。

AI 编排层的系统提示词每次对话都动态拼装：业务域概述、本体模型语义——包括对象字段、行为、规则、流程，再加上只读接口能力清单和完整的数据库表结构，连字段的中文标签和表关联关系都写进去，最后一层是行为准则。能力路由的优先级也定得很清楚：能调用行为接口就走行为接口，能走标准查询就走标准查询。

只有统计、聚合、按条件汇总、自定义列这类即席提问，才允许 AI 自己构造只读查询语句去取数，都不行才退化为语义解释。原则是能调接口就不拼语句，能调标准查询就不走自由查询。为保证自由查询不出事，只读模块用一整套边界守住：只允许查询语句、只允许访问白名单表、强制追加行数上限、禁止多语句、用正则拦截增删改等关键字、设置执行超时、记录审计日志。核心校验不过十几行代码，但该堵的口都堵上了。

五、界面规范与合同管理参考案例

图片

界面规范解决的是界面长什么样，它和界面模型有明确分工：界面模型负责语义和结构，只通过稳定标识引用其他模型，不承载任何视觉内容；而视觉层面的东西——配色、字号、间距、布局骨架——全部写在一份独立的界面设计规范里，成为一份可以反复调用的资产。

规范整体走紧凑专业的路线，全局九号字，信息密度高，接近传统企业级桌面系统的观感。框架是三栏结构：顶栏高六十像素、深色底，左侧菜单宽二百五十像素、两级结构，中间是多标签工作区，右侧是宽四百像素的 AI 对话区，支持拖拽调宽，左右两侧都可以随时显隐。

表单布局是其中最基础也最见功力的一条：标签列固定宽度九十六像素、右对齐，控件左对齐，形成规整的标签列加控件列网格。三类界面布局同样是硬规则——单表维护一行两个控件，备注类长文本占满整行；主从表维护主表一行三个控件、从表在下方做成表格，新增维护删除都在表格内完成；查询列表则是条件在上、结果表格在下并支持分页。

控件类型与属性类型的映射和界面模型完全一致：日期用日期控件、枚举和数据字典用下拉框、对象引用用跳选框——左边文本框显示目标对象名称、右边小按钮弹出选择对话框，布尔用复选框，长文本用多行文本域。还有一条关于审批的硬规定：带审批流的功能界面，创建时必须提供"保存草稿"和"提交"两个独立的按钮，分别对应两个独立的行为，不许合并成一个"保存"。

规范最后还附了一整套可以直接复用的东西：完整的样式变量表、完整的样式库，以及单表、主从表、查询列表、两级菜单、登录界面这五段界面骨架。换句话说，它把界面长什么样这件事，也从提示词里抽了出来，变成一份无论谁来做、做多少次都能对齐的确定性资产。

方法论之外，项目还带了一套完整的、能跑的实物参考案例，也就是销售合同执行管理系统。它的交付物是三份咬合在一起的东西——一份真正走完八阶段探索、状态标记为完整的需求规格说明书，一套把文档翻译成模型的七份模型文件，以及一套照着模型真正实现出来、能登录能审批能查报表的前后端系统。

业务本身不复杂，但足够有代表性。这套系统管的是已经线下签字盖章完成的销售合同，从登记开始，覆盖付款阶段、开票、收款、内部审批和查询统计，涉及十个业务对象、十四个业务功能、五张查询报表、六个角色，另外还配了两条协同流和两条审批流，规模不大不小刚刚好。

最能体现本体驱动价值的，是那条跨对象联动链。业务上它只是一句话：财务人员录入一笔收款，系统自动重算开票的收款状态，再判断合同是否已经全部收齐，收齐了就自动结清。而在模型里，它被拆成一条完整链路——录入收款、更新开票收款状态、合同结清校验规则、更新合同结清状态。

收款和合同关闭是两个独立聚合上的两个行为，它们之间靠联动声明建立联系、靠规则判断条件。需求文档里连"联动失败怎么办"都确认清楚了：源业务事实仍然成立，下游状态进入待处理并自动重试，不因联动失败而回滚源事实。审批也一样完整，合同登记按金额分级，财务经理先审，达到一百万元再走总经理审批。

两种审批都确认了驳回和撤回的路径，并且都加了职责分离规则——提交人不得审批自己提交的单据。这些判断不是写死在代码里的，而是从需求文档确认、到规则定义、到流程引擎网关求值，一路贯下来的。案例还附带两份很别致的产物，第一份是单文件自包含的高保真可交互界面原型，把需求文档里的界面意图直接变成能点的页面。

另一份是界面调用链追踪工作台。它读七份模型文件，生成一个可以沿着引用逐级穿透的可视化工具：从一个界面出发，看它有哪些元素和操作；点某个操作，看它会调用哪个行为；再往下看这个行为属于哪个对象、应用哪些规则、需要什么权限、关联哪张报表、由哪个角色承担。它最狠的一点是数据完全驱动，所有标识、名称、关系全部从模型文件读出来，不把任何示例数据写死在代码里。这其实是在用可视化验证一件事：模型里的引用链是不是真的自洽、真的完整。

六、这套方法的价值，以及它不打算解决的问题

把这些串起来看，这个项目的价值不在某个单点技术，而在于它把"AI 写业务系统"从一次性生成，变成了一个可追溯、可验证、可演进的工程过程。最根本的一条是语义有了唯一来源：数据库表、接口、菜单、权限、流程、规则全部可以回溯到某个模型元素，不存在模型一套、代码一套的情况。

改需求的时候改的是模型，改完只需要重新生成或增量落地，代码和模型就能始终保持同步。第二条是需求是确认出来的，不是假设出来的。八个阶段加人工门禁，把关键业务信息强行拉回到用户面前，每个问题都带 AI 建议，既不让人被问题淹没，也不让 AI 越权拍板。

第三条是七个模型的正交分解，让复杂系统的每一面都能被单独讨论和演进。对象归对象、行为归行为、规则归规则，跨对象联动有显式声明、跨对象读取有查询模型、界面入口有界面模型。更大的好处是可测试——每一条一致性门禁，都是一次机器能跑的检查。

第四条是 AI 是真的原生进来了，而且是安全的。它从系统提示词构建、工具注册、能力路由、流式渲染，到只读查询白名单，整套都围绕"让 AI 复用同一套业务能力"来设计。写操作一律不碰、引导用户去固定页面；读操作优先走标准接口，必要时才走严格受限的只读查询；所有工具调用都记录审计日志。

第五条是交付形态完整，技术栈也不绑死。走完三步法，手里有一份需求规格说明书、一套模型文件、一套能跑的系统，可选还有一份界面原型和一张调用链工作台。技能本身不依赖任何特定工具的专有机制，主流 AI 编程工具都能跑；技术底座也是刻意选了最没脾气的组合，单体结构、无对象关系映射、零外部依赖，一个人一天就能把它跑起来。

也要说清它的边界。这套方法面向的是单体同步部署的中小型业务系统，比如合同管理、资产管理、客户关系管理这一类。它明确移除了事件驱动架构，跨对象协作走同步调用和流程编排，追求的是链路顺序、可预测、可调试，而不是分布式解耦。如果你的业务是大型分布式、强事件驱动、需要独立数据仓库和指标平台的，这套模型不是为它准备的。

它也有明确的框架外清单：对象到数据库表的映射由实现阶段落地，不在本体层建模；性能、容量、可用性这类非功能需求不在七个模型里；视觉样式、动画、无障碍、多端适配属于设计系统，也不在界面模型里。换句话说，七个模型覆盖的是系统做什么、核心业务为何如此运转、用户如何驱动系统，至于达到什么质量目标、如何部署运行，仍然需要配套的规格文档。

最后还有一层门槛要说在前面：这套方法的价值，建立在使用者愿意先花时间把业务想清楚这个前提上。八个阶段的探索、每一步的人工确认、逐条核对一致性门禁，这些都不是零成本。但反过来，如果你手上是一个边界清晰、需要长期演进、还要能被 AI 持续接手维护的业务系统，那这套三步法省下来的时间和踩掉的坑，会相当可观。