把企业变成 AI 能理解的世界#07:一张表不等于一个对象,对象建模的四个判断

接下来，一个看似简单的问题出现了：这张表对应的本体对象叫什么？

叫“物料”似乎不对。同一种物料可以存放在多个仓库，也可能分属不同批次、货主和库存状态。叫“库存”也不够准确，因为“库存为 120 件”只是某一时点的数量，而企业真正需要持续追踪的，可能是“某物料在某仓库中的库存项”。

物料 M-1024 是一个对象实例；M-1024 在华东一号仓的库存项，是另一个对象实例。前者描述企业管理的是什么物料，后者承载当前位置、可用量、在途需求、短缺风险和补货动作。

一张库存表可以同时提供物料、仓库、库存项和批次的线索，却不等于其中任何一个对象。反过来，一个库存项的完整事实，也可能分别来自 WMS、ERP、计划系统和主数据平台。

这就是对象建模最容易走偏的地方：把“系统怎样存数据”误当成“企业怎样识别和处理业务事物”。

敲黑板：对象不是数据容器，而是企业需要持续识别、追踪、判断或操作的业务主体。

判断一个名词或数据结构是否值得成为本体对象，可以先问四个问题：

它有没有身份？

有没有生命周期？

是否承载判断？

是否承接行动？

一、先分清对象定义与对象实例

日常讨论中，“对象”经常混合了两个层次。

第一个层次是对象定义，也可以理解为对象类型。比如“物料”“库存项”“补货单”，描述的是一类业务事物：如何识别，有哪些关键事实，与谁相关，会经历哪些状态，可以参与哪些判断和动作。

第二个层次是对象实例。比如物料 M-1024、M-1024 在华东一号仓的库存项、编号为 RH-20260722-018 的补货单。企业运行时真正被查询、判断、修改和审计的，是这些具体实例。

两者的变化也不同。对象定义增加一个状态、修改一项规则，属于本体资产变更，需要版本和影响分析；某张补货单从“待确认”变成“已提交”，属于对象实例的业务状态变化。

这一区分看似基础，却会直接影响系统设计。如果把对象定义和实例混在一起，团队容易把“补货单已经完成”理解成“补货单对象已经消失”。实际上，单据完成后仍然存在，它的历史状态、审批记录和行动证据仍要用于审计和复盘。

所以，建模时要同时回答两个问题：

我们正在定义哪一类业务事物？

业务运行中，怎样定位其中某一个具体实例？

二、为什么表和对象不能一一对应

数据库表主要服务应用功能和数据存储，本体对象主要服务业务理解、判断与行动。两者相关，但设计目标不同。

一张表，可能包含多个对象的投影

以库存表为例，一行记录中可能同时出现物料、仓库、货主、批次和库存数量。物料和仓库具有各自身份；批次可能需要单独追溯；库存数量通常只是库存项的属性；“冻结”则可能是当前处境，也可能来自一次冻结事件。

这些内容是否拆成对象，不由字段多少决定，而由场景决定。如果当前任务只判断仓库层面的补货风险，库存项可能以“物料 + 仓库”为粒度；如果任务涉及质量追溯，批次就需要独立身份、检验结果、流转历史和处置动作，因而更可能成为对象。

同一张表中的内容，可以分别成为对象、属性、关系、状态或事件。把每张表直接变成一个对象，会掩盖这些业务差异。

一个对象，也可能由多张表共同提供事实

一个客户对象可能在 CRM 中有销售身份，在合同系统中有签约主体记录，在客服系统中有服务档案，在发票系统中有开票信息。一个库存项的当前事实，也可能需要组合 WMS 的实物库存、ERP 的在途采购和计划系统的未来需求。

本体对象的作用不是把这些数据复制到一张新表，而是建立业务身份锚点，说明各系统记录与它是什么关系，哪些事实以谁为准，冲突或延迟时怎样处理。

因此，数据库主键不能自动成为业务身份，表连接也不能自动成为业务关系。表结构提供事实线索，对象模型负责把线索组织成可运行的业务主体。

