上一篇说低代码平台的元数据是本体的天然矿藏，huozige-ontology-builder 扫描工程文件就能产出本体。读到这里，一个合理的问题是：既然可以自动抽取，为什么还有人选择人工维护？

这不是一个非此即彼的问题，而是一个场景匹配的问题。两条路径各自有它适合的土壤，选错了路径，代价不是"稍微麻烦一点"，而是要么本体和系统长期不同步，要么维护成本把团队压垮。

两条路径分别在做什么

• 自动抽取的逻辑：是系统本身已经包含了本体所需的信息，从系统元数据里直接读取，结构化输出。本体和系统共享同一个信息源，系统更新，重新跑一遍抽取工具，本体就跟着更新。
• 人工维护的逻辑：是在系统之外独立建模，由专人负责定义实体、属性、关系，用本体建模工具或者直接编写 YAML、JSON 文件来描述业务领域的概念结构。本体是一个独立的知识工件，和具体系统的实现细节保持一定距离。

两者的分歧不是技术上的优劣，而是在解决不同性质的问题。

自动抽取适合什么场景

自动抽取的核心优势是同步性。本体和系统从同一个工程文件里读取信息，不存在"文档落后于代码"的问题。这对频繁迭代的应用系统来说价值显著——每次发版之后重新抽取，本体就是最新的，不需要人工介入，不会因为有人忘记更新文档而导致 AI 拿着旧本体调用已经改变的接口。活字格这类低代码平台的典型发版节奏是周级别，有时候更快。业务需求变了，开发者改完配置，下午就能上线。如果本体需要人工同步维护，这个频率下的维护成本会变成一个显著的负担。自动抽取在这里通常是更可持续的主方案。自动抽取还有一个隐性优势，它不依赖于"有人愿意写文档"这个假设。工程实践里，文档的质量和开发者的习惯强相关，而习惯是不可靠的。自动抽取把本体的结构完整性更多地从人的自律里解放出来，只要系统配置本身是规范的，本体的基础质量通常就更有保障。

自动抽取的局限同样清晰。它只能输出系统里已经存在的信息。系统里没有的概念，抽取不出来。一个字段叫"状态"，备注是空的，抽取出来就是一个没有业务含义的"状态"，AI 不知道它可以取哪些值、每个值代表什么。这是工程治理的问题，不是抽取工具的问题，但它确实是自动抽取这条路的天花板——本体的质量上限被工程治理的质量上限锁死了。

人工维护适合什么场景

人工维护的价值体现在两类场景里。

• 系统变化慢、但数据规模大、分析需求复杂的场景。 例如 ERP 这类系统的核心数据模型相对稳定，不会每周都在改字段加表。但它积累了大量的历史数据，分析需求涉及跨模块的复杂关联，需要一个精心设计的语义层来支撑 AI 的分析推理。这类场景里，人工建模能把业务概念描述得更准确，能把跨系统的语义对齐做得更彻底，这些是自动抽取做不到的。
• 跨多个异构系统做数据整合的场景。 企业里往往同时运行着不同年代、不同技术栈的系统，比如老 ERP、新 CRM、自研 WMS，每个系统有自己的命名习惯和数据结构。要让 AI 跨这些系统做推理，需要一个统一的语义层把不同系统里的同一个业务概念对齐。这个对齐工作不能只靠自动抽取，因为各个系统的元数据格式不同，而且对齐本身就是一个需要业务判断的工作，“这个系统里的’客户’和那个系统里的’买方’是不是同一件事”，很难只靠算法稳定地给出可靠答案。

人工维护的代价是显而易见的。它需要持续的维护投入，也需要同时理解业务领域和建模的人。一旦维护跟不上系统变化，本体就会和现实脱节，脱节的本体比没有本体更危险，因为 AI 会以一种"看起来有依据"的方式做出错误的调用。

决策变量

选择哪条路，有三个变量值得重点考察。

• 发版频率。 系统每周都在变，自动抽取通常更合适。系统一年改一次核心数据模型，人工维护往往也是可行的。这是非常重要的判断依据。
• 团队规模和能力结构。 人工维护本体需要同时理解业务领域和知识工程的人，这个复合能力在小团队里很稀缺。如果团队里没有这样的人，人工维护的结果往往是一个质量不稳定的本体，比自动抽取产出的版本更难信任。
• 场景性质。 如果 AI 的主要任务是操作具体的业务系统（创建单据、查询数据、触发流程），本体需要和系统接口紧密对应，自动抽取更合适。如果 AI 的主要任务是跨数据做分析推理，需要理解业务概念之间的深层关系，人工维护的语义层能提供更丰富的推理基础。

这三个变量不是独立的，通常会共同指向同一个方向。一个用活字格开发、频繁迭代、小团队维护的业务应用系统，三个变量都指向自动抽取。一个大型企业的跨系统数据分析平台，三个变量都指向人工维护。真正需要权衡的是中间地带——系统迭代频率中等，团队有一定的知识工程能力，场景介于操作和分析之间。这种情况下，务实的策略是用自动抽取建立基础，用人工补注来提升质量。自动抽取保证本体和系统同步，人工在自动抽取的结果上补充枚举值含义、跨实体的语义说明、业务规则描述。两者不是互斥的，自动抽取是底座，人工补注是增量。

一个容易忽视的风险

不管选哪条路，有一个风险在两种方案里都存在，只是形式不同。

• 自动抽取的风险是"垃圾进，垃圾出"。 工程治理差，抽取出来的本体就差，而且差得很隐蔽，因为格式是对的，只是内容没有意义。
• 人工维护的风险是"维护断档"。 最初建本体的人离职了，接手的人不清楚当初的建模逻辑，新增的业务概念被遗漏，本体和系统悄悄脱节，但没有人发现，直到 AI 开始用过时的本体做出错误的操作。

这两个风险都没有银弹，但它们各自的应对方式不同。前者的应对是工程治理规范，后者的应对是本体的版本管理和定期审计。选定路径之后，对应的风险管理机制需要同步建立，这件事很容易在项目启动时被忽略，等出了问题再回头补，代价会更高。

本文是"企业AI落地"系列的第13篇。下一篇做一次具体的拆解：从一个活字格工程出发，完整列出能被抽取的本体内容清单，从实体到策略，逐类说明。