从一个审核脚本到理赔产品：Claw 的下一段进化

003 写协作，006 写产品

共创档案 003 记录的是天er与 Codex 如何在四轮迭代中改变协作方式：真实业务反例进入对话以后，我们不再只问“代码有没有运行”，而是区分材料识别、业务规则、流程状态和生产故障，再用下一轮证据继续修正。

但协作变顺，只解决了一半问题。

一个可以审核单个案件的脚本，怎样变成一项可以持续运行、服务客户、支持审核人员并接入真实业务系统的理赔产品？这才是理赔 Claw 的下一段进化。

脚本的终点，通常只是产品的起点

最初的审核能力以案件为单位工作：读取案件信息，下载材料，执行 OCR 与视觉理解，核对材料类型和关键字段，再输出通过、提示、补件或人工复核建议。

这条链路证明了 AI 可以进入理赔预审，却还没有完整回答：

• 客户怎样在提交前知道需要什么材料？
• 材料缺失或错传时，谁负责解释和补件？
• 多个案件怎样排队、重试和避免重复处理？
• 审核结果怎样回到业务工作台？
• 规则变化以后，怎样复用能力而不是重写整个脚本？

当这些问题出现，项目就不再只是“把识别做准”，而是开始设计一条端到端服务链路。

C 端不是上传入口，而是第一次质量控制

传统流程中，客户经常在提交后才知道材料缺失、模糊或不符合要求。客服需要反复解释，审核人员也会把时间消耗在补件沟通上。

理赔 Claw 的 C 端方向，是把一部分质量控制前移：

• 根据险种和案件状态解释材料要求。
• 在提交前提示常见缺件、模糊和错传问题。
• 用自然语言说明为什么需要补充，而不是只返回一个失败状态。
• 把无法确认的情况交回人工服务，不让模型继续猜测。

它的价值不只是减少一次人工操作，而是让后面的审核链路接收到更完整、更可判断的输入。

B 端不是自动结案，而是缩小人工判断范围

案件进入审核侧以后，系统先执行可结构化的基础工作：

1. 拉取案件、保单与材料信息。
2. 识别材料类型并抽取关键字段。
3. 根据险种责任、时效、重复理赔等规则执行基础校验。
4. 将通过项、异常项和需要人工确认的部分写回工作台。

审核人员看到的因此不再是一组未经整理的原始材料，而是一份带有依据和待确认事项的预审结果。

这里的产品目标不是让 AI 代替审核责任，而是把人工注意力从重复核对转移到真正需要判断的异常上。

把“一个大模型判断”拆成多种责任

理赔系统不能把整案材料一次性交给模型，然后等待一个“赔”或“不赔”的答案。

当前实现逐步形成了四层责任：

• OCR 与视觉模型负责材料内容和版式理解。
• 业务规则负责确定性条件与红线判断。
• 流程编排负责队列、重试、状态和结果回写。
• 人工负责无法确认、高风险和最终业务结论。

这四层之间可以协作，但不能互相冒充。

技术调用成功，只能说明模型返回了结果；材料类型正确，也不能证明案件满足所有责任条件；规则命中某个提示，更不等于可以直接替人完成最终理赔决定。

因此，结构化结果需要同时记录技术状态、材料核验状态、业务提示和人工复核建议。

Skill 编排的价值，是让新场景只增加差异

如果每增加一个险种就复制一套完整脚本，系统很快会出现大量相似但不一致的实现。

理赔 Claw 更适合把稳定动作拆成可组合能力：

• 案件信息读取
• 材料下载与去重
• 身份信息核对
• 材料类型判断
• 航班或事故证明识别
• 规则预审
• 异常分流
• 审核结果回写

新险种复用已有能力，只补充自己的材料清单、责任规则和异常条件。这样沉淀下来的不是某一个页面，而是一套可以继续编排的理赔能力组件。

模型切换不是改一个地址和密钥

项目中的视觉模型调用已经能够处理材料，但当前实现仍带有明确的供应商适配：端点、鉴权、请求结构、图片输入、响应解析和错误语义都写在具体调用路径里。

因此，未来切换模型不能只修改配置项。更可靠的产品结构需要把模型层拆成统一接口和供应商适配器：

业务审核流程
  ↓
统一视觉理解接口
  ↓
供应商适配器
  ↓
具体端点、鉴权、请求与响应解析

只有这样，业务规则和审核流程才不会随着模型供应商变化而一起重写。

这也是从脚本走向产品的重要标志：模型是可替换能力，不是整个系统的结构中心。

产品化还意味着资源和失败都要被管理

单次测试时，处理慢一点通常可以接受；进入持续运行后，OCR 页数、图片清晰度、并发数量、临时文件和失败重试都会影响稳定性。

项目已经经历过扫描版 PDF 过重、并发导致资源压力、固定临时文件造成冲突等问题。后续版本加入了页数限制、分辨率调整、命中即停止、独立临时目录和队列约束。

这些改动看起来不如模型能力先进，却决定了系统能否持续工作。

真正的理赔产品必须把“识别失败、下载失败、无法确认、需要人工复核、任务超时”都当成正常状态设计，而不是只为成功路径写演示。

从内部工具到服务能力，先标准化交付边界

当双端流程、审核工作台和 Skill 编排逐步稳定以后，这套能力可以继续扩展到更多高频、规则相对清晰的理赔场景。

但对外复制不能只复制代码。它需要明确：

• 接入方需要提供哪些案件与材料字段。
• 哪些规则由平台维护，哪些由具体险种配置。
• 哪些结果可以自动推进，哪些必须人工复核。
• 失败、补件和异常怎样留痕。
• 模型、规则和人工分别承担什么责任。

本期公开内容不披露具体客户、内部系统地址、供应商、成本、报价和业务容量。产品化可以讨论方法，敏感经营数据仍然留在授权范围内。

下一段进化的完成标准

从脚本到产品，不以“页面更多”或“模型更强”为完成标准。

更可靠的标准是：客户提交前得到清楚指引，审核人员获得带证据的预审结果，系统能够管理队列与失败，能力可以组合到新险种，供应商变化不会破坏业务流程，而所有高风险和最终决定仍然回到人工。

理赔 Claw 的下一段进化，不是让 AI 更像一个独立理赔员，而是让整条理赔服务链路更清楚地知道：什么可以交给机器，什么必须保留给人，以及每一个结论怎样被追踪和复核。