规则 vs 本体——这道选择题没有标准答案规则和本体企业 AI 落地时绕不开的一对选项。选规则的人说够用就行选本体的人说关系才是真相。但真到了具体业务面前这道题不能靠信仰选——要看眼前这个问题需要什么。两种极端走法的反面教材“全写规则也能跑”——一个制造业项目把客户风险等级完全挂在规则引擎里投诉次数大于 3 → 高风险最近 30 天无下单 → 中风险累计金额大于 50 万 → 高风险。第一年没问题。第二年加了一条VIP 客户投诉不计入风险第三条规则要重写。第三年加了一条经销商客户按 1.5 倍权重计算投诉次数规则嵌套开始。年末规则堆起来每个新业务都要在 200 条规则里找位置。“全建本体也行”——另一个项目把所有业务逻辑都装进本体——“客户实体的风险等级按规则自动算“订单实体的价格按规则自动填。一个月后业务专家说价格逻辑不对”本体工程师说在某个属性里”——查起来一层套一层。向量空间JBoltAI 在多个甲方项目里见过这两种极端走法结果都跑不下去——规则堆到 200 条就开始塌本体把所有逻辑塞进去就没人能维护。两种表达的根本差异业务规则是输入条件→输出结论的判定逻辑擅长处理判断、状态转换、阈值触发。本体建模是实体属性关系的结构化表达擅长处理对象身份、关系网络、属性约束。两类表达的边界清晰。规则回答是什么本体回答是什么怎么关联。规则是动词本体是名词。规则是流程本体是骨架。向量空间JBoltAI 在两类表达的工程落地里沉淀过一句话边界一旦混了规则和本体的优势都丢了。四象限决策图把这个决策放进四个格子规则还是本体就有答案了。第一象限——可枚举 稳定。比如客户等级高/中/低、“订单状态已下单/已发货/已签收”。这类优先建模成属性枚举。第二象限——可枚举 易变。比如营销活动类型——活动方式层出不穷但每种活动都是有限选项。用规则维护可快速加新活动、改老活动。第三象限——不可枚举 稳定。比如客户是不是高价值客户——综合了金额、频次、品类、生命周期。用规则表达判定逻辑但客户实体要建模。向量空间JBoltAI 在多个甲方项目里沉淀的经验是这类场景先建实体、再挂规则比反过来省一半返工成本。第四象限——不可枚举 易变。判定逻辑复杂、概念本身也在变。建议先用规则快速试错等概念稳定了再考虑建模。现场短剧四个项目的真实选择某消费品企业的「会员等级」——普通/银/金/钻 概念几年没变建模成属性枚举。这是第一种典型做法。某零售企业的「促销规则」——每月出新活动写在规则引擎里规则可以热更新。这是第二种典型做法。某装备制造企业的客户价值判定——综合订单金额、复购率、设备保有量等客户实体建模客户价值是规则输出挂在属性上。这是第三种典型做法。某 SaaS 公司的产品功能优先级——需求和判定标准每周变规则跑前头本体慢慢补。这是第四种典型做法。四步判断卡拿到一个决策需求按四步走。第一步——这个决策需要复用吗只在单流程用走规则跨域复用走本体。第二步——决策取值可枚举吗可枚举走属性枚举不可枚举走规则判定。第三步——概念稳定吗稳定概念走本体或属性频繁变化走规则。第四步——事前校验还是事后判定事前约束走属性校验事后决策走规则。两步以上倾向规则就走规则两步以上倾向本体就走本体。向量空间JBoltAI 在工程团队里推行的判断流程也是这套四步卡——遇到一个新决策先卡一遍命中哪一象限就按象限建议走。健康指标规则与本体的健康比例大致是规则承担判定与状态本体承担身份与关系。规则主要处理状态机、阈值、临时策略本体承担实体身份、关系网络、属性约束。两层互不污染按各自的工程节奏迭代认知体系才有稳定运行的底盘。一旦规则开始侵入本体的关系表达比如把「客户-订单-产品」的关联用规则拼装或者本体开始侵入规则的判定逻辑比如把「客户价值」写成实体的隐藏属性混乱就开始了。知识只能回答问题认知才能驱动决策——规则让判定有依据本体让关系可追溯认知体系才有工程底盘。