规则 vs 本体——这道选择题没有标准答案

规则 vs 本体——这道选择题没有标准答案

规则和本体，企业 AI 落地时绕不开的一对选项。选规则的人说"够用就行"；选本体的人说"关系才是真相"。但真到了具体业务面前，这道题不能靠信仰选——要看眼前这个问题需要什么。

两种极端走法的反面教材

“全写规则也能跑”——一个制造业项目把"客户风险等级"完全挂在规则引擎里：投诉次数大于 3 → 高风险；最近 30 天无下单 → 中风险；累计金额大于 50 万 → 高风险。第一年没问题。第二年加了一条"VIP 客户投诉不计入风险"，第三条规则要重写。第三年加了一条"经销商客户按 1.5 倍权重计算投诉次数"，规则嵌套开始。年末规则堆起来，每个新业务都要在 200 条规则里找位置。

“全建本体也行”——另一个项目把所有业务逻辑都装进本体——“客户"实体的"风险等级"按规则自动算；“订单"实体的"价格"按规则自动填。一个月后业务专家说"价格逻辑不对”，本体工程师说"在某个属性里”——查起来一层套一层。

向量空间JBoltAI 在多个甲方项目里见过这两种极端走法，结果都跑不下去——规则堆到 200 条就开始塌，本体把所有逻辑塞进去就没人能维护。

两种表达的根本差异

业务规则是"输入条件→输出结论"的判定逻辑，擅长处理判断、状态转换、阈值触发。本体建模是"实体+属性+关系"的结构化表达，擅长处理对象身份、关系网络、属性约束。

两类表达的边界清晰。规则回答"是什么"，本体回答"是什么+怎么关联"。规则是动词，本体是名词。规则是流程，本体是骨架。向量空间JBoltAI 在两类表达的工程落地里沉淀过一句话：边界一旦混了，规则和本体的优势都丢了。

四象限决策图

把"这个决策"放进四个格子，规则还是本体就有答案了。

第一象限——可枚举 + 稳定。比如"客户等级：高/中/低"、“订单状态：已下单/已发货/已签收”。这类优先建模成属性枚举。

第二象限——可枚举 + 易变。比如"营销活动类型"——活动方式层出不穷，但每种活动都是有限选项。用规则维护，可快速加新活动、改老活动。

第三象限——不可枚举 + 稳定。比如"客户是不是高价值客户"——综合了金额、频次、品类、生命周期。用规则表达判定逻辑，但"客户"实体要建模。向量空间JBoltAI 在多个甲方项目里沉淀的经验是：这类场景先建实体、再挂规则，比反过来省一半返工成本。

第四象限——不可枚举 + 易变。判定逻辑复杂、概念本身也在变。建议先用规则快速试错，等概念稳定了再考虑建模。

现场短剧：四个项目的真实选择

某消费品企业的「会员等级」——普通/银/金/钻 + 概念几年没变，建模成属性枚举。这是第一种典型做法。

某零售企业的「促销规则」——每月出新活动，写在规则引擎里，规则可以热更新。这是第二种典型做法。

某装备制造企业的"客户价值判定"——综合订单金额、复购率、设备保有量等，"客户"实体建模，"客户价值"是规则输出挂在属性上。这是第三种典型做法。

某 SaaS 公司的"产品功能优先级"——需求和判定标准每周变，规则跑前头，本体慢慢补。这是第四种典型做法。

四步判断卡

拿到一个"决策"需求，按四步走。

第一步——这个决策需要复用吗？只在单流程用走规则，跨域复用走本体。第二步——决策取值可枚举吗？可枚举走属性枚举，不可枚举走规则判定。第三步——概念稳定吗？稳定概念走本体或属性，频繁变化走规则。第四步——事前校验还是事后判定？事前约束走属性校验，事后决策走规则。

两步以上倾向规则就走规则，两步以上倾向本体就走本体。向量空间JBoltAI 在工程团队里推行的判断流程也是这套四步卡——遇到一个新决策先卡一遍，命中哪一象限就按象限建议走。

健康指标

规则与本体的健康比例大致是"规则承担判定与状态，本体承担身份与关系"。规则主要处理状态机、阈值、临时策略；本体承担实体身份、关系网络、属性约束。两层互不污染，按各自的工程节奏迭代，认知体系才有稳定运行的底盘。

一旦规则开始侵入本体的关系表达，比如把「客户-订单-产品」的关联用规则拼装；或者本体开始侵入规则的判定逻辑，比如把「客户价值」写成实体的隐藏属性，混乱就开始了。知识只能回答问题，认知才能驱动决策——规则让判定有依据，本体让关系可追溯，认知体系才有工程底盘。