实习日志 / 中文 / 实习 Journal / Journal 4：成果、反思与知识应用

Journal 4：成果、反思与知识应用

一、项目成果

项目概述

Northwind FNOL Agent 为保险公司处理事故发生后的第一次报案（First Notice of Loss，简称 FNOL），题目设定的保险公司是 Northwind Insurance。客户用自己的话讲述发生了什么，系统负责把它整理成带来源、可核实的理赔记录，并一路推进到下一个安全的步骤；理赔员工接手的是同一份记录，不必再向客户问一遍。项目由两个相连的关键功能构成：一个根据客户处境自适应的报案入口，和一份由客户、员工与外部服务共用的理赔记录。

功能与规格

系统分为客户端、agent 与运行时、员工工作台、知识与外部服务、管理与运行五个部分。我负责 agent 的行为与提示词、运行时里上下文的装载与权责划分、客户端体验，后期加上分流的判断条件、待答清单和案件面板；同时作为仓库的维护者，制订每个迭代的目标和任务，维护团队的协作规范。10 月 8 日，项目冻结并在 poster presentation 上向业界评委做了展示。

客户端。 客户可以不登录就开始报案，用文字或语音描述事故；案件可以跨会话继续，隔几天回来也能接着办。报案表单随着客户的描述长出来：从所有理赔都需要的几栏开始，说到追尾，长出车辆相关的栏目，提到有人受伤，再长出受伤相关的栏目，覆盖车险、房屋险和财物险三类。每条事实都记着出自客户的哪句话和确认状态，客户可以直接核对和修改。系统接收照片和 PDF，读出文件类型和关键信息，例如报价金额；材料暂时没有，只挂起依赖它的步骤，报案照常往下走。客户问到保单条款，回答附上条款出处；系统答不了或不该由它答的事，交给理赔团队，客户这边显示在等谁。提交前客户核对摘要，提交后得到案件号和下一步。

agent 与运行时。 模型负责理解客户和组织语言，运行时负责事实、权限和流程。模型的每次输出只是建议，经运行时校验后才执行，建议、批准和实际结果分别记录。字段、分支和案件阶段是带版本的有限清单，模型只能在清单之内提出内容；送给模型的上下文按险种和任务分层装载。出现人身危险的信号时，运行时在调用模型之前就中断常规流程，转交人工。模型接入是独立的一层，可以使用云端服务，也可以使用部署在团队服务器上的本地模型，每个会话可以选择。

员工工作台。 提交后的案件进入员工工作台，按固定的条件分为 Fast-track、Standard 和 Complex 三档，并写明理由；客户补交新材料后重新计算。员工接手时，先看到客户留下的待办和待答的问题，带着完整的上下文继续，不必重新询问。单据之间对不上的地方，例如收据的购买日期晚于失窃日期，作为提醒交给员工，由员工判断，系统不下欺诈的结论。

知识与外部服务。 保单条款进入带版本的知识库，检索时按险种、版本和生效期过滤。维修预约、车损评估、拖车等外部服务在同一份案件里收到请求并回传结果，客户同意之后才共享信息。

管理与运行。 提示词、模型档案、各类清单和知识库通过管理端带版本发布，运行时只引用已发布的版本，每一轮对话用的是哪一版可以事后查到。后端用 Python（FastAPI），数据存放在 MongoDB，文件放在对象存储；客户端、员工工作台和管理端是三个独立的 React 前端，其中客户端和员工工作台共用一套设计规范。部署目标是 AWS，模型接入已有 Amazon Bedrock 的适配。

二、反思：我从项目中学到了什么

先懂业务，再做设计。 项目开始时，我们直接动手设计产品，界面、流程和系统接口都先于对理赔业务的了解。保险公司现在怎样接报案、报案要收集哪些信息、已有哪些欺诈核查，这些调研是之后才补上的，本应在设计之前完成。随后对客户端和员工端做了一次完整检查，发现的每条问题背后都是一处界面替用户做的想当然的假设，例如落地页有六个入口且没有主次，页面上挂着一个实际流程装不进的"第 1 步，共 3 步"进度条。阶段性展示中业界评委的意见指向同一个方向：理赔流程要贴近真实的机制，只做出一个看起来像理赔的界面，不足以证明产品解决了问题。我带走的做法是，设计任何界面之前，先能说出每个元素回应的是哪条经过调研证实的事实。

