博世用豆包工作：让工程师少搬信息，多解问题

头图来源：豆包工作 客户在群里抛出一个问题，到工程师真正坐下来分析故障，中间隔着多少工作？ 在博世的某研发事业部，答案曾经是：找齐散落在各个群和私聊里的消息，按多个维度整理成完整描述，凭经验判断该找谁，接着再开会，再把结论写成报告。 故障分析还没开始，大半天已经过去了。 如今，这中间的一大段路，工程师交给了豆包工作和豆包工作伙伴。 博世的尝试：让 AI 接手沟通之后的工作 汽车产业链企业的研发部门，经常会遇到这样的情况：一个工程师要当三个用：研发细节要盯，还有很多日常重复的活儿需要做。 博世某事业部的工程师，其所在的团队需要对接各家客户，为客户提供系统综合解决方案。面对同一家客户，不同项目会有不同的群，测试、路试、投产任何一个环节出了问题，消息一条条蹦出来：哪个项目、哪个软件、报了什么故障代码、出现什么报错。 他得把这些碎片按不同的数个维度整合起来，所属项目、软件版本、车辆配置、测试工况、报错时间、诊断截图都在其中，再凭经验自己排障，或者转给负责对应模块的研发同学。解释不清的就拉会，双方澄清之后，再出报告发给客户。 让这位工程师下决心改变的，是两件事。 一是知识沉淀靠不住。经验都装在工程师个人脑子里，云文档、知识库不是没有，但每个人的模板和习惯不同，项目一忙，没人顾得上往里放。新问题来了还得先找人，人一走，经验就断档，这个恶性循环一直破不掉。 如果沉淀这件事不再靠自觉，不管是消息还是会议，AI 能在人无感的状态下自动记下来，那就可以节省很多时间精力。 二是客户不会按模板提问。问题是流式发生的，消息不停往外蹦，没人能把故障代码、截图和十四五条字段在一条消息里一次性给齐。碎片攒不齐，后面的分析就迟迟开不了工。 豆包工作和豆包工作伙伴的加入解决了这些问题。