构建本体最耗时的部分，通常不是写本体本身，而是搞清楚系统里有什么。

一个传统的手工编码系统，业务概念散落在各处：

• 表名在数据库里
• 字段含义在注释里
• 接口逻辑在代码里
• 参数规则在开发者的记忆里
• 业务实体和技术实体的对应关系可能只存在于当初写代码的人的脑子里。

要从这样一个系统里提炼出一份结构化的本体，首先要做的是"考古"，阅读代码、问人、猜测、验证，然后把挖出来的东西整理成机器可读的格式。这个过程费时费力，而且很难保证完整性。

活字格这类元数据驱动的低代码平台，能显著降低这个问题的处理难度。

元数据驱动意味着什么

"元数据驱动"这个词有时候被用滥了，在这里它有具体的工程含义。

活字格的开发者在平台上搭建应用时，不是在写代码，而是在配置：创建一张表、定义它的列、设置数据类型、建立表关联、创建服务端命令、定义命令的输入输出参数、在页面上放置控件、把控件绑定到数据源。这些配置行为产生的所有信息，都以结构化的形式存储在工程文件里。

换句话说，开发者在搭建系统的过程中，已经在无意识地生产本体所需的大量原材料：实体（表、页面、服务端命令）、属性（列、参数）、关系（表关联、数据绑定、服务端命令的输入输出参数关系）、动作（服务端命令、内置数据服务）。这些信息不在注释里，不在文档里，不依赖开发者有没有养成良好的记录习惯，它就在工程文件的数据结构里，格式固定，程序可读。

这是低代码平台在 AI 集成这件事上最被低估的优势，它让本体所需的大量结构信息从隐性变成了显性。

传统系统的对比

用一个具体的例子说明差异。

假设两个系统都实现了"采购订单"这个业务功能。

传统手工编码的系统，表名可能叫 po_header，字段名可能叫 vnd_id（供应商 ID 的缩写）、cr_dt（创建日期的缩写）、stat（状态）。接口可能是一个 REST 端点 /api/v2/po/create，参数格式定义在一个 Swagger 文件里，但 Swagger 文件上次更新是八个月前，和当前代码已经有出入。stat 字段的枚举值是 1、2、3、4，具体含义要去查另一个叫 po_status_dict 的字典表，或者去问做这个模块的开发者。

活字格里实现同样的功能，表名叫"采购订单"，字段名叫"供应商"、“创建日期”、“审批状态”，字段类型和约束在平台里显式配置，枚举类型的字段可以直接在列定义里写备注说明每个值的业务含义，服务端命令叫"创建采购订单"，输入参数叫"供应商 ID"、“采购数量”、“预计到货日期”。这些名称和配置以 JSON 格式存储在工程文件里，huozige-ontology-builder 扫描这个工程文件，就能直接产出结构化的本体。

同一个业务功能，一个需要考古，一个可以自动抽取。差距不在业务复杂度，在于系统的元数据是否以机器可读的形式存在。

能抽取出什么

从一个活字格工程里，自动抽取可以覆盖本体的全部四类要素。

实体

实体层面，可以抽取出两类。技术实体是系统内部的概念节点：每一张表是一个实体，每个服务端命令的输入参数集和输出参数集各自是一个实体。业务侧的语义节点是面向用户的概念入口：每个页面都可以提供一个业务入口，页面上的表格控件名称通常比表名更贴近业务语言。两类节点在本体里并存，它们之间的对应关系就是第九篇里说的"技术名称和业务名称的对齐"。

属性

属性层面，每张表的列定义直接对应实体的属性：列名、数据类型、是否必填、唯一性约束，这些在工程文件里都有明确记录。服务端命令的每个参数同样如此：参数名、类型、是否必填，加上开发者填写的备注（如果有的话）。

关系

关系层面，活字格工程里存在几类关系可以直接提取。表关联（一张表的外键指向另一张表的主键）是最明确的实体间关系；数据绑定（页面上的控件绑定到某张表的某个视图）建立了业务实体和技术实体之间的关联；服务端命令的输入输出参数定义了命令实体和数据实体之间的读写关系。

动作

动作层面，内置数据服务（TableBinding）是系统提供的标准查询接口，可以直接作为内置动作；开发者创建的每个服务端命令（简单理解为WebAPI）是自定义动作，名称、描述、参数约束全部来自工程配置。

把这些信息组合在一起，一份能让 AI 正确操作业务系统的本体就成型了。整个过程不需要人工逐条描述，huozige-ontology-builder 扫描工程文件，输出一组结构化的 Markdown 文件——一个索引文件列出系统的整体概况，每个实体、每个绑定、每个服务端命令各有一个详情文件。

自动抽取的边界在哪里

自动抽取不是万能的，它的产出质量直接取决于工程本身的治理质量。

如果表名是 GLC_JJPCHZB，自动抽取只能原样输出这个名字，AI 不知道它代表什么。如果枚举字段的备注是空的，抽取出来的属性描述就是一个没有业务含义的数字列表。如果服务端命令的名称是 cmd_execute_003，AI 无法从名字推断这个命令的用途。

这些是工程治理的问题，不是抽取工具的问题。抽取工具能做的是把已有的信息结构化地输出，但它没有办法凭空创造信息——开发者没有写的业务说明，抽取工具补不上来。

这个边界很重要，因为它决定了导入本体之前需要做哪些准备工作。治理的目标不是让工程"符合某种格式"，而是让工程里的信息足够清晰，清晰到一个刚入职的开发者读了之后能理解系统在做什么。能达到这个标准的工程，自动抽取出来的本体质量通常也是够用的——因为 AI 和刚入职的开发者在这件事上面临的是同一个问题：从有限的元数据里理解一个陌生系统。

低代码平台的这个优势很少被提及

谈论低代码平台的价值时，通常听到的是"开发速度快"、“不需要写代码”、“业务人员也能用”。这些都是真的，但在 AI 集成的语境下，元数据的可读性是一个更底层的优势，而且很少被单独提出来讨论。

一个用活字格开发的系统，在搭建完成的那一刻，它的元数据就已经是本体抽取的原材料了。不需要额外的文档工作，不需要为 AI 集成单独维护一套描述，更新系统之后重新运行抽取工具，本体就跟着更新。这种和系统同步的能力，相比大多数依赖额外文档维护的手工编码系统，要更容易实现。

用一句话总结，手工编码系统的结构信息需要被"挖出来"，低代码系统的结构信息本来就在那里，等着被读取。

本文是"企业AI落地"系列的第12篇。下一篇讨论本体的两条建设路径：从系统自动抽取，还是在系统外独立维护——两种方式各自适合什么场景，决策变量是什么。