01 · Origin
桌面不缺入口，
缺的是不牺牲导航就能播控的方式
不新造入口。沿 Smartbar 这个已有的全局入口向上展开一个悬浮容器——它不切分屏幕、且可拖到屏幕左右任意一侧，主驾导航与副驾听歌能同时进行。
小窗悬浮于地图之上 · 覆盖 24 款车型 · 主驾导航与副驾听歌同屏共存
沿 Smartbar 向上展开，在 13 种音源、3 块屏幕与多种场景中守住一致性。
不新造入口。沿 Smartbar 这个已有的全局入口向上展开一个悬浮容器——它不切分屏幕、且可拖到屏幕左右任意一侧，主驾导航与副驾听歌能同时进行。
业务需要用户不进入桌面也能快速播控、选歌、切音源。我比较了 4 种承载方案——只有小窗以叠加浮层的方式存在（信息不与底部 Smartbar 重复，导航与音乐也不相互割裂），其余三种方案都在做屏幕的固定分割。
一致性要在三个层面守住：操作、结构、感知。
列表 · 封面 · 歌词——小窗内横滑切换，与应用内是同一套操作。小窗是系统容器，但它的阅读结构和应用内互通，不需要用户重新学习。
歌词模式依赖「歌词数据存在且可读」这个前提，但这个前提对一半以上的音源都不成立——打开就是一大片空白。封面模式作为默认态总是成立，三屏框架在 13 种音源下都能保持完整。
蓝牙音乐不按原生音乐的结构回传——它会把歌词塞进歌名的位置。1.0 阅读重心分散，2.0 把歌名区整体下移，让歌名和歌词都落在小窗下半部分，阅读重心拉齐。同时封面融入背景，沉浸感与一致性同步升级。
旧版区分了音乐和播客，但只到类别级——播客缺倍速、快进快退。我推动的是把识别颗粒度从类别级推进到任务级：听歌需要收藏，听播客需要倍速。
这个方向是我在项目 0→1 阶段提出的设计判断，受限于底层 Media Center 能力当时仅部分落地。几年后同类车机产品陆续实现了类似机制。
一个系统不是 happy path 画完就结束——边界定义出来才算完成。这里有两个独立的判断要做：被打断后该如何恢复 · 切走时音源是否该消失。
动态音源（浏览器 / Link / CarPlay）接入了媒体中心，常规冲突仲裁规则存在。但被未接入媒体中心的音频（手机视频、K歌、系统Tele呼叫等）打断后，恢复行为是黑盒的——会出现空状态、无法播控、甚至类似bug的表现。我梳理了所有打断场景下的异常表现，推动跨业务修改。
用户从 CarPlay 切到蓝牙听歌时，小窗里的 CarPlay 该立刻消失吗？两个方案都合理——我选了方案 B。判断依据：「不想听了」的真正信号应该来自连接状态的变化，而不是切换行为本身。这个判断通过上线前的用户反馈验证并修正。
主副驾用小窗，因为有强多任务并行需求。后排不一样——多任务需求弱、多屏多开性能受限，同一套系统级承载思维在后排走了另一条路：能进就进应用，不能就进公共播放器。后排还经历了两代框架（桌面卡片 → 视频流 + Dock），两代里这套思维都成立。
高层改框架——首页铺视频流、底部仅留 Dock，桌面卡片这个承载消失了。重新做选择：沿用前排小窗，还是直接进应用？
覆盖窄是结构性事实——能进应用的进应用，进不去的兜在公播。这个容器不重做应用，它的设计是另一个判断：模式继承应用，能力继承小窗——靠近熟悉的应用记忆，又不越过小窗的克制。
公共播放器原本是孤立的兜底，装着动态音源（Flymelink、CarLink、浏览器）和跨屏分身应用。我把它并入了应用之间的音源切换体系——一个稳定的切换控件，在任何应用页和公播之间互通。
下一步：让公播把音源直接交给应用接管，用户播控不中断。需要应用侧二次适配，正在推进中。
同一套方法，我也用在了其他媒体业务上。
13 种音源、3 块屏幕、多种场景、两代后排框架——所有判断都守在三条主线上。
三屏框架与应用内一致、封面模式作为默认态、阅读落点跨音源稳定——让小窗在任何音源下都是可预期的容器。
识别颗粒度从类别级推进到任务级、能力级开放给三方应用——让系统真正知道每种音源需要什么。
黑盒边界定义、公共播放器在体系里的角色、后排两代框架的承载思维一致——让小窗、应用、公播之间的关系是设计过的，不是拼出来的。