第 10 章：对象不是数据表，而是行动单元

很多人容易把对象模型理解成数据表。

这会低估它。

一张表可以存数据，但一个业务对象不只是数据。

业务对象是组织行动的基本单位。

订单不是订单表里的一行。

设备不是设备表里的一行。

病人不是病历系统里的一条记录。

任务不是任务系统里的一个字段集合。

它们都是组织可以围绕其判断、协作、审批、执行和追责的行动单元。

1. 数据表为什么不等于业务对象

数据表主要为存储和查询服务。

它关心：

•字段；

•类型；

•主键；

•外键；

•索引；

•查询效率；

•数据一致性。

这些都重要，但不够。

业务对象还关心：

•当前状态；

•与其他对象的关系；

•谁负责；

•谁有权限；

•哪些动作可以执行；

•哪些规则限制动作；

•动作后影响什么；

•历史如何追踪；

•出错如何审计。

比如一张订单表可以存订单金额、客户、日期和状态。

但作为业务对象的“订单”，还要知道：

•这个订单是否重要；

•是否影响产能；

•是否关联某个关键客户；

•是否有特殊合同条款；

•是否可以延期；

•谁能批准延期；

•延期后是否影响财务确认；

•是否需要通知客户；

•这个过程如何留痕。

这些都不是普通数据表天然表达的。

2. 一个对象必须承载状态、关系、权限、动作和历史

真正的组织对象，至少要承载五类信息。

第一，状态。

对象当前处于什么阶段，决定下一步能做什么。

第二，关系。

对象与其他对象如何连接，决定动作会影响谁。

第三，权限。

谁能看、谁能改、谁能审批，决定 AI 和人能否行动。

第四，动作。

对象上允许执行哪些 Action，比如创建、修改、审批、关闭、调度、写回。

第五，历史。

对象过去发生过什么，决定判断是否可靠、风险是否积累、责任如何追溯。

一个对象如果没有动作，就只是资料。

一个对象如果没有权限，就可能被滥用。

一个对象如果没有历史，就无法学习。

一个对象如果没有关系，就无法进入组织系统。

所以，对象不是数据表，而是行动单元。

3. 企业 AI 为什么不能直接面对裸数据

大模型可以读表格、读文档、读数据库结果。

但企业 AI 如果直接面对裸数据，会有几个问题。

第一，语义不稳定。

同一个字段在不同系统里可能意思不同。

“客户”在 CRM、财务、合同系统里可能不是同一层含义。

第二，关系不完整。

数据表之间可能有外键，但真实业务关系常常没有完整写出来。

第三，权限不清楚。

AI 看到数据，不代表它有权使用数据。

用户能问，不代表系统能回答。

系统能回答，不代表能执行。

第四，动作不可控。

裸数据只告诉 AI 信息，不告诉它什么动作允许发生。

第五，责任不可追踪。

如果 AI 基于裸数据做出建议，后续谁负责、依据是什么、是否可复盘，都会变得模糊。

因此，企业 AI 不能直接面对裸数据。

它需要面对被组织化后的对象。

4. 对象模型如何减少跨系统翻译损耗

复杂组织里有很多系统。

CRM 管客户。

ERP 管资源。

MES 管生产。

EHR 管医疗记录。

SCADA 管能源设备。

财务系统管账。

审批系统管流程。

每个系统都有自己的数据结构和语言。

这会产生大量翻译损耗。

比如同一个客户，在销售系统、合同系统、财务系统和客服系统中可能有不同 ID、不同字段、不同状态。

对象模型的价值，是在这些系统上方建立统一业务语义。

它不一定替代所有底层系统，而是把它们映射到统一对象空间里。

这样 AI 和人讨论“客户”“订单”“设备”“任务”时，不再直接面对各系统碎片，而是面对统一业务对象。

这可以显著减少跨系统翻译损耗。

5. 组织对象层如何成为 AI 进入企业的语义底座

AI 要进入企业，必须先有语义底座。

否则它只能在碎片资料里回答问题。

组织对象层就是这个底座。

它把企业现实世界转化为：

•对象；

•属性；

•状态；

•关系；

•历史；

•可执行动作；

•权限上下文。

AI 有了这个底座，才能从泛泛回答进入具体判断。

比如不再只是说：

库存可能不足，建议补货。

而是可以说：

物料 A 当前库存低于安全线，关联订单 B 和客户 C，供应商 D 过去三次延迟，替代供应商 E 可用但成本高 8%，采购金额超过阈值需要经理审批，建议发起紧急采购 Action 并通知生产计划系统。

这就是对象模型带来的差别。

一句话：

对象模型把 AI 从“看资料”带到“理解组织”。