ontology-driven-dev：把业务语义钉成 AI 原生应用地基的本体建模开发法¶

📊 Level ⭐⭐⭐ | 8.9KB

ontology-driven-dev：业务语义作为可被机器消费的正式资产¶

开源项目（github.com/sharptoolbox/ontology-driven-dev，作者人月聊IT）针对的墙：大模型写业务系统"看着能跑"，但需求改一句话不知道代码改哪几处，二期后需求文档、数据模型、代码三张皮。根因判断："业务语义"从头到尾没被当成可被机器消费的正式资产——需求是散文、代码是程序，中间"业务由哪些对象、行为、规则、角色构成"的共识从未沉淀，模型每轮生成都是重新猜。

解法朴素而硬：在需求和代码之间钉死一层本体模型，让需求变成模型、模型生成代码、运行时 AI 读同一份模型。做成可交给 AI 助手执行的技能包（Skill），在 WorkBuddy、Claude Code、Codex、Cursor 里运行。

三步法 + 五份规范 + 七模型¶

强顺序三阶段管线（不能跳步）：①需求探索——一句话煲成符合《软件需求编写规范 V9.0》的规格说明书，内部八个子阶段每个结束必须停下等人确认；②本体建模——把已确认语义翻译成七份 YAML 模型；③应用构建——落成能登录/录入/审批/查询、侧挂 AI 助理的可运行系统。"强制人工确认"贯穿全程：AI 可以快，但每步业务真相由人拍板。

技术底座故意选"最没脾气"的组合：Flask + SQLite + React，单体、无 ORM、同步调用；工具调用全审计日志。

诚实边界（作者主动声明）¶

面向单体同步部署的中小型业务系统（合同/资产/CRM 类）；v9.0 明确移除事件驱动架构；M7 声明不是 BI 指标模型；非功能需求（性能/容量/可用性）不在七模型内；价值建立在"使用者愿意先花时间把业务想清楚"的前提上——八阶段人工确认不是零成本，需求本身模糊则救不了。

深度分析¶

本体模型的"一物三用"是整个架构的支点¶

原文最具启发性的判断是：同一份七模型 YAML 在系统里同时扮演三个角色——业务建模载体、代码生成基础、运行时 AI 的结构化知识底座。前两重角色是传统建模的常规用法，第三重才是 AI 原生的关键增量：系统启动时把全部 YAML 解析进内存语义注册表（Ontology Registry），AI 编排层每次对话都从注册表动态拼装系统提示词，把对象字段、行为、规则、流程甚至数据库字段中文标签全部注入上下文。这从根上改写了"AI 不懂你的业务"的默认处境——模型不再靠上下文猜业务语义，因为语义被显式喂进去了。这解释了为什么"需求改一句话"在本项目里不引发恐慌：改的是 YAML，代码、界面、AI 提示词全部随之同步，三张皮问题在源头消解。

A 类/B 类划分把"AI 替用户假设什么"变成可执行规则¶

需求探索阶段的精髓不是"多问"，而是精确切分业务信息的性质：行业通识（合同有编号、金额、签订时间）允许 AI 直接补全并标注来源；而依赖企业制度与合规的事实（金额是否含税、单据谁来审批）属于 B 类，AI 必须提问且不许只提问不给答案。配套的统一提问格式——建议 + 理由 + 备选项 + 快捷回复"按 AI 建议"——是一个成本工程学设计：它把用户回答的认知负担压到扫一眼点一下，同时用"每个子阶段结束必须停下等人确认"的硬门禁守住 AI 不越权拍板的底线。这与常见"AI 一口气生成全部需求文档"的做法形成鲜明对照：前者产出快但错误埋进地基，后者产出慢但每一层都被人签收。

规则归属唯一性：同一条业务判断只能有一个家¶

