实习日志 / 中文 / 基于旅程的研究 / 字母表背错了：我们的客户经理不懂真实的报案

字母表背错了：我们的客户经理不懂真实的报案

中文 | English

现在我们的报案流程有大问题。具体来说，我们要的客户经理现在已经实现了，但是这个客户经理的知识是错的，就像一个人从小就被教育字母表的顺序是 qazwsxedcrfvtgbyhnujmikolp，但这实际上从根源上就是错的。但是我们的系统也没错的这么离谱，只是没有一份真实的认知：一个人出了事故后，到底第一反应是什么，传统报案的痛点在哪里，报案本身的痛点又在哪里。

这是 9 月底我交给 Agent 的一段话。那时报案 agent 已经能顺畅地聊天、抽字段、判断险种，看上去像模像样。让我写下这段话的，是 Sprint 4 的展示。

Sprint 4 的那次展示

那是去 AWS 办公室之前最后一次常规的 sprint presentation。导师看完 demo，指出理赔流程必须贴近真实的理赔机制：界面做得再完整，业务逻辑不真实，产品就立不住。

导师举了几个真实理赔里的例子。车被追尾，现实中先要记下对方的车牌、驾驶人和保险公司；有人受伤，通常会有警察介入、出警方报告；责任在谁，决定了客户要不要付免赔额。我们 demo 里的表单和流程，这些一样都没有。只演示"出事以后直接提交理赔"，跳过了真实业务里必经的步骤，这个场景本身就站不住。

导师建议我们尽快补做调研，去问保险从业者和真的理过赔的人：理赔时到底会问什么，哪些信息必填，哪些可以拿警方文件代替，不同保单、不同责任下有什么区别。先弄清理赔流程到底怎么运作，否则做出来的只是一个看起来像理赔的界面。

翻出最初的调研

其实项目早期我们做过一份调研，基于 State、Tower、NZI、Westpac 公开的理赔流程，建了一条报案的现状基线：

事故或损失发生
→ 确保安全并收集初始事实
→ 选择报案渠道
→ 核实报案人、客户和保单
→ 确定理赔类型并进入对应路径
→ 提供核心事故信息
→ 回答理赔特定或事件触发的问题（视情况）
→ 上传照片和支持文件（视情况）
→ 确认声明并提交
→ 创建理赔并生成理赔编号
→ 完整性检查与初步分类
→ 分流：标准案件人工审核 / 满足规则自动处理 / 特殊案件交给经纪人、评估师、维修方或专家

它还整理了一张常见报案字段的分类表，从报案人、保单、事故、时间、地点、损失，到车辆、驾驶人、第三方、目击者、警方、受伤、道路天气、房屋、物品、盗窃、声明，每一类都标了是核心字段、视情况的字段还是某类理赔专属。

拿这张表去对照当时系统的字段注册表，一下就看出缺口在哪：

那份调研还有一节讲竞品的一个普遍弱点：Agent 转人工时上下文丢失。它引了几项外部证据，比如 Salesforce 的研究说 56% 的客户常常要向不同的代表重复解释，并把"转人工"的连续性分了三级：能不能找到人；原会话是否保留、不用重新验证身份；人工是否拿到完整的对话、结构化字段、附件、已完成的步骤、缺失项和转接原因，能从中断点接着做。只有第三级才算真正避开了这个弱点。调研也写清了证据边界：这是行业的普遍现象，但具体哪家竞品有没有这个问题，必须靠直接测试或访谈验证，不能张冠李戴。

对照下来，痛点其实有两层。第一层是传统报案的痛点，比如转人工时上下文丢失，调研里有外部文献支撑，但我们自己的系统有没有这个问题还没测过。第二层是报案本身的痛点，也就是出了事的人第一反应是什么、心里是什么状态，两份材料里都没有证据基础。

所以导师说的是对的。我们的系统把"顺畅地完成一段对话、提取安全相关的事实、判断险种"当成了报案的终点，可真实的报案需要这些字段去支撑一连串判断：认定责任、计算免赔额、联系对方的保险公司、核验警方文件。问题出在数量之外，"漏了几个字段"只是表面，根子在我们对"一次真实的报案要采集什么、为什么采集"的认知模型本身有缺口。

三个深挖的问题

