实习日志 / 中文 / 实习 Journal / Journal 3：职业能力与开发过程

Journal 3：职业能力与开发过程

一、工作内容：我负责的工作与得出的设计

产品 agent 的设计

设计这个 agent，首先要回答一个问题：ChatGPT 这类通用模型已经能流畅地对话，为什么不直接让它来接理赔报案？直接使用时，问题很快就会出现：它不知道一起追尾事故的报案需要收集哪些信息，也不知道什么时候该停下来交给人；它会把客户没有说过的内容当作事实写下来，会在什么都没有发生时告诉客户"已经为你安排好了拖车"；它也没有资格决定保障范围和责任。公开的 agent 平台和研究大多面向通用任务，或者零售、航空这类客服场景，理赔的特殊之处落在它们之外：客户刚经历事故，情绪紧张；判断的依据是保单条款和监管要求；一件理赔要持续数天，中间要等警方、评估师这类第三方的文件；保障、责任、欺诈和赔付这类影响重大的决定必须由人来做。

因此，我们的 agent 的领域能力，来自我围绕模型为理赔定制的运行时和提示词。运行时是包在模型外面的那一层程序，负责记录事实、校验权限和执行动作；提示词决定模型以什么身份、看着什么信息工作。这套定制随着产品从原型、MVP 到验证原型逐步成形，每一轮设计都来自上一轮暴露的问题。

原型阶段

原型阶段的目标是先确定产品要覆盖的范围：用一段固定脚本走通从报案到员工处理的完整路径，理解能力留到后面，同时约定演示脚本不能写进产品行为。即使在这个阶段，事实和权限也已经放在模型之外：每一轮对话里，客户的消息、agent 的回复、带来源的字段提议和权限裁决作为一个整体存储；出现伤亡或危险信号时，常规的信息收集立即中断，案件转交人工。一轮对话的意图，用提问、澄清、确认、更新、转人工、创建理赔等八个动作来表达。

MVP 阶段：第一轮调研与设计

进入 MVP 后要接入真实的模型，原型的局限很快显现出来。固定脚本没有理解能力；八个动作把回复方式和状态变化混在一起，一个"确认"既是在和客户说话，也可能在改动理赔记录，两者无法分别校验；不同服务商的模型在接口、能力和隐私条件上各不相同，需要一层统一的接入。为此我做了第一轮调研，要回答的是：一个真正能处理理赔的 agent 应当由哪些部分组成，别人已经证明了什么，还有什么需要我们自己设计。我按证据等级区分来源：官方技术文档可以作为工程依据；能读到代码的公开实现可以用来验证方法和缺陷；看不到内部实现的产品说明，只能确认产品定位；厂商对效果的宣称，一律只按产品说明对待。

第一类来源是成熟的客服 agent 平台。Dialogflow CX 用"页面"表示会话进行到哪一步，由参数收集和重问机制推动对话 [1]；我们借鉴了显式的会话状态和参数预填，同时注意到固定的页面和表单很容易退化成有顺序的问卷，所以在我们的设计里，对话顺序和字段顺序是两件事。Intercom Fin 的 Procedures 把自然语言指令和确定的条件、代码组合在一起，并支持模拟运行和分支回归测试 [2]；我们采用了同样的分工，用自然语言保持沟通的灵活，用受控的条件和工具保证执行，并要求每个分支都有成功、失败和边界输入的测试。Amazon Connect Cases 把案件当作长期存在的工作容器，会话只是进入它的一个入口 [3]，这对应我们把会话和理赔分开记录的设计。Copilot Studio 让模型选择和组合可用的能力，Genesys Agent Copilot 在员工一侧提供下一步建议和交接摘要，Sierra 把目标和约束分开定义；它们分别影响了我们"模型提出候选、系统决定是否允许"的做法，以及员工工作台和转交内容的设计。