三、对象、属性、关系、状态和事件的边界

业务访谈中出现的名词很多，但并不是每个名词都应该升格为对象。

如果一个概念只是描述另一个对象的取值，通常是属性。例如物料名称、设备型号、订单金额、库存数量。

如果它表达两个对象之间的业务连接，通常是关系。例如供应商供应物料、设备安装在站点、补货单关联采购申请。

如果它表达对象在某一时点的业务处境，通常是状态。例如待审批、风险中、已完成、已关闭。状态发生变化，并不代表对象消失。

如果它表达某件事已经发生，并且会改变事实、关系、状态或后续动作，可以考虑建成事件。例如到货事件、告警事件、审批事件、检验异常事件。

但这些边界不是只靠语法判断。一个概念是否需要独立身份、持续追踪和处置，才是关键。

例如“客户风险等级”通常只是客户属性；但如果一次风险识别需要编号、证据、负责人、处置状态、复核动作和关闭结果，那么“客户风险事件”就可能成为独立对象。又如“供应商供应物料”通常是一条关系；如果企业要独立管理其合同期间、供应份额、质量等级、审批和终止，它也可能被提升为“供货资格”或“供应关系”对象。

对象不是名词的高级版本，而是业务需要独立管理的单位。

四、粒度和标识必须一起决定

“它是什么”与“哪一个才算一个”必须同时回答。

对象粒度过粗，判断和动作无法准确落点。只建“物料”对象，就难以表达同一种物料在上海仓充足、在成都仓短缺；只建“订单”对象，就可能无法处理某一订单行的分批交付和退货。

粒度过细也会制造负担。如果把每一次临时计算、每个展示字段、每条接口记录都建成对象，身份匹配、权限、数据映射和变更治理会迅速复杂化。

确定粒度时，可以问三个问题：业务状态在哪一层变化？判断在哪一层得出？行动和责任最终落在哪一层？

如果补货风险按“物料 + 仓库”判断，补货建议也作用于这个组合，那么库存项就应至少细到物料和仓库层。如果批次不会改变当前判断和行动，就不必为了数据表中存在批次号而继续下钻。

粒度确定后，才能设计标识。标识要满足的不只是数据库内唯一，还包括业务上稳定、跨系统可对齐、历史可追溯。

库存项可以采用“物料统一编码 + 仓库编码 + 货主”等组合身份，也可以由本体分配全局标识，再关联各系统记录。无论采用哪种方式，都要说明对象合并、拆分、注销和系统迁移后，历史事实如何保留。

手机号码、名称和组织归属都可能变化，通常不适合作为客户主身份；两个系统编码不同，也不代表一定是两个业务对象。当匹配存在不确定性时，应保留匹配规则、可信程度和人工确认记录，而不是强行合并。

身份决定能否持续认出它，粒度决定认出的究竟是哪一层业务事物。两者有一个模糊，判断和行动就可能落错位置。

五、对象入选的四个判断

从身份、事实、关系、状态、判断和行动等方面识别对象。为了便于业务工作坊使用，我把这些内容收束成四个判断。

判断一：有身份——企业能否持续认出它

候选对象应能被定位到具体实例，并在名称变化、系统迁移或时间推移后仍可追溯。身份可以来自业务编号、主数据编码、组合键或全局标识，但必须有明确的业务含义和权威来源。

如果一个概念只能表现为某个字段值，也没有独立识别需要，它更可能是属性、标签或枚举。

判断二：有生命周期——它会不会经历需要管理的变化

生命周期不等于必须拥有复杂流程，而是对象从出现、变化到关闭或退役的过程是否值得持续记录。

补货单会经历草稿、待确认、已提交、已完成或已取消；设备会经历投运、检修、停用和退役；库存项会随收货、领用、冻结和补货而改变处境。

如果某项内容长期不变，只承担分类或参考作用，它仍可能作为轻量参考对象存在，但通常不是首期运行本体的核心对象。

判断三：承载判断——业务结论是否围绕它产生

问一问：企业是否会围绕它反复回答重要问题？

