ARTICLE · 995316

《本体驱动的 AI 数据管理》v0.3.0:从 16 个方法 Skill 到 25 个场景交付 Skill

发布时间：2026-09-15 20:34:53 最近访问：2026-09-15 20:34:51

《本体驱动的 AI 数据管理》Skill 套件 v0.3.0 更新记录

上一篇文章本体驱动的 AI 数据管理：16 个 Skill 的工程化实现，我介绍了自己怎样把《本体驱动的 AI 数据管理》拆成 16 个可以被 AI 调用的 Skill。

当时这套 Skill 已经覆盖了场景选择、知识提取、7+1 语义映射、模型质量检查、黄金用例、Agent 行动控制和本体运行治理。后来在 v0.2.x 里，我又把它从 Codex 扩展到 Claude Code 和 WorkBuddy，并补齐了三端打包、校验和发布链路。

从方法覆盖和工程结构看，它已经比较完整了。

但我把它重新放回真实场景里用了一遍，问题很快就出来了。

如果我只问：

❝
这个场景适不适合使用本体？

原来的 Skill 能回答。

如果我继续追问：

❝
我已经拿到一个场景，后面想把它做成智能体。智能体在这里到底能做什么？场景需要怎样完整梳理？业务、财务、IT 三类数据分别需要哪些？本体建设过程中究竟要产出哪些东西？

原来的 Skill 就开始出现断层。

它能告诉我有哪些方法，却很难连续交付一套可以直接指导建设的产物。

这就是 v0.3.0 的起点。

一套方法，进入真实场景后还缺什么

最初的 16 个 Skill 更像 16 张方法卡。

比如：

判断场景是否适合本体；
用 29 类语句提取业务知识；
用 7+1 检查语义是否完整；
用多层质量门审查模型；
用黄金用例做业务验收；
按风险决定 Agent 能否自动执行。

这些方法本身都有价值。真正开始施工时，中间还缺少一组更细的工作：

场景里哪些任务值得交给智能体；
智能体、确定性系统和业务人员怎样分工；
怎样把一句场景描述展开成完整业务过程；
为了完成这些任务，需要哪些业务、财务和 IT 数据；
知识来源、业务语义、概念模型和逻辑本体分别负责什么；
已经确认的数据怎样进入本体类、属性、关系和实例；
每个阶段应该交付什么，满足什么条件才能继续。

如果这些环节没有展开，AI 很容易在拿到一句场景描述后直接生成类、关系和规则。模型看起来很完整，里面混着大量未经确认的假设。

所以这次更新，我把重点放在了“从场景到交付物”的中间过程。

第一个调整：判断完本体，还要先判断智能体做什么

我一开始设计的链路是：

场景适配
→ 知识结构
→ 语义模型
→ 本体模型

继续讨论后发现，这里面少了一个很关键的问题：

❝
这个场景如果要做成智能体，智能体到底负责哪一部分？

有些工作适合智能体，例如阅读材料、识别意图、关联跨系统信息、解释规则、生成建议和协调任务。

有些工作更适合确定性系统，例如金额计算、固定规则校验、状态控制和事务写入。

高风险审批、例外判断和责任承担仍然需要业务人员。

只有这三方的边界清楚了，才能判断智能体需要什么知识、本体应该支撑哪些任务、Action 可以开放到什么程度。

因此，v0.3.0 增加了 scenario-agent-role-design。它会先输出：

智能体在场景中的作用；
候选任务及优先级；
Agent、系统和人工的责任边界；
每项任务的输入、输出和完成条件；
自动化等级、权限和人工介入点；
后续需要的数据、知识、本体和工具能力。

如果智能体只能完成简单查询，场景也没有复杂关系、规则和追溯要求，本体范围就可以及时缩小。

第二个调整：在建模前，把整个场景真正梳理清楚

确定智能体大致做什么之后，还不能马上进入语义建模。

一个完整场景至少需要回答：

