本体工程手记02 | 先判断问题，再建立模型——本体项目的第一步不是画图

前情提要

本体工程手记01《一个追溯问题为什么不能只靠一条SQL》以M厂成品M-FG-00017的终检振动异常为起点，画出了从业务问题一路走到验收版本的全链条，也把本体和SQL、数据治理的边界划清楚了。这次我们再度深入M厂，看他们怎样以提升追溯能力为目标，一步步拆成能写进验收单的具体问题。

1 问题定性：数据、流程，还是语义？

M厂先把追溯的困难拆成了三类。

第一类，数据本身有问题。字段是空的，编码写错了，时间戳丢了——这些靠补数据、修主数据就能解决。

第二类，流程没跑通。两个系统的接口没接上，谁录入谁确认没人管，数据回写不及时——这些靠改接口、定流程、划责任就能推进。

第三类就不同了。每个系统的数据都是对的、接口也是通的，但大家说的“产品”不是同一个东西：设计部门指图纸上的版本，生产部门指工单上的生产对象，质量部门指被检验的那台具体成品。数据能查，却对不上同一件事。

这种时候才需要本体——本体并不是一个天然更高级的答案。它只是当问题需要跨系统、跨角色、跨时间保持共同理解时，一种可能必要的工程手段。

M厂没有一上来就画图，他们先做了两份小文档。

一份叫《跨系统语义冲突清单》：产品在每个系统里各指什么、哪些设备编号可能说的是同一台机器、计划用料和实际消耗分别来自哪个系统。另一份叫《本体适用性判断表》：哪些问题补数据就能解决、哪些改流程就能解决、哪些确实需要建立一套共享的定义体系。

两份表没有任何炫目的技术。但它让项目从“我们想做本体”，变成了“我们知道哪一部分需要本体，以及怎样才能证明它有用”。

2 问题定准：从一句话到可验收的规格

问题分完类，下一步不是画类、画关系，而是把上篇定下的业务验收问题再往细里写一步——写到能测试、能验收。M厂做了件看似笨却管用的事：为每个问题提前写好期望答案。

比如第一个问题——异常成品M-FG-00017实际用了哪些物料？他们提前把答案写出来：查的是M-OP-2048这道工序，消耗的是M-LOT-A17和M-LOT-B06两个批次，时间取生产事件实际发生的那一段。后续模型建好、数据接进来、查询写出来之后，必须输出这组结果。对不上，要么实现有问题，要么需求本身需要改，这就是测试基准。

光写一个问题，它只是一句愿望。问题后面附上期望答案，它才算一份可以验收的工程规格。

M厂首批选了8-12个问题，又从中挑了3个最核心的作为硬验收：这三个问题必须答对，才算第一期通过。另外他们还做了一件事：把所有答案按可信程度分了四层。

第一层，板上钉钉的事实。比如生产系统记录某次投料确实用了这个批次，直接返回，带来源。

第二层，根据已确认的规则推导出来的结论。比如两台设备的历史编号经过确认确实属于同一台机器，那就可以把它们关联起来。

第三层，只能给出候选，需要人来复核。比如某台设备状态异常的那段时间里，有哪些产品经过了它，这些产品只是“值得检查一下”，不代表有问题。

第四层，经过进一步检验或实验确认过的结论，可以作为行动依据。

为什么要分这四层？因为本体能做的是帮你把事实组织好、把规则跑通、把候选范围缩小。从值得排查到确认问题，从确认问题到执行处置，这两步跳跃不能由系统自动完成。

3 概念定型：建模前拆开六个根本混淆

分完类、定完问题，M厂开始从各系统提取词汇，真正的麻烦却来了：设计系统、生产系统、质量系统都有一个字段叫“产品”，但一个指设计版本，一个指工单生产对象，一个指被检验的成品实例。同名不同义，不同名也可能指向同一对象。M厂花了很大功夫，拆出了六类最容易翻车的地方。

第一，类型和角色，是两回事。 数控机床是类型，它在某次任务中当主力、下次当备用，这些是随情境变化的角色。把角色固化到类型上，设备一换任务，模型就失真。

第二，对象和过程，不能揉在一起。 产品、设备、物料持续存在；加工、装配、检验发生并占据时间。工艺步骤定义应该怎么做，工序执行记录实际怎么做。两者混同，返工和临时变通就会被当前定义覆盖。

第三，记录与实物，不是同一个节点。 工艺规程不是加工过程，检验报告不是被检产品本身。它们之间是描述或规定关系。

第四，设计、计划和实际，三层各归各的。 图纸上的物料清单说明设计用料，工单说明计划投料，采集记录说明实际消耗。追溯默认查实际层，但设计层和计划层必须保留，否则无法解释偏差。

第五，编号相似不等于对象同一。EQ-08 和 ASSET-0008 可能指同一台设备，也可能一个指设备单元、一个指整条产线。错误合并比漏查更致命，会沿所有关系永久传播。

第六，组装关系有时间约束。零件今天装在这台成品上，返工拆下后明天可能装到另一台。只画一条关系线却不标时间，模型只能回答现在，回答不了当时。

4 模型定界：只交付最小可回答模型

六个混淆拆清楚后，白板上躺着上百个候选概念，全部画成方框连上线，很快就是一张大图。但首批那三个硬验收问题，真的需要这上百个概念吗？

第一版的目标不是完整，是能回答问题。 每个概念和关系必须能追溯到一个业务验收问题，每个问题需要的元素也必须在模型里找到位置。

从第一个问题反推：查具体成品，需要产品实例；查用了什么料，需要物料批次。两者不能直连，消耗发生在生产事件中，所以还需要工序执行作为中间节点，带出消耗关系、产出关系和时间。

关系不能只画一条线。标注三四秒，落地要问清方向、类型、时间、数量、来源和确认状态。M厂把消耗建模为一次可描述的事件而非一根边。时序、数量或来源一旦附着在关系上，它就不再是一条线。

模型做完，M厂不搞大评审，而是三种定向筛查。一线人员看对象粒度对不对、三层有没有分开。用三个核心问题逐项追踪：对象有没有、路径在不在、时间和身份有没有表达、数据能不能映射。然后灌入错误数据。同一个批次的累计消耗超过了领用总量，第一版模型没拦住。类和关系没错，但缺少跨记录的校验。团队没有强行修模型，而是把这件事归到了数据校验层。

最终，第一版模型收成一条清晰的制造故事：成品由生产事件产生，事件执行工艺步骤，消耗物料批次，由设备参与并留下数据，检验事件形成测量记录。三个核心问题沿着这条骨架都有了查询路径。用不到的概念不删，放进候选清单。

让每个信息都对应一个问题，每个问题都有一条能验证的路径，这才是本体工程第一版应该交付的东西。

项目自查

·哪些模型元素无法追踪到业务问题或复用需要？

·哪些关系带有时间、数量或来源，因此不能只画一条边？

·哪些规则应放在数据校验层而非本体公理？

下篇预告

本章完成了问题判断和最小可回答模型。第二单元进入技术选择与复用，把产品、物料、工艺、设备和质量证据链真正跑通。

案例声明：本文中的“M 厂”是用于教学的离散制造合成案例，不对应任何真实客户；人物、系统、编码、数据和事件均为模拟设定。