给Grok一个模糊的需求，它找到这个地方，在你确认后，发送给导航，FSD帮你把车开过去。从画面里你能看到，Grok多次推测地址的过程，推理过程也是在云端完成的。（导航查询无此地址时，Grok也是知道，可以继续推理）

这是一个座舱AI助手与FSD联合协作的案例。这个案例，也可以让我们思考：舱驾融合应该以什么样的形式出现？

此前我们谈到的舱驾融合，不止是硬件（芯片）的统一，还有软件的统一，甚至是组织架构的统一。为了避免座舱语音和智驾语音打架，有品牌会用两个不同的唤醒词来区分。

其实豆包手机，给了我们一个很好的启发，手机端只要开放足够高的底层权限，豆包助手可以像你一样，直接操作为人类设计的App。这个逻辑，在车上也是行得通的，在现有舱、驾分离的情况下，也就能达到某种融合的效果。

当然对于智驾和行车来说，它的安全等级更高，需要限制的也更多，但中间指令，比如：导航设置、目的地推荐、路径选择规划、补能选择规划这一类，就可以让AI助手直接完成，借助云端，它可以有更强推理能力，甚至可以比人类更聪明。

这个过程要求是双向的，AI助手不仅能发给导航指令，也要能读取导航当前状态，他要能“看懂”导航，要判断导航给的地址，是不是用户需求的那个，如果不是，继续推理，而不是从一开始，就要求用户来选择第几个。

而目前最大的挑战是：主机厂很难给第三方AI开放足够高的权限，这也是豆包助手，必须要做自己手机的原因。

当然，如果你在汽车、AI都做了自研布局，会容易得多……但多少主机厂，有足够的钱和资源，“烧出”一个Grok级别的大语言模型呢…… http://t.cn/AXU4fNFI