跳到主要内容
AI教程

用 ontology-driven-dev 从业务需求构建本体驱动管理系统

本教程介绍如何在 Claude Code、Codex、Cursor 等 AI 工具中安装 ontology-driven-dev，并按照人工确认的三阶段流程，将业务描述转化为需求规格、七模型 YAML 和可运行的 Flask、SQLite、React 管理系统。

AI我搜编辑部阅读约 11 分钟
用 ontology-driven-dev 从业务需求构建本体驱动管理系统

项目简介

ontology-driven-dev 是一套面向业务系统开发的 AI 技能，采用“需求探索 → 本体建模 → 应用构建”的强顺序三步法。你可以从一句业务描述开始，在人工逐阶段确认后，得到需求规格说明书、七模型 YAML，以及可运行的浏览器前后端系统。

它的核心目标不是单纯让 AI 快速生成代码，而是保证需求文档、本体模型和最终代码严格对齐。数据库表、接口、菜单、权限、流程、规则和报表均以模型为语义来源，从而减少需求、设计与实现相互脱节的问题。

需求探索阶段包含八个步骤，每一步都必须暂停并等待人工确认，不能由 Agent 自动跳过。

核心能力与项目结构

关键特性

  • 需求可追溯：每项功能都能够回溯到需求规格说明书中的对应条目。
  • 七模型统一语义：通过 M1、M2、M3、M5、M6、M7 和 MU YAML 描述对象、行为、规则、主体、流程、查询报表与 UI。
  • 人工确认门禁：需求探索的阶段零至阶段七均需人工确认后才能继续。
  • 内置技术底座：code-paas 提供 Flask、SQLite、React 和 TypeScript 单体应用基础，并包含系统管理、流程引擎、工作台与本体注册表。
  • AI 原生交互：生成的应用必须包含右侧 AI 对话框，支持本体注册表注入、工具调用、SSE 流式响应与只读 SQL 安全边界。
  • 多工具兼容：可用于 WorkBuddy、Claude Code、Codex、Cursor、Aider、Cline 以及能够加载项目指令的通用 Agent。

仓库中的主要内容

  • SKILL.md：定义方法论、三阶段管线和必须遵守的执行纪律。
  • references/：包含需求编写规范、本体建模框架、模型到实现的开发指导、AI 原生技术架构和 UI/UE 规范。
  • reference-example/：销售合同执行管理的完整范例，包括需求文档、七模型 YAML 和 manifest.json。
  • techbase/：可复制扩展的 code-paas 源码，包括后端、前端、模型示例和依赖文件。

准备运行环境

开始前，请确认本机具备以下环境：

  • Python 3.10 或更高版本。
  • Node.js 18 或更高版本。
  • 首次安装 Python 与前端依赖时可访问网络。

后端使用 Flask 和 SQLite，前端使用 React、TypeScript 与 Vite。项目采用 MIT License，可自由使用、修改和再分发。

安装到 AI 开发工具

安装到 Claude Code

Claude Code 能够自动发现技能目录中的 SKILL.md。可以选择用户级安装，让所有项目都能使用：

cp -r ontology-driven-dev ~/.claude/skills/ontology-driven-dev

也可以安装到当前项目：

cp -r ontology-driven-dev .claude/skills/ontology-driven-dev

完成后，Claude Code 会根据技能 frontmatter 中的 name 和 description 识别并加载流程。

安装到 WorkBuddy

用户级安装命令如下：

cp -r ontology-driven-dev ~/.workbuddy/skills/ontology-driven-dev

如果只想在一个项目中使用，则执行：

cp -r ontology-driven-dev <你的项目>/.workbuddy/skills/ontology-driven-dev

安装到 Codex

Codex 没有原生技能注册表，因此需要先把技能复制到仓库：

mkdir -p .codex/skills
cp -r ontology-driven-dev .codex/skills/

然后在项目的 codex.md 或 AGENTS.md 中加入加载规则：

当用户要做“本体驱动开发、需求探索、本体建模、七模型、code-paas 或 AI 原生应用”时，加载 .codex/skills/ontology-driven-dev/SKILL.md，并严格按照三阶段流程和人工确认门禁执行。

Codex 会把人工确认映射为交互式提问或审批。它所在的沙箱需要联网，才能执行 npm install 和 pip install。

用于 Cursor、Aider 或 Cline

  • Cursor：将 SKILL.md 的内容放入项目规则或 .cursorrules。
  • Cline、Aider：在会话开始时粘贴 SKILL.md，或者明确要求 Agent 加载它的路径。
  • 其他 Agent：将该文件作为系统指令或项目记忆注入上下文。

第一阶段：探索并确认需求

第一阶段以 references/AI需求探索与确认提示词V9.0.md 为依据，把初始业务描述整理成正式的软件需求规格说明书。

你可以向 Agent 输入类似指令：

帮我开发一个销售合同执行管理系统，需要管理合同、回款、交付和审批。

Agent 应按照以下八个阶段依次推进：

  1. 总体理解。
  2. 业务对象。
  3. 业务功能与规则。
  4. 跨对象联动。
  5. 端到端协同与审批流。
  6. 查询统计与报表。
  7. 角色权限。
  8. UI 原型，可按需要选择。

