非车险理赔原型系统：从领域建模到状态机驱动的流程落地

简介保险行业非车险理赔核心原型系统提供一套完整可运行的源码与说明文档面向计算机相关专业学生、保险科技从业者及准备毕业设计的人群可胜任课程大作业、毕设项目或初期项目立项演示等场景。压缩包共255个文件以136个Java后端类、40个Vue前端组件及33个XML配置为核心另含SQL脚本用于数据库初始化JS与CSS支撑页面逻辑与样式YAML等配置文件管理运行参数并附Markdown说明文档整体仅2.48MB轻量且目录清晰便于快速定位代码。包内代码经测试运行成功功能稳定已有61人学习参考。深入阅读可重点研究后端与前端的接口联动、数据库表结构设计及系统配置方式理解非车险理赔流程的模块划分与项目组织方法既能辅助课程设计与毕设答辩也可作为企业级原型开发的起点实用价值较高。1. 非车险理赔原型系统先跑通流程再谈生产化在保险科技项目里“车险理赔”常被当作数字化改造的样板间——流程标准、数据规整、系统成熟。但真正让理赔部门头疼的是非车险。企财险、责任险、货运险、工程险每个险种的查勘要点不同、单证要求不同、损失核定逻辑更是千差万别。指望用一套通用理赔核心直接适配所有非车险产品结果往往是“配了三个月还在配第一个险种”。这个原型系统的价值在于它不试图覆盖所有业务细节而是把非车险理赔最核心的能力抽象出来——案件创建、任务分配、查勘采集、定损计算、核赔审批、支付回写。用一套轻量但边界清晰的核心模型把业务方和开发团队拉到同一张蓝图前花一到两周跑通端到端流程。适合保险科技团队、理赔系统外包项目组、以及想快速验证非车险理赔中台方案的技术负责人。下面按一个可落地的原型实现路径来拆解。2. 理赔核心的领域建模先把“案件-任务-赔款”三件事分清楚2.1 为什么非车险理赔核心不比车险简单甚至更复杂车险理赔的主线是“一案一车一人”流程相对固定。非车险则是“一案多保单、一保单多险种、一险种多条款”。以企财险为例一张投保单下可能同时覆盖存货、厂房、机器设备每个标的物的损失核定方式都不同。责任险更是涉及第三方、诉讼、追偿这些分支。如果模型设计时就把所有字段揉进一张“理赔主表”后续每个险种接入都会变得极其痛苦。原型系统应当采用“核心加扩展”的建模思路。核心部分只保留所有非车险理赔都通用的概念案件Claim、保单Policy、损失标的LossItem、任务Task、赔款Payment。各险种的特殊字段放在扩展属性attributes JSON里。这样新险种接入时不需要改核心表结构只需要在扩展属性里约定好字段规范。2.2 用状态机约束案件流转而不是靠业务代码写 if else理赔案件的流转是最容易失控的地方。一个案件从报案到结案中间可能有“待查勘、查勘中、待定损、定损完成、待核赔、核赔退回、待支付、已支付、已结案、已注销”等状态。如果每个接口里都写一堆状态判断很快就会出现“案件被重复提交支付”或“已注销案件还能创建任务”这类问题。常见的做法是用状态机表来驱动流转。把案件状态、允许的事件、目标状态、以及触发事件需要的角色权限都配置在数据库里代码层面只维护一个状态机引擎。这样调整流程时不需要发版运营人员在管理端就能改。以下是原型系统中案件状态机的核心配置表结构CREATE TABLE claim_state_machine ( id BIGINT PRIMARY KEY AUTO_INCREMENT, current_state VARCHAR(32) NOT NULL COMMENT 当前状态, event_code VARCHAR(32) NOT NULL COMMENT 触发事件SUBMIT_REPORT, ASSIGN_SURVEY, SUBMIT_ASSESS, SUBMIT_VERIFY, APPROVE_PAYMENT, REJECT, CANCEL, target_state VARCHAR(32) NOT NULL COMMENT 目标状态, required_role VARCHAR(64) COMMENT 所需角色SURVEYOR, ASSESSOR, CLAIM_MANAGER, FINANCE, condition_expr VARCHAR(255) COMMENT 可选的条件表达式如 amount 50000, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); INSERT INTO claim_state_machine (current_state, event_code, target_state, required_role) VALUES (REPORTED, ASSIGN_SURVEY, SURVEYING, CLAIM_MANAGER), (SURVEYING, SUBMIT_ASSESS, ASSESSING, SURVEYOR), (ASSESSING, SUBMIT_VERIFY, VERIFYING, ASSESSOR), (VERIFYING, APPROVE_PAYMENT, PAYING, CLAIM_MANAGER), (VERIFYING, REJECT, REPORTED, CLAIM_MANAGER), (PAYING, CONFIRM_PAID, PAID, FINANCE), (REPORTED, CANCEL, CANCELLED, CLAIM_MANAGER);这里的重点在于condition_expr字段。比如定损金额超过 5 万需要走上级审批这个规则放在状态机配置里而不是写在服务逻辑中。后续如果调整审批额度只需更新配置表。状态机引擎执行时通过事件码查出所有可流转的目标再校验角色和表达式命中就完成状态迁移。2.2.1 状态机引擎的最小实现引擎不需要引入复杂的规则引擎框架一个简单的校验方法就能支撑原型阶段的全部流转需求。public class StateMachineEngine { private final JdbcTemplate jdbcTemplate; public boolean transition(Claim claim, String eventCode, String operatorRole) { String sql SELECT target_state FROM claim_state_machine WHERE current_state ? AND event_code ? AND required_role ?; ListString targets jdbcTemplate.queryForList(sql, String.class, claim.getCurrentState(), eventCode, operatorRole); if (targets.isEmpty()) { throw new IllegalStateException(当前状态 [ claim.getCurrentState() ] 不允许操作 [ eventCode ] 或角色 [ operatorRole ] 无权限); } if (targets.size() 1) { // 多条目标状态时需要逐条判断 condition_expr // 原型阶段用预设规则处理生产环境建议结合规则引擎做动态解析 String configSql SELECT condition_expr FROM claim_state_machine WHERE current_state ? AND event_code ?; // 这里做条件表达式求值 } claim.setCurrentState(targets.get(0)); return true; } }这个引擎的逻辑要点有三处第一用 SQL 直接过滤角色操作者没有权限时直接抛异常避免越权第二允许同一事件根据条件流转到不同目标状态比如金额小直接终审通过金额大转人工复核第三状态变更与业务操作在同一个事务里执行避免出现“数据改了但状态没动”的不一致场景。原型阶段这么做足够清晰后续引入 Flowable 或 Camunda 做工作流引擎时也只需把状态机表替换为 BPMN 定义。2.3 非车险理赔的三个核心聚合根领域模型不宜拆得太散原型系统把核心逻辑收敛在三个聚合根上。案件聚合根Claim聚合了报案信息、保单引用、损失标的列表、当前状态、总估损金额。对外暴露的方法是createClaim、submitReport、addLossItem、updateAssessment。所有操作都走聚合根方法确保不变量不被绕过。损失标的聚合根LossItem承载每个标的物的损失描述、定损明细、核减原因。任务聚合根Task负责查勘任务、定损任务、核赔任务的生命周期管理。3. 理赔核心流程的代码实现从报案到支付的状态流转链路3.1 报案登记保单校验和初步责任判断报案是整个理赔流程的入口。非车险报案登记和生产系统不同的一点是非车险的报案往往是报案人描述不清的保单号记不全、出险时间说不准是常态。原型系统要做的是“宽松登记、严格校验”登记时只拦截必填数据真正校验保单有效性放在后续节点。在下单代码中接口逻辑分成两部分先做结构和参数基础校验比如报案人联系方式、出险日期不能晚于当前时间再做保单弱校验比如保单号格式检查、保单是否存在、是否在有效期内。如果保单校验失败系统不阻断登记而是把案件标记为“保单异常”推给人工确认。public Claim createClaim(CreateClaimRequest request) { // 宽松登记即使保单信息异常也允许创建案件 Claim claim new Claim(); claim.setPolicyNo(request.getPolicyNo()); claim.setPolicyId(policyService.matchPolicy(request.getPolicyNo())); claim.setNotifierName(request.getNotifierName()); claim.setNotifierPhone(request.getNotifierPhone()); claim.setReportTime(LocalDateTime.now()); if (claim.getPolicyId() null) { claim.setPolicyVerifyStatus(EXCEPTION); claim.setPolicyExceptionReason(保单号未匹配到有效保单); } else { claim.setPolicyVerifyStatus(NORMAL); } claim.setCurrentState(REPORTED); claim.setCreateOperator(request.getOperatorId()); claimRepository.save(claim); return claim; }这一段实现里有三点值得留意。第一案件主键使用数据库自增 ID 还是业务号原型阶段建议双轨制数据库主键 案件编号claim_no案件编号生成规则可以用日期加序列例如CL20250624001便于人工沟通时引用。第二policyService.matchPolicy做的是保单快照匹配如果匹配到多条保单比如同一保单号存在续保周期应当返回异常由人工选择而不是取第一条。第三状态机的初始状态直接在创建时指定为REPORTED不走一遍流转接口因为案件尚不存在状态机引擎依赖案件主键。3.2 查勘任务分配基于业务类型和案件金额的路由策略查勘任务分配是理赔系统里业务分歧最大的地方。有的保险公司按行政区划派单有的按查勘员当前工作量动态分配有的按渠道归属固定处理团队。原型系统不能替业务方做决策但必须把“路由策略”做成可扩展的接口。定义TaskAssignStrategy接口内置两种实现WorkloadBalanceStrategy按当前未完成任务数分配和ChannelFixedStrategy按报案渠道固定团队。业务方后续可以在不修改核心代码的情况下新增第三种策略。public interface TaskAssignStrategy { ListLong assign(CreateTaskRequest request, ListSurveyor candidates); } public class WorkloadBalanceStrategy implements TaskAssignStrategy { Override public ListLong assign(CreateTaskRequest request, ListSurveyor candidates) { // 按未完成查勘任务数升序排序取前 N 位 return candidates.stream() .sorted(Comparator.comparingInt(s - s.getPendingTaskCount())) .limit(request.getAssignCount()) .map(Surveyor::getId) .collect(Collectors.toList()); } }assign接口的两个入参值得说明CreateTaskRequest里包含险种代码、预估损失金额、出险地区、客户等级等路由因子ListSurveyor是经过区域筛选取后的候选查勘员列表。真正做区域匹配的代码在上游完成策略实现关注的是“在候选集合里选谁”。这样每个策略只算“打分”或“排序”这一件事不会把区域逻辑和分配逻辑缠在一起。分配结果写入claim_task表时同时记录分配模式AUTO/MANUAL自动分配的任务发生争议时可以追踪到是哪个策略产出的结果方便复议。3.3 定损与核赔金额权限校验的两种实现方式定损环节是最能体现非车险复杂度的点。车险的定损对象是车辆的某个部件非车险的定损对象可能是整条生产线、一批库存货物、或者一栋建筑的部分结构。原型系统不尝试做自动定损而是提供结构化的“损失录入模板”。损失模板按险种类别配置每个模板包含损失项目列表、计量单位、单价、损失数量、核定折扣比例。端上或 Web 端录入后后端按模板计算公式自动汇总估损金额。public BigDecimal calcLossAmount(LossItem item, LossTemplate template) { BigDecimal rawAmount BigDecimal.ZERO; for (LossDetail detail : item.getDetails()) { // 数量 * 单价 * 折扣比例 BigDecimal detailAmount detail.getQuantity() .multiply(detail.getUnitPrice()) .multiply(detail.getDiscountRate()); rawAmount rawAmount.add(detailAmount); } // 超过免赔额的才赔付免赔额从保单条款中读取 BigDecimal deductible claimService.getDeductible(item.getPolicyId(), item.getLossCause()); return rawAmount.subtract(deductible).max(BigDecimal.ZERO); }这段代码逻辑不复杂但discountRate的取值来源值得展开。折扣比例的设置权限应该独立于录入权限——查勘员可以录数量和单价但折扣比例的修改必须由定损主管确认。原型系统把discountRate的变更记录单独存到loss_detail_change_log表保留修改前值、修改后值、修改人、修改原因。后续对接审计系统时这份日志就是合规依据。核赔环节的权限校验除了状态机里的角色校验还需要金额层级校验。核心逻辑是“案件当前累计赔付金额超过当前节点的授权额度时必须升级到更高审批节点”。实现时把审批层级配置做成一张独立规则表支持按机构层级、按赔付金额、按险种三个维度设置。4. 从原型到可演示数据初始化和理赔流程串联技巧4.1 造数脚本一次生成可供演示的完整业务台账原型系统交付时最影响演示效果的不是功能缺失而是没数据。评审会上业务方最常问的问题是“能不能演示一个从报案到赔付的全流程”。如果每点一个按钮都需要现场录入几分钟数据气氛就会冷下来。我会在项目里内置一套造数脚本预置五个险种的完整数据企财险火灾出险、货运险运输途中货物受损、责任险第三方人身伤害索赔、工程险施工意外、意外险团体人身意外。每个险种预置至少两个案件一个处于“查勘中”一个处于“待核赔”这样评审时既能演示流程推进也能展示不同节点的界面状态。-- 预置一个处于“查勘中”状态的责任险案件 INSERT INTO claim_main ( claim_no, policy_id, policy_no, risk_code, risk_name, notifier_name, notifier_phone, report_time, loss_date, loss_address, loss_cause, estimated_amount, current_state, policy_verify_status, create_operator, create_time ) VALUES ( CL20250610001, 1001, PL202406010001, CGL, 公众责任险, 张经理, 13800001111, 2025-06-10 10:24:00, 2025-06-10 09:50:00, 上海市浦东新区XX路88号, 顾客在店内滑倒受伤, 15000.00, SURVEYING, NORMAL, SYS, NOW() ); INSERT INTO claim_task ( claim_id, task_type, assign_type, assignee_id, task_status, plan_start_time, plan_end_time, create_time ) VALUES ( 1, SURVEY, AUTO, 21, PROCESSING, 2025-06-10 11:00:00, 2025-06-10 15:00:00, NOW() );造数脚本里最容易忽略的是时间字段的合理性。演示时如果系统显示“报案时间是刚刚但任务已经处理完”业务方会明显地感知到数据是造出来的。时间一定要模拟真实时效报案在上午查勘任务应该在下午查勘完成后定损需要一至两天核赔到支付之间隔半天以上。把时间轴做自然演示效果会有质的提升。4.2 查勘报告的移动端采集交互图片和坐标怎么关联远程查勘在非车险理赔里越来越常见原型系统如果只做 PC 端后台说服力不够。移动端 H5 查勘需要解决的三个问题照片采集带位置、语音转文字形成查勘备注、离线时本地暂存。H5 采集照片时通过navigator.geolocation获取经纬度与照片元数据关联后上传。这里有个兼容性细节H5 无法直接读取照片的 EXIF 信息需要前端把 GPS 坐标作为单独字段传给后端再由后端拼进业务数据模型里。查勘照片的坐标系建议统一用 GCJ-02。国内的地图 SDK 使用坐标时如果直接传原始 WGS-84 坐标地图上会偏移几十米到几百米。navigator.geolocation.getCurrentPosition( (pos) { const photoData { claimNo: claimNo, lossItemId: lossItemId, photoBase64: compressImage(file, 0.7), latitude: pos.coords.latitude, longitude: pos.coords.longitude, timestamp: Date.now() }; // 先写本地 localStorage待网络恢复后统一上传 pendingUploads.push(photoData); }, (err) { // 定位失败时允许手动选择位置 showLocationPicker(); } );这个实现里有两个细节要强调。第一photoBase64在传photoBase64之前要先做压缩不压缩的话一张照片经常超过 5MB移动环境下上传体验会非常差压缩到宽度 1280 像素左右画质选 0.7兼顾清晰度和体积。第二pendingUploads存在localStorage时要注意容量限制批量照片建议使用 IndexedDB 存储避免存储溢出。4.3 预置一套可演示的自动核赔规则理赔系统的核心价值最终体现在“自动化核赔”上。不能自动核赔的理赔系统只是电子流程软件。原型阶段不需要引入复杂规则引擎用表达式配置即可跑通演示。规则编码规则名称适用险种条件表达式动作优先级R001小额快速赔付意外险amount 3000 cause ACCIDENT noDispute true自动通过核赔10R002责任险人工复核公众责任险cause SLIP_FALL amount 5000转人工核赔20R003企财险免赔额校验企财险lossType FIRE amount 20000自动通过核赔15规则表可以用 Groovy 脚本做表达式解析也可以用轻量引擎比如 Aviator。原型系统建议直接用 Java 内置的ScriptEngine。public class AutoVerifyRuleEngine { public VerifyResult evaluate(Claim claim, MapString, Object context) { ListVerifyRule rules ruleRepository.findByRiskCode(claim.getRiskCode()); // 按优先级排序命中后不再继续 for (VerifyRule rule : rules) { if (evaluateExpression(rule.getConditionExpr(), context)) { return new VerifyResult(rule.getAction(), rule.getRuleName()); } } return new VerifyResult(MANUAL_AUDIT, 未命中自动规则转人工); } }演示时先把自动核赔规则的金额阈值调低造一批小额案件跑自动通过再把责任险案件的金额调高展示转人工核赔的提醒列表。一个页面内同时呈现两类案件的流向评审效果会更好。5. 非车险理赔体系的原型系统落地集成策略与排错指引5.1 核心模块的清单与二次开发边界任何一个非车险理赔系统的建设都要重新审视自身的功能边界。报告实现中哪些通用能力可以采用业界成熟的组件哪些行业特性需要自行开发这两者的划分决定了开发成本的上限。原型系统的标准模块清单包括案件管理、任务管理、查勘小程序 H5、定损录入、核赔审批、支付请求、短信通知、报表统计。其中任务调度、权限管理、消息通知、文件存储这四类能力业界有高度可复用的方案比如流程引擎选 Flowable、权限模型基于 RBAC 扩展、文件存储走对象存储、消息推送接钉钉/企微机器人不建议在原型阶段重复造轮子。真正需要投入精力自研的是损失模板配置、定损计算公式、自动核赔规则、单证 OCR 接入、理赔反欺诈规则引擎。5.2 环境部署的三个定位技巧原型系统交付时最常遇到的部署问题就是端口占用和配置缺失。压缩包内的说明文档一般会写部署步骤但实际跑起来出错时排错路径得提前梳理清楚。常见做法是让项目里带一个Dockerfile和一份docker-compose.yml把 MySQL、Redis、后端服务、前端静态文件四件事在一个命令里拉起。version: 3 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:-root123} MYSQL_DATABASE: nonauto_claim ports: - 3306:3306 volumes: - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql redis: image: redis:7-alpine ports: - 6379:6379 backend: build: ./backend depends_on: - mysql - redis ports: - 8080:8080 environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/nonauto_claim?useUnicodetruecharacterEncodingutf8 SPRING_REDIS_HOST: redis frontend: image: nginx:alpine ports: - 8800:80 volumes: - ./frontend/dist:/usr/share/nginx/htmlposition有两处常见问题一是mysql初始化脚本只会在数据目录首次创建时执行如果之前已经跑起来过一个 MySQL 容器然后又修改了init.sql删除旧容器是必要的否则新脚本不会生效二是frontend的 nginx 静态页面调用后端接口时跨域问题会在浏览器层面拦截。开发阶段用nginx反向代理解决把这行配置写进default.conf里而不是让前端单独配置代理location /api/ { proxy_pass http://backend:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }5.3 数据库表结构变更的进展示范如何让业务方“看得见”模型非车险理赔原型系统交付时不要拿着 ER 图去给业务方讲表结构。更直观的方式是把核心数据模型做成一个“演示报告”一页一个模型每个模型一张表样和一句业务解释。附件中最好带一份 SQL 脚本的注释版把每个注释字段的出处写清楚。原型系统在这个阶段往往存在一个动态调整的过程。业务方看完演示后会提出大量流程调整需求比如“增加一个未决赔款管理”“查勘报告需要关联影像清单”等。代码上很好处理但数据库脚本的变更要谨慎。每次调整后在客户的测试环境上用mysqldump导出增量脚本再在归档环境验证一次严格限制不更新已有脚本文件。这保证了每次交付包里只有一份干净、可直接执行的脚本不会出现“改了脚本但忘了改说明”的情况。理赔系统的核心价值不在写代码本身而在于让业务的损失认定过程清晰化、可追踪、有权限边界。这套原型拖着这些基础能力走通一遍后续生产化的工作量就能从“从零设计”压缩为“按需加固”。本文还有配套的精品资源点击获取