1. 课程导入
在风控、营销、计费、权限、推荐、工单流转等系统中，业务规则往往不是孤立存在的。它们会同时命中、相互覆盖、彼此约束，甚至因为配置顺序不同而产生完全相反的结果。规则引擎的价值，不只是“把 if-else 搬出代码”，而是让业务人员能够以可配置、可审计、可演进的方式管理决策逻辑。然而，一旦规则数量从几十条增长到几千条，真正棘手的问题就不再是“如何写一条规则”，而是“当多条规则同时成立时，系统应该听谁的”“哪些规则不能同时生效”“某条规则依赖的前置条件是否已经满足”。这正是本课程要解决的核心问题。
一、什么是规则系统
规则系统通常由四部分组成：事实（Fact）、规则（Rule）、推理引擎（Inference Engine）和结果（Result）。事实是输入数据，例如用户等级、订单金额、设备指纹、当前时间；规则是“条件 + 动作”的声明式表达；推理引擎负责匹配、冲突消解与执行；结果是最终决策或动作集合。
一个典型的规则可以抽象为：
WHEN 用户等级 = 黄金
AND 订单金额 >= 1000
AND 活动标签 = 双十一
THEN 折扣 = 0.85
PRIORITY = 100
GROUP = 大促折扣规则系统与普通业务代码的关键差异在于：规则是数据，不是硬编码逻辑。它可以被动态加载、热更新、灰度发布和版本回滚。但这也带来新的复杂度：规则之间不再由代码结构天然隔离，而是由优先级、互斥关系和依赖关系共同约束。
二、规则优先级：决定“谁先说话”
优先级解决的是冲突消解问题。当多条规则同时满足条件时，系统必须决定执行顺序或最终采用哪一条。常见优先级模型包括：
- 数值优先级：数值越大越先执行，适合简单场景，但容易出现“抢数字”和难以维护的问题。
- 分组优先级：先按业务域分组，再在组内排序，例如“合规规则 > 风控规则 > 营销规则”。
- 显式互斥优先级：通过规则间的排斥声明，保证高优先级规则命中后低优先级规则不再参与。
- 动态优先级：根据事实上下文实时计算，例如 VIP 用户临时提升某类规则权重。
三、互斥与依赖检测：决定“谁能一起说话”
互斥检测关注的是规则之间不能同时生效或不能同时执行。例如“新客首单立减”和“老客复购折扣”在同一订单上不应同时叠加；“禁止发货”和“自动发货”更不能同时触发。依赖检测关注的是规则生效的前置条件，例如“满减规则”依赖“活动已开始”，“会员折扣”依赖“用户等级已同步”。
如果把规则系统比作交通网络，优先级是红绿灯的放行顺序，互斥是禁止同时通行的车道，依赖则是必须先到达某个路口才能继续前行。三者缺一不可。
| 检测类型 | 核心问题 | 典型场景 | 失败后果 |
|---|---|---|---|
| 优先级 | 谁先执行或谁最终生效 | 大促折扣与会员折扣叠加 | 折扣错误、利润损失 |
| 互斥 | 哪些规则不能同时生效 | 禁止发货与自动发货 | 业务矛盾、客诉风险 |
| 依赖 | 规则生效需要哪些前置条件 | 活动未开始却触发满减 | 资损、活动超发 |
四、核心价值与学习目标
掌握优先级、互斥与依赖检测，能够带来四方面价值：第一，正确性，避免规则冲突导致错误决策；第二，可维护性，让规则数量增长后仍能被人理解和审计；第三，可观测性，当结果异常时能快速定位是哪条规则、哪组冲突造成的；第四，可演进性，支持规则热更新、灰度发布和版本回滚。
本课程的学习目标如下：
- 理解规则系统中优先级、互斥、依赖三者的关系与边界。
- 掌握优先级建模、冲突消解和规则排序的常用方法。
- 能够设计互斥规则组，并实现静态与运行时互斥检测。
- 能够识别依赖关系，构建依赖图并检测循环依赖与缺失依赖。
- 能够将检测能力落地到规则发布、执行和监控流程中。
五、整体课程框架
课程将按照“原理—方法—实现—实战—复盘”的路径展开。前几章建立规则系统与冲突检测的基础认知；中段深入优先级模型、互斥检测算法、依赖图构建与循环检测；后段通过风控、营销、权限等场景进行综合实战，并讨论性能优化、灰度发布与线上问题排查。每一章都会围绕可运行的规则片段、检测流程和失败案例展开，避免停留在概念层面。
六、常见误区与复盘
初学者最容易陷入以下误区：
- 把优先级当成万能钥匙：所有冲突都用“调高优先级”解决，最终导致优先级膨胀、无人敢改。
- 只做静态检查：规则发布时检测通过，但运行时事实变化导致新的冲突。
- 忽略依赖的传递性：A 依赖 B，B 依赖 C，但只检查了 A 与 B，漏掉 C 缺失的情况。
- 互斥定义过宽：把本可叠加的规则设为互斥，损失业务灵活性。
- 缺少可观测性：冲突发生后没有日志、指标和追踪，无法复盘。
接下来，我们将从规则系统的基本模型出发，逐步进入优先级、互斥与依赖检测的实战世界。请先记住一个判断准则：规则系统的可靠性，不取决于单条规则写得多漂亮，而取决于规则之间的关系是否被正确管理。