第二类来源是保险垂直产品和公开实现。Hi Marley 强调理赔过程中持续的客户沟通，Sprout.ai 把材料抽取、保单核对和欺诈解释做成独立的能力，Five Sigma 围绕完整的理赔视图组织员工的工作，Shift 面向欺诈检测和专业决策辅助，Indemn 强调把保险业务流程和确定性的约束放在模型之外，并保留审计记录。这些公开资料只能证明产品的定位，证明不了内部怎样划定判断的边界，所以我们只从中确认方向：同一份理赔记录要贯穿后续的沟通；欺诈只能作为信号出现；员工工作台围绕理赔状态和待办事项组织。AWS 的无服务器理赔示例用事件和接口把理赔、文件、欺诈、结算、通知等服务连接起来 [4]，证明 agent 可以作为既有理赔系统的入口，领域服务应当保持独立；但示例中的语音 agent 提交之后只能得到"已请求"，最终结果要等界面上的异步通知，客户在对话里无从知道下一步。

第三类来源是流程与基础设施。Rasa 的 flows 只描述业务逻辑和分支，不穷举所有对话路径，字段可以由模型或确定的映射填写，并分别校验 [5]；LangGraph 和 Temporal 提供检查点、中断和持久执行，一个流程可以暂停几天后从记录的位置继续 [6]；Open Policy Agent 把"做出决定"和"执行决定"分开 [7]；Azure AI Search 要求在检索阶段就按用户权限过滤结果，不能先取回再要求模型不说 [8]；LiteLLM 证明多家模型服务可以统一接入；OpenAI 的结构化输出能约束输出格式，但格式合法的输出在业务上未必可以执行 [9]。

综合这些来源，我得出几条判断：模型不拥有理赔状态，它可以理解、抽取、解释和建议，事实和流程由应用掌握；流程图不等于对话脚本，系统需要确定的状态和分支，客户却可以跳着说、随时纠正或暂停；一轮对话往往同时包含回应、记录、查询和安排下一步；转交人工是一项正常能力，它的质量取决于转交理由和上下文是否完整；调用外部服务包括准备、授权、提交、追踪和核实，每一步都可能单独失败；检索到的保单内容不授权任何动作；评估要检查整个处理过程，最后一句回答正确，不代表中间没有越权或重复追问。

据此，我在 MVP 阶段写出了目标设计。模型的每一次输出都只是建议，运行时校验之后形成被批准的计划，执行之后再记录实际的结果，三者分开记录，事后可以查清"模型想做什么、系统允许了什么、最后实际发生了什么"。八个混合动作被拆成六类概念：客户这一轮想做什么，agent 怎样回应，理赔记录要做哪些改动，调用哪些工具，下一步是继续、等待、中断还是转人工，以及实际执行的结果；动作按沟通、理赔记录改动、人工与复核、外部服务、运行控制分为五组，每组有各自的校验和权限要求。保障、责任、欺诈和赔付这类决定只交给人，欺诈只以附带来源的信号出现；员工一侧的 agent 可以用自然语言调用，但只出建议稿，员工确认后才执行。

理赔领域的知识写进运行时里一组带版本的有限清单。字段清单登记每一栏的含义、类型、适用的险种，以及它是当下就需要还是提交前需要；分支清单登记什么样的描述会让表格长出哪些栏目；阶段清单登记案件可以处在哪些状态，以及状态之间怎样合法地转换。模型只能在清单之内提出内容，不能发明新的字段或分支。参考 Rasa 的做法，流程只决定表格能长成什么样，不决定提问的顺序：一开始只有所有理赔都需要的几栏，客户说车被追尾，表格长出车辆相关的栏目，提到乘客受伤，再长出受伤相关的栏目。一句话里可以提取多条事实，每条都记下它出自客户的哪句话，时间保留客户说出的精度；"理赔涉及什么"和"案件推进到哪一步、正在等谁"分成两套状态管理；保单检索的设计要求先按保险产品、版本、生效期和可见范围过滤，检索到的内容只是判断的依据。

模型接入独立成一层，兼容官方接口、中转服务和本地部署的模型。LiteLLM 证明了统一接入可行，但模型的能力、隐私和行为约定要我们自己定义：每个模型档案登记它经过验证的能力，没有验证过的用途不交给它承担。第一次接入真实模型从车辆报案开始，提示词以私人客户经理为原型，语气专业、克制，带版本管理，模型的输出受严格的结构约束。到了验证原型阶段，这套设计扩展到车辆、房屋、财物三类险种，三类的分支互不重叠；团队在自己的服务器上部署了开源模型，通过私有网络接入，每个会话可以选择本地或云端模型，作为客户数据不能交给云端时的备选；提示词、模型档案和各类清单通过管理端带版本发布，运行时只引用已发布的版本，事后可以查到每一轮用的是哪一版。

