豆包接管车机模型：替你开车（荣威家越 07）我会稳稳的接住你 @晚点LatePost

「一辆车、四个人、一个大脑：豆包座舱助手实测。」

豆包座舱助手首发实测：车机开始适应人

9 月 17 日，豆包与火山引擎联合发布豆包座舱助手，首款搭载车型荣威家越 07 计划于 9 月 21 日开启预售。发布前夕，我们在一辆仍处于测试阶段的家越 07 里，让豆包找拍照好看的地方，随后改成文艺街区，又接着问停车和吃饭。车内豆包随我们需求变化调整推荐地点，最后启动了去餐厅的导航。

实测：目的地在否定与补充中成形

整个过程没有一条完整的指令。目的地是在几个人的否定、补充和改变主意中逐渐形成的。几次插话之后，它仍然记得目的地、被否定过的选项，以及还有哪件事没有处理完。之所以能做到这些，是因为豆包座舱助手基于大模型“理解、执行、反馈”的闭环，而不是基于规则去调用车辆功能。

大模型上车已经两年多。

车机更博学，但人更需要控制

多数车企先让它聊天、搜索、画画，车机更博学，也更像人。但人在车里更多需要的是控制车辆、到达目的地，这就需要有调动起全车功能的能力。此前理想、特斯拉等车企较早开始借助大模型让用户用自然语言调用车内功能，比如理想 i8 上市搭载的那一版本理想同学，听到用户说“肩膀冷”“胸口热”就能调节电动出风口。

“根据我们的规划，到年底时，豆包座舱助手会像人一样思考、基于目标持续地办事。”火山引擎副总裁杨立伟今年北京车展期间对我们说。现在目标兑现，火山引擎希望把对话、记忆和执行结合起来，让豆包座舱助手开启大模型上车的下一步：让汽车开始适应人的表达、习惯和不断变化的需求。

速览

关键时间线

从理解一句话，到持续完成任务

汽车装上大屏，功能的复杂性并没有随之消失。空调风向、座椅腰托、驾驶模式……上千个功能从实体按键进入触摸菜单，语音成为与触屏并列的主要入口，智能座舱越来越像一台移动终端。但它的核心交互原则没有变：用户需要精确发出功能指令。

高频场景：车控与导航

这些也是车载助手最常处理的事情。今年 4 月，杨立伟向我们介绍，当时汽车端豆包大模型的日常调用中，车控占 53%，导航占 29%。

单一功能比如启动回家导航，点一下屏幕或者声控“导航回家”，不需要大模型泛化能力。但如果几件操作同时发生——上车通电、调整空调和座椅、导航目的地、回应家人——大模型上车的价值显现，将人的自然语言表达对应到车辆的确定功能。

相关人士告诉我们，家越 07 上的豆包座舱助手没有写规则，判断全部由模型完成。

实测：一句抱怨，豆包就改了出风

在我们的体验中，说“感觉这个风一直对着我脸吹”，豆包降低风量、关上车窗，随后将主驾出风口改成避人吹。

这需要它同时了解车上有什么功能、此刻是什么状态，以及用户过去怎么选择。今年 4 月，火山引擎智能座舱产品负责人张航向我们回忆，团队从 2023 年开始尝试让大模型调用车内功能，可控制接口从 100 多个扩展到 1000 多个，此后又接入车速、温度、电量、车窗开合等信息。

从数百种信号到数千项原子能力

如今，范围继续扩大。豆包座舱助手已经能感知数百种车辆信号，调用车控、导航、辅助驾驶和娱乐等数千项原子能力。具体到荣威家越 07，上汽向豆包开放了超过 2000 项 SOA 服务接口。豆包座舱助手结合车辆状态和这些工具规划任务，再将用户偏好与执行反馈用于后续决策。

执行过程中，还会遇到计划之外的问题。我们曾让豆包调用车内功能营造恐怖氛围。它调暗灯光、降低温度并搜索背景音乐。第一次因为没有音乐软件会员，没有切换成功，它重新搜索了另一个来源。后排乘客提出用座椅震动模拟有人敲击身体，由于后排座椅没有按摩功能，它改用音效和剧情推进。

另一个考验是如何处理中途插入的新任务。在一个展示豆包处理连续任务的演示中，豆包主持多人知识问答，乘客先把题目总数从十道改成五道，又在中途要求调整氛围灯、继续第三题。豆包要同时保留游戏规则、答题进度和得分，调好灯光后继续出题。

