4、核心概念拆解：规则(Rule)、条件(Condition)、动作(Action)、规则集(RuleSet)、决策表(DecisionTable)
好，咱们今天来啃几个硬骨头。
规则引擎里最基础、也最容易混淆的几个概念：规则、条件、动作、规则集、决策表。
很多新手一上来就写规则，结果写出来的东西又臭又长，维护起来想哭。我当年也踩过这个坑——一个规则里塞了十几个条件，最后自己都看不懂了。
咱们一个一个拆开看。
4.1 规则（Rule）—— 最小的业务决策单元
规则是什么？说白了就是 「如果…那么…」。
在风控场景里，规则就是一条业务判断逻辑。比如：
如果 用户年龄 < 18，那么 拒绝该笔交易这就是一条规则。
我个人习惯把规则拆成三部分：
- 名称：一眼能看懂这条规则是干嘛的，比如「未成年拦截规则」
- 优先级：多条规则同时命中时，谁先执行
- 生效范围：这条规则对哪些场景、哪些用户生效
核心要点：规则是原子级的。一条规则只做一件事。别想着一条规则搞定所有风控逻辑，那是灾难的开始。
我在项目中遇到过有人把「年龄判断 + 地域判断 + 金额判断 + 历史行为判断」全塞进一条规则里。结果上线后出了问题，排查了整整两天才找到是哪条子条件写错了。嗯，从那以后我定了个规矩：一条规则，不超过三个条件。
4.2 条件（Condition）—— 规则的「触发器」
条件就是规则里的「如果」部分。它决定了规则要不要触发。
条件通常由三要素组成：
- 左操作数：你要判断的数据字段，比如
user.age - 操作符：等于、大于、小于、包含、正则匹配等
- 右操作数：阈值或参考值，比如
18
举个例子：
条件：user.age >= 18 AND user.credit_score > 600这里有两个条件，用 AND 连接。只有两个条件都满足，规则才会触发。
小技巧：条件尽量写成「正向判断」。比如「年龄大于等于18」比「年龄不小于18」更直观。你想想看，读代码的时候是不是前者一眼就能看懂？
我曾经犯过一个低级错误：条件里写了个 user.status != 'black'，结果数据库里 status 字段有空值，空值不等于 'black'，导致所有空值用户都被放行了。嗯，空值处理是条件设计里最容易翻车的地方。
4.3 动作（Action）—— 规则触发后的「后果」
条件满足了，然后呢？动作就是那个「然后」。
动作可以是：
- 拒绝：直接拦截交易，返回拒绝码
- 标记：给这笔交易打上标签，比如「高风险」
- 转人工：交给风控专员审核
- 调整额度：降低用户的单笔限额
- 记录日志：把这条规则命中的信息存下来，方便事后分析
动作的设计有个原则：动作要可追溯。每条规则触发了什么动作，必须能查得到。不然出了问题你都不知道是哪个动作导致的。
避坑指南：我曾经见过一个系统，规则触发了「拒绝」动作，但日志里只记录了「规则命中」，没记录「执行了拒绝」。结果业务方投诉说「明明规则没拒绝，为什么交易被拒了？」查了半天才发现是另一条规则干的。所以，动作日志一定要完整。
4.4 规则集（RuleSet）—— 规则的「容器」
单条规则能做的事情有限。实际风控场景里，我们需要把多条规则组合起来，形成一个规则集。
规则集的核心作用有两个：
- 分组管理：把相同场景的规则放在一起，比如「登录风控规则集」、「支付风控规则集」
- 执行策略：规则集里的规则怎么执行？是按顺序执行？还是并行执行？还是只要命中一条就停止？
规则集的执行策略，我一般用这三种：
| 策略类型 | 说明 | 适用场景 |
|---|---|---|
| 顺序执行 | 按优先级依次执行，全部跑完 | 需要综合多条规则结果时 |
| 短路执行 | 命中一条就停止，不再执行后续规则 | 拦截类规则，命中即拒绝 |
| 并行执行 | 所有规则同时跑，汇总结果 | 高性能场景，需要快速出结论 |
我个人习惯用短路执行。为什么？因为风控场景里，一旦命中「拒绝」规则，后面的规则就没必要跑了，节省性能。你想想看，用户都已经被拒绝了，你还去查他的历史行为干嘛？
4.5 决策表（DecisionTable）—— 规则的「矩阵化」
决策表是规则的一种高级表现形式。当规则的条件和动作组合非常多时，用文字描述会变得很啰嗦。这时候决策表就派上用场了。
决策表长这样：
| 用户等级 | 交易金额 | 历史违规 | 动作 |
|---|---|---|---|
| 普通 | < 1000 | 无 | 放行 |
| 普通 | >= 1000 | 无 | 转人工 |
| 普通 | 任意 | 有 | 拒绝 |
| VIP | < 5000 | 无 | 放行 |
| VIP | >= 5000 | 无 | 转人工 |
| VIP | 任意 | 有 | 拒绝 |
你看，用决策表表达，一目了然。业务方也能看懂，不需要开发人员翻译。
决策表的优势：
- 可视化强，业务人员可以直接维护
- 减少重复条件，表格结构天然去重
- 容易发现逻辑漏洞，比如某个组合没覆盖到
我在项目中遇到过业务方提了30多条规则，用文字描述写了满满两页纸。我一看，好多规则的条件是重复的，只是动作不同。后来我帮他们整理成一张决策表，缩到了8行。业务方看了直呼「原来这么简单」。嗯，决策表就是干这个的。
4.6 它们之间的关系
说了这么多，这几个概念到底怎么串起来的？我画了张图，你看一眼就明白了。
从这张图你能看到：
- 规则集是顶层容器，里面装了一堆规则
- 每条规则由若干个条件和动作组成
- 决策表是规则的另一种表达形式，可以替代多条规则
说白了，规则集就是「怎么组织规则」，规则就是「判断逻辑」，条件就是「判断依据」，动作就是「判断结果」，决策表就是「规则的表格化」。这五个概念搞清楚了，规则引擎的骨架你就拿下了。
我的建议：刚开始设计规则引擎时，别急着写代码。先在纸上把这五个概念的关系画清楚。画明白了，代码自然就好写了。
公众号:蓝海资料掘金营，微信deep3321