验证原型阶段：第二轮调研与上下文

三类险种的真实旅程跑起来之后，响应速度成为突出的问题：一句简单的问题，有时要等八十多秒才得到回复。我先让系统记录每轮请求的构成，发现普通回合固定调用两次模型：第一次带着完整的提示词、理赔数据和读取理赔的工具，第二次把这些内容连同读取结果和完整的输出格式再发一遍，合计约九千个 token，是设计上限的三倍多。此外，工具集合每轮变化会让缓存失效，历史对话也只按条数截断。

为了找到成熟的做法，我做了第二轮调研，对象是 12 个系统怎样管理上下文：AI 编程工具 Kiro [10]、Cursor、Claude Code [11]、Codex、Aider [12] 和 Sourcegraph Cody，Anthropic [13] 与 Manus [14] 的工程文章，以及 OpenAI Agents SDK、Google ADK、MCP 和 Amazon Bedrock [15] 的相关机制。几种做法反复出现。常驻的核心内容尽量少，Kiro 按始终装载、按文件匹配、按语义判断、手动引用四种方式决定一段指令何时进入上下文。能力目录和正文分开，Cursor、Claude Code 和 Codex 都只常驻技能的名称和描述，用到时才读取全文，Aider 先给模型一份很小的代码地图，再按需读取具体文件。确定的条件优先于语义匹配，Sourcegraph Cody 同时使用代码之间的确定关系和语义检索，两者不混成一个相似度分数。

历史的处理也有共识：OpenAI Agents SDK 把完整的持久化历史和本轮输入的历史分开，Google ADK 以 token 阈值作为压缩的主要触发条件，消息条数只作辅助。缓存方面，Manus 把缓存命中率当作生产 agent 的关键指标；Bedrock 的缓存按工具、系统提示、消息的顺序生效，工具定义一变，后面的缓存全部失效；MCP 要求工具列表按确定的顺序返回，并把发现、授权和执行作为三个独立的边界。Claude Code 的文档还特别说明，写在上下文里的指令只是指导，需要确定地阻止的操作要交给程序控制，这和我们"提示词不能替代运行时校验"的原则一致。

在这些做法之上，我得出的核心判断是："让模型知道某项内容存在"和"本轮把它的全文发给模型"是两个动作。再细分下去，一项内容被发现、被选中、被装载、被授权、被执行，是五个不同的状态；把它们混在一起，是上下文膨胀和越权的共同根源。优化的目标因此定为：在正确、有权限、可追溯的前提下，让普通回合只调用一次模型，保持高信息密度和稳定的缓存前缀，任何额外的装载都能说明原因、来源和授权边界。按这个判断，我设计了分层装载：少量安全和权限要求每轮都带上，其余内容按当前的险种和任务装载；模型先只看到材料的编号和摘要，需要时再取全文；完整的对话保存在外部，每轮只带上当前理赔的快照、尚未解决的问题和最近几轮对话；工具、输出格式和提示词的顺序按场景固定并带版本，理赔的动态内容放在固定的前缀之后。

模型、运行时与提示词的联调

速度问题解决之后，更深的问题浮了出来。追查一个对话中途报错的原因时发现，这一轮"该问什么"并不由理解客户的模型决定，决定它的是一个不理解语言的函数：它每轮把一张固定的清单从头扫一遍，挑出第一个还没确认的项目去问，模型写的问句会被替换成固定的模板。同类的问题还有几处：客户一提到受伤，运行时转交人工之后就不再调用模型，客户之后说什么都得不到回复；判定一句话是否"确认"了某个事实的标准过严，一个简单的房屋报案要来回二十步；分支搭好了，其中一些却没有对应的专属字段；字段在领域模型里本来有七种状态，对话逻辑却把它们压成了"填了、没填、够了"三种，"客户说了不知道"这种合法的答案因此消失，模型为了填满一格，有时会编出一个答案。

