为什么通用规则引擎在金融风控中‘跑得动’却‘看不懂’？
通用规则引擎（如 Drools）将业务逻辑抽象为通用布尔表达式，缺乏对金融语义的原生建模能力。例如：
- ‘逾期天数滚动计算’需手动封装时间窗口逻辑；
- ‘贷后行为评分建模’依赖外部代码拼接特征，无法在规则层直接定义输入结构；
- 多系统协同时，‘多头借贷接口’字段口径不统一（如
totalCreditAmountvscredit_limit_sum），导致规则结果不可比、难复盘； - 默认仅输出终态结果（如
REJECT），缺失节点级归因（谁改了规则？依据哪条条件？为何跳过某分支？），难以满足监管审计留痕要求。
本质问题不在功能缺失，而在于架构未以‘强语义、高可解释、多系统协同’的金融决策过程为设计原点。
决策设计器：让业务逻辑真正可读、可管、可溯
JVS-Rules 的决策设计器不是低代码表单生成器，而是面向金融决策过程的语义化编排界面：
- 预置贷前筛查、贷中实时决策、贷后周期管理等模板，降低业务理解门槛；
- 支持决策树 + 评分卡混合编排，适配‘逐层准入 → 多维打分’复合路径（如先用决策树过滤高风险客群，再对剩余用户启用评分卡核定额度）；
- 提供双模式配置：
- 条件分支模式：保障逻辑透明，供规则审核人逐条复核；
- 决策表模式：支持按地区、产品类型等维度批量配置组合规则；
- 内置版本留痕与细粒度权限控制：每次变更自动记录操作人、时间戳、生效版本，规则演进全程可追溯。
函数计算器：把业务计算沉淀为标准化、可复用的因子
函数计算器将散落于各处的金融计算逻辑，封装为可声明式调用的业务因子：
- 开箱即用金融函数模板：如
overdueDaysRolling()（逾期天数滚动计算）、marketingWeightDynamic()（营销权重动态分配），无需开发即可嵌入规则； - 多引擎支持：API、DB、SQL、Groovy 等函数可混合调用，灵活对接征信系统、黑名单库、反欺诈服务等外部数据源；
- 变量分层设计：
- 基础变量：单值指标（如
debtRatio、creditLimit）； - 复合变量：多行结构化结果（如近6个月还款流水列表、他行信贷明细数组），支撑复杂模型输入；
- 基础变量：单值指标（如
- 全链路执行日志：记录入参、出参、耗时、异常堆栈，为模型效果验证与合规复盘提供原始数据基底。
数据源抽象：统一异构金融数据的契约与接入范式
金融数据分散于核心银行系统、支付平台、外部征信、JVS 低代码模型等异构环境。JVS-Rules 通过数据源抽象层实现语义对齐：
- 将数据库、HTTP API、Excel、JVS 数据模型等统一抽象为‘数据源实例’，屏蔽连接细节，聚焦数据语义；
- 针对高频场景预置向导：如‘多头借贷接口自动映射’，可智能识别返回字段语义（
totalCreditAmount→ ‘他行授信总额’），一键绑定至业务变量，避免人工误配； - 支持前置校验与失败降级：当接口超时或空值时，自动启用缓存、默认值或跳过该分支，保障风控链路确定性输出；
- 数据源、函数、规则在同一配置界面强绑定，实现‘查什么、怎么算、如何判’三位一体。
执行追溯：构建金融级可解释性与可审计性
执行追溯是满足《银行保险机构操作风险管理办法》的核心能力：
- 节点级执行日志：精确记录每个条件判定依据（如
debtRatio=72.3% > 70% → REJECT）、评分卡各维度得分、决策树路径选择原因； - 规则日志与函数日志双向关联：支持从终态结果（
REJECT）一键下钻至技术根因（如‘某征信接口返回空值’）； - 强制元信息字段：包含规则版本号、操作人、时间戳、调用方 IP，符合监管留痕要求；
- 日志以标准 JSON 格式输出，支持一键复制，可直接用于审计报告或监管报送，规避人工整理失真。
对开发者而言，这不是‘加日志’，而是将可解释性作为第一性需求，内建于规则执行引擎的设计契约中。
