单一来源
当前只有一个可用来源,尚未完成多源交叉核验博世用豆包工作:让工程师少搬信息,多解问题
头图来源:豆包工作 客户在群里抛出一个问题,到工程师真正坐下来分析故障,中间隔着多少工作? 在博世的某研发事业部,答案曾经是:找齐散落在各个群和私聊里的消息,按多个维度整理成完整描述,凭经验判断该找谁,接着再开会,再把结论写成报告。
故障分析还没开始,大半天已经过去了。 如今,这中间的一大段路,工程师交给了豆包工作和豆包工作伙伴。 博世的尝试:让 AI 接手沟通之后的工作 汽车产业链企业的研发部门,经常会遇到这样的情况:一个工程师要当三个用:研发细节要盯,还有很多日常重复的活儿需要做。
博世某事业部的工程师,其所在的团队需要对接各家客户,为客户提供系统综合解决方案。面对同一家客户,不同项目会有不同的群,测试、路试、投产任何一个环节出了问题,消息一条条蹦出来:哪个项目、哪个软件、报了什么故障代码、出现什么报错。
他得把这些碎片按不同的数个维度整合起来,所属项目、软件版本、车辆配置、测试工况、报错时间、诊断截图都在其中,再凭经验自己排障,或者转给负责对应模块的研发同学。解释不清的就拉会,双方澄清之后,再出报告发给客户。
让这位工程师下决心改变的,是两件事。 一是知识沉淀靠不住。经验都装在工程师个人脑子里,云文档、知识库不是没有,但每个人的模板和习惯不同,项目一忙,没人顾得上往里放。新问题来了还得先找人,人一走,经验就断档,这个恶性循环一直破不掉。
如果沉淀这件事不再靠自觉,不管是消息还是会议,AI 能在人无感的状态下自动记下来,那就可以节省很多时间精力。 二是客户不会按模板提问。问题是流式发生的,消息不停往外蹦,没人能把故障代码、截图和十四五条字段在一条消息里一次性给齐。
碎片攒不齐,后面的分析就迟迟开不了工。 豆包工作和豆包工作伙伴的加入解决了这些问题。 在工程师真实的日常工作中,问题通常是从私聊开始的,工程师可以在豆包工作里配置定时任务,巡检自己收到的私聊消息,识别出故障类信息,再以本人身份转发到问题报告专项话题群。
在这个流程里,客户的沟通习惯不用改,工程师少了手动搬运,散落在流程外的事被拉回了流程里。 消息进了专项群,每个问题占一个独立话题,不同任务的材料互不混杂,天然形成「一事一议」的界面。
豆包工作伙伴爬取群里的历史上下文,把流式蹦出来的碎片聚成完整的问题描述,再调用封装好的报告生成技能,按标准模板出初稿,同时登记进飞书多维表格,提醒对应工程师处理。 在一次真实的问题处理记录里,AI 把消息整理成飞书文档,问题状态标为「进行中」;
驱动形式、驾驶模式这些没给全的信息,就保留「待补充」,工程师需要做的就是在初稿上核对、补齐,不必从空白文档开始。 还有些细节只有在开会时才能敲定下来。 工程师可以邀请豆包工作伙伴参加问题沟通会,它全程旁听,散会后直接把会上澄清的信息同步进报告,讨论、记录和报告之间,省掉了人工转述的环节。
按工程师自己的估算,AI 初稿能覆盖七八成内容,剩下两成交给人判断;会议结论补完,报告基本齐活,再经人工复核一遍,才发给客户。 报告同时会归档进团队知识库,状态和进度留在多维表格:表格管跟进,知识库管留存。
再遇到相似问题,AI 检索历史材料,先给出初版台账和归因。 它能调用的知识分两类:一类是外部行业知识,比如通用故障码各自代表什么含义;另一类是团队自己的历史沉淀,哪怕是已经离职的老工程师当年处理过的问题,也能被翻出来引用。
这个项目从需求到落地,用了短短一周多时间。事实上,豆包工作伙伴真正上岗的只花了一天,它进群跟工程师工作一天后,项目已经运转了起来,后面一周则用来调优细节,比如哪些报告写得太啰嗦,哪些内容不该放进去,哪些描述不够准确,工程师可以一条条告诉它:下次记住别再这么处理。
培养一位 AI 数字员工,和带教一位新同事一样简单。 目前豆包工作伙伴前后跑了五六十份问题报告,已经能够稳定在七八十分的水平。 剩下的二十分留给人来最终把关。故障原因怎么定、验证计划怎么排、对外给什么结论,这些关键工作仍然要由工程师人工审核、补充和确认。
不起眼的工作里,藏着 AI 的真实价值 引入豆包工作后,工程师可以少搬一遍消息,少重写一份报告,遇到新问题可以从历史工作里查找处理经验,重复的步骤交给 AI,精力可以回到问题分析、验证和客户沟通这些更重要的事情上。
在一个人当三个用的团队里,这些是实打实的产能提高。 对团队来说,更深的变化在信息的流动。过去一次沟通结束,信息散在聊天记录、个人云盘和某个人的脑子里;现在消息自动变成任务、报告和知识库条目,一次次处理留下的记录,从个人文件变成同事可以共同使用的资产。
过去讨论 AI,注意力很容易放在它能不能替人完成复杂的专业任务——能不能写代码、做诊断、出方案。但在真实的知识工作里,专业判断只占时间的一部分,更多时间消耗在沟通之后:整理零散信息、记录会议结论、把问题转给对的人、跟进处理进度、归档留痕。
这些事没有技术光环,琐碎、重复,却实实在在地占用人的精力。 就像在博世与豆包工作的合作里,AI 创造价值的位置,并非是工作流里最核心的那一环——把沟通、判断和解决专业问题留给人,把沟通之后的整理、记录和行动尽可能交给 AI,如此一来,工程师就能腾得出手,去做真正需要工程师来做的事。 AI 不一定要做最重要的事,才能创造重要的价值。
Evidence
来源与证据
当前仅有一个可用来源,尚未完成多源交叉核验。
- 发布时间
- 内容处理
- AI 翻译 / 摘要,需结合原文核对
相关资讯
苹果披露机器人 HALO 进展:基于千问模型在宇树 G1 验证 单任务成功率 91%
苹果披露机器人 HALO 进展:基于千问模型在宇树 G1 验证 单任务成功率 91% 6 小时前 苹果研究团队在预印本平台披露人形机器人自主控制系统 HALO,将其部署在宇树科技 G1 人形机器人上,可让机器人把仿真环境中学到的动作迁移到陌生现实房间执行,相关数据生成、模型训练和部署代码也同步公开。HALO 采用三层协同控制架构,上层为基于千问大模型的任务编排模块,可本地运行无需联网,能处理指令模糊信息并拆分子任务。中间层用千问小模型配合解码器规划约 5 秒的全身动作,每秒更新 3 次。底层动作跟踪器以每秒 50 次的频率将动作计划转化为关节控制指令。研究团队通过在千个程序生成的模拟家庭环
网传 OpenAI 出现大规模封号
近日网传 OpenAI 出现大规模封号情况,不少用户反馈账号未收到通知就直接无法登录或显示已删除。被封账号集中在倒卖 / 拆分 API 免费额度、多人共享账号、使用反代服务、使用低价区号注册、学生认证等类型,部分无违规操作的自用号也有被波及的情况,总体有违规操作前科的账号更易被封禁。目前关于封号原因的推测分为两类,靠谱方向包括 OpenAI 打击 API 额度转售、反代和模型蒸馏行为,刚落地的设备与支付卡绑定数量限制的后续动作,以及 11 月 20 日新使用政策生效前的违规账号清理。另有两个非靠谱的巧合类联想说法。目前 OpenAI 尚未就这波封号发布公开声明,官方帮助中心仅说明违规使用政策或
AI短剧“降智”争议下《持械入宋》中国爆红播放量破120亿
(北京综合讯)中国人工智能(AI)短剧陷入“降低智商”、让人沉迷上瘾等争议之际,一部名为《持械入宋》的短剧罕见获得口碑流量双丰收,播放量破120亿。 据封面新闻报道,《持械入宋》是一部用AI生成的历史穿越短剧,改编自字节跳动旗下番茄小说平台同名作品,今年8月在同样由字节开发的红果短剧平台上线,目前已更新至第10季,总计约1000集。制作方称,《持械入宋》截至星期六(11月7日)的播放量已突破120亿,成为中国爆红的现象级作品。据介绍,《持械入宋》的剧情设定在北宋末年,讲述一支现代五人作战小队携装备意外穿越至北宋后发生的故事。中共江西省委宣传部官方微信公众号星期六发文称,虽然《持械入宋》的“AI
中国科普作家协会发布 2026 年度十大科普热词,AI 相关占据七席
IT之家 11 月 7 日消息,中国科普作家协会今天(7 日)发布了 2026 年度十大科普热词,人工智能相关占据七席,包括“人工智能 +”“人机协同”“脑机接口”“智能体”“人形机器人”“词元”“具身智能”,另三大科普热词分别是“科学玩具”“科技伦理”“健康管理”。根据介绍,人工智能相关词汇成为本年度热词的重要组成部分。“人工智能 +”“智能体”“词元”等,反映人工智能加快融入生产生活带来的新知识需求;“脑机接口”“人形机器人”“具身智能”等,为公众理解前沿技术的原理、进展与应用场景提供了切入点。与此同时,“科学玩具”体现科普作品形态的拓展,“人机协同”反映人工智能参与下科普创作的方式变化,
AI 翻译、摘要和解读仅用于辅助判断;涉及重要决策时,请回到上方来源核实。