设计先沿着修补的方向改了多轮，每轮解决一个具体的矛盾。随后我在真实浏览器里把新版本从头走了一遍：客户第一句话就讲清了追尾经过，agent 还在请他描述经过；同一件事被问了两次；对一句简单的"yeah"，模型编出了"已记录有人受伤"；内部的字段编码直接出现在对话里；该出现服务卡片的时候，卡片没有出现。我判断修补的路线已经失败。这些修补都在改进"运行时怎样核实一件事"，没有一次在问"这件事该由谁来判断"；修补越多，运行时替模型做的决定越细，方向本身却是错的。我据此提出了几条设计基础，作为之后每个设计决定的检验标准：

客户不应感觉到运行时的存在，它只在出于安全或权限拦下某件事时才露面；
模型决定这一轮做什么，运行时决定能不能做、怎样做成；
表格的骨架由运行时掌握，填表的是模型，每一栏都允许"暂时不知道"；
一次提交是否完成，看员工能不能直接接手；
文件和对话同样重要。

按这些基础，运行时退回到边界上：下一问问什么、话怎么说、汇总怎么写，交还给模型；运行时保留的是核实原话、划定险种边界、授权不可逆的动作，以及守住安全底线。运行时在正常流程中不再生成任何客户能看到的文字，并有自动检查保证这一点；同时增加一道核对，防止模型说的和系统记下的不一致，模型如果提到了被拒绝的服务，或者声称一件未经授权的事已经办成，会带着运行时的裁决重写一次，仍不通过就退到兜底回复，"我会把报案交给理赔团队"这类将要做的事可以说，"已经提交"必须有系统记录支撑。

字段恢复了完整的七种状态，并规定每一栏在提交时有四种合法的归宿：填好了；客户说了个大概，已经够用；现在不知道，以后会补；或者客户本就不该被问，交给第三方来填。模型可以明确标注"以后会补"或"等第三方"，但运行时要核实客户的原话是否支撑这个标注，"等第三方"还必须有客户同意过相应服务的记录。文件和对话同等对待，它可能由客户主动发来，可能是 agent 请客户提供的，也可能要由 agent 代为向第三方索取；从文件里读出的值是模型的解读，从"待确认"开始。

险种的判断交还给模型。让客户先选险种的下拉框被去掉，原来的关键词匹配退为排序参考和兜底；模型的判断权只限于最初的险种分支，描述对应多个险种或者和已确认的事实冲突时，agent 必须问客户；本轮的险种判断只有一个权威结果，路由、上下文、服务选择和字段都使用它。第三方服务则反过来收归运行时：运行时按本轮的险种和客户的意图从清单中选定服务，模型只给出有限的意图代码，不抄写服务编号；核心回复和服务卡片分开，某张卡片出错只影响这张卡片，回复照常送达。转交人工之后是否继续回复客户，队友已经实现了静默的设计，我在核实转交的实际范围之后采用了它，同时区分出一种例外：因网络中断而重试的同一条请求，照常处理完成。

模型的选择也作为联调的一部分。测试中，模型对明显能判断的字段也只标"以后再说"，我判断这是模型能力不足，于是换模型时只换大小、不换服务商，让结果可以直接确认或否定这个判断；换过之后，同样的事实一次就被准确地提取出来。关闭思考模式的开关原本只接给了本地模型，联调中也接到了云端模型上，进一步缩短了等待。

面向真实报案流程的调整

在阶段性的 sprint presentation 中，业界评委指出，系统展示的理赔流程需要贴近真实的理赔机制：追尾时通常要先记下对方的车牌、驾驶人和保险公司，有人受伤时往往有警方介入，责任归属不同，免赔额的处理也不同；只做出一个看起来像理赔的界面，不足以证明产品解决了问题。学术 supervisor 从用户的角度指出了另一处缺口：客户发出第一条消息后弹出的第三方服务列表会让人困惑，客户不知道这个弹窗意味着什么，也不清楚进入对话后能做什么、能得到怎样的帮助，并建议把整个旅程的体验设计得更清楚，例如用一份快速开始的报案指引代替这个弹窗。