设计永远以用户为中心。 好的体验要站在用户的位置上去检验。一方面，只有在真实浏览器里把系统从头走一遍，才能以用户的视角发现我们的设计到底哪里有问题；另一方面，我们的用户旅程经历过一次推翻重来，因为从sprint和presentation的feedback中我们才发现我们的设计与真实情景其实是脱节的。我由此养成的mindset是，评价任何功能，先把自己放进用户当时的处境里走一遍；做任何功能的时候，也先把自己当成用户，思考自己真正想要什么。

团队合作中的沟通。 五个人各做一块，沟通让各自的工作能接到一起：接口两边的理解一致，问题在还容易改的时候被发现，返工少。我学到的做法主要有两条。一是把话说完整并且写下来，开头就讲清现在的情况、需要对方做什么、什么时候要，对方读完就能回应，书面的内容也可以反复核对。二是说具体的事，反馈时指出哪里不一致并附上证据，出了问题尽早说，越早，大家能调整的余地越大。同一件事对不同的人讲法也不同：对队友讲到接口和字段，对评委和导师讲到价值和结果。

与人共事。 共事的难点在于每个人手里的信息和背景不同：队友有的熟悉后端，有的做数据，有的做员工端界面，对同一句话的理解会不一样。我学到的是，先弄清对方的目标和约束，再谈方案；把前因后果讲到对方能直接接上。分工上，边界和接口先一起说定，各自范围内的做法尊重负责的人的判断，需要跨边界时先沟通再动。对待意见，无论来自队友还是自己的复查，都先当作一个要验证的说法；发现自己错了就当场承认并更正，因为留着一个错的判断，后面接手的人会照着它做。

阶段性调研。 调研要跟着项目的阶段反复做，每一步都应当先有充分的调研作基础。调研的对象包括业内的成熟经验、真实的数据和资料，目的是先弄清用户真正的痛点和设计上真正的难点，再定方向。资料也要分级：厂商对效果的宣称只当产品说明，样本小的调研结论只用来排优先级，公开评论只当个别例子。外部的意见和自己最初的设想，同样要放回证据里检查之后再采用。

三、所学知识在实习中的应用

软件工程。 软件开发的基本流程依次是需求分析、设计、实现、测试、部署和维护，上一阶段的产出是下一阶段的输入，所以上游的错误会被下游放大，越晚发现，修改的代价越大。软件工具与技术（COMPSCI 732）的课程项目里，我和队友按这个流程完整做了一个软件。实习中它指导我的有两点：发现问题时先判断它出在哪个阶段，再回到那个阶段去改，不在下游打补丁；每个迭代都从需求走到可以验收的结果，测试和集成不攒到最后。

人工智能。 机器学习高级专题（COMPSCI 760）讲模型怎样训练和评估，一个模型的能力只能由它在评估数据上的表现来说明。这指导我在项目里用完整的报案过程来评估模型，只看最后一句回答会漏掉中间的越权和错误。健康知识管理（DIGIHLTH 702）讲知识怎样被组织、更新和治理，让我把保单条款当作要治理的知识来对待：带版本，有生效期，知识库没有的条款，系统如实交给理赔团队回答。

以人为中心的设计与研究。 人机交互高级专题（COMPSCI 705）讲的实验设计、访谈和定性分析，指导了我们最初的探索性研究，包括问卷调查和用户访谈。这门课也教了怎样做知情同意：研究开始前，向参与者提供参与者信息表和知情同意书，说明研究的目的、数据怎样使用，参与是自愿的，随时可以退出。团队的问卷也是这样做的：匿名、自愿，调查前有参与说明。

安全、隐私与伦理。 可用安全与隐私工程（COMPSCI 725）让我在设计时先问：这个系统可能被怎样滥用，客户的哪些信息会被送到哪里。项目处理的是事故、受伤、照片和保单这类个人信息，这个问题落到了两处设计上：模型可以换成部署在团队自己服务器上的本地模型，客户的信息不必送到境外；欺诈提醒只依据单据之间的不一致，不使用年龄、民族、住址这类个人属性。

系统思维。 系统动力学与复杂建模（OPSMGT 741）讲反馈回路、延迟和系统原型，其中"无效的修补"和"局部最优不等于整体最优"两条，给了我一个说法来描述 agent 对话的经历：每一轮修补单看都解决了一个具体的矛盾，叠在一起，回路里却不断产生新的矛盾，对话越改越生硬。要改的是回路本身，做法是回到目标，先定义一次好的报案是什么样，再倒推需要哪些设计决定。