企业官网建设流程全解析

第22篇在流程描述里提到，治理是影响本体质量最关键的前置工作。这篇把治理的具体内容展开，逐类说明哪些问题最影响 AI 的调用准确率，以及怎么修。

一个重要的前提：治理不是一次性的突击工作。它应该作为开发习惯嵌入日常的工程实践，让每次迭代产出的代码本身就达到可被 AI 理解的质量。如果一个系统在开发阶段就遵循了这些规范，接入 AI 工作台几乎不需要额外的治理投入。

为什么治理质量直接影响 AI 准确率

AI 在处理任务时，依赖本体里的元数据做推理：这个字段是什么含义、这个命令做什么操作、这两张表是什么关系。如果元数据是残缺的或者模糊的，AI 的推理就建立在一个不稳定的基础上。

一个字段叫stat，AI 不知道它是"状态"还是"统计"，不知道可以取哪些值，只能猜。猜对了，这次调用成功；猜错了，传了一个系统不接受的值，调用失败，AI 还要花一轮上下文推理为什么失败。每一个模糊的元数据都是一个潜在的错误点，而且这类错误很难通过调整 Prompt 来修复，因为问题出在信息层，不在推理层。

把元数据治理好，是让 AI 调用准确的最高性价比投入。

名词治理：让 AI 认识你的概念

表名和列名不用拼音，不用缩写。

这条规则的门槛看起来低，但在实际项目里违反的频率很高。历史系统通常有大量拼音命名的表：CGRK（采购入库）、CGRKD（采购入库单）、CGRKDMX（采购入库单明细）。这些名字对当初写代码的人来说是一目了然的，但对 AI 来说，CGRKDMX和XYZ_TABLE_002一样，都是没有语义的字符串。

改成中文或规范英文之后，AI 至少能先认识这个表叫什么，初步判断它适合回答什么类型的查询。语义信息从名字本身流动出来，可以减少额外描述的负担。但名字不能替代显式元数据，表关联、权限边界、枚举取值、操作约束仍然需要在工程里配置清楚。

技术侧名词在所有位置保持一致。

一个业务概念在系统里可能出现在多个地方：表名叫"费用单元"，页面标题叫"成本中心"，服务端命令参数里叫"部门"。三个名字指的是同一个东西，但 AI 不知道。它会把三者识别为三个不同的概念，在推理时产生混乱。

治理的目标是在技术侧选定一个主规范名，所有技术实体尽量统一使用这个名字。用哪个词不是最关键，关键是同一层级内部一致。如果业务侧习惯用"成本中心"，而历史表名里叫"费用单元"，可以保留业务侧别名，但要让本体明确记录它们指向同一个概念。

业务侧名词可以在页面名和表格名里使用，且在这个范围内保持一致。

考虑到实际情况，我们可以给技术实体（表）用技术侧规范名词，业务实体（页面）可以更贴近业务语言。"采购订单管理"这个页面名，比"PO_HEADER 表"更接近业务人员说话的方式，AI 在理解用户意图时更容易把"帮我查采购订单"映射到这个页面。两套名词不矛盾，本体里会记录它们的对应关系。

枚举类型的参数必须加备注。

这是治理投入产出比最高的单项工作，也是最容易被忽略的。

一个叫"供应商等级"的字段，取值是 1、2、3，AI 完全不知道每个数字的业务含义。备注里加上"1=一级供应商，2=二级供应商，3=临时供应商"，AI 就能在用户说"找临时供应商"时正确传参，而不是猜测。

在库存管理系统和设备管理系统这两个接入实践中，枚举值备注的缺失是导致调用错误最多的单一原因。集中处理这类字段，通常就能让主流程的准确率从不可用提升到基本可用。这个结论来自当前样本，不是所有系统的通用统计，但它足以说明枚举备注是优先级很高的治理项。

ID 类参数必须在名称里说明归属。

一个服务端命令有三个 ID 类型的参数：ID、关联 ID、父级 ID。AI 不知道这三个 ID 各自指向哪个实体，只能靠上下文猜测，猜错率很高。

改成出库单 ID、供应商 ID、仓库 ID，AI 立刻能把参数和本体里对应的实体关联起来，推断出调用这个命令之前需要先获取哪些前置数据，以及从哪里获取。

关系治理：让 AI 看见表之间的连接

有关联关系的表，必须补充表关联配置。

这是治理里最容易被遗漏的一项，因为它对系统的人机使用没有直接影响，开发者在搭建系统时没有强烈的动机去做。

活字格的表关联配置，需要在表设计里显式指定某个字段是哪张表的“外键”（不是真正的外键，而是元数据层面上的一种标记）。配置完成后，抽取工具能把这条关系写入本体，AI 在跨表查询时知道通过哪个字段连接两张表。没有表关联配置时，AI 遇到"查询某个供应商的所有采购记录"这类需求，要么只查采购订单表（拿不到供应商信息），要么只查供应商表（拿不到采购记录），无法自动推导出需要联表查询。

