构建基于WorkBuddy的元技能-实现基于本体模型驱动的领域技能动态创建

为什么需要“元技能”

在企业软件建设中，最难的往往不是写代码，而是把业务说清楚、拆清楚、固化清楚。传统系统开发通常从需求访谈开始，经过需求文档、原型设计、数据库设计、后端接口、前端页面、测试部署等多个环节。每个环节都需要不同角色理解同一份业务材料，再把它翻译成自己的产物。这个过程天然存在语义损耗：业务人员说的是“合同付款条款”“开票对应付款阶段”“收款后更新开票状态”，需求文档里变成字段和流程，数据库里变成表和外键，代码里变成接口、函数和校验逻辑。只要其中任何一次翻译出现偏差，最终系统就会偏离业务真实意图。

WorkBuddy 的元技能构建思路，正是为了解决这个问题。所谓元技能，不是面向某一个固定业务场景的技能，而是一个“技能生成器”：它接收不同领域的原始需求，通过结构化需求探索，把业务对象、行为、规则、事件、流程、查询、界面和接口逐层澄清；再基于确认后的需求生成本体模型；最后把本体模型转换为一个可安装、可运行、可交互的领域技能。也就是说，元技能的产物不是一段说明文字，而是另一个真正能在 WorkBuddy 中使用的业务应用技能。

这种方式的核心价值在于，把“业务理解”从一次性文档变成可执行资产。需求探索不是为了写一份漂亮的文档，本体建模也不是为了画一张复杂的图，而是为了让领域知识直接驱动应用生成。最终形成的领域技能，不仅包含需求文档和模型文件，还包含自动建库引擎、单据录入表单、自然语言查询能力、本体知识图谱和 UI 调用链工作台。业务专家可以继续用自然语言与技能对话，也可以直接打开表单录入业务数据。这是从“写系统”转向“生成领域应用”的关键变化。

总体架构：需求探索、本体建模、技能生成三段式

整个元技能构建过程可以概括为三段式架构：第一段是需求探索，第二段是本体建模，第三段是领域技能生成。

第一段，需求探索，解决“业务到底是什么”的问题。用户可以只提供一段原始需求，例如销售合同履约管理、客户拜访管理、费用报销管理、采购订单管理等。元技能不会立即进入建模或开发，而是按照固定阶段逐步追问和确认。它先确认总体范围，再确认业务对象、业务功能、规则、事件协同、端到端流程、查询报表、角色权限、接口边界和 UI 原型。每个阶段都要求业务方确认，尤其是那些不能由 AI 自行假设的企业专属规则，比如金额是否含税、父对象删除时子对象如何处理、是否需要审批流、状态变化是否影响其他对象、查询统计口径如何定义等。

第二段，本体建模，解决“业务如何成为可执行模型”的问题。经过确认的需求会被转化为十一类模型：M1 对象模型、M2 行为模型、M3 规则模型、ME 事件模型、M4 场景模型、M5 主体模型、M6 流程模型、M7 查询报表模型、MU UI 模型、MM 对象-数据表映射模型、MI 接口模型。这些模型不是孤立文件，而是一套彼此引用、相互校验的语义网络。对象定义数据结构，行为定义用户能做什么，规则定义什么能做、什么不能做，事件定义事实发生，场景定义跨对象协同，流程定义端到端业务流，报表定义读模型，UI 定义用户入口，映射定义对象如何落到数据库，接口定义系统边界。

第三段，领域技能生成，解决“模型如何变成可用应用”的问题。元技能把本体 YAML 和 JSON、需求文档、知识图谱、UI 调用链工作台、运行引擎和录入表单打包到一个新的技能目录中。这个领域技能安装到 WorkBuddy 后，就可以通过自然语言触发，例如“打开合同录入界面”“查询当前所有合同信息”“录入开票”“查看已开票未收款记录”。

