企业官网建设流程全解析

先说实话：我一开始听人聊“保险理赔 Agent”，脑子里浮现的也是一套“大模型看照片、直接出定损单”的神奇系统。真到自己动手才发现，重点根本不在模型有多聪明，而在怎么把影像识别、定价规则、配件库、人工审核这些零散能力装进一个可靠的工作流里。这个装法，就是我们说的 Harness。

这篇文章想聊的，就是我从零搭一套自动化定损 Harness 的完整思路：为什么先拆业务流程、管线怎么分层、定价环节有哪些坑、防欺诈为什么不能依赖模型、上线前数据口径和灰度策略怎么定。不堆理论，都是实际跑通过、也踩过坑的经验。给正在做理赔系统改造、或者打算用大模型做业务自动化的团队做个参照。

1. 定损业务的真实堵点：为什么人工流程会把理赔时效拖垮

1.1 传统定损的五个环节和各自的时间黑洞

定损在保险业务里很少单独存在。一次车险理赔，从客户报案到赔款到账，通常要走报案登记、资料收集、损失核定、维修方案确认、复核支付这几个环节。定损这个动作，卡在资料收集和维修方案确认的中间，是整条链路里最耗时、也最依赖老师傅经验的一环。

我见过太多理赔员的日常：早晨打开系统，发现昨天夜里涌进十几个案件，每个案件挂着十几张现场照片，有的是手机拍的，有的是行车记录仪截的，甚至还有模糊的监控截图。他需要一张一张看，先判断受损部位，再对照保单确认哪些属于赔付范围，然后凭经验估一个维修金额，再写一段结论文案。这套流程跑下来，一个熟练理赔员一天能处理的案件量非常有限，而那些刚入职不久的新人，常常连“这个保险杠该修还是该换”都拿不准。

时间黑洞主要集中在三处：

• 照片整理和筛选。现场照片没有固定规范，角度、亮度、拍摄距离千奇百怪，人工要先理解“拍的是什么”，才能判断“坏成什么样”。
• 维修方案的判断。定损不是简单的“坏了赔钱”，要区分剐蹭、凹陷、开裂、碎裂，要判断损伤是否涉及结构件，还要考虑原厂件和副厂件的差别。
• 金额校验。系统里虽然有配件价格库，但实际定损时很容易出现工时费虚高、重复报价、超范围维修等问题，复核人员得逐条核对。

1.2 Agent 真正值得介入的三个切入口

很多人把 Agent 想得很玄，其实落到业务上，它就是一段“能自己调用多种能力的自动化决策流程”。对定损来说，最值得做的不是让模型直接输出“赔多少钱”，而是把上面三个人工环节拆成机器擅长的事：

第一个切入口是影像的规范化整理。让视觉模型先做质量过滤、场景分类、损伤区域定位，把几十张混乱的照片变成一组“部位+损伤类型+置信度”的结构化信息。

第二个切入口是标准化损失描述。把视觉模型的输出交给语言模型，生成统一的报案摘要和损失说明，理赔员不用再从头看一遍照片。

第三个切入口是规则化校验。把定价和审核规则变成可配置的流程节点，Agent 自动对照保单条款、配件价格库和维修标准，发现异常直接弹给人工。

我当时的判断是：这三个环节一旦打通，理赔员就能从“看图写作文”里解放出来，只处理模型不敢拍板的高风险案件。响应时效、审核一致性、人力成本三个指标都会同步改善。

1.3 为什么叫 Harness 而不叫“模型”

这里我要强调一个容易混淆的概念。我们搭的是定损 Harness，不是简单部署一个视觉模型或语言模型。Harness 的本意是“装配架”，放在软件工程里，就是一套把模型、规则、数据源、人工审批串起来的执行框架。

模型负责感知和生成，规则负责约束和校验，工作流负责调度和兜底，审计日志负责留痕。缺少任何一层，系统都很难真正落地。我也见过团队直接拿开源大模型接图片输入，让模型自由发挥写定损意见，结果输出格式千奇百怪、金额张冠李戴，这样的系统根本没法进生产环境。

所以下面我讲的整个方案，都围绕“如何搭一个让模型在规则边界内高效工作的 Harness”展开。

2. Harness 的管线设计：从“一堆照片”到“结构化损失清单”

2.1 整体流程分六段，节点间只用结构化数据传递

我习惯把定损管线拆成六段：影像采集与质检、车辆信息识别、损伤检测、方案生成、价格计算、审核输出。每段可以单独替换算法，也可以独立开关。

