去年 5 月，马化腾第一次在公开场合确认了车载微信的落地计划。在前天的腾讯全球数字生态大会上，车载微信正式发布，年内将首先在长安、广汽的车型上落地。

关于腾讯车联网的战略细节，可以点击这里看我们之前的分析。 今天主要想聊聊车载微信的意义以及腾讯车联网战略背后的一些逻辑。

在车里聊天不是重点

腾讯在介绍车载微信的功能时，是这么描述的：

车载微信为驾车场景量身定制，提供基于全语音交互方式的微信消息收发和语音通话功能，用户只动嘴、不动手即可完成消息收发；

结合车载硬件，通过方向盘按键即可一键下达指令，唤起微信；

车载微信服务能够与手机蓝牙感应，上车自动登录，下车自动断开；

同时，支持在微信上收到位置，快捷发起导航。

很明显，为了保证用户的使用安全、隐私等问题，腾讯做了相对周全的考虑。但即便如此，我依然认为车载微信「纯聊天」的部分很鸡肋。

微信作为社交软件，毫无疑问是国民应用。这就意味着社交作为核心，是微信维持用户粘度的绝对原因。但是在车里，抛开朋友圈、公众号这些功能之外，微信能剩下的几乎只剩收发文字信息。

另外，微信也需要解决隐私问题。微信语音的收发很多时候只适合个人的使用场景。我们不讨论人性的阴暗面，但很多时候微信还是需要一个更隐私的使用环境。

对很多人来说，微信承担了工作、生活的绝大部分社交功能。如果开车的时候收到了多条信息，系统很难区别优先级，也容易造成干扰。

总之，车载微信的出现存在影响驾驶安全的可能。虽然腾讯的目的是为了让用户安全的在车里收发信息，但也变相地给了用户在驾驶时聊微信的可能性。不仅仅是聊车载微信，包括看手机、发呆等等任何分心都可能导致安全问题，车载微信的出现，可以说是给了用户另一种「犯错」的机会。

设计者如果无法界定边界，那一旦用户因此出现安全问题，即使不会引发法律上的纠纷，道德层面依然会有责任。Tesl因为在 AP 宣传时的一些不当描述，在用户发生意外时招来了多少对于产品和企业的质疑？这两件事本质上是类似的。

当然，除了聊天之外的功能，车载微信还有一些实用的应用场景。例如结合 LBS 的服务，通过微信收发好友发来的位置、分享的餐馆等之后，车辆可以直接完成导航，就能简化用户在车里的操作步骤。类似例子还有很多，不一一举例。

车载微信的目的

在车载微信发布后的这两天里，身边的讨论不少，认为有必要和没必要的用户数量基本对等。

腾讯冒着可能引起的争议，依然要做车载微信，真的是为了满足一部分用户在车里聊天的需求么？

背后显然有更重要的目的，也就是服务整体的车联网解决方案。

根据介绍，这套解决方案的核心能力是：

「腾讯小场景（一套跨 OS 的、云端轻量化的开发者应用框架）」承载腾讯的海量 CPSP 互联网服务生态；

「AI 场景引擎」在适当的时候提供适合的功能，千人千面；

「超级 ID 与微信支付」为用户提供连贯的功能体验。

很容易就能看出，小场景负责车机端的功能实现，AI 场景引擎则主要通过云端完成。超级 ID 就承载获取用户使用习惯、串联车内、手机、智能家居等不同场景的功能。

根据我的观察和个人使用习惯，我们在登录各种互联网 App 时都能通过微信登录，并且很多数据已经授权给了微信。把场景转移到车内，这样的情况一定会延续。一旦用户在车内登录自己的微信账号，手机、智能家居上的各种数据就很有可能完成打通，更好实现体验和服务的延续。结合车辆本身 LBS 的属性，实现在特定场景提供特定服务，这才构成了腾讯车联网战略的整个用户体验架构。

也就是说，微信的账号体系有着成为车联网超级 ID 的一切潜质。

但账号体系一直是主机厂非常重视的一环，背后代表的是用户黏度维持、车辆数据、使用习惯等等。为了消除主机厂的疑虑，腾讯强调，不会抢占车企的账号体系。

