Eileen 客户在群里提出问题，到工程师坐下来分析故障，中间隔着一段不短的距离。在博世某研发事业部，这段距离曾经要花掉大半天：先把散落在各个群和私聊里的消息找齐，按项目、软件版本、车辆配置、测试工况、报错时间、诊断截图等多个维度整理成完整描述，再凭经验判断该找谁，接着开会澄清，最后写成报告。故障分析还没开始，时间已经过去大半。
让这位工程师决定改变的有两件事。一是知识沉淀靠不住，经验装在个人脑子里，云文档和知识库虽然存在，但模板和习惯各不相同，项目一忙就没人往里放，人一走经验就断档。二是客户不会按模板提问，故障代码、截图和十几条字段很难在一条消息里一次给齐，碎片攒不齐，后续分析就迟迟开不了工。
如今，这些环节交给了豆包工作和豆包工作伙伴。工程师在豆包工作里配置定时任务，巡检自己收到的私聊消息，识别出故障类信息后，以本人身份转发到问题报告专项话题群，客户的沟通习惯不用改。消息进群后，每个问题占一个独立话题，材料不互相混杂。豆包工作伙伴读取群里的历史上下文，把陆续出现的碎片聚成完整的问题描述，再按标准模板生成报告初稿，同时登记进飞书多维表格并提醒对应工程师。在一条真实记录里，未给全的驱动形式、驾驶模式等信息保留为“待补充”，工程师在初稿上核对补齐即可。需要开会敲定的细节，工程师可以邀请豆包工作伙伴旁听，散会后它把澄清的信息同步进报告。
按工程师的估算，AI初稿能覆盖七八成内容，剩下两成交给人判断。报告归档进团队知识库，状态和进度留在多维表格。它调用的知识包括通用故障码含义这类外部行业知识，也包括团队历史沉淀，连已离职工程师当年处理过的问题也能被检索引用。这个项目从需求到落地用了一周多，豆包工作伙伴上岗只花一天，进群工作一天后流程就跑了起来，随后一周用于调优细节。目前它已处理五六十份问题报告，水平稳定在七八十分。故障原因怎么定、验证计划怎么排、对外给什么结论，仍由工程师审核确认后再发给客户。