谁在什么情况下触发任务；
当前过程怎样运行；
中间有哪些判断、审批和系统操作；
涉及哪些对象、事件和状态；
正常、边界和异常情况分别怎样处理；
Agent 在哪个步骤介入；
最终什么结果算完成；
哪些内容属于首期范围。

这部分现在由 business-scenario-deep-analysis 负责。

它形成的场景规格，是后续数据需求、知识结构和语义建模的共同输入。场景深描之后，还要重新确认一次本体范围。很多时候，一个大场景只需要在其中一两个任务上建设本体。

第三个调整：把场景数据需求单独拆出来

真实项目里还有一个经常被跳过的问题：

❝
为了支撑智能体完成这些任务，到底需要哪些数据？

这次新增了 scenario-data-requirements-readiness，专门梳理业务、财务和 IT 三类数据。

以“工程进度变化影响预算”为例：

业务数据包括项目、WBS、工程活动、计划进度、实际进度、变更事件、合同和工程量；
财务数据包括预算事项、预算版本、成本、实际发生和资金计划；
IT 技术数据包括系统标识、接口、表字段元数据、更新时间、权限和调用日志。

这三类数据还要继续判断：

支撑哪个 Agent 任务；
用于哪个判断或动作；
需要什么粒度、时间和版本；
来自哪个系统、表、字段或接口；
当前是否有权限和真实样本；
质量和时效是否满足；
缺失后会阻断哪个任务。

在这个阶段，系统、表、字段和接口的位置就应该确认下来。后面的语义模型负责解释这些数据在业务上表示什么。

第四个调整：重新划清知识结构和语义模型

这一部分我们来回校准了几次。

最开始，我把对象、术语、关系、约束和规则同时放进了“场景相关的知识结构”。这样写会和数据语义发生明显重叠。

现在的划分是：

场景相关的知识结构

负责组织当前场景需要的知识原料：

制度、文档和业务资料；
数据和接口说明；
历史案例；
专家经验；
已有模型和语义资产；
知识来源、证据、责任人和适用版本；
知识冲突和缺口。

它回答的是：完成 Agent 任务需要哪些知识，这些知识在哪里，可信度怎样，由谁确认。

场景相关的语义模型

负责对这些知识形成正式、统一的业务定义：

术语、概念和业务对象；
属性、标识和数据粒度；
业务对象分类体系和概念继承关系；
组成、归属、影响、依赖、责任和状态关系；
业务约束、规则、事件、流程和例外；
权限、动作、输入输出和前置条件；
场景目标、Agent 任务完成条件和评价口径。

这里还有两个容易混淆的点。

“分类与层级”现在改成了“业务对象分类体系与概念继承关系”。项目包含 WBS、WBS 包含工程活动属于组成关系；工程进度变更属于工程变更事件，才属于概念继承。

“目标和评价指标”也做了收敛。语义模型里保留场景业务目标、Agent 任务目标、动作结果以及完成条件。语法是否通过、SHACL 是否通过等指标，交给后面的技术验证阶段。

第五个调整：把模型建设继续拆到可以施工

语义模型完成后，v0.3.0 又补了三个连续环节。

概念模型

ontology-conceptual-model-design 把语义条目组织成业务专家能够审查的多种视图，包括：

概念关系图；
类层级树；
对象关系图；
规则决策表；
事件与状态流转；
流程、动作和权限矩阵；
目标与评价路径。

概念模型先解决业务是否看得懂、关系是否准确、规则是否符合实际。

逻辑本体模型

ontology-logical-model-generation 再把已经确认的概念模型转成机器能够处理的形式，包括 RDF、OWL、SKOS、SHACL、查询模板和 Action 契约。

这一步保留来源、状态和版本，未经确认的内容继续保持候选状态。

数据到本体映射与实例构建

这里也修正了一个容易写错的地方。

真实数据在哪个系统、哪张表、哪个字段，已经在数据需求和准备度阶段确认。