9 月 28 日，我在这份诊断的基础上又追问了三个更具体的问题，都要求对着代码回答，不凭印象。

一、Agent 作为统一入口，三种场景该怎样开始？ 当时险种完全交给模型从文字里判断，入口就是一个纯聊天输入框。结论是可以在输入框旁边加三个很轻的场景提示（车辆事故、房屋损坏、财物受损），点了就把对应的文字放进第一句话里，不阻塞直接打字。这只是给模型一个可选的强信号，不改变模型自己判断险种的机制。

二、客户想走保险，定责和定损怎么处理？Agent 该不该给建议？ 查下来，保单条款本身就写死了权限边界：责任是专业决定，永远不由 Agent 决定；Agent 只能收集事实、找出缺的明细或证据、引用条款原文，保障是否适用、责任、批准或拒赔、有争议的免赔额、赔付决定都必须交给员工。这条边界在提示词的权限和安全部分反复重申，是故意设计的红线，不是遗漏。现有唯一的自动信号，只在保单检索本身失败时触发，和案情判断无关。如果要让 Agent 给出"对方责任更大，比例大概一九开"这样的初步建议、由员工裁决，需要一种全新的提议类型，复用员工对信号做确认、驳回、覆盖、解决的四态裁决流程。这不违反红线，决定权仍在员工手里，只是把一个"哑传话筒"升级成"带草稿的传话筒"。但它是全新的设计，不是现成的能力。

三、基本信息覆盖得怎么样？ 时间、地点、人物、起因、经过、结果这六要素，字段注册表里其实都有，只是必填的时机分散在各个状态里，没有在入口统一问一遍。个人资料只有身份和联系方式；车辆的品牌型号存在"我的资产"里，是客户自愿保存、可选带入的；保单只存了一个不透明的保单号字符串。当时我的结论是：就算客户存了保单号，Agent 也算不出真实的免赔额，系统根本不知道这个号码对应哪种保单、哪个档次、多少免赔额，卡点在数据模型缺一张"保单号到具体条款和免赔额"的映射表。

这个结论，第二天被证明是错的。下面会讲。

正确的流程该是什么样

9 月 29 日，我让 Agent 换一个方向：不再顺着"找缺口"往下推，先独立地想清楚正确的流程是什么样，再拿外部资料印证。它先纠正了两处之前被带偏的假设：

自由文字的入口本身没有错。 行业的报案话术培训反而强调，受惊的报案人会先讲事情经过，好的做法是先让对方讲完，再补齐保单细节，不要一上来就拿一个分类菜单堵住对方。所以场景提示只能是"可选的便利"，不能理解成"入口设计有问题要大改"。

案件编号的发放时机，我们其实做对了。 对话一开始、还没收集任何字段，系统就已经分配了编号；最后提交给下游理赔服务的是外部的理赔单。这和行业实践一致：理赔编号应该在第一次接触时、凭最少的信息签发，不该等信息收集完整。这一条不该算进问题清单。

然后从报案人的角度写了七条"应该是什么样"：

1. 打开页面不用先点分类菜单，能立刻把刚发生的事像打电话给真人客服那样说出来，不被结构打断；
2. 从第一句话起，系统就主动确认"你现在安全吗、有没有人受伤"，真实的客服话术把安全排在最前面几项，不会排在车型之后被动记录；
3. 我讲的经过会被复述确认，比如"我理解你是在某某路口被追尾，是这样吗"，不要立刻抛下一个填空题；
4. 不用我问，从第一句话起就知道报案已经生效、有一个编号；
5. 提到"对方也有责任""有人看到了"时，会被追问下去：对方的姓名、车牌、保险公司，目击者的联系方式。这些信息此刻最容易拿到，晚了就没了；
6. 我问"这次我要自付多少钱"，能得到针对这一张保单的具体数字，听到的不能只是一段通用条款的朗读；
7. 结束时清楚地知道接下来会发生什么、谁负责、大概多久；如果转人工，知道为什么转。

从客户经理的角度看，真实的客户经理接电话时心里有一张隐形的优先级表，但不会照本宣科念问题：先让对方讲完，边听边勾哪些已经有了、哪些还缺，讲完再用几个精准的问题补缺口。我们按优先级补问的机制方向是对的，差的是安全检查应该更靠前、更主动。真正的差距在客户经理的专业输出上，有两层：给客户的具体数字（一查保单就知道免赔额、保障范围和档次），和给理赔员的初步判断（转交前带一句"听起来对方责任更大，但需要你确认"，给同事一个起点，不要只递过去一张空表）。