我们把这些意见汇总成缺口，对照代码逐项核实，并按真实的报案流程重新调研。对照的结论是，系统把"顺畅地完成一段对话、提取安全相关的事实、判断险种"当成了报案的终点，真实的报案还需要支撑责任认定、免赔额计算、联系对方保险公司和核验警方文件的信息：驾驶人、对方车辆和保险公司、目击者都还没有对应的字段；客户的保单号只是一串文字，系统不知道它对应哪一档保单、怎样的免赔额结构。调研中我也检查了自己有没有被批评带偏，纠正了两个最初的设想。一是受到惊吓的报案人往往先讲经过，好的做法是先让他讲完再补问，所以自由对话的入口本身没有问题，场景提示只作为可选的便利。二是理赔编号应当在首次接触时就签发，这一点系统原本就做对了。

由此形成了现在这版 agent 的调整方向。安全确认提到最前面，由 agent 主动询问；客户讲完经过后，agent 先复述确认，再精准追问缺口，对方信息、目击者、警方报告状态这些当下最容易取得的信息被补进字段。在保单条款需要专业判断的地方，agent 整理依据、提出可以核实的初步意见，交给员工决定，权限的边界保持不变。客户的保单要和具体的免赔额结构关联起来，让客户能问到这份保单自己要付多少。转交人工时，agent 要向客户说明原因。入口和首条消息之后的体验，按 supervisor 的建议改为清楚的报案指引。目前我们正在按这些方向调整。

agent 如何服务于用户旅程

从客户的视角把报案过程走一遍，可以看到上面的设计怎样落在旅程的每一段，以及后端逻辑和界面各自在哪里起作用。

进入。 客户可以不登录直接开始报案，也可以用语音输入，因为刚出事的人可能正处在紧急或焦急的状态。入口是一个对话框，旁边提供可选的场景提示。客户不需要先弄清自己的事故属于哪一类，险种由 agent 从描述中判断。

讲述。 客户可以一口气说出很多信息。agent 从一句话里提取多条事实，每条都记下来源；已经知道的信息不再问，只问推进下一步真正缺少的内容。

表格。 对话旁边展示"目前我们了解到的"内容：每条事实的值、来源和状态，本轮新增的会被标出。客户可以直接修改，也可以在对话里要求纠正。模型提出的内容要经客户确认才生效，而且旧页面不会覆盖新的事实。表格从所有理赔都需要的几栏开始，随着客户的描述长出与事故类型相关的栏目。每一栏的最终状态可以是已经填好、大致知道、以后补充，或者交给第三方来填；"不知道"本身就是合法的答案。

材料。 材料可能是客户主动发来的，也可能是 agent 请客户提供的，还可能需要第三方出具，例如警方报告或评估报告。后端为每份材料单独记录状态：一份材料还没到，只挂起依赖它的步骤，其他步骤照常推进。

第三方服务。 需要评估师、拖车或维修时，agent 会在相关回复的下方给出服务卡片，说明将把哪些信息共享给谁，以及原因。客户可以说暂时不需要，也可以先同意、之后撤回。请求的准备、提交、处理、失败和结果未知分别记录；在系统确认之前，agent 不会说某件事已经办好了。

转交人工。 客户明确要求人工时，系统立即转交。出现伤亡或危险信号时，运行时在调用模型之前就中断常规流程并升级处理。转交时会带上已确认的事实、缺失的内容、材料状态、风险信号和转交原因，客户不必向员工重复说明。

员工接手。 员工工作台按员工的工作顺序组织：第一屏回答现在该处理哪个理赔、它卡在哪里、下一步是什么；操作区只显示当前状态下允许的动作；证据、历史记录和完整对话按需展开。欺诈只以附带来源的信号形式出现，界面上不给出结论。员工处理理赔前需要先认领，两个人不会同时修改同一份记录。员工一侧的 agent 只提供建议稿，员工编辑并确认后才成为正式动作，执行时再检查一次权限。

在后端逻辑上，会话和理赔分开记录，同一份理赔可以跨越多次会话；每次修改都带有版本号，旧版本不会覆盖新版本；客户重复提交同一条消息，也只会产生一次效果；一次处理失败时，不会留下写了一半的状态。在界面上，前端只呈现产品真实具备的能力：后端尚未就绪的功能显示为不可用，并说明原因；等待就显示等待，失败就显示失败；流程状态是唯一的事实来源，界面只是它的呈现；刷新、后退或直接输入网址时，页面都会先校验状态，不会渲染出半个页面。