在不断强化大模型能力的同时，火山引擎和合作车企对不同操作设置不同权限。以荣威为例，双方设定如空调、车内灯光等可以由 AI 直接调节的操作属于彩区。涉及车辆状态的操作进入灰区，例如行驶中能否调节座椅，要受底层规则限制；刹车、转向等核心驾驶控制属于黑区，不向座舱大模型开放。

官方演示中，副驾以快要迟到为由要求车辆开快一点。豆包先重新规划了一条更快的路线，当需求涉及提高巡航速度时，它转而向主驾确认，获得允许后才执行。

豆包如何同时读懂一车人

手机上的助手通常面对一名用户，车内却有主驾、副驾和后排乘客。他们会相互补充，也会提出冲突的意见。某个人说“有点闷”，系统既要理解这句话，还得确认是谁、希望调整哪个位置。

连续交流：30 秒窗口与多轮唤醒

在我们体验的设置中，豆包首次唤醒后默认保持 30 秒连续交流，也可改为 60 秒或 90 秒。打开多人自由交互后，其他乘客可以加入，不必每次重复唤醒。中控台上的实体豆包屏会随对话切换表情，让车内成员都有一个可见的交谈对象。

建立身份，在相处中学习习惯

要让连续交流进一步变成个性化服务，系统还要建立稳定的身份，并在相处中学习每个人的习惯。豆包会结合声源位置、座位和车内摄像头识别乘客，再将习惯与相应身份绑定。我们告诉豆包，以后开空调不要让风吹脸。另一名乘客说，自己说“有点闷”时，希望它打开左后车窗。几分钟后，同一个人再次说“有点闷”，豆包按照刚才形成的偏好为她打开了对应车窗。

用户可以直接用自然语言告诉豆包，下次遇到类似情况应该怎么处理，不必进入菜单配置规则。按照火山引擎的设计，豆包座舱助手会根据用户的反馈调整处理方式，将新的经验沉淀为个人习惯，并通过长期记忆延续到之后的使用中。随着交流和反馈增加，同一句“有点闷”“有点累”，可以针对不同乘客出发不同操作，做到“越用越懂你”。

系统还能根据要求调整助手处理多人意见的方式。我们对目的地提出不同要求时，豆包起初跟随最后一位说话者。我们要求它遇到分歧先询问大家，尤其确认主驾意见。再次讨论餐厅时，它改变了回应方式，给出折中建议，并在导航前询问主驾。

从主驾倾斜到全员平等

燃油车时代传统、经典的人机交互原则是所有体验向主驾倾斜。比如国际品牌把中控整体向主驾偏转，核心功能留给主驾，副驾只够得到几个按键。

在火山引擎产品经理的设定中，餐厅、音乐和娱乐等可以让乘客平等参与，但座椅、后视镜、驾驶模式和辅助驾驶等涉及行车安全的功能，仍必须服从主驾权限和车辆状态。个人偏好可以被学习，安全权限有严格限制。

除了听人说话，豆包座舱助手还能通过车内摄像头识别人数、座位、部分动作和乘员状态。我们询问自己坐姿是否健康时，它注意到后背没有贴紧椅背，并在调整后再次提醒。这种需求跟随在开车时更重要，对驾驶员来说，座舱交互应尽量少占用看路的注意力，让人愿意开口，和让人不必一直参与，是同样重要的产品要求。

而对于整个座舱成员的体验而言，“读懂一车人”真正困难的地方是要在身份可能识别错误、需求随时改变、权限并不平等的情况下，持续判断应该回应谁、照顾谁，以及什么时候必须拒绝。

火山引擎从技术供应商走向产品共建

从车机延伸到手机

按照此次发布的计划，之后车主可以通过手机豆包应用查询车况、远程控车，并把对话中规划的行程推送到车上。手机里选好的目的地，可以接着交给汽车处理。助手开始有机会承接一段跨越设备的出行安排。

这进一步改变了火山引擎在汽车里的存在方式。此前，它向车企提供模型能力，而消费者接触到的通常是车企自己的助手名字和形象。在家越 07 里，用户直接叫的是豆包，看到的也是豆包。手机端积累的熟悉感随之进入汽车。

两种合作方式

包括与荣威的合作在内，目前火山引擎与车企有两种合作方式。AI 座舱套件由车企自选模型、语音、记忆、智能体和工具平台，产品定义、形象和用户关系留在车企，上汽奥迪 E7X 的奥迪助手，与特斯拉中国今年 7 月起向 Model 3 和 Model Y 推送接入豆包的车机语音，就属于这种。

