实体、关系、规则：本体的三要素入门

上一篇聊了为什么 AI Agent 需要本体，这篇把本体拆开看。剥掉学术外衣之后，一个能用的本体其实只有三样东西：实体、关系、规则。它们分别回答三个朴素的问题：什么是什么？什么和什么有关？什么在什么条件下成立？

实体：先说清"什么是什么"

实体就是你这个领域里"存在的东西"。拿我最熟悉的单据审核场景举例：发票、采购单、入库单、付款单、员工、审批额度，这些都是实体。定义实体不难，难的是划边界。"发票"要不要区分专票和普票？"员工"和"审批人"是一个实体还是两个？我的经验是：如果两个概念适用的规则不一样，就拆成两个实体；规则完全一样，就合并。边界跟着规则走，而不是跟着直觉走。

关系：再说清"什么和什么有关"

孤立的实体没有用，业务含义藏在关系里。"付款单关联采购单""发票开具方必须等于合同签署方"——前半句说的是关系的存在性（有没有关联），后半句是关系上的约束（关联的双方要满足什么）。很多业务问题本质上是关系问题：所谓"四流合一"，说穿了就是订单、发票、物流、资金四类单据之间的关联关系是否完整、是否一致。

规则：最后说清"什么条件下成立"

规则是压在实体和关系之上的判断逻辑。一条好的规则大概长这样：

rule R07 "超额度需上级审批":
when  申请单.金额 > 审批人.额度
then  结论 = 转上级审批
cite  《差旅费管理办法》第十二条

三个部分缺一不可：条件（when）、结论（then）、出处（cite）。尤其是出处——规则不是凭空长出来的，它是某份制度文件里某个条款的形式化。留着这根线，将来才能回答"这条规则为什么存在""制度改了要动哪些规则"。

三样东西怎么咬合

我喜欢用一个比喻：实体是名词，关系是介词短语，规则是完整的句子。名词表和介词短语先立起来，句子才写得清楚。反过来，写规则的过程会倒逼你修正实体和关系的定义——我不止一次在写规则时发现某个实体的属性根本没定义，只好回头补。这种来回修正不是返工，恰恰是建模在收敛的信号。

本体建模不是一次画完的图，而是一场和业务反复对齐的谈判。

还有一个容易漏掉的细节：属性可能缺失。发票号可能没填，金额可能识别失败。规则语义里必须给"不知道"留位置——条件算不出来时，结论应该是"待人工确认"，而不是默认通过或默认拒绝。这个三值逻辑的坑，我打算以后单独写一篇。