第 10 章 · 从表和指标，到对象、状态与动作

仓库里少了十吨原料。

这句话落进不同系统，会变成不同的东西。

在 ERP 里，它可能是一笔库存差异，要追查收货、领料和盘点记录；在 BI 里，它是一项偏离阈值的指标；到了准备采取行动的系统里，问题还没问完：是哪一种物料，正被哪些生产订单占用，能不能调拨，谁有权批准，调拨以后会不会让另一条产线停下来？

表和指标让企业能够记录、汇总和比较。可当软件准备修改现实，只知道“数值异常”远远不够。它必须知道自己面对的是什么，这个东西现在处于什么状态，可以做什么，又由谁承担后果。

这正是数据老兵既熟悉又容易误判的地方。

表从来不是现实本身

关系数据库把现实拆成表、字段、主键和关系。维度模型又把分析问题组织成事实与维度，让人能够按时间、地区、产品和客户观察业务。指标体系再往上走一步，把收入、库存周转、客户流失这些管理概念变成可以计算的共同语言。

这些方法并没有过时。

ERP 中的一张订单，需要连接客户、物料、价格、交付和财务凭证；电信系统里的一位客户，可能同时对应账户、号码、套餐与计费事件；保险系统中的一张保单，也会连接投保人、被保险人、保障责任和理赔案件。

没有稳定的数据结构，后面的智能只是踩在流沙上。

但模型一定会舍弃现实的一部分。表中的“客户”可能是签约主体，也可能是实际使用者；“库存”既可能指账面数量，也可能指能立即投入生产的可用量；“案件已审核”还可能分成机器初审、人工复核和正式生效。

建模不是把现实完整复制进计算机。它是在某个目的下，决定哪些差异必须保留，哪些可以暂时忽略。

经验丰富的人知道，字段名相同不代表含义相同。一家公司的“订单完成”是货物出库，另一家可能要等客户签收，还有一家要等结算结束。模型看起来整齐，业务未必真的一致。

指标指出问题，对象承接动作

指标擅长报警，却不一定告诉人下一步怎么办。

“理赔平均处理时长上升”能让管理者看到问题。要处理具体案件，系统还要知道这份保单是否有效，材料是否齐全，案件处在哪个审核状态，有没有关联历史记录，当前处理人是谁。

动作总是落在具体对象上。

补充材料，是向某个案件的某位申请人发送请求；调整套餐，是在满足合约约束后修改某个账户；库存调拨，是把某批物料从一个地点移到另一个地点，并改变后续生产可用量。

对象不只是属性的集合。进入执行层以后，它至少还要带上四类信息：

它和其他对象有什么关系；
它当前处于什么状态；
在这个状态下允许采取什么动作；
谁能够发起、批准和查看动作结果。

这并非 AI 发明的新问题。工作流、领域模型和业务规则系统早就在处理它。今天常被提到的“本体”，也不是给字段词典换个时髦名字。

字段词典告诉人 claim_status 是什么。本体还要说明保单、案件、申请人和审核员如何相连，“待补件”能够转向哪些状态，什么动作会触发客户通知，什么证据要进入审计记录。

Palantir 对本体的描述，强调用对象、属性、关系、动作和业务逻辑表达企业。这个框架有用的地方，不在于创造了一套神秘术语，而在于把数据世界与操作世界放进同一张图里。

权限不是最后再加的一道门

很多系统的权限设计发生得太晚。

团队先把功能做出来，上线前再配置谁能看、谁能改。对只读报表，这种顺序有时还能补救。对会采取行动的软件，权限必须更早进入模型。

同样是“修改订单”，销售可以改收货地址，仓库可以改拣货状态，财务也许只能冻结结算；订单一旦发货，原本允许的动作还会失效。权限不只是人的角色，还取决于对象状态、金额、地点、时间和风险等级。

审计也不能只留一行“用户 A 修改了记录”。需要知道修改前后是什么，依据了哪些数据，模型给了什么建议，谁确认了动作，调用了哪个工具，失败后是否重试。

换句话说，权限、规则和审计不是套在业务模型外面的安全附件。它们决定了业务对象究竟能做什么。

这也是传统数据模型与行动模型的分界。前者最怕事实失真，后者还要防止真实而合法的数据被用来做不合适的事。

三种对象，三套现实

把 ERP、电信和保险放在一起看，会更容易发现“对象—状态—动作”不是互联网业务的特例。

制造企业关心订单能否履约。对象之间连接着物料、库存、工艺与产能。动作可能是补货、调拨、改排产；一次调整会沿供应链传导。

电信企业关心服务能否持续、计费是否正确。客户、账户、号码和套餐不是同一个对象。停机、复机、换套餐看似简单，却受到实名、合约、欠费和生效周期约束。

保险企业关心责任是否成立、证据是否充分。保单有效不代表每次理赔都应通过。补件、拒赔、转人工、支付，每一步都涉及客户权益和监管留痕。

三者不能共用一套行业模型，但可以共用一种提问方式：对象是谁，状态是什么，依据什么变化，谁有权让它变化，变化以后如何追踪。

这才是可复用的部分。

模型太少和模型太多

模型不足时，系统只认识字符串和字段。

Agent 读到“请把这批货转过去”，也许能生成一段漂亮回复，却不知道“这批”指向哪批库存，“过去”是哪座仓库，更不知道调拨是否会影响已经承诺的订单。于是所有关键判断仍要由人补上。

模型过度时，团队试图一次画完整个企业。

每个对象都有几十种状态，每条关系都要求完美定义，每个例外都提前写进规则。半年以后，图越来越大，能落地的动作仍然没有几个。现实一变，维护模型本身就成了新项目。

好的起点通常不是“企业有哪些对象”，而是“我们准备让系统协助哪一个动作”。从动作往回找必要对象、状态、证据和权限，只建足以支撑这次部署的部分。遇到稳定复现的问题，再扩大模型。

这不是反对体系化。恰恰因为现实不会服从模型，体系才需要接受现场反馈。

数据老兵最值得带进 FDE 的，不是某一种建模方法，也不只是写 SQL 的熟练程度，而是对语义差异和业务例外的警觉。

同时也要放下一个隐秘的自信：仿佛模型一旦建立，现实就该照它运行。

模型只是行动的地图。地图画得再准确，也不能代替交通规则、驾驶权限和事故处置。下一章要讨论的，正是当软件开始沿着这张地图行动以后，治理该管什么。

本章资料

场景说明：本章制造、电信与保险对象均为行业常见业务结构的复合示例，不对应某一家企业的真实系统。