4. 规则配置入门：规则创建流程、规则版本管理、规则生效时间配置
好，咱们今天正式进入动手环节。前面几章聊的都是策略引擎的架构和设计理念，说白了就是「纸上谈兵」。从这一章开始，我们要真正去配置一条规则，让它跑起来。
规则配置这件事，看起来就是填几个表单、写几行条件。但我在项目中见过太多人栽在细节上——版本搞混了、生效时间没算对、规则上线了才发现条件写反了。嗯，这些坑我都踩过。今天我把整个流程拆开，带着你一步步走一遍。
4.1 规则创建流程：从需求到上线
一条规则的生命周期，通常包含五个阶段。我习惯把它画成一张流程图，方便团队对齐。
你看，这个流程里有一个很容易被忽略的环节——条件调整的回退箭头。我曾经带过一个项目，开发同学写完规则直接提上线，结果线上跑了一天才发现条件里的金额单位写错了。从那以后，我要求团队必须走完「本地测试 → 灰度发布」这个闭环，哪怕只是改一个数字。
4.1.1 需求分析阶段
这个阶段不写代码，只写文档。你需要回答三个问题：
- 触发时机：规则在什么时候被调用？是用户下单时、还款时、还是每天定时跑批？
- 输入数据：规则需要哪些字段？用户等级、订单金额、历史行为？
- 输出动作：规则命中后做什么？是拒绝、打标、还是调整利率？
我的习惯：用一张表格把这三个问题列出来，发给业务方确认签字。别嫌麻烦，我吃过「口头需求」的亏——业务说「很简单，就加个判断」，结果上线后才发现漏了两个关键字段。
4.1.2 条件编写与本地测试
条件编写是规则配置的核心。我们用一个实际例子来说明。假设有一条风控规则：
规则名称：高风险订单拦截
触发时机：用户提交订单时
条件：
- 订单金额 > 5000
- 用户注册天数 < 30
- 用户历史订单数 < 3
动作：拒绝订单，返回原因码 R1001在策略引擎中，这条规则通常写成 JSON 或 YAML 格式。我个人偏好 JSON，因为结构清晰，方便做版本对比。
{
"ruleId": "RULE_001",
"name": "高风险订单拦截",
"trigger": "ON_ORDER_SUBMIT",
"conditions": {
"operator": "AND",
"items": [
{ "field": "orderAmount", "operator": "GT", "value": 5000 },
{ "field": "regDays", "operator": "LT", "value": 30 },
{ "field": "orderCount", "operator": "LT", "value": 3 }
]
},
"action": {
"type": "REJECT",
"reasonCode": "R1001"
}
}写完之后，一定要在本地跑一遍测试。我常用的方法是准备三组数据：
- 正向用例：满足所有条件，期望规则命中
- 反向用例：不满足任一条件，期望规则不命中
- 边界用例：金额刚好等于 5000、注册天数刚好 30 天
注意：边界用例最容易翻车。我曾经遇到过金额判断用的是「大于等于」，但业务方要的是「大于」。差一个等号，结果完全不同。所以边界测试一定要做。
4.2 规则版本管理：别让「改错了」成为事故
规则不是写一次就完事的。业务在变、数据在变、策略也在变。你今天上线了一条规则，下个月可能就要调整阈值。这时候，版本管理就变得至关重要。
我见过最惨的案例：某团队直接在线上数据库里改规则，改完发现效果不对，想回退却找不到上一版。最后花了三天重新推导逻辑。嗯，这种痛，经历过一次就再也不敢了。
4.2.1 版本号规范
我建议采用 三段式版本号：
| 版本号 | 含义 | 示例 |
|---|---|---|
| v1.0.0 | 初始版本 | 规则第一次上线 |
| v1.1.0 | 条件调整（阈值、字段变更） | 金额阈值从 5000 改为 8000 |
| v1.2.0 | 动作调整（拒绝码、提示信息变更） | 原因码从 R1001 改为 R1002 |
| v2.0.0 | 重大重构（条件逻辑、触发时机变更） | 从 AND 改为 OR 逻辑 |
版本号要记录在规则的元数据里，不能只靠文件名区分。我习惯在规则配置中加一个 versionHistory 字段：
{
"ruleId": "RULE_001",
"currentVersion": "v1.1.0",
"versionHistory": [
{ "version": "v1.0.0", "deployTime": "2024-01-15 10:00:00", "author": "张三" },
{ "version": "v1.1.0", "deployTime": "2024-02-20 14:30:00", "author": "李四", "changeLog": "金额阈值从5000调整为8000" }
]
}4.2.2 版本回滚策略
规则上线后，如果发现效果异常，要能快速回滚。我推荐两种方式：
- 全量回滚：将规则整体回退到上一个版本。适合灾难性事故。
- 增量回滚：只回滚某一条条件的变更。适合局部调整失误。
核心原则：每次上线前，必须保留当前版本的完整备份。不要依赖 Git 的 commit 记录，规则引擎的运行时状态和代码仓库不一定同步。我团队的做法是：每次上线前，自动将当前规则快照存入一个独立的备份表。
4.3 规则生效时间配置：时间错了，规则就废了
生效时间配置看起来简单，但坑最多。我把它分为三种场景：
4.3.1 立即生效
配置上线后立刻开始执行。适合紧急修复或临时策略调整。
{
"effectiveTime": "IMMEDIATE",
"expireTime": null
}但要注意：立即生效不代表「瞬间生效」。规则引擎通常有缓存，配置下发到所有节点需要时间。我建议在配置后等待 1-2 分钟再验证。
4.3.2 定时生效
指定一个未来的时间点开始生效。适合计划性调整，比如大促活动规则。
{
"effectiveTime": "2024-06-18 00:00:00",
"expireTime": "2024-06-20 23:59:59"
}这里有一个容易忽略的点：时区问题。我曾经遇到一个线上事故——规则配置时用了 UTC 时间，但业务方理解的是北京时间。结果规则提前 8 小时生效，导致白天正常订单被拦截。从那以后，我要求所有时间配置必须显式标注时区。
4.3.3 条件触发生效
不依赖时间，而是依赖某个业务状态的变化。比如「当用户等级变为 VIP 时，自动启用 VIP 专属规则」。
{
"effectiveCondition": {
"field": "userLevel",
"operator": "CHANGE_TO",
"value": "VIP"
}
}这种场景在实时风控和营销系统中很常见。配置时要注意：条件触发生效的规则，通常需要配合事件监听器一起使用，否则引擎不会主动去检查状态变化。
避坑指南：我曾经配置过一条「用户首次下单优惠」规则，生效条件设为「用户历史订单数 = 0」。结果上线后发现，所有历史订单数为 0 的用户都触发了优惠，包括那些注册了三年但从未下单的老用户。业务方说「首次」指的是「注册后的第一次」，而不是「历史上从未下单」。你看，同一个条件，理解完全不同。所以生效条件一定要和业务方逐字确认。
4.4 本章小结
规则配置入门，核心就三件事：
- 创建流程：需求分析 → 条件编写 → 本地测试 → 灰度发布 → 全量上线，缺一不可
- 版本管理：用三段式版本号，保留完整历史，支持快速回滚
- 生效时间：分清立即、定时、条件触发三种模式，注意时区和业务语义