规范把约束写入位置钉死为三级：只依赖单个属性值的进属性级 refRules；聚合内多属性或子实体间的进对象级 invariants；只有真正跨对象、跨行为或被多个行为复用的判断才进 M3。这条规定直接封死了"为了看起来完整而到处堆规则"的坏习惯——同一条业务判断在三个地方各写一遍、改一漏二的经典腐烂模式。与之配套的是语义分工三件套：行为只回答"做什么、改变什么状态"，规则只回答"条件是否满足"，跨对象联动由 syncTriggers 显式声明。跨对象联动被单独列为强制阶段三，正是因为"收款后收齐自动关合同"这句话表面是一件事，实际藏着两个独立聚合和一条因果链，不拆就会腐烂成"收款行为里顺手改合同"。

MU 作为纯引用层：让调用链全程可被机器追踪¶

UI 模型 MU 被刻意设计为不重新定义任何语义的引用层——只通过稳定 ID 引用 M1～M7，视觉样式交给独立的 UI-UE 规范。由此"用户点哪个按钮 → 调用哪个行为 → 操作哪个对象 → 应用哪条规则 → 需要什么权限"这条链路全程由稳定 ID 串起，既能被机器校验（USER_ACTION 行为必须有 MU 引用、M7 与 M2 双向一致、子流程图无环），也能被人核对。参考案例附带的"UI 调用链追踪工作台"是这个设计的自我验证工具：从 YAML 读出全部 ID 与关系，沿引用逐级穿透可视化——本质上是用机器检查模型引用链的自洽性，而不是靠人工 review。

克制底座与开放查询的张力处理¶

技术选型固执地"最没脾气"（Flask + SQLite + React、单体、无 ORM），但 AI 层却做了激进的事：允许 AI 自由构造只读 SQL。这组张力的解法是能力路由分层（行为 API → 标准查询 → 只读 SQL → 语义解释）加十几行核心校验：仅 SELECT、白名单表、强制 LIMIT、禁多语句、正则拦截写关键字、超时与审计日志。项目明确承认固定报表覆盖不全即席提问，与其硬凑报表不如把"安全地跑自由 SQL"做好再放手——用"固定工具管高频确定性操作、AI 对话管低频探索性提问"的 Hybrid UI 分工收尾，写操作则一律引导回固定页面。

实践启示¶

给业务语义建一份"单一事实源"，并让它被代码与 AI 同时消费。 哪怕是手写的一份 YAML/JSON 语义清单，只要数据库结构、接口、菜单和 AI 提示词都从它生成或校验，"改需求改哪几处"就从考古题变成查表题。
把"AI 可以假设什么"写进提示词层面的硬规则。 仿照 A/B 类划分：通用行业知识允许自动补全但需标注"基于通用做法，请确认"；依赖本组织制度的事实必须提问，且每个问题自带建议答案与理由，把确认成本压到"回复一个字母"。
先定规则归属再写规则。 建模或编码前先声明三级约束的判定标准（属性级 → 聚合级 → 跨对象），从制度上杜绝同一业务判断散落三处；跨对象联动必须显式声明，禁止在某个行为里"顺手"改另一个对象的状态。
为模型一致性写机器可跑的门禁，而非靠人工 review。 孤儿行为检测、引用双向一致、调用图无环——这些检查成本低、可反复运行；再用一个从模型文件直接读数、沿引用链穿透的可视化工具做人工抽查。
放开 AI 读、锁死 AI 写。 运行时 AI 接入业务系统时，读路径给足（标准 API 优先 + 严格受限的只读 SQL 兜底即席提问），写路径全部引导到固定页面，所有工具调用留审计日志——这是目前最稳妥的 AI 原生权限姿态。

定位¶

与 Anthropic Skill 模式的 skill-as-workflow 思路同构，但把 skill 的对象从"AI 如何做事"换成了"业务本身长什么样"；其"语义资产层"主张是 Context Engineering 在需求工程侧的延伸。人工确认门禁与 Harness 验证思想同源。

→ 原文存档