第22篇在流程描述里提到治理是影响本体质量最关键的前置工作。这篇把治理的具体内容展开逐类说明哪些问题最影响 AI 的调用准确率以及怎么修。一个重要的前提治理不是一次性的突击工作。它应该作为开发习惯嵌入日常的工程实践让每次迭代产出的代码本身就达到可被 AI 理解的质量。如果一个系统在开发阶段就遵循了这些规范接入 AI 工作台几乎不需要额外的治理投入。为什么治理质量直接影响 AI 准确率AI 在处理任务时依赖本体里的元数据做推理这个字段是什么含义、这个命令做什么操作、这两张表是什么关系。如果元数据是残缺的或者模糊的AI 的推理就建立在一个不稳定的基础上。一个字段叫statAI 不知道它是状态还是统计不知道可以取哪些值只能猜。猜对了这次调用成功猜错了传了一个系统不接受的值调用失败AI 还要花一轮上下文推理为什么失败。每一个模糊的元数据都是一个潜在的错误点而且这类错误很难通过调整 Prompt 来修复因为问题出在信息层不在推理层。把元数据治理好是让 AI 调用准确的最高性价比投入。名词治理让 AI 认识你的概念表名和列名不用拼音不用缩写。这条规则的门槛看起来低但在实际项目里违反的频率很高。历史系统通常有大量拼音命名的表CGRK采购入库、CGRKD采购入库单、CGRKDMX采购入库单明细。这些名字对当初写代码的人来说是一目了然的但对 AI 来说CGRKDMX和XYZ_TABLE_002一样都是没有语义的字符串。改成中文或规范英文之后AI 至少能先认识这个表叫什么初步判断它适合回答什么类型的查询。语义信息从名字本身流动出来可以减少额外描述的负担。但名字不能替代显式元数据表关联、权限边界、枚举取值、操作约束仍然需要在工程里配置清楚。技术侧名词在所有位置保持一致。一个业务概念在系统里可能出现在多个地方表名叫费用单元页面标题叫成本中心服务端命令参数里叫部门。三个名字指的是同一个东西但 AI 不知道。它会把三者识别为三个不同的概念在推理时产生混乱。治理的目标是在技术侧选定一个主规范名所有技术实体尽量统一使用这个名字。用哪个词不是最关键关键是同一层级内部一致。如果业务侧习惯用成本中心而历史表名里叫费用单元可以保留业务侧别名但要让本体明确记录它们指向同一个概念。业务侧名词可以在页面名和表格名里使用且在这个范围内保持一致。考虑到实际情况我们可以给技术实体表用技术侧规范名词业务实体页面可以更贴近业务语言。采购订单管理这个页面名比PO_HEADER 表更接近业务人员说话的方式AI 在理解用户意图时更容易把帮我查采购订单映射到这个页面。两套名词不矛盾本体里会记录它们的对应关系。枚举类型的参数必须加备注。这是治理投入产出比最高的单项工作也是最容易被忽略的。一个叫供应商等级的字段取值是 1、2、3AI 完全不知道每个数字的业务含义。备注里加上1一级供应商2二级供应商3临时供应商AI 就能在用户说找临时供应商时正确传参而不是猜测。在库存管理系统和设备管理系统这两个接入实践中枚举值备注的缺失是导致调用错误最多的单一原因。集中处理这类字段通常就能让主流程的准确率从不可用提升到基本可用。这个结论来自当前样本不是所有系统的通用统计但它足以说明枚举备注是优先级很高的治理项。ID 类参数必须在名称里说明归属。一个服务端命令有三个 ID 类型的参数ID、关联 ID、父级 ID。AI 不知道这三个 ID 各自指向哪个实体只能靠上下文猜测猜错率很高。改成出库单 ID、供应商 ID、仓库 IDAI 立刻能把参数和本体里对应的实体关联起来推断出调用这个命令之前需要先获取哪些前置数据以及从哪里获取。关系治理让 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 完成了一个有意义的任务项目就有了继续推进的基础。剩下的边界是后续迭代治理要覆盖的范围不需要在第一次接入时全部做完。
