4. 报价引擎核心概念
报价引擎是保险交易系统的“定价大脑”。它把产品配置、核保规则、费率表、折扣因子、渠道政策等静态资产，转化为针对某一投保请求的可解释、可追溯、可复现的报价结果。理解报价引擎，不能只把它当成一个计算公式，而应把它看作一条从请求接入到报价落库的完整决策流水线。
一、报价引擎的定义与边界
报价引擎（Rating Engine）是接收标准化投保请求，按照产品版本、费率表和业务规则，计算保费、保额、费用与承保条件的服务组件。它的核心职责是“算得准、算得快、算得清”。算得准指结果与产品定义一致；算得快指满足渠道高并发与低延迟要求；算得清指每个金额都能追溯到具体规则、费率项和计算步骤。
报价引擎通常不负责保单持久化、支付和理赔，这些属于保单系统与交易系统的职责。报价引擎的边界应清晰：输入是报价请求与上下文，输出是报价结果与计算轨迹。边界模糊会导致规则散落、费率版本混乱、责任难以定位。
二、输入与输出：报价请求的契约设计
报价输入一般包括投保人信息、被保人信息、标的信息、险种与保额、期间、渠道、代理人、优惠码、询价场景等。输出则包括总保费、分项保费、保额、费率因子、折扣明细、承保条件、报价有效期和计算轨迹。
| 类别 | 典型字段 | 作用 |
|---|---|---|
| 请求标识 | requestId、channel、quoteScene | 幂等、追踪、场景区分 |
| 标的与险种 | productCode、riskCode、sumInsured、period | 确定产品版本与费率表 |
| 客户与渠道 | age、occupation、region、agentLevel | 影响核保与折扣因子 |
| 输出结果 | totalPremium、premiumDetail、factors、validUntil | 报价展示与后续投保 |
三、规则引擎、计算引擎与决策流
规则引擎负责“能不能保、按什么条件保”，计算引擎负责“具体收多少钱”。规则引擎通常处理核保规则、销售限制、渠道准入、黑名单、职业类别限制等；计算引擎处理费率查找、保额分段、短期费率、折扣叠加、税费计算等。
决策流（Decision Flow）是把规则判断、计算步骤、外部服务调用和结果组装串联起来的编排层。它决定先做资格校验还是先算费，哪些规则可以并行，哪些必须串行。一个典型的决策流如下：
1. 请求校验与标准化
2. 产品版本与费率表路由
3. 核保规则评估（准入、限制、加费）
4. 基础费率计算
5. 折扣与优惠叠加
6. 税费与费用计算
7. 报价结果组装与有效期设置
8. 计算轨迹落库与返回规则引擎与计算引擎不应互相侵入。规则引擎输出“承保条件与因子”，计算引擎消费这些因子完成金额计算。若规则引擎直接写保费，或计算引擎内嵌核保判断，后续费率调整和规则变更都会变得非常危险。
四、报价生命周期：从询价到失效
报价不是一次性动作，而是有状态的生命周期。典型状态包括草稿、已报价、已锁定、已转投保、已失效。草稿阶段允许反复试算；已报价阶段生成正式报价号与有效期；已锁定阶段冻结费率与因子，防止后续变更；已转投保阶段报价被保单引用；已失效阶段因超期、产品下架或信息变更而不可用。
生命周期管理的关键是“报价快照”。报价结果必须绑定产品版本、费率表版本、规则版本和因子快照。否则客户三天后回来投保，费率表已更新，系统无法复现原报价，会引发大量争议。
五、常见误区与复盘
- 把规则引擎当计算引擎用：用规则表达式直接算保费，短期看似灵活，长期导致费率逻辑碎片化，无法统一测试与审计。
- 忽略报价有效期：报价长期有效但费率已变，投保时金额不一致，客户体验与合规风险同时出现。
- 决策流硬编码：把步骤写死在代码里，新增渠道或产品时只能改代码发版，失去配置化意义。
- 缺少计算轨迹：只返回总保费，出现争议时无法解释每一项金额来源，运营与客服成本极高。
- 版本未绑定：报价时用新费率，投保时用旧费率，或反之，导致对账差异。
复盘时可以用“三问法”检查报价引擎设计：第一，这个金额由哪条规则、哪张费率表、哪个因子产生？第二，如果费率表明天更新，今天的报价还能复现吗？第三，新增一个渠道或产品，需要改代码还是改配置？三问都能清晰回答，报价引擎的核心概念才算真正落地。