data-to-ontology-mapping-and-instantiation 负责的是：

一条数据记录对应哪个本体类；
一个字段对应哪个本体属性；
外键或映射关系对应哪个对象关系；
状态代码对应哪个统一概念；
业务标识怎样生成稳定的实例 URI；
数据变化怎样更新、失效或形成新版本实例。

这一调整让“数据源定位”和“数据进入本体”变成了两个边界清楚的工程步骤。

v0.3.0 现在形成了怎样的链路

经过这些调整，完整链路变成了：

本体适用性初判
→ 智能体作用与任务识别
→ 场景完整梳理
→ 业务、财务、IT 数据需求与准备度
→ 场景相关的知识结构
→ 场景相关的语义模型
→ 概念模型
→ 逻辑本体模型
→ 数据到本体映射与实例构建
→ 技术验证
→ 业务验证与黄金用例
→ 资产登记、版本发布和运行服务
→ 运行反馈与模型演进

这次新增了 1 个总控 Skill 和 8 个施工型 Skill，整个仓库从 16 个扩展到了 25 个。

统一入口是：

ontology-scenario-delivery

用户只需要提供场景、资料和当前数据条件。它会先判断当前成熟度，再决定能够产出哪些成果、缺少哪些输入、下一步调用哪个 Skill。

资料不完整时，输出候选框架和缺口清单。具备制度、数据字典、真实样本和专家确认后，再进入逻辑模型、实例、验证和发布。

每一个关键条目都要保留：

唯一编号；
所属场景和 Agent 任务；
定义；
来源和证据；
当前状态；
责任人；
适用范围和版本；
对应模型、实例、测试和运行结果。

状态统一为候选、有证据、已确认、已验证、受阻和已废弃。

这样，一条语义可以沿着下面的路径一直追下去：

原始资料或数据
→ 知识条目
→ 语义元素
→ 概念模型元素
→ 逻辑本体元素
→ 数据实例
→ 黄金用例
→ Agent 运行结果

三个平台继续共用同一套核心

v0.3.0 继续支持：

Codex；
Claude Code；
WorkBuddy。

三端共用同一套 SKILL.md、详细契约和模板。平台适配只处理安装、发现、文件能力和输出降级。

目前已经完成：

25 个 Skill 的结构与引用校验；
9 个新增 Skill 的规范校验；
Codex 和 Claude Code 各安装 25 个 Skill 的本地冒烟测试；
25 个 WorkBuddy 单 Skill 包校验；
三个主发布包和 SHA-256 校验；
GitHub Actions 与正式 Release 发布。

新的 25 Skill 路由环境还需要继续在三个真实客户端里做行为抽样。这个状态已经写进 README 和测试记录里。

怎么安装和更新

项目地址：

https://github.com/SuperChason/ontology-driven-ai-data-management-skills

v0.3.0 Release：

https://github.com/SuperChason/ontology-driven-ai-data-management-skills/releases/tag/v0.3.0

Codex：

./scripts/install.sh codex --force

Claude Code：

./scripts/install.sh claude-code --force

WorkBuddy 可以从 Release 下载合集，再按实际需要上传单个 Skill ZIP。完整的安装、使用、更新、验证和回滚方式已经写进 README。

写在最后

上一篇文章解决的是一个问题：怎样把书里的方法拆成 AI 可以调用的 Skill。

这次 v0.3.0 继续往下走了一步：当我真正拿到一个业务场景时，这套 Skill 能不能告诉我智能体做什么、需要什么数据和知识、怎样形成语义和本体、每个阶段应该交付什么、怎样验证它能够进入运行。

目前这套链路已经形成，接下来还需要放进更多真实场景里使用。只有经过真实数据、业务专家和运行反馈反复校准，它才会逐步变成一套真正可复用的本体落地工具。

如果你也在做企业 AI、知识工程或智能体项目，欢迎一起讨论：从一个业务场景走到可运行本体，中间还有哪些经常被忽略的施工环节？