技能运行时会自动创建 SQLite 数据库，根据 M1 对象模型生成表结构，并基于模型元数据提供录入和查询能力。如果对话内容是录入单据，那么AI会自动打开动态UI界面方便业务数据的录入。

这三段式架构的关键，不是把开发步骤自动化得更快，而是让每一步都有清晰的语义边界：需求阶段不抢跑开发，本体阶段不随意扩展业务，技能生成阶段不再凭代码猜业务。业务结论一旦确认，就成为后续模型和应用生成的唯一依据。

需求探索：把模糊描述变成可确认的业务语义

元技能首先解决的，是原始需求往往不完整、不规范、不够可实现的问题。业务人员通常会说“我要做一个合同管理系统”，但这句话背后可能包含完全不同的范围：是管理合同起草审批，还是只管理签署后的履约？是销售合同，还是采购合同？是否包含开票、收款、变更、结清、归档？是否对接财务系统？是否需要客户门户？这些问题如果不在前期明确，后续生成的系统就会不可控。

因此，需求探索采用阶段化确认机制。阶段零确认总体范围，先把系统边界说清楚；阶段一确认业务对象，包括主数据、核心单据、明细对象、关联对象及字段口径；阶段二确认业务功能与规则，明确哪些是录入、哪些是查询、哪些规则在保存时必须校验；阶段三识别事件，判断哪些操作只是一次保存，哪些操作会在保存后影响另一个独立对象；阶段四确认跨对象协同场景；阶段五确认端到端流程和审批流；阶段六确认查询报表及统计口径；阶段七确认角色权限；阶段八确认接口需求；阶段九确认 UI 原型。

这个过程有一个重要原则：AI 可以基于通用业务知识自动补全，但不能替企业决定关键规则。例如“金额必须大于 0”属于通用规则，可以自动补全；但“合同总金额是否含税”“合同产生开票后是否允许删除”“一个开票是否允许多笔收款”“是否需要审批流”就必须由用户确认。为了降低业务方确认成本，每个问题都给出 AI 建议答案、建议理由和备选项。用户可以直接回复“按 AI 建议”，也可以针对某个问题修改。

这背后的设计思想是：让 AI 做结构化归纳和专业建议，让业务方做少量关键决策。传统需求访谈中，业务方往往被要求从零描述完整规则，负担很重；而元技能把通用部分先整理出来，只把高风险、不确定、企业专属的点拿出来确认。这样既保证了需求完整，又避免 AI 擅自扩展用户没有提出的功能。

以销售合同履约管理为例，原始需求只要求管理生效后的销售合同、付款条款、开票、收款和查询。经过阶段化探索后，系统明确不包含合同起草、合同签订过程、审批流、合同变更、自动关闭、财务核算、外部接口和导出功能。这个“不做什么”的确认，与“做什么”同样重要。因为很多系统失败不是因为功能少，而是因为边界不清、功能膨胀，最后模型和实现都变得混乱。

本体模型：把业务系统拆成可组合的语义构件

需求确认后，元技能进入本体建模阶段。这里采用的不是传统“页面加表”的建模方式，而是以业务本体为中心的十一模型体系。

M1 对象模型是基础。它描述业务世界中真实存在的对象，例如产品、客户、部门、人员、合同、合同付款条款、开票、收款等。对象模型强调聚合边界：合同与付款条款是一个复合对象，付款条款不能脱离合同独立存在；产品、客户、部门、人员则是独立主数据，通过 ID 被合同引用；开票和收款是独立业务对象，各自有生命周期和业务规则。这样建模可以避免把数据库表结构误当成业务对象，也能保证后续行为和规则都围绕业务语义展开。

M2 行为模型定义对象能做什么。合同可以录入，开票可以录入，收款可以录入，合同可以查询详情，已开票未收款可以查询，履约汇总可以查询。行为模型把“用户动作”变成稳定 ID，并记录前置条件、后置结果、所需权限和 UI 入口。这样后续无论是表单按钮、自然语言指令，还是流程节点，都可以引用同一个行为定义。