每一阶段结束后，Agent 都必须按照“问题、AI 建议、理由、其他选项、快捷回复”的格式发起确认，并暂停等待你的决定。企业专属的 B 类内容也必须明确询问，未确认时不得进入下一阶段。

这一阶段最终生成：

<业务域>-需求规格说明书-V9.md

文档中的附录 C 是下一阶段的七模型建模输入基线，因此应重点检查业务对象、流程、规则、角色和报表是否完整。

第二阶段：生成七模型 YAML

需求确认后，Agent 根据 references/ontology_modeling_framework_v9.md 和需求文档附录 C 建立本体模型。此时输入已经是确定性基线，不应重新进行大范围业务拆分。

如果你已有符合要求的需求规格说明书，可以直接触发仅建模流程：

基于这份需求规格说明书，做本体建模，并输出七模型 YAML 和 manifest.json。

输出到 yaml/ 目录的内容包括：

  • M1 对象模型：描述业务对象。
  • M2 行为模型：描述业务行为。
  • M3 规则模型：描述业务规则。
  • M5 主体模型：描述角色与相关主体。
  • M6 流程模型：描述业务流程。
  • M7 查询报表模型：描述查询与报表。
  • MU UI 模型：描述用户界面。
  • manifest.json：记录模型清单。

完成建模后，应执行一致性检查，至少覆盖需求可追溯性、M7 与 M2 的一对一关系，以及 M6 引用是否无环。发现不一致时，应先修正模型，再进入代码构建阶段。

第三阶段：构建可运行的 BS 系统

复制 code-paas 技术底座

将技能目录中的 techbase/ 完整复制到当前项目的 code-app/：

cp -r <技能根目录>/techbase/. <当前项目>/code-app/
cd <当前项目>/code-app/frontend && npm install
cd <当前项目>/code-app/backend && pip install -r requirements.txt

正式开发时，应使用第二阶段生成的模型替换底座中的示例七模型 YAML。

按照十步顺序实现

  1. 写入或整理七模型 YAML。
  2. 生成 DDL 和数据库表。
  3. 注册数据字典。
  4. 实现行为与规则服务。
  5. 写入角色权限种子数据。
  6. 接入流程引擎。
  7. 生成菜单、页面与路由。
  8. 实现右侧 AI 对话框。
  9. 进行前后端全链路联调。
  10. 依据需求和模型完成验收。

右侧 AI 对话框是强制组成部分，不应在开发过程中省略。它需要遵守项目定义的本体注册表注入、工具调用、SSE 流式传输和只读 SQL 安全边界。

启动后端与前端

启动 Flask 后端：

cd code-app/backend
pip install -r requirements.txt
python app.py

后端默认访问地址为 http://localhost:5000。

另开一个终端启动前端开发服务器：

cd code-app/frontend
npm install
npm run dev

前端默认访问地址为 http://localhost:5173。默认账号是 admin，默认密码是 admin123；更多底座运行细节可查看 techbase/README.md。

常用触发方式

根据已有输入和目标，可以采用不同的触发语。

从需求开始完整开发

帮我开发一个设备维修管理系统，严格按本体驱动开发流程执行，每个需求探索阶段都等我确认。

只进行本体建模

基于这份需求规格说明书做本体建模，输出 M1、M2、M3、M5、M6、M7、MU 和 manifest.json。

根据现有模型构建应用

基于这几份七模型 YAML 生成系统，使用 code-paas 底座，并完成前后端联调。

“本体驱动”“需求探索”“本体建模”“七模型”“code-paas”“AI 原生应用”和“业务系统开发”等关键词也可以帮助 Agent 识别技能。

进阶实践建议

不要跳过人工门禁

即使初始需求看起来很完整，也不要一次性让 Agent 直接生成系统。逐阶段确认可以提前暴露对象边界、审批节点、权限范围和统计口径等问题。

把附录 C 作为建模边界

阶段二应以需求文档附录 C 为确定性输入。若建模时发现关键业务内容缺失，应回到需求阶段补充并确认，而不是让模型自行扩展未确认的业务范围。

优先检查跨模型引用

进入代码构建前，重点核对 M7 与 M2 的对应关系、M6 的引用关系以及需求条目到模型元素的可追溯性。模型层面的错误如果进入数据库、接口和页面，会增加后续联调成本。

保留黄金范例用于对照

reference-example/ 提供销售合同执行管理的完整实物范例。首次使用时，可以对照其中的需求规格说明书、七模型 YAML 和 manifest.json，理解各阶段产物之间的衔接方式。

先替换模型，再扩展底座

techbase/models/ 中的是示例模型。正式项目应先放入自己的七模型 YAML，再按照模型到实现的十步流水线扩展后端服务、权限、流程、菜单和页面，避免直接围绕示例数据修改业务代码。

结语

ontology-driven-dev 将需求澄清、本体建模和应用实现连接成一条带人工门禁的开发链路。正确使用它的关键，是坚持先确认需求，再验证七模型一致性，最后基于 code-paas 构建和验收。这样既能利用 AI 提升业务系统开发效率，也能保留清晰的语义来源与完整的需求追溯关系。