完整的豆包座舱助手由火山引擎与车企共同做交互、任务执行、形象和持续运营。在家越 07 上，上汽提供电子电气架构、车端状态和超过 2000 项 SOA 服务，火山引擎提供模型、规划、对话和任务调度。

AIVA 与火山引擎的合作，也是采用更深度的联合定义、联合设计 AI 体验的模式，相应成果会在品牌全系车型标配，首款车也会在今年内落地。

Ben Thompson：组织模型工作才是壁垒

技术分析作者 Ben Thompson 在今年 3 月分析编程智能体时指出，模型之外，组织模型工作、调用工具、检查执行结果的软件同样重要。他认为，模型与这部分软件的紧密配合，会形成产品差异，也让相关供应商有机会获得更多利润。

互联网公司进汽车的得与失

过去十多年，互联网公司多次尝试进入汽车。从地图、音乐和内容，到云服务、车联网和辅助驾驶，它们通常提供某一项能力，鲜有今天这样作为万亿市场核心供应商的机会。

从这个角度看，完整座舱助手扩大了火山引擎参与产品设计的范围。这种合作需要更早投入，也需要车企开放更多信息。今年 4 月，杨立伟对我们说，火山引擎为首批深度合作投入了上百人，当时不优先考虑利润。选择合作伙伴时，品牌因素现阶段不是最重要的，更重要的是对座舱 AI 的认同、开放和投入意愿，以及推进速度。

但如果每增加一款车，都要重新组织一支团队开发大部分功能，合作数量增长就会带来相应的人员投入。火山引擎此前提出的路径，是先做好少数车型，再把可复用的产品能力和工具标准化，与一级供应商等伙伴合作，扩大服务范围。理论上，车企可以因此少做一部分基础开发，把资源用在自己的车型上；火山引擎则能把前期研发投入分摊到更多项目。

如我们此前所分析，这与 AWS、Shopify 等基础设施公司的商业逻辑相近：供应商提供通用能力，客户在其上做出不同的产品，客户业务增长再扩大供应商的服务规模。双方的利益因此有了共同方向。

后来亚马逊再把虚拟助手 Alexa 搬到车内，2022 年与 Stellantis 宣布联合开发 STLA SmartCockpit，将 Alexa、导航、娱乐和个性化服务集成进座舱。亚马逊希望将这次合作的成果推广给更多车企。但到 2025 年 5 月，双方确认结束座舱联合开发，AWS 云服务合作以及部分车型上的 Alexa 则继续保留。

双方没有披露具体终止合作的原因。但云服务合作得以继续，座舱联合开发却结束，提示了两种业务的不同要求：向车企提供基础能力之外，共同交付一套座舱产品，还需要双方持续协调车型开发、系统适配和后续维护；互联网公司在车端直接面向消费者，原来的品牌力和用户积累的熟悉感就更重要了，这是 Alexa 欠缺的，也是前期其他互联网服务上车并不顺利的重要原因。

连苹果 CarPlay 也是几经起伏。2014 年苹果推出 CarPlay 时，车企不愿意把中控屏交给手机，担心失去数据和界面。CarPlay 还是进了几乎所有品牌的车，因为 iPhone 用户上车就要它。2023 年，福特在回答股东提问时表示，会继续提供 CarPlay 和 Android Auto，原因就是消费者喜欢通过它们使用和控制手机应用。今天正有更多中国自主品牌车企适配 CarPlay。车外积累的用户关系，开始影响车内的产品选择。

豆包同样有机会把手机端积累的熟悉感带进汽车。但要让用户持续使用，完整座舱助手还需要提供手机本身无法完成的服务。汽车是一个可以移动、容纳多人的空间，座椅、温度、灯光和声音都能调节。豆包座舱助手可以将对话、内容与这些能力结合，帮助用户安排出行、休息和共同娱乐。它处理的需求，也由此从屏幕上的信息延伸到人所处的环境。

汽车功能还会增加，驾驶员却不应因此学习更多指令、承担更多操作。豆包接下更多任务，应当让车主少重复解释需求、少纠正操作，也更方便地使用车内空间。车企则需要通过复用基础能力，减少每款新车的重复开发投入。如果用户在换车时仍希望继续使用豆包，这种偏好就会进一步影响车企对产品和供应商的选择——用户愿意持续使用，车企能够控制开发和维护成本，火山引擎与车企的合作才有长期基础。

来源：晚点LatePost　原文链接

文｜曾兴（晚点LatePost）