管线跑起来以后，节点之间传递的不是自然语言，而是一份统一的 JSON 结构。打个比方，影像检测节点之后，输出的不是一句“前保险杠有损伤”，而是：

{ "panel": "front_bumper", "damage_type": "crack", "severity": "medium", "bbox": [152, 310, 480, 420], "confidence": 0.92, "image_id": "claim_20250110_A002_03" }

这个设计的核心原因只有一个：可控。自然语言的自由度太高，下游的价格计算和规则引擎无法稳定依赖。先让模型吐出结构化字段，再由语言模型基于字段生成人类可读的报告，这样无论模型怎么换，定价模块的输入格式永远稳定。

2.2 影像质检这一步，很多人会忽略它的重要性

定损系统的准确性，一半取决于模型能力，另一半取决于输入质量。照片本身就是歪的、糊的、反光的，后面的流程做得再好也是白搭。所以我在 Harness 的第一段专门放了一个影像质检节点，做以下几件事：

• 清晰度检测。低于阈值的图片直接退回，并自动通知客户重新拍摄。
• 场景有效性判断。区分“事故现场照”“车身局部照”“行驶证证件照”，避免把无关图片误送入损伤检测。
• 敏感信息剥离。移除图片上的 GPS 坐标、人脸、车牌等隐私信息，只保留业务需要的视觉特征。这里要特别提醒，很多隐私问题不是模型造成的，而是原始数据本身带进来的。
• 多角度覆盖检查。结合车辆识别结果，判断上传图片里是否包含了前、后、左、右等多个角度，缺角度时自动提示补拍。

这些逻辑不复杂，但能显著降低后续模型出错率。我做过一个统计，加入自动质检后，损伤检测的误报率下降了大约三成，主要就是滤掉了反光、失焦和无关背景。

2.3 损伤检测节点：边界框、分割蒙版和分类标签缺一不可

损伤检测节点是整条管线的感知核心。只输出一个“车坏了”的结论没有任何价值，我们要的是结构化位置和程度。

具体做法是让视觉模型同时完成三件事：

• 目标检测。用边界框示意损伤在图片中的位置。
• 语义分割。细化到“保险杠左侧”“翼子板下部”这类区域级粒度，方便后续匹配配件编码。
• 分类标签。区分剐蹭、凹陷、开裂、碎片脱落等损伤类别，以及轻度、中度、重度的程度分级。

分类标签要跟业务端对齐，不能拍脑袋写。比如“开裂”在维修语境里通常意味着更换，而“剐蹭”大多走修复。如果模型把开裂识别成剐蹭，后面生成的定损金额就会差出一大截。

检测节点跑完，就会生成一份损失清单的“毛坯版”，包含所有被识别出来的部位和损伤属性。还没到定金额的程度，但理赔员看起来，脑子里已经对“这是个什么案子”有画面了。

2.4 语言模型在这里的角色：不是裁判，是文书

管线里我安排了一个语言模型节点，但它承担的并不是定损决策，而是把结构化字段转译成标准报告。比如：

输入是上面那个 JSON，输出可能是：

经检测，本案车辆前保险杠中部存在一处中度开裂损伤，建议维修方案为更换前保险杠面罩，需同步确认是否存在内部支架变形。

这步的意义在于，理赔员和客户看到的报告是自然语言，但机器关心的字段一个不少。语言模型还能帮客户写报案摘要、自动回答“下一步需要做什么”的说明文案，这也是提升体验很直接的一环。

不过要强调，语言模型的输出必须基于上游结构化字段生成，不允许它自行编造损伤部位或金额数字。在 Lite 引导词里写死“只允许描述输入 JSON 中已有的信息”，生产环境里很管用。

3. 定损估价：维修方案和金额怎么算，各方才会认

3.1 “修还是换”是估价的第一道选择题

定损金额的大头往往不是工时，而是配件费用。所以估价的第一步，是判断配件走“维修”还是“更换”。

这个判断依赖下面几个输入：

这三个前端输入交叉分析后，定损 Harness 会生成一个“建议方案”，但这里不能直接拍板。我见过最坑的情况是：模型看到保险杠开裂就建议换总成，但实际上原保险杠壳体可以单独更换，且成本远低于总成。这就要求规则引擎里必须配置配件层级映射，细分“总成、面罩、骨架、支架”等子件，而不是把所有情况都推到总成。

3.2 金额计算的本质是把人工定价逻辑程序化

定了修还是换，下一步才是金额测算。这部分的核心逻辑并不神秘，就是把理赔员的经验变成规则：