二、职业能力：我在这些工作中学会了怎样做事

规划、组织与建立协作规范

计划随实际情况调整。 我负责团队的迭代目标和任务拆分。拆分从迭代目标出发，依次拆成能力、工作包，最后拆到一两个小时可以完成的任务；每项任务有唯一的负责人、明确的输入和输出、验收标准以及依赖关系。计划方法本身也随着暴露的问题调整过几次。这几次调整让我认识到，计划本身也需要验证：拆分方式是否合适，要看团队能否按它合出完整、可以验收的结果。任务卡的写法也在这个过程中统一下来，让团队成员和他们使用的工具读到同一张卡时，都能明白要做什么、做到什么程度算完成。

风险管理。 保险数据涉及个人隐私，真实部署时，保险公司可能不允许把客户数据交给云端模型，因此模型保持可替换，并准备了本地部署的备选，换掉模型不需要推翻 agent 的设计；与第三方共享客户数据，也先取得客户同意。这让我认识到，风险管理的重点在于提前准备退路：做决定时就考虑前提失效的情况，代价远小于问题发生之后的补救。

提高工作效率。 团队成员大多没有在规范运作的仓库里协作的经验，因此仓库本身要示范规范的协作方式：任务模板、协作规则，以及随开发进度自动流转的看板，让每个人不必把整个项目记在脑子里，也能开始工作。但有一次，一个改动在检查全部失败的情况下仍被合并，主分支因此出了问题。此后，我把规则改成可以自动执行的检查，从本地推送到服务端合并，各有一道关口；后来又把检查提前到任务创建阶段，说不清要解决什么问题的任务，在有人为它花时间之前就会被标出来。队友都借助 AI 编程工具工作，所以规则放在各种工具进入仓库时都会读取的入口处，并要求工具在接手任务前先说明它对任务的理解。这个过程让我认识到，规则写下来并不等于会被遵守，能持续生效的规范需要落实为可以自动执行的检查。

调研与技术判断

信息检索与证据分级。 做 agent 调研时，我按来源的可信程度区分证据，厂商对效果的宣称只当作产品说明。同样的标准也用在团队的用户研究上：区分事实、判断和假设，样本小的结论只用来排优先级，公开评论只作为个别的例子。由此我认识到，资料越多，越需要先判断每份资料能证明到什么程度，再决定是否把它当作依据。

批判性阅读与核实。 在 agent 的联调中，单项测试没有暴露的问题，在完整的报案流程里集中出现：agent 反复追问客户已经说过的内容，还会写下客户没有说过的事实。测试检验的是我们写下的预期，预期本身偏离了客户的经历，测试全部通过也证明不了产品是对的；文档里一项能力"已经登记"，同样不等于它"真的能被执行"。代码审查报告也需要这样读：合并前收到的一份报告列出了几个阻塞问题，我要求先逐条核实、找到根因，确认属实之后再动手修改。这让我认识到，验收的标准要从客户的完整经历出发来定；任何文档、测试或报告给出的结论，都要先弄清它实际证明了什么。

问题定义。 这个项目里走过的弯路，大多可以追溯到同一个原因：问题的本质没有抓准。按照问题的表面描述去设计，方案做得再细，解决的也可能是一个次要甚至错误的问题；而且这种偏差往往要等到真实测试或外部评审时才暴露出来，那时已经积累了不少需要推翻的工作。agent 的对话一度越改越生硬，系统一度把顺畅地完成一段对话当成了报案的终点，都是这样的例子。这让我认识到，抓不住问题的本质，设计就做不好；当设计开始反复修补，或者被外部意见指出方向上的缺口时，要先回头确认问题本身有没有定义对，再讨论怎样改。