权限边界不放开。不能判定保障、责任、欺诈和赔付，是保险行业对 AI 下判断的真实监管顾虑，不是产品失误。正确的设计是让 Agent 主动做安全确认、听完经过再精准追问、给出针对保单的具体数字、形成可核实的初步判断交给人、转人工时把原因说清楚。这五件事里，当时只有"按优先级追问"一件做对了。

一个被我写错的判断

同一天，负责后端的队友提交了一份字段补全的请求，要在一个正在进行的 PR 里把字段从 28 个补到 52 个，涵盖第三方财产、受伤人数、防损措施和保单关联。我逐条核实以后，写了一份确认和授权。

核实是固定在对方给的两个提交上做的，不凭印象：用 git worktree 分别检出 main 和 PR 的最新提交，直接数字段注册表，main 是 28 个，PR 是 52 个，差 24 个，和请求里报的一致；跑了对方给的测试命令，65 个通过，也一致；抽查了请求里列的"main 上已有"的两条，都原样存在，没有夸大。请求里报了一个"只提供对方保险公司时返回 500"的问题，我在 PR 上定位到了比请求里写的更深一层的根因：请求模型的校验器把保险公司名称、保单号、理赔号也算进"至少提供一项"，存储记录的校验器却只认姓名、电话、邮箱、车牌四项，请求被放行，存储层直接拒绝，于是 500。这是请求层和存储层校验规则不同步的典型例子，我建议把它写成回归测试，而不只是修掉。

核实的过程中，我发现请求里列出的保单字段里有免赔额、币种和保障项目，这直接推翻了我自己前一天写进一个 issue 的判断。我当时只查了账户里那个裸字符串的保单号，就断言系统根本不知道这个号码对应什么保单。补查完整的链路以后才知道：报案时，系统会拿客户确认过的保单号，通过保单查询的适配器查回带免赔额、币种、保障项目和生效日期的保单事实。这是一条已经端到端接通的真实机制。

真正的缺口要重新表述成两层：一是目前只有模拟的适配器，没有接真实保险公司的系统，这一点本来就不在这次的范围里；二是保单事实里只有一个笼统的免赔额，可条款里写的是驾驶人、年龄、用途等多种附加免赔额可能同时适用，这个粒度够不够用，正是那份请求要解决的。

我在回复里专门写了一节"一个需要我主动纠正的地方：我自己此前的判断错了"，然后去改了那个 issue 的描述，把"数据模型不存在"改成"模拟适配器加粒度不足，需要和这位队友的保单关联工作对齐，不重复建模"。

授权的写法我也想得比较清楚。在不越过几条已确认边界的前提下（不做定责、免赔额裁决和最终赔付，不接真实保险公司的接口，不改 Agent 的对话策略），字段命名、枚举取值、记录结构、修复顺序、要不要新增字段还是扩展现有记录、要不要拆小 PR，全部由这位队友自己决定，不需要再来找我确认，这份回复本身就是授权记录。唯一需要回来同步的情况，是在实现中发现必须扩大到"本次不纳入"的范围之外，比如非得改 Agent 的对话策略才能让某个字段真正被用上。原因跟权限无关：那部分工作归我负责的几个 issue，我需要知道，免得两边重复做。最后我也写明了自己这边会做什么：改我那个 issue 的描述，不在对方的 PR 和 issue 上做任何改动或评论，那是对方的工作。

两天下来

导师那盆冷水，让我们把系统和真实的报案流程摆在一起看了一遍。结论比我预想的更深：问题不在少了几个字段，在于系统对"一次报案要采集什么、为什么"的理解是错的，就像背错了字母表。

但这两天里同样重要的，是我自己的一次纠错。我对"系统算不出免赔额"的判断，建立在只看了一处代码的印象上；队友的请求逼着我顺着完整的链路查下去，才发现那条机制早就接通了。核实要固定在具体的提交上做，结论要能经得起完整链路的检验，而发现自己错了，就在写给对方的那份文件里直接写出来。