如果时间投入有限，建议优先处理主数据表和业务单据表之间的关联，比如：物品表和出库单明细表、供应商表和采购订单表、设备表和维修记录表。这类关联在业务查询里出现频率最高，漏掉一条对主流程的影响最大。

动词治理：让 AI 知道能做什么

服务端命令使用谓宾结构命名。

“创建出库单”、“审批采购申请”、“更新设备状态”、“删除维修记录”，这类命名把动作和对象都表达清楚了，AI 从名字就能判断这个命令的用途，不需要读描述字段。但cmd_execute_003、process_data、handle_request这类命名，AI 只能靠描述，如果描述也是空的，这个命令就是盲区。

一个额外的建议：不要依赖"私有"、“内部”、"临时"这类命名暗示来阻止 AI 调用。如果有不希望 AI 调用的命令，在描述里加上[HOB_EXCLUDE]标记，或者干脆不在白名单里包含它，比依赖命名暗示更可靠。

重要业务操作优先提供服务端命令。

这是一个从实测中得出的经验。对于创建、审批、关闭、更新状态这类有明确业务动作的任务，服务端命令有明确的语义名称和参数定义，AI 在选择调用时有清晰的依据，也更容易通过白名单控制操作边界。表格数据绑定的名称通常是页面控件的名称，语义信息更少，AI 选错的概率更高。

对于重要业务操作，或者涉及多张表、多个筛选条件的复杂查询，如果现在只是通过数据绑定实现，可以考虑同时提供一个服务端命令版本，命名规范，描述清晰，优先把这个版本放进白名单。对于简单只读查询，治理良好的数据绑定仍然可以作为低风险入口，不需要为了 AI 额外包装成命令。

业务逻辑复杂的服务端命令，需要写好描述字段。

有些命令从名字看起来很简单，但背后的业务规则很复杂。比如"释放预订库存"，简单四个字，但执行这个命令需要满足什么前提条件、会影响哪些关联数据、在什么情况下不应该调用——这些信息只能靠描述字段传递。

描述字段的写法不需要精确到技术规格，但要用业务语言说清楚"这个命令做什么、什么时候用、什么时候不能用、前置条件是什么、会影响哪些数据、失败后应该怎么处理"。AI 在判断是否调用这个命令时，会把描述和当前任务上下文一起考虑。

治理完成度的判断标准

怎么判断一个工程是否已经达到可以接入的质量基准线？

一个实用的人工检查标准是“像 Agent 一样思考”，比如让一个对这个系统完全陌生的同事，只看本体文件（不看代码、不看数据库、不问任何人），能不能在 20 分钟内理解这个系统能做什么，以及怎么用它完成一个典型的业务操作。如果他做不到，说明本体里缺少了他需要的某类信息，这类信息对 AI 同样是缺失的。如果他能做到，说明本体至少达到了人类可读的基准线，但这还不能直接等同于 AI 一定能稳定调用。

这个测试方法不需要任何工具，随时可以做，结果直观。发现问题，回工程里补充，再让这位同事检查一遍。这个循环走两三轮，通常就能让本体质量到达人类可读的基准线。真正接入工作台之前，还需要再做一层典型任务回归测试。准备 10 到 20 条常见业务任务，覆盖查询、创建、状态更新、跨表查询和权限边界，观察 Agent 是否选对应用、选对工具、传对参数、遵守白名单和当前用户权限。人工可读性检查解决的是"信息够不够清楚"，回归测试解决的是"AI 实际会不会用对"。

为了帮助大家理解，我们把治理完成度拆成一张检查清单，供大家参考：

• 表名、列名、页面名是否使用清晰的中文或规范英文。
• 同一技术概念是否有主规范名，业务侧别名是否在本体里有对应关系。
• 枚举字段是否补充了每个取值的业务含义。
• ID 类参数是否写明归属实体。
• 主数据表和业务单据表之间的表关联是否配置完整。
• 服务端命令是否使用谓宾结构命名。
• 服务端命令描述是否包含适用场景、不适用场景、前置条件、影响范围和失败处理。
• 白名单是否只包含准备开放给 AI 的命令。
• 典型任务回归测试是否覆盖了主流程和高风险边界。

投入产出的实际数据

在库存管理系统、设备管理系统、企业知识库这三个接入实践中，治理总投入均为小时级别。具体分布大致是：枚举值备注占 60%、服务端命令描述补充占 20%、表关联配置占 15%、命名调整占 5%。这个分布说明了几件事。枚举值备注是最密集的工作，因为每个枚举字段都需要逐一处理，而且业务系统里枚举字段的数量通常比预想的多。服务端命令的描述补充次之，因为历史命令大多没有写描述的习惯。命名调整反而占比最小，因为活字格的工程在搭建时通常会使用中文命名，这个习惯已经帮助规避了大部分命名问题。

在这些样本里，小时级别的治理投入，换来的是主流程可用。不是所有场景都完美，但核心业务流程能跑通，用户看到 AI 完成了一个有意义的任务，项目就有了继续推进的基础。剩下的边界，是后续迭代治理要覆盖的范围，不需要在第一次接入时全部做完。