從頁面到駕駛艙交互范式變遷的兩種路徑2026-07-29過去二十多年軟件界面遵循著一種底層邏輯時間被凍結(jié)在一張張頁面里用戶通過空間導(dǎo)航在功能之間移動。無論是打開一個App、進入一個菜單、還是找到某個按鈕本質(zhì)上都是在二維平面上進行尋路。這種范式在短平快的操作中運轉(zhuǎn)良好卻天然排斥那些跨越數(shù)分鐘、甚至數(shù)天的長流程任務(wù)。然而當(dāng)執(zhí)行主體開始從人向Agent轉(zhuǎn)移界面的核心矛盾正從空間尋路轉(zhuǎn)向時間追蹤。用戶的核心訴求似乎正在從這個功能在哪里變?yōu)槭虑檫M行到哪一步了。如果這一趨勢持續(xù)下去界面設(shè)計可能會從空間展開走向時間展開從凍結(jié)的頁面走向流動的駕駛艙。本文所謂駕駛艙并非簡單的信息看板而是圍繞進行中的任務(wù)組織狀態(tài)、操作和異常處理的一種持續(xù)性交互界面。這種轉(zhuǎn)變并非單一維度的替代而可能沿著兩條路徑同步發(fā)生——操作系統(tǒng)層級的Launcher演進以及垂直應(yīng)用內(nèi)部的駕駛艙化改造。這兩條路徑恰好對應(yīng)了信息空間與信息敘事兩種設(shè)計哲學(xué)的分野與融合。一、為什么是現(xiàn)在在深入兩條路徑之前有必要先回答一個問題這種轉(zhuǎn)變?yōu)槭裁窗l(fā)生在當(dāng)下而非五年前或十年后三個條件第一次同時成熟。第一Agent能夠執(zhí)行。過去界面只能推薦信息推薦引擎、呈現(xiàn)信息信息流無法自主操作。但隨著AI從建議走向執(zhí)行從Copilot走向Agent軟件第一次有能力代表用戶完成多步驟操作。駕駛艙的本質(zhì)是任務(wù)的控制臺——沒有執(zhí)行主體控制臺便沒有意義。第二實時狀態(tài)可以持續(xù)同步。iOS的Live Activity、Android的實時通知、MCP協(xié)議對服務(wù)器推送的支持這些基礎(chǔ)設(shè)施在過去幾年才逐步成熟。駕駛艙要求界面與后端狀態(tài)保持持續(xù)同步而非用戶下拉刷新時才更新。這個前提直到2024年前后才在主流操作系統(tǒng)中得到系統(tǒng)性支持。第三LLM統(tǒng)一了意圖表達。傳統(tǒng)GUI依賴按鈕、菜單等預(yù)設(shè)控件來表達用戶意圖——用戶只能在開發(fā)者預(yù)判的路徑中選擇。LLM使得任意自然語言描述都可以轉(zhuǎn)化為可執(zhí)行的任務(wù)意圖界面不再需要窮舉所有可能的操作入口。這從根本上降低了駕駛艙作為命令匯集點的使用門檻。這三個條件共同推動了一個拐點的到來界面設(shè)計的中心正在從如何呈現(xiàn)信息轉(zhuǎn)向如何追蹤和干預(yù)任務(wù)的演化。二、系統(tǒng)層Launcher的任務(wù)駕駛艙化在操作系統(tǒng)層面一個值得觀察的問題是Launcher是否會重新獲得它在移動互聯(lián)網(wǎng)早期曾經(jīng)擁有的核心地位不過即便真的發(fā)生其復(fù)興的形態(tài)也絕非傳統(tǒng)意義上那個裝滿應(yīng)用圖標(biāo)的抽屜而更像是一種圍繞任務(wù)組織的駕駛艙界面——即從應(yīng)用啟動器進化為任務(wù)駕駛艙。過去十年Launcher的邊緣化有目共睹。超級App通過小程序?qū)⒎?wù)入口內(nèi)化iOS對第三方Launcher的封閉態(tài)度都讓獨立Launcher的生存空間被壓縮。然而一些變化正在發(fā)生。蘋果在iOS 16中引入的鎖屏小組件和實時活動以及在iOS 17中增強的交互式小組件都在暗示一個趨勢操作系統(tǒng)正在把更多即時狀態(tài)推向用戶的第一屏而非藏在應(yīng)用內(nèi)部。更值得留意的是桌面端的變化macOS上的Raycast已經(jīng)從單純的應(yīng)用啟動器演變?yōu)槊蠲姘骞ぷ骺臻g的綜合入口其Agent功能允許用戶通過自然語言觸發(fā)多步驟操作這已超出了傳統(tǒng)Launcher的能力邊界驗證了Launcher作為控制中樞的可行性。如果將視線拉回移動端通知中心、鎖屏界面和主屏幕三者之間的功能邊界正在模糊。實時活動讓鎖屏承擔(dān)了任務(wù)狀態(tài)展示小組件讓主屏幕顯示動態(tài)信息而通知中心則成了任務(wù)事件的匯總流。這三者各自分擔(dān)了任務(wù)狀態(tài)呈現(xiàn)的工作但尚未整合成一個統(tǒng)一的任務(wù)控制平面。這個空白會不會由未來的Launcher來填補目前還很難判斷。操作系統(tǒng)正在從應(yīng)用容器變成意圖管道iOS 18的Apple Intelligence和Android的Gemini試圖在系統(tǒng)任意界面截獲意圖并路由到服務(wù)節(jié)點這本質(zhì)上是在瓦解應(yīng)用圖標(biāo)網(wǎng)格的存在根基。當(dāng)然系統(tǒng)級方案落地的阻力不小。第三方Launcher面臨操作系統(tǒng)廠商的權(quán)限封鎖與用戶二十年來形成的找應(yīng)用→點圖標(biāo)的肌肉記憶。因此即便系統(tǒng)級駕駛艙真的成為現(xiàn)實也更可能由操作系統(tǒng)廠商親自推動如Google在Android中整合Gemini的任務(wù)自動化蘋果擴展實時活動的交互能力而非第三方Launcher完成逆襲。三、應(yīng)用層垂直應(yīng)用的域內(nèi)駕駛艙改造相比之下垂直應(yīng)用內(nèi)部的駕駛艙化改造路徑更為清晰。垂直應(yīng)用圍繞明確的任務(wù)域展開意圖的收斂性使得任務(wù)狀態(tài)管理在架構(gòu)上更為直接。更重要的是垂直應(yīng)用天然掌握著完整的業(yè)務(wù)數(shù)據(jù)和任務(wù)生命周期不需要像系統(tǒng)級方案那樣去協(xié)調(diào)跨應(yīng)用的接口開放問題。我們已經(jīng)在一些產(chǎn)品中看到了駕駛艙的雛形。美團和餓了么的訂單追蹤頁面能夠?qū)崟r顯示從接單到配送的全鏈路狀態(tài)飛書和釘釘?shù)墓ぷ髋_把待辦、審批、日程聚合在首頁。這些界面雖然仍以頁面形式存在但其底層邏輯已接近任務(wù)卡片圍繞一個具體任務(wù)的進程聚合狀態(tài)信息和操作入口。它們距離完整的駕駛艙形態(tài)中間只隔著一個界面層的重構(gòu)將入口網(wǎng)格讓位于任務(wù)狀態(tài)矩陣。然而我們必須重新定義垂直應(yīng)用駕駛艙的適用邊界。并非所有應(yīng)用都適合變成駕駛艙這取決于兩個維度任務(wù)密度與任務(wù)持續(xù)時間。任務(wù)密度決定了界面上需要同時呈現(xiàn)多少個進行中的任務(wù)高密度并行任務(wù)域原生駕駛艙如飛書、釘釘。屏幕上天然有10個進行中的事項用戶同時處理多個任務(wù)線程需要并行監(jiān)控和切換。低密度線性任務(wù)域增強型頁面如美團、順豐。用戶在同一時刻通常只有1-2個進行中的訂單不需要完整看板但需要快速訪問當(dāng)前任務(wù)的狀態(tài)和操作。無任務(wù)瀏覽域內(nèi)容消費如抖音、小紅書。幾乎沒有駕駛艙的應(yīng)用場景依然是沉浸式空間導(dǎo)航。任務(wù)持續(xù)時間則決定了用戶對追蹤進度的需求強度。一次支付操作持續(xù)30秒用戶不關(guān)心支付到哪里了但一次裝修工程持續(xù)90天用戶需要反復(fù)查看進度、溝通異常、確認(rèn)節(jié)點。即便任務(wù)密度同樣很低同一時間只有一個裝修項目長持續(xù)時間本身就會催生駕駛艙需求。將這兩個維度組合可以更清晰地界定駕駛艙的適用邊界短持續(xù)秒~分鐘長持續(xù)天~月低密度支付、掃碼裝修、買房、保險高密度外賣配送飛書、項目管理短持續(xù)低密度不需要駕駛艙傳統(tǒng)的單頁操作足夠。短持續(xù)高密度如外賣配送需要緊湊型狀態(tài)條任務(wù)周期雖短但多個訂單并行需要快速切換和追蹤。長持續(xù)低密度如裝修非常適合駕駛艙用戶需要長期追蹤單一任務(wù)的演化。長持續(xù)高密度如飛書駕駛艙的主戰(zhàn)場多任務(wù)并行且每個任務(wù)都在時間中持續(xù)展開。對于美團這類短持續(xù)高密度的應(yīng)用其駕駛艙化可能不是把首頁變成任務(wù)看板而是把信息流本身任務(wù)化。例如首頁上半部分是進行中的外賣/行程卡片強任務(wù)“下半部分是猜你想吃弱任務(wù)/瀏覽任務(wù)”。用戶從瀏覽中挑選下一個任務(wù)將駕駛艙管理進行中任務(wù)和啟動臺發(fā)現(xiàn)下一個任務(wù)合二為一。垂直應(yīng)用駕駛艙的獨特價值在于域內(nèi)深度。系統(tǒng)級方案只能展示配送中的淺層狀態(tài)但垂直應(yīng)用可以在同一張卡片中嵌入修改地址、聯(lián)系騎手、申請退款等全鏈路操作。當(dāng)異常發(fā)生時如珍珠售罄駕駛艙可以直接給出域內(nèi)最優(yōu)解“推薦更換為椰果”而不是僅僅拋出一個通知。四、廣度與深度兩種路徑的互補結(jié)構(gòu)如果這兩條路徑都向前推進它們之間的關(guān)系未必是替代或競爭。實際上它們并非并列的兩條路徑而是一條主路徑與一條配套路徑。為什么因為任務(wù)本身產(chǎn)生于應(yīng)用而非操作系統(tǒng)。美團知道訂單狀態(tài)、騎手位置、退款流程蘋果不知道。飛書知道項目進度、審批節(jié)點、任務(wù)依賴iOS也不知道。真正擁有任務(wù)的是應(yīng)用系統(tǒng)只是聚合。因此更準(zhǔn)確的關(guān)系是應(yīng)用層是Source of Truth任務(wù)的狀態(tài)、操作、異常全部由應(yīng)用定義和維護應(yīng)用負責(zé)完整的敘事——從任務(wù)啟動到完成的全部情節(jié)。系統(tǒng)層是Projection操作系統(tǒng)只能呈現(xiàn)應(yīng)用主動暴露的狀態(tài)摘要提供一個跨應(yīng)用掃視的索引。換句話說垂直駕駛艙負責(zé)講述任務(wù)的故事“這個訂單發(fā)生了什么現(xiàn)在卡在哪里我該怎么辦”系統(tǒng)駕駛艙負責(zé)列出所有正在進行的故事標(biāo)題“你有3個任務(wù)進行中2個需要關(guān)注”。這種分工決定了形態(tài)上的差異**系統(tǒng)級方案信息空間**擅長廣度提供一個跨域任務(wù)的統(tǒng)一掃視入口解決有哪些事在進行的全局感知問題。**垂直方案信息敘事**擅長深度在單一任務(wù)域內(nèi)提供最完整的操作能力和最精準(zhǔn)的異常處理講述這件事具體怎么樣了的完整故事。兩者服務(wù)于同一范式轉(zhuǎn)變的不同層面。用戶既需要偶爾在鎖屏上瞥一眼外賣送到了哪里也需要在美團里深度修改一份復(fù)雜訂單的每一個細節(jié)。這里還存在一個中間層場景化駕駛艙。手機的駕駛模式、專注模式負一屏的情景智能以及車機端的艙駕融合界面都是基于場景聚合任務(wù)的迷你駕駛艙。這種場景化形態(tài)很可能比全局駕駛艙更早普及更符合用戶分場景使用設(shè)備的心智。五、頁面的歸宿與范式的前提頁面未必會消失。在高度創(chuàng)造性、探索性、沉浸式的任務(wù)中如寫代碼、深度閱讀其價值恰恰在于不可預(yù)測的過程而非可追蹤的進度。在這些場景下時間凍結(jié)的頁面依然是不可替代的信息空間。更可能的結(jié)果是頁面被降級為任務(wù)卡片的一種特殊形態(tài)當(dāng)用戶需要專注時卡片展開為頁面當(dāng)用戶只需要狀態(tài)感知時頁面折疊為卡片。時間展開成為默認(rèn)范式時間凍結(jié)成為主動進入的模式。最后我們必須正視一個前提任務(wù)的結(jié)構(gòu)化是駕駛艙范式成立的基礎(chǔ)。無論是系統(tǒng)級還是應(yīng)用級駕駛艙底層都依賴任務(wù)的標(biāo)準(zhǔn)節(jié)點、異常分支和可調(diào)用接口的標(biāo)準(zhǔn)化。目前只有外賣、快遞等高度標(biāo)準(zhǔn)化的消費任務(wù)能完整適配大量長尾業(yè)務(wù)還不具備結(jié)構(gòu)化能力。這決定了駕駛艙范式只能從高標(biāo)準(zhǔn)化任務(wù)逐步滲透而非全面替代頁面。但這場變遷的深層邏輯已經(jīng)清晰。軟件歷史上的每一次交互范式演進本質(zhì)上都在改變?nèi)伺c任務(wù)的距離。GUI讓人不必記住命令而直接操作對象Agent時代則讓人逐漸不必操作對象而開始管理任務(wù)。當(dāng)界面的中心從對象轉(zhuǎn)向任務(wù)軟件也就從一個被瀏覽的空間演化為一個持續(xù)運行的系統(tǒng)。我們不需要爭論駕駛艙會不會來只需要持續(xù)觀察兩個信號系統(tǒng)廠商是否在持續(xù)打通鎖屏、桌面、通知的任務(wù)數(shù)據(jù)垂直應(yīng)用是否在把首頁從功能入口網(wǎng)格改成任務(wù)狀態(tài)矩陣。這兩個方向的推進速度就是交互范式從空間導(dǎo)向的信息空間向時間導(dǎo)向的信息敘事遷移的真實進度條。