考虑到小场景是一个跨 OS 的轻量化的应用框架，无需下载和安装、语音触发、云端加载，这就意味着，在系统层，腾讯并不需要特别多的权限，只需要把服务加载到主机厂自身的车机系统中即可。

这也就保证了主机厂自身账号体系不会被替代。

所以更有可能的一种情况是，通过主机厂账号绑定微信，之后形成一个超级 ID 的体系，直接获取腾讯的各种服务。这样一来，主机厂依然拥有自己的账号体系，但背靠的是微信这个超级 ID。用户不需要重新改变各种应用的账号登录方式，数据和使用习惯依然能够延伸到车内，是一个「皆大欢喜」的方案。

之前在搭载小度 OS 的星途 EXEED 上，百度也采用了类似的策略。当然，和微信相比，百度的账号体系就弱了很多，也能看出，作为超级账号的载体，微信有巨大的先天优势。

而车载微信在 PR 层面的优势就更不用说了。考虑到现在整车厂们动不动就用上「人工智能汽车」这样的宣传语，「可以聊微信的汽车」是不是很有传播性？

为什么没必要做 OS？

和百度阿里都在做车机 OS 不同，腾讯选择了体量更轻、开发更方便的小场景作为服务的载体。接下来说说这里面的逻辑。

目前，斑马和百度已经有不少 OS 级的产品落地了。特别是斑马，已经和不少主机厂进行了合作。看起来画面很美好，车企互联网企业一家亲。但长期来看，这种模式还是不完美的。

首先，主机厂始终希望主导车机系统的体验，背后涉及到了数据、用户运营、品牌识别度、功能定义等各种原因。

而斑马这样的供应商提供的几乎是标准化的产品，很难提供特别差异化的体验和服务。举个简单的例子，上汽大通在前几天发布了全新的蜘蛛智联系统，其中有部分功能就是为了车联网系统和自身商用车管理的系统结合。在这一点上，大通品牌原本所使用的斑马系统，目前来看显然无法提供对应的服务。在和大通相关同事的沟通中，也证实了我的这种猜测。

在现阶段，汽车智能化主要体现在车机系统，还有一些简单的车身控制和自动驾驶辅助功能。但往后发展，汽车的智能化会从底层架构开始进行，无论是更多 ECU、传感器的加入、或者是自动驾驶技术的发展，都会让车机系统承担的功能越来越多。

到那个时间点，就需要把底层系统和车机娱乐系统进行深度打通，从而实现数据传输。但是，这就牵扯到两个问题，首先是隐私和数据归属权的问题，尽管供应商一般强调不会跟主机厂争夺数据的归属，但围绕数据归属权的博弈，想必以后会越来越多。在这个问题上，除了利益和主导权的分配之外，背后还涉及到信任问题，并不容易解决。

网络安全也是隐患，在传统汽车时代，就出现了 Chrlie Miller 这样的大神，通过攻破克莱斯勒联网的车机系统就能控制车辆底层部件。当 5G 来临、每辆智能汽车几乎都是实时 online 时，这里的隐患就更大了。这也使得主机厂不敢开放更多权限给车机系统。

只看 BAT 的话，斑马做整体方案；百度既做整体方案、也输出单项的服务和能力；腾讯则主要以轻量化的小场景服务主机厂和用户。而在 CPSP 角度，各家也有各自的长处，例如百度的语音、AI，腾讯的音乐、微信、阿里的支付、高德地图等，都是可以产生差异化的长项。

在这里，我想不评判现阶段各家方案的优劣，只能说，主机厂数量不少，各家的考量和需求都不尽相同，不同的方案总会有受众。

我的一个观点是：从长期来看，如果有某家企业能保持不入侵底层系统，并且专心提供生态服务，那么它可能会比较容易获得主机厂的青睐。

但汽车智能化不断发展，车机操作系统和整车底层架构的结合是必然。所以我还是比较期待包括 BAT 在内的车联网供应商们后续的打法，跟主机厂之间的关系的走向也值得持续关注。而对于一些新造车企业以及 GKUI 这类一开始就选择自己做的产品，就又是另外一个故事了。

返回第一电动网首页 >