3. 版本管理核心概念
在保险核保系统中，核保规则不是一成不变的。监管政策调整、产品迭代、风险策略优化，都会触发规则变更。如果没有一套清晰的版本管理语言，团队就会陷入“这个规则到底改没改”“线上跑的是哪一版”“回滚该回到哪里”的混乱。本节将系统梳理版本管理中最核心的七个概念：版本号规范、语义化版本、基线、分支、标签、快照与变更记录，为后续的灰度发布打下共同语言基础。
一、核心原理：版本管理解决什么问题
版本管理的本质，是让“变化”变得可追溯、可比较、可还原。在核保规则场景中，它要回答四个问题：当前生效的是哪一版、这一版和上一版差在哪里、谁在什么时间因为什么改了它、出问题时能否快速回到已知稳定状态。这四问对应了版本管理的四个能力：标识、差异、审计与回滚。
版本号是标识，语义化版本是标识的约定规则，基线是稳定参照点，分支是并行开发的空间，标签是给关键节点钉上的“书签”，快照是某一时刻的完整状态，变更记录则是状态之间的叙事。它们不是孤立概念，而是一套协同机制。
二、方法流程：七个概念逐一拆解
版本号规范是团队约定的编号规则。核保规则常见的版本号形式如 UW-2024.03.15-001，其中 UW 表示核保域，日期表示发布批次，序号表示当日第几次变更。规范的价值在于：任何人看到版本号，就能判断新旧、定位批次、关联发布记录。
语义化版本采用“主版本号.次版本号.修订号”格式，即 MAJOR.MINOR.PATCH。在核保规则中，主版本号变更意味着不兼容的规则调整，例如投保年龄上限从 60 岁改为 55 岁；次版本号变更表示向下兼容的功能新增，例如新增一条职业类别限制；修订号变更表示向下兼容的问题修复，例如修正某条规则的文案错误。
核保规则版本示例：
1.0.0 初始版本：基础核保规则上线
1.1.0 新增：职业类别 4 类加费规则
1.1.1 修复：职业类别 4 类加费比例计算错误
2.0.0 不兼容：投保年龄上限由 60 岁调整为 55 岁基线是经过评审、测试并确认稳定的版本状态，通常作为后续开发的起点。例如“2024 年 Q1 核保规则基线”就是该季度所有规则变更的参照点。基线一旦确立，不应随意修改，否则后续所有差异比较都会失去意义。
分支是从基线或某个版本派生出来的独立开发线。核保团队常见做法是：主分支保持稳定，每个监管政策调整或产品需求开一个特性分支，如 feature/2024-03-职业类别调整。分支让并行开发互不干扰，完成后合并回主线。
标签是给某个提交或版本钉上的不可变书签。与分支不同，标签不会移动。核保规则发布上线时，通常打上标签如 release-2024.03.15，便于日后精确回溯“3 月 15 日线上跑的是哪一版”。
快照是某一时刻全部规则、参数、配置的完整副本。分支和标签指向的是版本历史中的位置，而快照保存的是那个位置上的完整内容。灰度发布前做快照，是回滚的最后一道保险。
变更记录记录每次版本之间的差异、原因、提出人、评审人和生效时间。它不只是技术日志，更是审计证据。监管检查时，能够清晰说明“某条规则为什么改、谁批准的、什么时候生效”。
三、案例场景：一次核保规则变更的完整版本轨迹
假设某寿险公司要调整重疾险的核保规则：将甲状腺结节 TI-RADS 3 类的核保结论从“除外承保”改为“加费承保”。团队的操作轨迹如下：
- 从当前基线
baseline-2024Q1创建分支feature/thyroid-nodule-adjust。 - 在分支上修改规则，版本号从
1.3.2升至1.4.0，因为属于向下兼容的功能新增。 - 完成评审与测试后，打标签
release-2024.03.20，并生成快照snapshot-2024.03.20。 - 变更记录中写明：变更原因、监管依据、影响范围、评审人、生效时间。
- 灰度发布时，先对 5% 流量生效，观察核保结论分布与投诉率，确认无误后全量。
四、误区与复盘
| 常见误区 | 后果 | 正确做法 |
|---|---|---|
| 版本号随意编，如“最终版”“最终版2” | 无法判断新旧与兼容性 | 统一采用语义化版本，团队共识 |
| 基线确立后仍直接修改 | 差异比较失真，回滚目标模糊 | 基线只读，变更走新分支 |
| 只用分支不打标签 | 分支移动后无法精确定位发布点 | 每次发布打不可变标签 |
| 变更记录只写“修改了规则” | 审计时无法说明原因与影响 | 记录原因、范围、评审人、生效时间 |
| 灰度前不做快照 | 回滚时缺少完整状态副本 | 发布前强制生成快照 |
复盘来看，七个概念中，版本号与语义化版本解决“怎么叫”，基线、分支、标签、快照解决“怎么存”，变更记录解决“怎么查”。它们共同构成核保规则版本管理的完整闭环。理解这套语言，是后续开展灰度发布实战的前提。