M3 规则模型承载跨对象或可复用规则。比如累计开票金额不得超过合同总金额，收款金额不得超过对应开票剩余未收款金额，收款对应的开票必须属于同一合同。这些规则不应该散落在页面脚本或接口代码中，而应该以模型形式存在，成为后续引擎执行和 UI 调用链追踪的依据。

ME 事件模型和 M4 场景模型用于表达跨对象协同。并不是所有顺序动作都需要建事件。合同录入时保存付款条款，只是同一聚合的一次主从保存；开票录入时保存付款阶段对应关系，也只是一次同步录入。真正的事件协同发生在收款保存之后：一笔收款记录生成后，系统需要判断该开票累计收款是否达到开票金额，如果达到，就更新开票的是否收款和收款时间。这条链路可以表达为“收款已记录”事件，订阅“开票是否已收款判断”规则，再触发“更新开票收款状态”行为。

M5 主体模型定义角色和权限，M6 流程模型定义端到端业务流，M7 查询报表模型定义列表、详情和汇总查询。MU UI 模型把界面、控件、事件与后端行为、规则、报表串联起来。MM 映射模型说明对象和属性如何落到数据库表和字段。MI 接口模型则明确系统边界：如果无外部接口，就明确标注无接口，而不是默认生成不必要的 API 契约。

这套本体模型的核心架构思想，是正交分解。对象、行为、规则、事件、流程、查询、界面、映射、接口各自承担单一职责，彼此通过稳定 ID 关联。它避免了传统系统里常见的混杂：页面里藏规则，接口里藏流程，数据库里藏业务含义，报表里重复计算口径。模型一旦拆清楚，系统就具备了可追溯、可扩展、可生成的基础。

从模型到技能：让领域知识变成可运行应用

本体模型生成之后，元技能并不止步于文档和图谱，而是继续生成一个完整的领域技能。这个技能包被安装到 WorkBuddy 的技能目录中，包含运行所需的全部材料：需求文档、十一模型 YAML 和 JSON、运行引擎、录入表单、知识图谱、UI 调用链工作台和 SQLite 数据目录。

运行引擎的设计遵循“模型驱动、轻量自包含”的原则。它读取 M1 对象模型和 MM 映射模型，自动创建数据库表；读取字段类型、必填、唯一、字典、引用等信息，生成基础 CRUD 能力；读取规则模型，执行必要的业务校验；读取对象关联信息，在查询时把外键 ID 转换为业务名称；读取报表模型，支持固定查询和自然语言查询的 SQL 生成依据。引擎不需要依赖大型框架，采用本地服务加 SQLite，就可以支撑 MVP 级领域应用运行。

录入表单也是由模型生成的。每个聚合根对象都会生成独立 HTML 表单。普通主数据采用两列表单布局，例如产品、客户、部门、人员；主从对象采用上部主表、下部明细表布局，例如合同基本信息加付款条款明细。字典字段自动渲染为下拉框，引用字段自动从本地接口拉取可选对象，编号字段只读展示并由引擎保存时自动生成。这样，用户无需等待前端开发，就能直接打开表单录入业务数据。

自然语言对话能力则让领域技能不只是一个表单系统。用户可以问“查询当前所有合同信息”“查一下已开票未收款记录”“查看某个合同详情”。技能根据模型元数据理解有哪些表、哪些字段、哪些外键关系和哪些报表口径，再生成只读 SELECT 查询，并把结果以表格返回。这里的关键不是让大模型随意猜数据库，而是让它在本体模型约束下进行查询翻译。模型提供了可理解、可追溯、可控的语义边界。

