2. 核保规则基础
在保险业务系统中，核保规则是连接“业务策略”与“系统执行”的关键桥梁。它把精算假设、风控政策、监管要求和运营经验，翻译成系统可以自动判断的条件与动作。理解核保规则的本质，是后续掌握版本管理与灰度发布的前提。
一、核保规则的定义与核心原理
核保规则（Underwriting Rule）是指在投保、承保、保全等环节中，用于判断风险、决定承保结论、计算费率或触发人工复核的结构化逻辑单元。它通常由三部分构成：条件（Condition）、判断（Decision）和动作（Action）。条件描述“在什么情况下”，判断描述“命中哪条策略”，动作描述“系统做什么”。
核保规则的本质是“可执行的业务策略”。它必须同时满足三个特性：业务可读、系统可执行、结果可追溯。缺少任何一项，规则都会在版本迭代中失控。
从系统视角看，核保规则是规则引擎的输入。规则引擎负责解析、匹配和执行规则，而规则本身则独立于代码存在，从而支持业务人员参与维护、支持热更新、支持版本回滚。
二、核保规则的常见分类
核保规则可以按多个维度分类，不同分类决定了它在版本与灰度发布中的管理方式。
| 分类维度 | 类型 | 典型示例 | 发布敏感度 |
|---|---|---|---|
| 业务环节 | 投保规则、核保规则、费率规则、保全规则 | 投保年龄限制、职业加费 | 高 |
| 判断性质 | 准入规则、风险规则、定价规则、合规规则 | 既往症拒保、监管限额 | 极高 |
| 执行方式 | 自动规则、人工复核规则、混合规则 | 保额超限转人工 | 中 |
| 作用范围 | 全局规则、产品规则、渠道规则、地区规则 | 某渠道专属风控 | 中 |
| 变更频率 | 稳定规则、高频规则、临时规则 | 活动期临时放宽 | 高 |
分类的意义在于：不同类别的规则，其灰度策略、回滚成本和验证方式完全不同。例如合规类规则通常不允许灰度，必须全量且可审计；而营销活动类规则则适合小流量灰度快速验证。
三、核保规则的生命周期
一条核保规则从诞生到退役，通常经历六个阶段，这也是版本管理的天然锚点。
- 需求提出：业务方基于风控、监管或运营目标提出规则需求。
- 规则设计：将需求转化为条件、判断与动作，明确优先级与冲突处理。
- 开发与配置：在规则引擎中编写、配置或通过DSL表达。
- 测试验证：单元测试、回归测试、影子比对，确认无副作用。
- 发布上线：通过版本发布与灰度策略逐步生效。
- 监控与退役：持续监控命中率与业务指标，失效规则下线归档。
生命周期中最容易被忽视的是“退役”。大量系统事故并非来自新规则，而是来自旧规则未及时下线，与新规则产生冲突或重复命中。
四、核保规则的常见表达形式
规则的表达形式决定了它的可维护性与可测试性。常见形式包括决策表、表达式、DSL和脚本。
// 决策表形式（简化）
规则ID: UW_AGE_001
条件: 投保年龄 > 55 且 险种 = 重疾险
判断: 风险等级 = 高
动作: 转人工核保 + 提示“超龄需体检”
// 表达式形式
IF age > 55 AND product == "CI" THEN
decision = "MANUAL_REVIEW"
reason = "OVER_AGE"
END决策表适合业务人员阅读和批量维护；表达式与DSL适合开发与自动化测试；脚本形式灵活但风险最高，通常需要更严格的版本与灰度控制。选择哪种形式，取决于规则的复杂度、变更频率和参与维护的角色。
五、核保规则在保险业务系统中的作用
核保规则在系统中承担四类核心作用：风险筛选、定价支持、合规保障和运营提效。它让承保决策从“人工经验”走向“系统化、可复制、可审计”。
下面这张图展示了核保规则在业务系统中的位置与数据流：投保请求进入规则引擎，规则引擎读取规则版本，执行匹配后输出承保结论，同时将命中记录写入日志供追溯。
六、常见误区与复盘
误区一：把规则当代码写。规则硬编码在业务代码中，导致每次调整都要发版，无法灰度、无法回滚。
误区二：规则无版本概念。多条规则互相覆盖，出问题后无法定位是哪次变更导致。
误区三：只测单条规则，不测规则组合。单条规则通过，组合后产生冲突或重复命中，是灰度阶段最常见的故障来源。
复盘经验表明：规则的可观测性比规则本身更重要。每条规则执行后都应记录规则ID、版本号、输入快照和输出结论。只有这样，灰度发布时才能对比新旧版本的命中差异，快速判断是否放量或回滚。
掌握核保规则的定义、分类、生命周期与表达形式，就为后续的版本管理和灰度发布打下了坚实基础。规则不是静态配置，而是持续演进的业务资产，需要用工程化方式对待。