骑行座舱 OS · 让界面只留下此刻需要的事

产品与交互探索 · 依据 2026 年 7 月 17 日至 9 月 3 日的方案记录整理

骑车时，屏幕不应该变成另一个需要照顾的任务。我想探索的是：能不能把路线、设备状态和必要提醒组织成一眼就能读懂的界面，让骑行者少做选择？

第一条方向：手机即车机

早期 Carline 方案把它定义为软件平台。手机承担主要体验，车辆接入层提供可用的车辆状态与能力；面向用户的座舱负责出发准备、导航、语音和行程结束。

这与 电自圈 的选车、查资料和养车工具不同。社区与复杂服务目录不进入骑行主界面，避免把一个途中使用的界面做成内容门户。

跨品牌接入是探索方向，不能预先假设每辆车都支持同样的数据或控制能力。现有 H5 主要用于验证界面与任务流程，不代表已经接入真实车辆。

第二条方向：手机与车把屏分工

后来在 SteedPilot 与 Aurora Riding OS 的设备探索中，问题变得更具体：手机负责地图、定位和路线计算，车把上的小屏只呈现当前动作、距离与少量状态。

设备不能把「手机在线」当成能否工作的唯一条件。没有新导航数据时，仍应保留时间、电量与本地状态；过期的路线指示则应撤下，而不是看起来还在正常导航。

这两条方向共享减少注意力负担的目标，但属于不同的原型与工程探索，并不是已经合成一个完整产品。

一个屏幕，只保留一个主要任务

2026 年 8 月 30 日的 Riding OS 交互规范给出了明确顺序：安全提示、语音状态、导航、骑行状态、日常座舱。

导航是视觉中心；语音只在需要时出现，避免挤掉转向和距离。骑行中减少菜单与小按钮，复杂设置留到停车后。

我关心的不只是正常页面，也包括重算路线、失去连接、数据过期、语音失败与恢复。不同状态要能被理解，不能都表现成一个转圈图标。

AI 做什么

AI 可以承担查询状态、解释信息或触发受限操作。设备端的动作范围应明确，重要操作由程序检查条件；自然语言不能直接越过执行边界。

Aurora 后续方案尝试将按住说话、语音状态和可切换网关分别管理。这里记录交互与架构思路，不把代码接入、构建成功和完整骑行验收混为一谈。

目前停在哪里

已有手机原型、设备交互规范、模拟器与固件探索。SteedPilot 基于第三方开源项目继续迭代；Aurora 是另一个独立工程，使用现成板卡与第三方组件，不把这些基础能力列为自研成果。

真正的下一步仍是实际使用：阳光下能否看清、戴手套能否操作、风噪下语音是否可用，以及手机锁屏、断连和恢复时界面是否可信。界面截图无法回答这些问题。

原稿依据：Carline 边界决策（2026-07-17）、Riding OS v2 交互规范（2026-08-30）、Aurora 语音网关决策（2026-09-03）；日期来自文档正文标注。