3. 产品参数体系概述
在信贷核心系统中，产品参数体系是连接“业务意图”与“系统执行”的桥梁。如果把信贷产品比作一台可配置的精密设备，那么参数就是它的控制面板：业务人员通过调整参数来定义利率、期限、还款方式、费用规则和审批策略，系统则依据这些参数在放款、计息、扣款、核销等环节自动执行。参数化设计的本质，是把易变的业务规则从硬编码中剥离出来，沉淀为可维护、可版本化、可灰度发布的数据配置。
一、参数化设计思想：从硬编码到可配置
传统做法常把产品规则写死在代码里，例如“等额本息还款计划计算逻辑”直接嵌入某个服务类。一旦业务要求新增“先息后本”或“随借随还”，开发就必须改代码、重新测试、重新上线。参数化设计思想的核心是关注点分离：将“做什么”（业务规则）与“怎么做”（计算逻辑）解耦。系统提供稳定的执行引擎，产品人员通过参数组合表达差异。
这种思想带来三个直接收益：第一，产品上线周期从“按周”缩短到“按小时”；第二，规则变更可追溯、可回滚，降低生产事故风险；第三，同一套引擎支撑多产品线，减少重复开发。但参数化并非“一切皆参数”，过度参数化会导致配置爆炸、理解成本上升，因此需要合理的分类与分层。
二、参数分类：按业务语义划分
信贷产品参数通常可分为以下六类，每类对应不同的维护角色与生效时机：
| 参数类别 | 典型参数 | 维护角色 | 生效时机 |
|---|---|---|---|
| 基础属性 | 产品编码、产品名称、币种、起贷金额 | 产品经理 | 实时 |
| 期限与还款 | 贷款期限、还款方式、还款日规则 | 产品经理 | 实时 |
| 利率与费用 | 年化利率、计息方式、罚息利率、服务费 | 定价岗 | 按版本 |
| 额度与授信 | 授信额度上限、额度有效期、循环标志 | 风控策略岗 | 按版本 |
| 审批与风控 | 准入规则、反欺诈开关、人工复核阈值 | 风控策略岗 | 灰度发布 |
| 账务与核销 | 入账科目、核销顺序、宽限期天数 | 财务岗 | 按版本 |
分类的价值在于明确“谁改、何时改、影响谁”。例如利率参数变更会影响存量客户的计息，必须走版本审批；而产品名称变更通常可实时生效。
三、参数层级：从产品到合同的继承与覆盖
参数不是平铺的，而是存在清晰的层级关系。典型层级为：产品模板 → 产品版本 → 合同/借据。产品模板定义默认值与可选范围；产品版本锁定某一时点的参数快照；合同在签约时继承版本参数，并允许在授权范围内做个性化覆盖（如利率优惠、期限调整）。
层级设计的关键是快照机制：合同一旦签约，其参数即被冻结为独立副本。后续产品版本升级不会影响存量合同，除非业务明确发起“重定价”或“参数迁移”。这保证了账务的稳定性和可审计性。
四、参数与业务规则的关系
参数是业务规则的“输入”，业务规则是参数的“执行逻辑”。二者关系可概括为：参数定义边界，规则决定路径。例如“宽限期天数”是参数，“宽限期内是否计罚息”是规则；参数给出数值，规则根据数值和逾期状态做出判断。
在系统实现中，常见两种结合方式：
- 参数驱动规则：规则引擎读取参数值，动态选择分支。如根据“还款方式”参数选择等额本息或先息后本计算器。
- 规则约束参数：参数录入时由规则校验合法性。如“年化利率不得低于3.5%”作为校验规则，防止错误配置流入生产。
五、常见误区与复盘
在参数体系落地过程中，以下误区最为常见：
- 参数粒度过细：把每个计算步骤都做成参数，导致配置项上百个，业务人员无法理解。复盘：应按“业务可解释”原则合并，例如“计息天数规则”用一个枚举参数而非多个布尔开关。
- 缺少版本快照：直接修改产品参数，导致存量合同计息异常。复盘：任何影响资金计算的参数变更必须生成新版本，合同绑定版本号。
- 参数与代码逻辑不一致：参数含义在文档与代码中解释不同，引发生产事故。复盘：建立参数字典，每个参数明确编码、类型、默认值、取值范围和业务含义，并与代码常量一一对应。
- 忽略生效时间：参数修改后立即全量生效，未考虑在途业务。复盘：引入生效时间窗和灰度范围，支持按机构、渠道、客户群逐步放量。