車裡聊微信不是重點
去年 5 月，馬化騰第一次在公開場合確認了車載微信的落地計劃。在前天的騰訊全球數字生態大會上，車載微信正式發佈，年內將首先在長安、廣汽的車型上落地。
關於騰訊車聯網的戰略細節，可以點擊這裡看我們之前的分析 。今天主要想聊聊車載微信的意義以及騰訊車聯網戰略背後的一些邏輯。
在車裡聊天不是重點
騰訊在介紹車載微信的功能時，是這麼描述的：
車載微信為駕車場景量身定製，提供基於全語音交互方式的微信消息收發和語音通話功能，用戶只動嘴、不動手即可完成消息收發；
結合車載硬件，通過方向盤按鍵即可一鍵下達指令，喚起微信；
車載微信服務能夠與手機藍牙感應，上車自動登錄，下車自動斷開；
同時，支持在微信上收到位置，快捷發起導航。
很明顯，為了保證用戶的使用安全、隱私等問題，騰訊做了相對周全的考慮。但即便如此，我依然認為車載微信「純聊天」的部分很雞肋。
微信作為社交軟件，毫無疑問是國民應用。這就意味著社交作為核心，是微信維持用戶粘度的絕對原因。但是在車裡，拋開朋友圈、公眾號這些功能之外，微信能剩下的幾乎只剩收發文字信息。
另外，微信也需要解決隱私問題。微信語音的收發很多時候只適合個人的使用場景。我們不討論人性的陰暗面，但很多時候微信還是需要一個更隱私的使用環境。
對很多人來說，微信承擔了工作、生活的絕大部分社交功能。如果開車的時候收到了多條信息，系統很難區別優先級，也容易造成干擾。
總之，車載微信的出現存在影響駕駛安全的可能。雖然騰訊的目的是為了讓用戶安全的在車裡收發信息，但也變相地給了用戶在駕駛時聊微信的可能性。不僅僅是聊車載微信，包括看手機、發呆等等任何分心都可能導致安全問題，車載微信的出現，可以說是給了用戶另一種「犯錯」的機會。
設計者如果無法界定邊界，那一旦用戶因此出現安全問題，即使不會引發法律上的糾紛，道德層面依然會有責任。Tesla 因為在 AP 宣傳時的一些不當描述，在用戶發生意外時招來了多少對於產品和企業的質疑？這兩件事本質上是類似的。
當然，除了聊天之外的功能，車載微信還有一些實用的應用場景。例如結合 LBS 的服務，通過微信收發好友發來的位置、分享的餐館等之後，車輛可以直接完成導航，就能簡化用戶在車裡的操作步驟。類似例子還有很多，不一一舉例。
車載微信的目的
在車載微信發佈後的這兩天裡，身邊的討論不少，認為有必要和沒必要的用戶數量基本對等。
騰訊冒著可能引起的爭議，依然要做車載微信，真的是為了滿足一部分用戶在車裡聊天的需求麼？
背後顯然有更重要的目的，也就是服務整體的車聯網解決方案。
根據介紹，這套解決方案的核心能力是：
「騰訊小場景（一套跨 OS 的、雲端輕量化的開發者應用框架）」承載騰訊的海量 CPSP 互聯網服務生態；
「AI 場景引擎」在適當的時候提供適合的功能，千人千面；
「超級 ID 與微信支付」為用戶提供連貫的功能體驗。
很容易就能看出，小場景負責車機端的功能實現，AI 場景引擎則主要通過雲端完成。超級 ID 就承載獲取用戶使用習慣、串聯車內、手機、智能家居等不同場景的功能。
根據我的觀察和個人使用習慣，我們在登錄各種互聯網 App 時都能通過微信登錄，並且很多數據已經授權給了微信。把場景轉移到車內，這樣的情況一定會延續。一旦用戶在車內登錄自己的微信賬號，手機、智能家居上的各種數據就很有可能完成打通，更好實現體驗和服務的延續。結合車輛本身 LBS 的屬性，實現在特定場景提供特定服務，這才構成了騰訊車聯網戰略的整個用戶體驗架構。
也就是說，微信的賬號體系有著成為車聯網超級 ID 的一切潛質。
但賬號體系一直是主機廠非常重視的一環，背後代表的是用戶黏度維持、車輛數據、使用習慣等等。為了消除主機廠的疑慮，騰訊強調，不會搶佔車企的賬號體系。
考慮到小場景是一個跨 OS 的輕量化的應用框架，無需下載和安裝、語音觸發、雲端加載，這就意味著，在系統層，騰訊並不需要特別多的權限，只需要把服務加載到主機廠自身的車機系統中即可。
這也就保證了主機廠自身賬號體系不會被替代。
所以更有可能的一種情況是，通過主機廠賬號綁定微信，之後形成一個超級 ID 的體系，直接獲取騰訊的各種服務。這樣一來，主機廠依然擁有自己的賬號體系，但背靠的是微信這個超級 ID。用戶不需要重新改變各種應用的賬號登錄方式，數據和使用習慣依然能夠延伸到車內，是一個「皆大歡喜」的方案。
之前在搭載小度 OS 的星途 EXEED 上，百度也採用了類似的策略。當然，和微信相比，百度的賬號體系就弱了很多，也能看出，作為超級賬號的載體，微信有巨大的先天優勢。
而車載微信在 PR 層面的優勢就更不用說了。考慮到現在整車廠們動不動就用上「人工智能汽車」這樣的宣傳語，「可以聊微信的汽車」是不是很有傳播性？
為什麼沒必要做 OS？
和百度阿里都在做車機 OS 不同，騰訊選擇了體量更輕、開發更方便的小場景作為服務的載體。接下來說說這裡面的邏輯。
目前，斑馬和百度已經有不少 OS 級的產品落地了。特別是斑馬，已經和不少主機廠進行了合作。看起來畫面很美好，車企互聯網企業一家親。但長期來看，這種模式還是不完美的。
首先，主機廠始終希望主導車機系統的體驗，背後涉及到了數據、用戶運營、品牌識別度、功能定義等各種原因。
而斑馬這樣的供應商提供的幾乎是標準化的產品，很難提供特別差異化的體驗和服務。舉個簡單的例子，上汽大通在前幾天發佈了全新的蜘蛛智聯繫統，其中有部分功能就是為了車聯網系統和自身商用車管理的系統結合。在這一點上，大通品牌原本所使用的斑馬系統，目前來看顯然無法提供對應的服務。在和大通相關同事的溝通中，也證實了我的這種猜測。
在現階段，汽車智能化主要體現在車機系統，還有一些簡單的車身控制和自動駕駛輔助功能。但往後發展，汽車的智能化會從底層架構開始進行，無論是更多 ECU、傳感器的加入、或者是自動駕駛技術的發展，都會讓車機系統承擔的功能越來越多。
到那個時間點，就需要把底層系統和車機娛樂系統進行深度打通，從而實現數據傳輸。但是，這就牽扯到兩個問題，首先是隱私和數據歸屬權的問題，儘管供應商一般強調不會跟主機廠爭奪數據的歸屬，但圍繞數據歸屬權的博弈，想必以後會越來越多。在這個問題上，除了利益和主導權的分配之外，背後還涉及到信任問題，並不容易解決。
網絡安全也是隱患，在傳統汽車時代，就出現了 Charlie Miller 這樣的大神，通過攻破克萊斯勒聯網的車機系統就能控制車輛底層部件。當 5G 來臨、每輛智能汽車幾乎都是實時 online 時，這裡的隱患就更大了。這也使得主機廠不敢開放更多權限給車機系統。
只看 BAT 的話，斑馬做整體方案；百度既做整體方案、也輸出單項的服務和能力；騰訊則主要以輕量化的小場景服務主機廠和用戶。而在 CPSP 角度，各家也有各自的長處，例如百度的語音、AI，騰訊的音樂、微信、阿里的支付、高德地圖等，都是可以產生差異化的長項。
在這裡，我想不評判現階段各家方案的優劣，只能說，主機廠數量不少，各家的考量和需求都不盡相同，不同的方案總會有受眾。
我的一個觀點是：從長期來看，如果有某家企業能保持不入侵底層系統，並且專心提供生態服務，那麼它可能會比較容易獲得主機廠的青睞。
但汽車智能化不斷髮展，車機操作系統和整車底層架構的結合是必然。所以我還是比較期待包括 BAT 在內的車聯網供應商們後續的打法，跟主機廠之間的關係的走向也值得持續關注。而對於一些新造車企業以及 GKUI 這類一開始就選擇自己做的產品，就又是另外一個故事了。
投票有效期截止至：2019 年 05 月 27 日
作者：大白
長按掃碼勾搭本文作者
？
作者問答
問：你會在開車的時候聊微信麼？
每篇 GeekCar 原創文章的作者會向大家提出一個相關的問題，GeekCar 也很想知道大家的想法，和大家一起聊一聊，歡迎大家踴躍回答！
