理赔 Claw

项目背景

短期意外险、航延险等高频小额案件，往往不是责任判断特别复杂，而是咨询多、材料多、重复动作多。客户需要反复确认“能不能赔、交什么材料、为什么退回”；审核人员则要持续处理材料完整性、身份信息和规则核验。

理赔 Claw 的目标不是让 AI 直接决定赔付，而是把适合标准化的动作前置：帮助客户更准确地提交材料，帮助审核人员更快看见通过项、疑点项和需要人工判断的问题。

我的角色

我以保险专业和产品经理的双重视角规划项目：选择适合 AI 进入的业务环节，定义客户侧与审核侧链路，把保险规则转成系统可执行的检查项，并用真实案件中的误判和异常推动版本迭代。

Codex 参与需求拆解、代码实现、问题定位、版本修复、验证说明和阶段沉淀。我们的协作不是一次性“生成一个系统”，而是在真实反馈中不断校准业务理解与工程实现。

一条双端闭环

客户侧：把问题解决在提交之前

• 解释理赔流程、所需材料与常见问题。
• 在提交前识别缺失、模糊或错传的材料。
• 及时说明补件原因，减少等待和重复沟通。

审核侧：让人工带着结论复核

• 识别材料并抽取姓名、证件、航班、时间等关键字段。
• 按险种责任、时效、材料要求和一致性规则完成基础校验。
• 输出通过、提示、人工复核或不通过等分级意见。
• 保留依据、异常项和处理状态，支持最终人工复核与追踪。

这条链路形成了“AI 识别 + 规则校验 + 人工复核 + 留痕追踪”的人机协同机制。AI 负责高频、标准、重复的动作，人工保留责任判断和最终决定。

项目的五次进化

版本一：先让流程跑起来

最初版本解决的是“能不能完成一次预审”。系统能够拉取案件与材料，执行 OCR 和材料识别，按基础规则生成审核结果。

这一阶段让 AI 从聊天和演示进入了真实业务流程，但“单案能跑通”还不等于系统能够稳定运营。

版本二：从能跑，变成不会在批量中失控

真实运行很快暴露出新的问题：并发任务可能争用临时文件，队列中断后需要恢复，技术失败也可能与业务不通过混在一起。

我们随后加入独立临时目录、结构化结果、持久化队列、失败重试、重复任务控制和状态恢复，并把“技术执行状态”与“业务审核结论”分开。这样，系统不会因为接口异常、网络问题或资源不足，就错误地把案件解释成业务不通过。

版本三：从统一规则，变成理解材料之间的差异

理赔材料不能用同一套关键词粗暴判断。登机材料、延误证明、身份证件和申请表，各自有不同的出具主体、版式和信息要求；申请表里出现“护照”字段，也不代表整份文件就是护照。

在真实误判推动下，我们逐步拆分材料类型规则，明确必需材料与条件材料，引入“先 OCR、必要时再由视觉模型兜底”的策略，并把结果从简单的通过/不通过扩展为分级结论。系统开始学会表达“不确定，需要人工复核”，而不是为了自动化率强行给出答案。

版本四：从追求识别更多，变成在资源约束下识别得刚刚好

扫描版 PDF、多页材料和并发 OCR 会迅速放大资源消耗。继续堆页数、分辨率和模型调用，并不一定带来更好的生产结果。

我们根据运行表现调整处理页数、图像分辨率和并发策略，加入命中即停止，并坚持“规则能够判断的交给规则，只在材料理解和异常判断等必要环节调用模型”。这一版的进化不只是更快，而是开始同时考虑准确性、稳定性和资源成本。

版本五：从一个项目，变成可以继续复用的能力

当材料识别、字段交叉核验、案件队列、异常分级、人工复核和结果回写被拆成独立能力后，项目就不再只对应一个险种或一个页面。

后续接入新场景时，可以复用通用能力，只补充差异化材料和业务规则。理赔 Claw 因此从一个自动审核脚本，逐渐进化为可组合、可验证、可继续扩展的服务链路。

阶段结果

• 形成客户侧材料指引与审核侧智能预审的双端方案。
• 智能识别准确率达到 98.3%。
• 标准案件基础预审由人工约 10 分钟缩短到系统平均约 40 秒。
• 系统结果能够回到审核流程，并由人工完成最终复核。
• 真实误判、技术异常和资源问题已经能够进入持续迭代闭环。

这些结果说明项目已经跨过“能演示”的阶段，开始具备真实运行、持续校准和能力复用的基础。

产品边界

系统提供材料识别、基础规则校验、预审意见与风险提示，不替代最终人工审核责任。模型输出不是赔付决定；无法确认、材料冲突和高风险情况必须进入人工复核。

公开内容只保留已经确认、能够脱敏的产品方法和阶段结果，不披露公司与客户名称、案件数据、人员配置、成本与报价、业务容量、内部系统地址、账号密钥、未脱敏材料、模型供应商和具体版本。