3. 规则模型设计：规则的三要素、规则组与规则集、规则元数据管理
好，咱们进入第三章。这一章我打算聊聊规则模型的设计。说实话，很多团队做风控，上来就写 if-else，写到后面自己都看不懂。我见过一个项目，规则文件超过 5000 行，改一条规则要排查半天。为什么会这样？
说白了，就是没把规则当成「模型」来设计。你想想看，数据库有数据模型，业务有领域模型，规则凭什么不能有模型？
3.1 规则的三要素：条件、动作、优先级
一条规则，拆开来看就三样东西：条件、动作、优先级。我习惯叫它「规则铁三角」。少了任何一个，这条规则就跑不起来。
条件（Condition）
条件就是「什么时候触发」。比如：
- 用户年龄 > 60
- 交易金额 > 10000
- 设备指纹命中黑名单
条件可以组合，用 AND、OR、NOT 连接。我个人建议，条件表达式尽量保持扁平，不要嵌套太深。我在项目中遇到过有人写了五层嵌套的条件，结果线上出了 bug，查了两天才发现是括号位置错了。
动作（Action）
动作就是「条件满足后干什么」。常见的动作有：
- 放行（PASS）
- 拒绝（REJECT）
- 人工审核（REVIEW）
- 增强验证（OTP、人脸）
- 记录日志（LOG）
动作可以串联。比如先记录日志，再拒绝交易。嗯，这里要注意：动作的执行顺序也很重要，我一般会在规则引擎里给动作也排个序。
优先级（Priority）
优先级决定了规则之间的「谁先谁后」。数值越小，优先级越高。比如：
| 规则名称 | 优先级 | 说明 |
|---|---|---|
| 黑名单拦截 | 1 | 最高优先级，先执行 |
| 大额交易审核 | 5 | 中等优先级 |
| 新用户放行 | 10 | 低优先级，最后执行 |
我曾经犯过一个错：把两条互斥的规则设成了相同优先级，结果每次执行结果都不一样。后来我强制要求：同一规则组内，优先级必须唯一。这个坑，你们别踩。
3.2 规则组与规则集
单条规则好理解，但实际业务中，规则往往是成组出现的。这就引出了规则组和规则集的概念。
规则组（Rule Group）
规则组是一组逻辑相关的规则集合。比如：
- 登录风控组：包含设备指纹、IP 地理、账号异常等规则
- 交易风控组：包含金额阈值、频次限制、商户黑名单等规则
- 提现风控组：包含银行卡验证、身份核验、反洗钱等规则
规则组内部有独立的优先级排序。组与组之间可以并行执行，也可以串行执行。我习惯用「组内串行、组间并行」的策略，这样性能好，逻辑也清晰。
规则集（Rule Set）
规则集是规则组的集合，通常对应一个完整的业务场景。比如：
- 支付风控规则集：包含登录风控组 + 交易风控组 + 支付验证组
- 注册风控规则集：包含设备风控组 + 身份验证组 + 黑产检测组
规则集之间可以共享规则组。比如「设备风控组」既用在支付场景，也用在注册场景。这样设计的好处是：一次配置，多处复用。
3.3 规则元数据管理
规则元数据，就是「关于规则的数据」。很多人只关注规则本身的逻辑，却忽略了元数据。其实元数据才是规则长期可维护的关键。
元数据包含哪些内容？
| 元数据字段 | 说明 | 示例 |
|---|---|---|
| 规则 ID | 全局唯一标识 | RULE_20241001_001 |
| 规则名称 | 业务可读的名称 | 大额交易人工审核 |
| 规则版本 | 版本号，用于灰度发布 | v1.2.3 |
| 生效时间 | 规则开始生效的时间 | 2024-10-01 00:00:00 |
| 失效时间 | 规则自动失效的时间 | 2024-12-31 23:59:59 |
| 创建人 | 谁创建的这条规则 | 张三 |
| 最后修改人 | 谁最后修改的 | 李四 |
| 规则状态 | 启用/禁用/灰度/归档 | 启用 |
| 所属规则组 | 归属的规则组 ID | GROUP_TRADE_01 |
| 标签 | 自定义标签，用于检索 | 高优先级、反洗钱 |
为什么元数据重要？
我给你讲个真实案例。有一次线上出了个事故，一条规则本该在凌晨 3 点失效，但因为没配失效时间，它一直生效到第二天中午。结果大量正常交易被误杀。从那以后，我强制要求：每条规则必须配置生效时间和失效时间，没有失效时间的规则不允许上线。
另外，元数据还能帮你做很多事：
- 灰度发布：通过版本号控制，先让 10% 的流量跑新规则
- 快速回滚：出问题时，直接切回上一个版本
- 审计追踪：谁在什么时候改了规则，一目了然
- 规则检索：通过标签快速找到相关规则
3.4 规则模型的核心逻辑图
下面我用一张 SVG 图来展示规则模型的整体结构。你可以把它当作本章的知识地图。
这张图展示了从规则集到规则组再到规则的三层结构，以及元数据如何贯穿始终。你想想看，如果没有元数据，这些规则就像没有标签的文件夹，找起来得多费劲。
3.5 落地实战建议
最后，我结合自己的经验，给你几条落地建议：
- 规则模型要支持热加载：规则变更不能重启服务。我一般用配置中心 + 本地缓存的方式实现。
- 规则版本要可追溯：每次修改都生成一个新版本，旧版本保留至少 30 天。
- 规则优先级要留有余地：比如优先级范围设为 1-100，中间留一些空位，方便后续插入新规则。
- 元数据要自动化：创建时间、修改时间这些字段，让系统自动填充，不要人工填写。
- 规则组不要超过 20 条规则：超过这个数，维护成本会指数级上升。如果规则太多，考虑拆分成更细的规则组。
嗯，规则模型设计这块，今天就聊到这儿。记住：规则不是代码，是模型。用模型思维去设计，你的风控系统才能跑得稳、改得动、查得清。
公众号:蓝海资料掘金营，微信deep3321