• 配件费：以本地化配件库的价格为准，原厂件、品牌件、副厂件分档录入。
• 拆装工时：按车型维修手册的标准工时乘以实时单价。
• 喷漆费用：喷漆面积结合漆面类型和颜色覆盖率计算。
• 旧件残值：更换件在部分险种下需要扣除残值。

这些计算如果直接让模型完成，数字很容易飘。实际做法是设置一个专门的定价引擎，由规则驱动，所有价格数据从库里查询。Agent 只负责传递配件编码、工时用量、喷漆面积这些键值对，不直接参与乘除。

这里分享一个教训：初期我图省事，让语言模型直接输出最终金额，结果模型把“某车型前门喷漆工时费”和“某车型前门总成价格”混在一起，生成了一份离谱的报价单。后来改成下图这种规则引擎算价、模型只做校验解释的结构，再没出过类似问题。我这里说的“下图”其实没有图，就是一条铁律：数字计算永远交给程序，不交给概率。

3.3 自动放行阈值：把低风险案件交给机器，高风险留给人工

即使规则引擎可靠，我也不会让系统对所有案件自动定损。成本上不划算，风险上也不可控。

通常我按金额和风险把案件分成三类：

• 自动通过：金额低于设定阈值、损伤类型简单、维修方案明确。比如轻微剐蹭单面喷漆，系统直接出单并通知理赔员复核。
• 人工审核：涉及结构件、涉及更换总成、金额超阈值、或者图片质检不过关的，自动分配给人伤定损员。
• 自动退回：明显超出保单责任范围、或涉嫌篡改图片的，直接退回并触发预警。

这个分而治之的思路，比追求“完全自动化”现实得多。我见过好几个团队非要让系统处理所有案件，结果复杂案件的坏口碑拖累了简单案件的好体验。把 70% 的简单案件自动化，剩下的 30% 沉淀给人工精耕，反而整体效率提升最明显。

4. 规则闸门与反欺诈：Agent 身边必须有一道“紧箍咒”

4.1 反欺诈不是模型的活，是规则引擎的活

不少人在打磨视觉模型上花了很多功夫，却忽略了定损环节最常见的欺诈风险，根本不是靠看图片能发现的。

举个很常见的例子：同一辆车在短时间内反复出险，每次事故的照片虽然不同角度，但细节高度相似；或者理赔人上传的事故照片和信息填报时间前后矛盾。这些问题从单张图片看不出毛病，必须在跨案件数据里找关联。

我在 Harness 里设置了一组规则闸门，跑在所有环节之后、审核之前：

• 报案频率检查。同一投保人、同一车牌在过去一段时间的出险次数超限时自动标记。
• 照片重复度检查。计算当前案件照片与历史案件照片的感知哈希相似度，异常相似直接进入人工排查。
• 损失部位一致性检查。比如上一案修的是左后门，这次报案又说左后门受损，且相隔时间很近，就需要关注是否重复索赔。
• 图像元数据异常。删除 GPS 之后仍然记录拍摄时间，时间与报案时间段严重不符的，进入风控队列。

这些规则没有任何一条依赖大模型的“推理能力”，全部是确定性逻辑。但它们能挡掉的案件量非常可观，因为很多时候欺诈者的手法并不精妙，只是在量大时不被注意到。

4.2 合规兜底：让每条决策都可以回放

保险作为强监管行业，尤其重视决策可解释性和数据完整性。我在设计 Harness 时，把“过程留痕”当做一个硬需求，而不是事后补加的日志。

具体来说，每个案件会生成一份完整的决策档案，内容包括：

• 输入的原始照片和清洗后的照片；
• 每个模型节点的输出结果和置信度；
• 定价引擎使用的配件编码、工时单价、计算过程；
• 命中哪些规则、被哪个规则拦截；
• 人工审核人的操作记录和修改理由。

这种设计在争议处理时特别好用。客户质疑赔偿金额不合理，我们不需要重新找人看照片，直接把整条决策链调出来，对应到是哪个环节、哪条规则、哪个数据导致的最终结果。对内部来说，也很容易复盘 Agent 到底在哪一步开始跑偏。

4.3 人工介入点要“早设”而不是“后补”

很多做自动化的团队有个惯性：系统先跑，跑完了再让人看结果。这个反馈链路太长了。

我现在的做法是在管线里早早埋下人工介入点。比如损伤检测节点发现图像不清或视角不足，直接挂起等补拍；规则闸门命中高风险标记，案件直接跳过价格计算的等待队列，优先派给审核人。也就是说，机器先做粗筛，人类在处理疑难时只看到机器已经整理好的半成品，不需要从零看一遍证据。

