還記得春節期間千問請客喝奶茶的盛況吧,很多人的 AI 購物第一單就是那時候產生的。
也正是那次,直接讓千問在國民 AI 產品的賽道上往前沖了一把。
這次,他們又干了一件事,千問接入了打車 Skill。
有了這個能力,千問就能實現復雜需求的意圖理解,例如「6個人需要匹配商務車」、「接個人是要增加途經點」等。還具備地點記憶、時間預約等能力。
我體驗了產品在不同打車場景下對需求的滿足程度,從目前的情況看,完成度已經不錯了。
你可以先更新到千問最新版,然后直接跟它說出你的出行打車需求。比如我,就一句話告訴他我要去長沙五一廣場。
![]()
一開始,它會讓你先完成授權。
![]()
千問識別分析完我的需求后,會基于起點和終點推薦一個出行方案,包括車型、價格明細、路線規劃和時間等。
![]()
注意一個細節,我只告訴它我的終點在哪里,并沒有給他起點,但千問也是基于定位識別到了我的當前位置。
如果此時我沒有其他問題,直接跟它說確認用車就行,接下來它就會幫我去叫車。
后續的支付流程,也是用支付寶來完成的。
看似很絲滑,但實際的打車場景可比這個要復雜。
所以,我們給它上點難度。
這次,我的需求里不僅包含了對車型的選擇,還有就是出發時間是未來,也就是預約打車。
![]()
很顯然,千問也是準確識別到了我的需求,并且幫我設計好了打車方案。
只要我確認用車,這個打車需求就會被發出去,然后完成叫車。
還是前面說的,日常生活中的打車場景是非常多樣化的,所以我再復刻一個真實的打車場景。
這次,我指定起點,但是這個起點不是我的當前定位,也就是我幫別人打個車,并且把他送到我家里來。
注意,這個過程中我也沒有告訴千問我家在哪。
然后,它也準確識別分析并完成了叫車方案設計,全程沒毛病,這背后應用到了長下文記憶的能力。
![]()
別覺得我在為難它,其實我這就是日常場景里的正常需求而已。
實際上,打車看似是一個小需求,但是它所覆蓋的場景其實非常多,而且很復雜。
不過看到千問可以打車這件事,我最大的感受不是 AI 又能干一件事了,而是 AI 開始真正進入辦事時代了。
很多人會把它理解成一個演示:你說一句「幫我打車去公司」,系統替你完成下單。
看起來像是把原來 App 里的點擊操作,換成了一句自然語言。
如果只看到這里,那就低估這件事了。
因為打車的本質,從來不是「操作」,而是「決策」。
為什么這么說?
你點外賣點錯了,最多重下一單,損失的是一點錢和等待時間。
但是,打車不一樣。
車打錯了、位置錯了、車型選錯了、時間卡錯了,代價往往不是幾塊錢,而是遲到、誤事、情緒被打亂,甚至影響后面一整天的安排。
所以,打車不是一個輕交互服務,而是一個強履約服務。
這也是為什么全球很多 AI 產品都嘗試過幫用戶打車,但真正做好的并不多的原因。
核心問題,往往不在于能不能調起打車接口,而在于誰對結果負責。
技術上,把一個 App 喚起來不難,難的是 AI 要理解你的真實需求,要替你做出合適的選擇,還要對最終結果兜底。
因此,這才是 AI 辦事的真正門檻。
過去我們討論 AI,更多是在說它能不能回答問題、能不能寫文案、能不能做總結。
這些事情本質上屬于信息處理,哪怕答錯一點,問題也未必很大。
但一旦進入真實世界,進入辦事的場景,標準立刻變了。
你要的不是一個差不多的回答,而是一個能落地的結果。
從這個角度看,千問能打車,真正有價值的地方不是它替你省了幾個點擊動作,而是它邁過了一道更難的門檻:AI 不只是執行指令,而是開始承接責任。
這背后還有一個更大的變化,是交互范式的變化。
以前打車的流程很固定:打開 App,輸入目的地,選擇車型,確認費用,提交訂單,等待司機接單。
整個過程,本質上是人去學習工具的操作邏輯,再按照工具規定的步驟一步步完成。
所以,這是一種典型的「操作導向」。
而現在,如果你只需要說一句「幫我打車去公司」,系統就能理解你的意圖、結合你的歷史習慣、當前位置、常用路線、支付方式,直接幫你完成任務,那么人與工具的關系就變了。
以前,是人找服務。
以后,是服務找人。
以前,是你去適應工具。
以后,是工具來理解你。
這看起來只是少了幾個步驟,實際上是一次人機交互范式的遷移。
因為,自然語言不是更方便的按鈕,而是一種更接近人類需求表達方式的接口。
說白了,人真正想表達的從來不是我想點擊哪個按鈕,而是我現在要去哪里,我希望快一點、舒服一點、別出錯。
當 AI 能直接理解這個層面的需求,工具就不再只是工具,而開始變成你的數字分身。
這也是我認為這件事特別重要的原因:它讓 AI 從會聊天走向會辦事,從輔助工具走向代理角色。
那么,為什么是阿里先把這件事做出來?
很多人第一反應會覺得,這是模型能力的問題。誰模型更強,誰就更容易搞定。
但如果你把這件事拆開看,就會發現核心不只是模型,而是生態。
AI 打車不是一個單點能力,它至少需要幾樣東西協同:地圖定位、路線理解、司機供給、實時調度、支付閉環、異常處理。
你不能只有一個聰明的大腦,還得有完整的手腳和神經系統。
全球范圍內,真正同時擁有這些能力的公司并不多,阿里就是其中一個。
千問并不是憑空創造一個新能力,而是把原本分散在不同業務里的能力串了起來,讓模型成為那個新的統一入口。
這也說明了一個趨勢,AI 競爭正在進入下一階段。
上一階段,比的是誰的模型更聰明,誰的參數更多,誰的推理更強。
下一階段,比的是誰能把模型和真實世界的服務網絡連接得更深。
不是模型軍備競賽,而是生態能力 PK。模型決定上限,生態決定落地。
還有一個細節,我覺得特別有意思。
如果用戶說:「幫我打車去公司,不要臭車」,AI 會怎么理解?
這句話在生活里是一種人味兒的表達,看起來很生活化,但對于 AI 來說就有點模糊。但恰恰這種模糊,才最考驗 AI。
不要臭車,到底是什么意思?
是司機身上有異味?車里有煙味?空調味太重?還是車況不佳、衛生太差?
以前,很多 AI 遇到這類表達會直接懵掉,因為它只能理解字面意思,缺乏真正的生活經驗。
而真實世界里的需求,恰恰大量都是這種不標準、不結構化、但又非常真實的表達。
這個過程中,用戶不是在給系統下結構化命令,而是在表達感受和偏好。
「不要臭車」的重點,不是「臭」這個字本身,而是人為什么在乎這件事。
因為坐車和點外賣不一樣,人在車里是被困住的、無法回避的。體驗一旦差,就不是不滿意,而是難受。
所以 AI 真正要理解的,不只是你說了什么,而是你為什么這么說。
這揭示了 AI 辦事的本質:不是識別需求表面,而是理解需求背后的原因。
誰先做到這一點,誰才真正摸到了 Agent 的門檻。
更進一步看,AI 打車其實只是一個開始。它背后真正發生的,是 AI 正在吃掉越來越多的「認知勞動」。
過去我們打車,需要自己做很多微小但消耗精力的決策:用哪個平臺、選什么車型、在哪個上車點更順、價格是否劃算、是否需要趕時間。
這些決策看似不難,但每天都在消耗注意力。
現在,AI 可以逐步接管這些事。
未來也一樣,幫你選餐廳、幫你比價、幫你安排行程、幫你篩選酒店、幫你做信息歸納,甚至幫你做部分投資輔助判斷。
越來越多原本由人親自完成的認知勞動,都會被 AI 接手。
這意味著,人在很多場景中的角色會發生轉移。
先是執行者。
然后是決策者。
再往后,可能變成監督者。
所以未來真正稀缺的能力,未必是你會不會操作工具,而是你知不知道什么應該交給 AI,什么必須自己掌握。
你能不能判斷 AI 的建議靠不靠譜,你有沒有能力在自動化越來越強的世界里,保留自己的判斷權。
AI助手千問能打車了,看起來只是一次產品升級。但如果放到更長的時間尺度里看,它其實像一個信號——服務的入口正在從App 圖標,轉移到一句自然語言之中。
而這場遷移的沖擊波,首先就會打在那些依賴固定交互路徑的單一服務 App 上。
出行類 Skill 的上線,不只是多了一個打車渠道,更是對滴滴這類傳統打車軟件的根本性挑戰。
在傳統模式下,用戶必須在 App 里按菜單一步步點選:輸入起點、終點、選車型、確認價格等等。
整個過程預設了「人要適應工具」的前提,這不僅限制了表達——比如你說「我想去一個市區最近很火的看郁金香的地方」,系統根本無法理解;而且也讓大量不熟悉圖形界面的用戶,比如老年人,被擋在服務之外。
而 AI 助手 + Skill 的模式,把交互還原成了最自然的語言。你不需要知道「怎么操作」,只需要說出「我想做什么」。
這種范式的切換,激活的不僅是新需求,更是被長期忽視的用戶群體。
一旦核心出行場景被 AI 助手承接,傳統打車 App 的打開率和用戶黏性將面臨結構性下滑。
就像 Claude 推出設計技能后,Adobe 和 Figma 股價應聲下跌所預示的那樣:當任務可以在通用智能體中完成,垂直工具的價值就會被重新定價。
未來最值得關注的,不是哪個模型又刷了多少分。
而是,哪個 AI 真的能用最自然的方式把事辦成!
················· 唐韌出品 ·················
安可時刻
生活服務是 AI 能夠介入且大大提效的場景,可能一開始我們會懷疑,甚至是抵觸,以及不信任。
但是,這就像我們第一次把錢放在支付寶和微信錢包里一樣,也是伴隨著不確定和小心翼翼。
但是,有些進程就是不可逆的。
AI,正是其中之一。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.