大局观。 各个模块单独看都合理，合在一起却可能互相冲突。agent 开发中曾有一段时间，每一轮修补都解决了一个具体的矛盾，整体的对话却越来越生硬。这让我认识到，局部的正确不能代替整体的判断：评估改动时，要把它放到整条客户旅程和整个项目里去看；当一种修补方式反复失效时，应当停下来，回到目标重新判断方向。项目的几个阶段也让我认识到，"做完"在不同阶段的含义不同：原型要求路径完整，MVP 要求可以重复运行，验证阶段要求用真实的旅程证明价值，冻结之后只修复影响验证的问题。权衡同样要放在这个大局里做，例如在提问的完整和客户的耐心之间，我们选择只问下一步真正需要的。

保持怀疑。 收到业界评委"流程不够真实"的意见后，我先把它拆成几个可以验证的问题，再去调研；调研中，我把自己最初的改进设想也放回证据里检查，其中两个是被批评带偏的，因此放弃。之后在核实一位队友的请求时，我发现自己之前写进任务里的一个判断有误，并公开做了更正。这两件事让我认识到，外部意见和自己的结论一样，都是需要检验的假设。

与人共事

在协商与处理分歧上，遇到自己不能独自决定的设计问题，我会把它整理成议题，写清楚要决定什么、有哪些选项以及各自的代价，再交给团队讨论，界面重构时就整理出了十三个这样的议题，这让我认识到，把分歧写成有选项、有代价的议题，比口头争论更容易达成一致；当分歧涉及已有的设计时，我区分两种情况，团队已有明确决定的，遵循既有决定，只把确有理由的例外单独提出，改动会破坏设计基础的，坚持原有的设计原则，不逐条迁就。

在项目的 ownership 上，项目中后期我实际承担了团队负责人的协调工作，由此认识到，协调者要做的是把边界讲清楚，边界之内的具体做法由各方向的负责人决定；跨越边界的改动先用书面提案沟通，例如前端需要新的后端字段时，先向后端负责人提交字段提案，前端不自行添加；对于边界清楚的工作，我以书面方式授权负责人自主决定具体做法，只有超出约定范围时才需要同步。

在跨角色对接上，持续集成服务因额度耗尽停止工作的那天晚上，我连夜把最急需的合并检查和看板同步临时搭了起来，第二天一早提交了新平台的访问申请，并写邮件向管理员说明情况；这件事让我认识到，需要他人审批的事应当第一时间提出，自动化替代不了及时的沟通。与队友之间的协作也要按边界分工，双方只在事先约定的接口处衔接，跨角色的交接材料首先要写清边界。

References

[1] Google Cloud, "Dialogflow CX: Pages." [Online]. Available: https://cloud.google.com/dialogflow/cx/docs/concept/page

[2] Intercom, "Fin Procedures explained." [Online]. Available: https://www.intercom.com/help/en/articles/12495167-fin-procedures-explained

[3] Amazon Web Services, "Amazon Connect Cases." [Online]. Available: https://docs.aws.amazon.com/connect/latest/adminguide/cases.html

[4] Amazon Web Services, "Serverless insurance claims processing (aws-samples)." [Online]. Available: https://github.com/aws-samples/serverless-eda-insurance-claims-processing

[5] Rasa, "Flows." [Online]. Available: https://rasa.com/docs/reference/primitives/flows/

[6] LangChain, "LangGraph: Durable execution." [Online]. Available: https://docs.langchain.com/oss/python/langgraph/durable-execution

[7] Open Policy Agent, "Open Policy Agent documentation." [Online]. Available: https://www.openpolicyagent.org/docs/latest/

[8] Microsoft, "Security filters for trimming results in Azure AI Search." [Online]. Available: https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search

[9] OpenAI, "Structured Outputs." [Online]. Available: https://developers.openai.com/api/docs/guides/structured-outputs

[10] Kiro, "Steering." [Online]. Available: https://kiro.dev/docs/steering/

[11] Anthropic, "Claude Code: Agent skills." [Online]. Available: https://docs.anthropic.com/en/docs/claude-code/skills

[12] Aider, "Repository map." [Online]. Available: https://aider.chat/docs/repomap.html

[13] Anthropic, "Effective context engineering for AI agents." [Online]. Available: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[14] Manus, "Context engineering for AI agents: Lessons from building Manus." [Online]. Available: https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

[15] Amazon Web Services, "Prompt caching for faster model inference." [Online]. Available: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html