知识图谱和 UI 调用链工作台则用于解释和校验系统。知识图谱展示对象、行为、规则、事件、场景、角色、流程和报表之间的关系；UI 调用链工作台可以从一个界面控件一路追踪到行为、规则、对象和数据库表。对业务专家来说，这相当于一张可交互的业务地图；对开发者来说，它是模型一致性检查和后续扩展的依据。

最终效果：从一次需求到一个可用领域应用

通过元技能构建出来的领域技能，最终达到的效果是：用户不再只拿到一份需求文档，而是拿到一个可以运行、可以录入、可以查询、可以解释自身结构的业务应用。

以销售合同履约管理技能为例，最终技能可以管理产品、客户、部门、人员等基础资料；可以录入已生效销售合同，并同时录入合同付款条款；可以录入开票信息，并维护开票与付款阶段的对应关系；可以录入收款信息，并在累计收款达到开票金额时自动更新开票收款状态；可以查询合同列表、合同详情、已开票未收款记录和合同履约汇总。整个技能明确不包含未确认功能，例如审批流、合同变更、外部接口、导出和驾驶舱，从而保持系统边界清晰。

更重要的是，这套能力不是为合同场景硬编码的。合同只是一个验证样例。换成采购管理、项目交付、售后服务、设备巡检、客户拜访、费用报销，只要业务存在相对清晰的对象、单据、规则、流程和查询口径，就可以走同样的管线。不同业务需求进入同一个元技能，经过需求探索形成不同的本体模型，再生成不同的领域技能。

这意味着 WorkBuddy 中的技能可以从“人工编写”走向“本体生成”。过去要做一个领域技能，需要手工写说明、写引擎、写表单、写查询逻辑；现在则可以把重点放在业务语义确认上。只要业务边界和规则确认充分，后续的模型文件、数据库、表单、查询和知识图谱都可以自动生成。AI 不再只是回答问题，而是在业务专家确认下，把领域知识沉淀成可执行的软件资产。

设计思路总结：用本体作为业务和软件之间的中间层

这套方法最核心的架构思想，是在自然语言需求和可运行应用之间增加一个稳定的本体层。自然语言适合表达业务意图，但不适合作为系统执行依据；代码适合执行，但不适合作为业务共识载体。本体模型位于二者之间：它足够结构化，可以驱动建库、表单和查询；又足够业务化，可以被业务专家理解和确认。

因此，元技能的真正价值不是“自动生成页面”，而是建立了一条语义连续的链路：原始需求经过九阶段探索，变成确认过的需求文档；需求文档变成十一模型本体；本体变成数据库、表单、规则、查询和工作台；这些产物再被打包成 WorkBuddy 领域技能。每一步都能回溯，每个功能都能找到来源，每条规则都能解释为什么存在。

这种架构特别适合企业内部大量长尾应用的构建。很多业务系统规模不大，但规则复杂、口径细碎、需要快速落地。传统开发模式下，这类系统往往因为投入产出比不高而迟迟不能建设；低代码平台虽然降低了页面搭建成本，但仍然需要人手工设计对象、字段、规则和流程。元技能则进一步把“建模”和“生成”结合起来，让业务人员与 AI 共同完成语义建模，再自动生成可运行技能。

最终，WorkBuddy 的领域技能不只是工具插件，而可以成为企业知识资产的一种新形态。每个技能都携带自己的需求背景、本体模型、界面入口、运行引擎和查询能力。它既能服务当前业务操作，也能被后续迭代、复用和扩展。随着更多领域技能被构建出来，企业会逐步形成一套可执行的业务本体库：不是静态知识库，而是可以录入数据、执行规则、回答问题、展示关系的活系统。

这就是基于元技能构建领域技能的最终目标：让需求不再停留在文档里，让模型不再停留在图纸上，让领域知识真正进入 WorkBuddy，成为能被调用、能被验证、能持续演进的软件能力。

另外，该技能已经发布到workBuddy对接的skills hub技能市场。在技能市场搜索本体驱动应用构建器（ontology-app-builder）即可搜索到并安装。具体如下：