从页面到驾驶舱：交互范式变迁的两种路径

从页面到驾驶舱交互范式变迁的两种路径2026-07-29过去二十多年软件界面遵循着一种底层逻辑时间被冻结在一张张页面里用户通过空间导航在功能之间移动。无论是打开一个App、进入一个菜单、还是找到某个按钮本质上都是在二维平面上进行寻路。这种范式在短平快的操作中运转良好却天然排斥那些跨越数分钟、甚至数天的长流程任务。然而当执行主体开始从人向Agent转移界面的核心矛盾正从空间寻路转向时间追踪。用户的核心诉求似乎正在从这个功能在哪里变为事情进行到哪一步了。如果这一趋势持续下去界面设计可能会从空间展开走向时间展开从冻结的页面走向流动的驾驶舱。本文所谓驾驶舱并非简单的信息看板而是围绕进行中的任务组织状态、操作和异常处理的一种持续性交互界面。这种转变并非单一维度的替代而可能沿着两条路径同步发生——操作系统层级的Launcher演进以及垂直应用内部的驾驶舱化改造。这两条路径恰好对应了信息空间与信息叙事两种设计哲学的分野与融合。一、为什么是现在在深入两条路径之前有必要先回答一个问题这种转变为什么发生在当下而非五年前或十年后三个条件第一次同时成熟。第一Agent能够执行。过去界面只能推荐信息推荐引擎、呈现信息信息流无法自主操作。但随着AI从建议走向执行从Copilot走向Agent软件第一次有能力代表用户完成多步骤操作。驾驶舱的本质是任务的控制台——没有执行主体控制台便没有意义。第二实时状态可以持续同步。iOS的Live Activity、Android的实时通知、MCP协议对服务器推送的支持这些基础设施在过去几年才逐步成熟。驾驶舱要求界面与后端状态保持持续同步而非用户下拉刷新时才更新。这个前提直到2024年前后才在主流操作系统中得到系统性支持。第三LLM统一了意图表达。传统GUI依赖按钮、菜单等预设控件来表达用户意图——用户只能在开发者预判的路径中选择。LLM使得任意自然语言描述都可以转化为可执行的任务意图界面不再需要穷举所有可能的操作入口。这从根本上降低了驾驶舱作为命令汇集点的使用门槛。这三个条件共同推动了一个拐点的到来界面设计的中心正在从如何呈现信息转向如何追踪和干预任务的演化。二、系统层Launcher的任务驾驶舱化在操作系统层面一个值得观察的问题是Launcher是否会重新获得它在移动互联网早期曾经拥有的核心地位不过即便真的发生其复兴的形态也绝非传统意义上那个装满应用图标的抽屉而更像是一种围绕任务组织的驾驶舱界面——即从应用启动器进化为任务驾驶舱。过去十年Launcher的边缘化有目共睹。超级App通过小程序将服务入口内化iOS对第三方Launcher的封闭态度都让独立Launcher的生存空间被压缩。然而一些变化正在发生。苹果在iOS 16中引入的锁屏小组件和实时活动以及在iOS 17中增强的交互式小组件都在暗示一个趋势操作系统正在把更多即时状态推向用户的第一屏而非藏在应用内部。更值得留意的是桌面端的变化macOS上的Raycast已经从单纯的应用启动器演变为命令面板工作空间的综合入口其Agent功能允许用户通过自然语言触发多步骤操作这已超出了传统Launcher的能力边界验证了Launcher作为控制中枢的可行性。如果将视线拉回移动端通知中心、锁屏界面和主屏幕三者之间的功能边界正在模糊。实时活动让锁屏承担了任务状态展示小组件让主屏幕显示动态信息而通知中心则成了任务事件的汇总流。这三者各自分担了任务状态呈现的工作但尚未整合成一个统一的任务控制平面。这个空白会不会由未来的Launcher来填补目前还很难判断。操作系统正在从应用容器变成意图管道iOS 18的Apple Intelligence和Android的Gemini试图在系统任意界面截获意图并路由到服务节点这本质上是在瓦解应用图标网格的存在根基。当然系统级方案落地的阻力不小。第三方Launcher面临操作系统厂商的权限封锁与用户二十年来形成的找应用→点图标的肌肉记忆。因此即便系统级驾驶舱真的成为现实也更可能由操作系统厂商亲自推动如Google在Android中整合Gemini的任务自动化苹果扩展实时活动的交互能力而非第三方Launcher完成逆袭。三、应用层垂直应用的域内驾驶舱改造相比之下垂直应用内部的驾驶舱化改造路径更为清晰。垂直应用围绕明确的任务域展开意图的收敛性使得任务状态管理在架构上更为直接。更重要的是垂直应用天然掌握着完整的业务数据和任务生命周期不需要像系统级方案那样去协调跨应用的接口开放问题。我们已经在一些产品中看到了驾驶舱的雏形。美团和饿了么的订单追踪页面能够实时显示从接单到配送的全链路状态飞书和钉钉的工作台把待办、审批、日程聚合在首页。这些界面虽然仍以页面形式存在但其底层逻辑已接近任务卡片围绕一个具体任务的进程聚合状态信息和操作入口。它们距离完整的驾驶舱形态中间只隔着一个界面层的重构将入口网格让位于任务状态矩阵。然而我们必须重新定义垂直应用驾驶舱的适用边界。并非所有应用都适合变成驾驶舱这取决于两个维度任务密度与任务持续时间。任务密度决定了界面上需要同时呈现多少个进行中的任务高密度并行任务域原生驾驶舱如飞书、钉钉。屏幕上天然有10个进行中的事项用户同时处理多个任务线程需要并行监控和切换。低密度线性任务域增强型页面如美团、顺丰。用户在同一时刻通常只有1-2个进行中的订单不需要完整看板但需要快速访问当前任务的状态和操作。无任务浏览域内容消费如抖音、小红书。几乎没有驾驶舱的应用场景依然是沉浸式空间导航。任务持续时间则决定了用户对追踪进度的需求强度。一次支付操作持续30秒用户不关心支付到哪里了但一次装修工程持续90天用户需要反复查看进度、沟通异常、确认节点。即便任务密度同样很低同一时间只有一个装修项目长持续时间本身就会催生驾驶舱需求。将这两个维度组合可以更清晰地界定驾驶舱的适用边界短持续秒~分钟长持续天~月低密度支付、扫码装修、买房、保险高密度外卖配送飞书、项目管理短持续低密度不需要驾驶舱传统的单页操作足够。短持续高密度如外卖配送需要紧凑型状态条任务周期虽短但多个订单并行需要快速切换和追踪。长持续低密度如装修非常适合驾驶舱用户需要长期追踪单一任务的演化。长持续高密度如飞书驾驶舱的主战场多任务并行且每个任务都在时间中持续展开。对于美团这类短持续高密度的应用其驾驶舱化可能不是把首页变成任务看板而是把信息流本身任务化。例如首页上半部分是进行中的外卖/行程卡片强任务“下半部分是猜你想吃弱任务/浏览任务”。用户从浏览中挑选下一个任务将驾驶舱管理进行中任务和启动台发现下一个任务合二为一。垂直应用驾驶舱的独特价值在于域内深度。系统级方案只能展示配送中的浅层状态但垂直应用可以在同一张卡片中嵌入修改地址、联系骑手、申请退款等全链路操作。当异常发生时如珍珠售罄驾驶舱可以直接给出域内最优解“推荐更换为椰果”而不是仅仅抛出一个通知。四、广度与深度两种路径的互补结构如果这两条路径都向前推进它们之间的关系未必是替代或竞争。实际上它们并非并列的两条路径而是一条主路径与一条配套路径。为什么因为任务本身产生于应用而非操作系统。美团知道订单状态、骑手位置、退款流程苹果不知道。飞书知道项目进度、审批节点、任务依赖iOS也不知道。真正拥有任务的是应用系统只是聚合。因此更准确的关系是应用层是Source of Truth任务的状态、操作、异常全部由应用定义和维护应用负责完整的叙事——从任务启动到完成的全部情节。系统层是Projection操作系统只能呈现应用主动暴露的状态摘要提供一个跨应用扫视的索引。换句话说垂直驾驶舱负责讲述任务的故事“这个订单发生了什么现在卡在哪里我该怎么办”系统驾驶舱负责列出所有正在进行的故事标题“你有3个任务进行中2个需要关注”。这种分工决定了形态上的差异**系统级方案信息空间**擅长广度提供一个跨域任务的统一扫视入口解决有哪些事在进行的全局感知问题。**垂直方案信息叙事**擅长深度在单一任务域内提供最完整的操作能力和最精准的异常处理讲述这件事具体怎么样了的完整故事。两者服务于同一范式转变的不同层面。用户既需要偶尔在锁屏上瞥一眼外卖送到了哪里也需要在美团里深度修改一份复杂订单的每一个细节。这里还存在一个中间层场景化驾驶舱。手机的驾驶模式、专注模式负一屏的情景智能以及车机端的舱驾融合界面都是基于场景聚合任务的迷你驾驶舱。这种场景化形态很可能比全局驾驶舱更早普及更符合用户分场景使用设备的心智。五、页面的归宿与范式的前提页面未必会消失。在高度创造性、探索性、沉浸式的任务中如写代码、深度阅读其价值恰恰在于不可预测的过程而非可追踪的进度。在这些场景下时间冻结的页面依然是不可替代的信息空间。更可能的结果是页面被降级为任务卡片的一种特殊形态当用户需要专注时卡片展开为页面当用户只需要状态感知时页面折叠为卡片。时间展开成为默认范式时间冻结成为主动进入的模式。最后我们必须正视一个前提任务的结构化是驾驶舱范式成立的基础。无论是系统级还是应用级驾驶舱底层都依赖任务的标准节点、异常分支和可调用接口的标准化。目前只有外卖、快递等高度标准化的消费任务能完整适配大量长尾业务还不具备结构化能力。这决定了驾驶舱范式只能从高标准化任务逐步渗透而非全面替代页面。但这场变迁的深层逻辑已经清晰。软件历史上的每一次交互范式演进本质上都在改变人与任务的距离。GUI让人不必记住命令而直接操作对象Agent时代则让人逐渐不必操作对象而开始管理任务。当界面的中心从对象转向任务软件也就从一个被浏览的空间演化为一个持续运行的系统。我们不需要争论驾驶舱会不会来只需要持续观察两个信号系统厂商是否在持续打通锁屏、桌面、通知的任务数据垂直应用是否在把首页从功能入口网格改成任务状态矩阵。这两个方向的推进速度就是交互范式从空间导向的信息空间向时间导向的信息叙事迁移的真实进度条。