这样安排，人工审核的负担能减轻很多。而且对理赔员来说，系统不是“抢饭碗”，而是帮他们把脏活累活先干完了，这种协作模式比单纯让模型全自动更容易获得业务部门的配合。

5. 上线前必须解决的三件小事：数据口径、灰度路径、效果度量

5.1 标注口径不统一，模型训练多少次都是原地打转

定损模型的微调效果，很大程度上不取决于训练轮次，而取决于标注数据的一致性。我踩过最深的坑，就是同一个损伤在不同标注员手里被打上了不同的标签。

有人把“需要钣金修复的凹陷”标成“中度剐蹭”，有人把“保险杠面罩轻微碎裂”标成“保险杠总成损坏”，模型学到的全是噪音。

所以项目一开始，就要建立一本标注规范，里面至少要写明：

• 损伤类别的最小像素面积和边界，低于多少不算损伤。
• 同区域多重损伤时如何切分，是合并一个框还是拆成多个类别。
• 哪些边缘情况必须标注“待人工确认”，禁止硬猜。
• 上传图片的拍摄角度、距离、光线要求，标注数据应与线上真实数据分布一致。

这个规范最好邀请有经验的定损员一起制定，而不是纯算法团队自己写。定损员知道什么是“轻微、中度、重度”的真实业务边界，算法团队如果闭门造车，标出来的数据再漂亮也没法用。

5.2 先跑影子模式，再灰度放量，最后才谈自动支付

再好的实验室指标也不能代替线上复杂场景的考验。我把上线路径拆成三个阶段：

第一个阶段是影子模式。系统只跑分析，不对外输出，也不影响真实理赔流程。唯一的任务是积累一批“机器定损结果 vs 人工定损结果”的对照样本。这一步能暴露出大量问题，比如某些车型的配件库里根本没有对应编码，某些区域照片始终无法触发损伤检测。

第二个阶段是人工建议模式。系统把定损报告作为建议推送给理赔员，理赔员可以一键采纳，也可以全部推翻。这个阶段开始收集采纳率，同时让人工反馈“为什么否决”。我通常会每周拉一次否决原因清单，把高频问题直接提到迭代会上。

第三个阶段才是部分自动放行。限制金额上限，限制损伤类型，只处理最简单的那部分案件。同时保留随机抽检比例，防止模型在无人注意的时候悄悄漂移。

5.3 效果度量，别只盯着“准确率”一个数字

衡量定损 Harness 的效果，我一般用五个维度同时看：

• 人工审核率：多少案件完全不需要人工介入。
• 建议采纳率：人工审核模式下，理赔员采纳系统建议的比例。
• 定损时效：从照片上传到结果输出的端到端时间。
• 金额偏离率：机器结果和人工复核后最终赔付金额的差距。
• 争议率：客户或维修厂对定损结果提出异议的案件比例。

只盯着准确率是很危险的。准确率高，可能只是因为系统只处理了最简单的案件，实际业务价值的提升被掩盖。更合理的做法是，在灰度期间按案件类型分别统计这几个指标，每个类型单独决策是放量还是收紧。

5.4 一个容易被忽略的细节：给客户的文案要有人味

最后说一个很容易被忽略的细节。Agent 算完账之后，如果不经过包装就把“您的前保险杠开裂，建议更换，金额 3200 元”这样冷冰冰的文本发给客户，体验会非常糟糕。

我会在整条流水线的最末端加一个“话术生成”环节，同样是语言模型，但它只负责根据结构化结果生成温和、清晰的告知文案，包含下一步操作指引和人工客服联系方式。必要时还会主动附上一句“该结果由系统辅助生成，已同步理赔专员复核”，既满足告知义务，也减少不必要的对质。

这个细节看起来小，却直接决定了用户面对自动化的第一印象。系统越智能，越要在对外沟通时保留必要的温度。

做这套 Harness 的整个过程，让我最深的体会是：定损自动化的难点不在“让机器像人一样判断”，而在于把判断过程拆成机器能稳定执行的动作，再配一套兜住意外的规则和流程。模型会迭代、数据会变化、业务口径也会调整，但分层清晰的管线、明确的数据口径和稳妥的灰度路径，才是这套系统能走远的地基。如果让我给正准备启动类似项目的团队一个建议，那就是别急着追求全自动，先把影子模式跑透，把人工和机器的边界画清楚，后面的事会顺很多。