库存项是否存在缺货风险，客户是否具有流失风险，设备告警是否需要升级，补货单是否存在重复申请。这些判断都需要一个稳定对象承载输入事实、判断结果和解释证据。

如果某项内容既不被规则读取，也不承载判断结果，它进入本体的运行价值通常较弱。

判断四：承接行动——业务动作是否会创建、改变或关闭它

对象往往是行动的落点。创建补货单、提交审批、冻结批次、派发任务、关闭投诉，都会创建对象或改变对象状态。

一旦候选对象承接行动，就需要进一步定义前置条件、权限、允许的状态变化、失败处理和审计记录。行动越重要，对象边界就越不能含糊。

四个判断不是机械的考试。身份和生命周期说明它是否具有独立对象基础；判断和行动说明它是否具有进入运行闭环的价值。不同组合，应得到不同处理方式。

六、用四象限决定“建多重”

可以把“身份与生命周期”合并为对象基础，把“判断与行动”合并为运行价值，形成对象入选四象限。

核心运行对象应优先进入本体，并配置事实来源、关系、状态、判断、行动、权限和审计。轻量参考对象可以只保留稳定身份与必要关系，不必强行设计复杂生命周期和动作。

“运行价值高、对象基础低”的候选最值得警惕。比如业务说要“处理库存异常”，但异常没有编号、边界和状态。此时不要直接建一个含糊对象，而要判断它究竟是库存项的风险状态，还是一次需要分派、处置和关闭的异常事件。

四象限不是为了给名词打分，而是帮助团队决定：它是不是对象，以及应该建到什么深度。

七、反例：只有字段集合，没有业务边界

下面是一种常见的对象定义：

物料对象：包含物料编码、物料名称、物料分类、规格、单位、状态等字段。

这段话只说明系统准备展示哪些数据，没有说明“物料”在当前场景中承担什么角色。它没有回答物料与库存项、产品和批次的边界，也没有说明标识、事实来源、生命周期、判断、行动和权限。

一份更可运行的定义应当至少说明：

物料是企业为采购、生产、库存和销售统一识别的品项定义，不等同于某仓库中的库存项，也不等同于某一生产批次。在安全库存场景中，物料用于连接库存项、需求、供应商和替代料，参与补货适用性与替代关系判断；物料事实以主数据平台为准，启用、停用和替代关系变更需要保留记录。

两段定义的差别不在字数。后一段说明了它是什么、不是什么、为什么进入这个场景，以及如何被系统和 AI 使用。

好对象的定义不是字段说明书，而是一份业务边界声明。

带走一张卡：对象入选四象限与精简对象卡

完成四象限判断后，可以用下面这张精简对象卡记录结果。

评审一张对象卡时，可以再做三个删减检查：

• 如果去掉独立身份，它是否仍只是另一个对象的属性？

• 如果去掉生命周期，它是否只是状态、标签或一次计算结果？

• 如果它不改变任何判断和行动，当前场景是否真的需要它？

对象卡的目的不是把所有栏目填满，而是让业务和技术共同确认：这个对象为什么必须存在，以及它应被建到什么深度。

结语：对象是行动需要认准的业务主体

数据表记录系统中的事实，业务对象组织企业需要持续管理的事物。两者可以映射，却不应简单画等号。

一张表可能拆出多个对象、属性、关系和事件；一个对象也可能连接多张表和多个系统。对象是否成立，最终要回到四个判断：有没有稳定身份，有没有值得管理的生命周期，是否承载业务判断，是否承接业务行动。

这四个判断帮助团队找到的，不是更多对象，而是更少、更稳定、更有运行价值的对象。它们让 AI 知道自己面对的究竟是哪一件业务事物，为什么要关注它，以及可以对它做什么。

但对象一旦被选出来，还只是一个个孤立节点。真正的业务上下文，要靠关系连接起来。同样一条关系，在不同时间是否仍然有效？它来自系统事实、人工确认还是模型推断？关系本身有没有状态和证据？

留一道思考题：

关系为什么不是一条连线，以及时间、证据与状态怎样进入关系模型。