前言¶
给某个业务域做领域建模时，常见做法是先写一份需求说明，再由人把对象、流程、规则拆到表格里。产出的是文档，不是模型：后面要改一个规则，得回到文档里找；想让团队点开就能看整体结构，还得再写一份图谱说明或者手工做图。
这个 Skill 试图把这件事压缩成一次调用：输入行业、业务域和业务文档，产出一套按规范组织的本体模型（YAML）加一份独立可交互的 HTML 图谱。模型和图谱同源，改完重新出图即可。
这是什么¶
Skill 名称：本体驱动的企业可视化知识图谱，坐标 @user_81d33501/ontology-business-map，版本 1.0.0，来源 community，分类 ai-agent，发布者 user_81d33501，标签 requires_api_key=false。
它面向的场景是：用户明确要求「对某行业某业务域做本体建模」「生成业务本体模型」「做领域模型 + 可视化」「按建模规范产出 YAML + 动态图谱」。不是让模型自由发挥整理一份摘要，而是按既定视角切分业务域，产出可校验、可复查的模型文件，再渲染成图谱。
核心功能¶
五视角本体模型¶
建模结果是按五个视角组织的：对象、行为、规则、事件、场景、报表。这六项在资料中是并列列出的，实际执行时以 Skill 内附带的建模规范为准。
按视角切分的意义在于校验和补全：对象有没有对应行为，规则挂在哪个对象上，事件由什么触发，报表覆盖哪些对象。漏项在分视角审视时比在一段自然语言描述里更容易看出来。
独立可交互的 HTML 图谱¶
产出的 HTML 是独立文件，不依赖外部服务，可以单独分发或嵌入内部页面。这一点对交付场景比较关键：图谱要给业务方看，通常不希望对方安装环境或登录某个平台。
增量维护¶
除首次建模外，也用于在既有本体模型上补视角、修校验错误、重出图谱。即模型文件保留在项目中，后续改动走同一套流程，而不是每次重新从文档开始。
安装与启用¶
本篇依据的资料只有 SkillHub 页面元信息，未包含安装命令、目录结构或配置文件字段。官网页面本次抓取失败，因此下面不给出未经核实的 npx / curl 命令，以免误导。
启用方式建议先到官方页面确认：
https://api.skillhub.cn/user_81d33501/ontology-business-map
SkillHub 页面：
https://www.skillhub.cn/skills/user_81d33501/ontology-business-map
确认坐标为 @user_81d33501/ontology-business-map，版本 1.0.0，来源 community。该 Skill 标签为 requires_api_key=false，按元信息看不需要额外配置 API Key，实际以页面说明为准。
典型用法¶
首次建模¶
输入三要素：行业、业务域、业务文档。业务文档是建模依据，可以是需求文档、制度文件或流程说明。Skill 据此产出五视角本体模型文件和一份 HTML 图谱。
这类需求通常是这样的表述：
- 「对零售行业的库存管理业务域做本体建模」
- 「按建模规范产出 YAML，并生成动态图谱」
增量修改¶
在已有模型上操作时，直接说明要改的部分：
- 补一个视角，例如「给这套模型补上报表视角」
- 修校验错误，例如「校验报出规则挂在不存在的对象上，修掉」
- 改完重出图谱
适用场景与注意¶
适合的场景：有明确业务文档可依据、需要把业务域结构化成模型、并且需要把结果以可交互图谱形式交付给非技术角色的建模任务。
需要注意的地方：
- 建模质量取决于输入文档的完整度。文档里没有提到的规则和事件，模型里也不会有。资料中没有给出该 Skill 会主动补全业务知识的说明，不要假定它会替你补。
- 五视角是固定的切分方式，如果业务域的关注点不落在这六个维度上，需要自己判断哪些视角可以留空，而不是强行填充。
- 本篇只核实了 Skill 的名称、来源、版本、分类和功能描述，未核实 Skill 包内的建模规范细则、YAML schema 和图谱渲染实现。要确认字段级细节，需要安装后阅读 Skill 内的规范文件。
- 官网抓取失败，文中不保留无法核实的安装命令与配置项。
结尾¶
这个 Skill 的价值在于把「业务域建模」和「图谱交付」合并成一次产出：模型按视角组织便于校验，图谱独立可分发便于交付。两者同源，改动可以重新生成。
官方地址：https://api.skillhub.cn/user_81d33501/ontology-business-map
