标签： 赛道驾驶

结论：一块屏扩成五块屏，成本取决于「一套规则能复用多少」，而不是画了多少张图。我们的赛道 HMI 原型用一套设计令牌加一组布局推导规则驱动 5 种画布，从 456×280 到 1280×720，自动生成 52 张预览。新增一块屏时改的是推导规则，不是重画一套视觉。

五块画布的尺寸与旋转关系

这里有个容易沿用的错误：1.64 寸不是圆屏。它的原生面板是 280×456 的长方形 AMOLED，早期视觉稿里的「400×400 圆表」是过时概念稿。这个数字很重要——它决定了 UI 必须按 456×280 重新排，而不是把圆表缩放过来。

令牌分两层：结构色与语义色

以默认的「厂商（pro）」主题为例，令牌按职责分成两层，这个分层是跨尺寸复用的前提：

结构层可以随主题变化，语义层不可以。红 / 琥珀 / 绿在五套主题中始终对应报警、预警与正常——这样驾驶员换主题后仍然能「不读数值就判断状态」。语义色不得用于装饰，只能承载状态。

布局靠推导，不靠等比放大

这是跨分辨率适配的核心规则：圆表的半径与圆心由可用区宽与高度共同推导，而不是从一个基准尺寸缩放。宽屏下如果直接放大，两个圆表会重叠；按可用区反推半径之后，4.3 寸与 5.0 寸都能保证不重叠。

同理，信息密度也不是线性增长。5.0 寸的底栏比 4.3 寸多一格胎压，这是宽屏专属的密度提升，而不是把 4.3 的布局拉长。反过来，1.64 寸承担不了圈速栈——那个尺寸只做超大数字双格与底部进度条。

两类硬约束：电子纸与浅底主题

电子纸单独一套版式，白底黑字，不套用任何彩屏主题。这不是风格偏好，而是刷新特性决定的：它只用于静态路书与停车状态信息，不显示实时车速、转速或胎压告警。局刷、翻页残影与休眠电流目前仍是待实测项目，在确认波形与刷新能力之前，不能把部分刷新写成必然支持。

复古主题是浅底设计，被明确排除在夜间驾驶首屏之外——浅底在夜间的反差不足。这条排除规则和电子纸一样，属于设计约束而非审美取舍。

余光可读靠排版，不只靠字号

标签统一加字距，数值走 Bahnschrift 类窄体无衬线。窄体能让同样的横向空间容纳更多字符，加字距则让标签在余光扫过时更容易被区分。这两个手段加起来的效果，比单纯放大字号更省空间。

需要提醒的是，预览使用的是系统字体（Bahnschrift / Microsoft YaHei / Impact / Georgia / Consolas）。固件移植前必须选定允许嵌入式再分发的字体，并重新检查文字边界——换字体就会改变字宽，越界检测要重跑一遍。

主题切换在设计上有一个可复现的前提：五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。这让主题对比变成可比较的实验，而不是五次不同的演示。像 鄂尔多斯国际赛车场 这类高差明显的场地，坡度信息在底部辅助条里的价值更高；而赛道数据的赛后分段复盘可以交给 SR-Data 圈速分析套件，HMI 只负责当场能读懂的那一屏。

FAQ

一套令牌真的能覆盖 456×280 到 1280×720？

能。令牌定义的是色板与字号层级，布局由可用区宽与高度共同推导。例如双圆表的半径与圆心会按可用区计算，以保证宽屏下不重叠。

1.64 寸是圆屏吗？

不是。它的原生面板是 280×456 长方形 AMOLED，UI 横屏使用为 456×280，早期视觉稿里的 400×400 圆表是过时概念稿。

为什么切换主题不会重置回放？

因为五套主题共享同一组模拟 OBD 数据、计时与告警状态，主题只改变渲染方式，不重置数据。

语义色可以跟着主题改吗？

不可以。红 / 琥珀 / 绿在五套主题中分别对应报警、预警与正常，主题只改变底色与版式。

参考资料

• 项目 06 —— D:/AI/PROJECTS/kno/README.md（五屏五主题、设计令牌与布局推导）
• 项目 06 —— D:/AI/PROJECTS/kno/style-skill-research.md（原创风格与检索边界）
• 项目 04 —— research/five-board-hardware-facts.md（各板原生分辨率与旋转关系）
• 项目 04 —— research/instrument-matrix.md（风格覆盖规则与 52 张预览）

更新记录

首次发布 2026-10-11 最近核对：2026-10-11

{“@context”:”https://schema.org”,”@graph”:[{“@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”一套设计令牌真的能覆盖 456×280 到 1280×720 五种分辨率？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”能。令牌定义的是色板与字号层级，布局由可用区宽与高度共同推导。双圆表的半径与圆心会按可用区计算，以保证宽屏下不重叠。”}},{“@type”:”Question”,”name”:”1.64 寸车载屏是圆屏吗？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”不是。它的原生面板是 280×456 长方形 AMOLED，UI 横屏使用为 456×280。早期视觉稿里的 400×400 圆表是过时概念稿。”}},{“@type”:”Question”,”name”:”为什么切换主题不会重置 OBD 回放？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”五套主题共享同一组模拟 OBD 数据、计时与告警状态，主题只改变渲染方式，不重置数据，因此主题对比是可复现的实验。”}},{“@type”:”Question”,”name”:”HMI 的语义色可以跟着主题改变吗？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”不可以。红、琥珀、绿在五套主题中分别对应报警、预警与正常状态，主题只改变底色与版式，语义色不得用于装饰。”}}]}]}

延伸阅读

• 回放三入口：可视化订阅与 CAN 硬件回放的边界完全不同

结论：五套赛道 HMI 主题（厂商 / JDM / 赛道 / 复古机械 / 霓虹遥测）只改视觉语言，不改信息架构：它们共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。决定余光可读性的不是配色本身，而是固定位置的告警区、统一字距的标签与窄无衬线大数值。

五套主题改的是视觉语言，不是信息架构

五套主题的差异只落在配色、字形与动效这一层，数据优先级与告警逻辑完全一致。这一点在 kno 赛道 HMI 原型里是硬约束：五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。换句话说，主题是一层皮，不是一套新逻辑。

这条约束的价值在于可验证性。如果每个主题各带一套自己的数据流或计时状态，就没法判断「同一个工况下五种视觉是否都读得出来」——变量太多。把主题限制在视觉层，才能让「换主题」这件事变成纯粹的视觉对照。信息架构本身的设计顺序另见 赛道仪表的信息架构：从圈速到告警的设计顺序。

五套主题分别在强调什么？

五套主题各有明确取向：厂商主题求统一克制，JDM 与霓虹求动效层次，赛道与复古求朴素可读。下表是各主题的视觉规则与数据驱动的动效。

「厂商」是这一轮新增并设为默认的主题。它的参考对象（RaceLogic / AiM MXS / PLEX SDM / MoTeC / Forza / iRacing / SimHub / RaceLab 等）在本轮只以文字描述的形式提供，图片文件不在工作区内，因此该主题是按描述建立的信息架构与原创视觉，未做逐图参考比对。所有图形、文字与布局均重新绘制，不使用任何参考品牌的 logo、商标字体或截图素材。

颜色为什么必须写成「有用途的令牌」，而不是随手取色？

把颜色写成有用途的令牌，是让五块屏、五套主题保持一致的前提；pro 主题的令牌按背景层、文字层、语义层三级组织。

把颜色分成三层，解决的是「改一处、乱一片」的问题。背景层只负责层次，五档灰阶拉开卡片与底条的关系；文字层只负责可读性，主读数与次级、三级文字之间有明确的亮度落差；语义层只负责含义，青 / 琥珀 / 绿 / 红各自绑定一种状态，不参与装饰。语义色一旦被拿去当装饰，告警就不再可靠——这是配色表里最需要守住的一条。

余光可读性靠哪三条规则保证？

余光可读性靠三条可执行的规则：告警位置固定、标签统一加字距、数值走窄无衬线大字号。它们都是可检查的工程约束，不是审美偏好。

第一条是告警位置固定。赛道驾驶时不可能逐字阅读，只能靠余光判断颜色和位置：在 3.5 寸上是顶部换挡灯条加下方四格，告警时水温与油压两格转红并描红边；在 4.3 与 5.0 寸上是右侧独立的告警状态柱，固定显示油压、水温、电压、OBD 四项。位置不随数据变化而移动，是余光可读的前提——告警一旦会「跳」，余光就失效了。

第二条是标签统一加字距（letter-spacing）。中文标签在深底窄间距下容易糊成一团，统一拉开字距能让字符边界在余光下更清楚。

第三条是数值走 Bahnschrift 类窄无衬线字体。窄无衬线在相同物理宽度内能塞下更大的字号，这对 1.64 寸这类小画布尤其关键。

这些主题目前能证明什么、不能证明什么？

能证明的是信息架构与视觉语言的自洽性，不能证明的是任何实机显示与计时性能。原型的自动校验用 Playwright 遍历 5 块屏 × 5 套主题 × 全部副视图，逐项检查：SVG viewBox 是否为各板原生像素尺寸；所有 <text> 元素是否越出画布（用 getBBox() 逐项检测）；SVG 内容中是否泄漏 undefined 字符串；默认主题是否为 pro、主题切换是否生效；以及 OBD 回放推进、计时完成、断连状态、路书翻页、移动端横向溢出等交互状态。

但边界必须写明——这套原型不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度。显示链路的帧率约束可参考 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪。另外两条限制同样要留档：预览使用的是系统字体（Bahnschrift / Microsoft YaHei / Impact / Georgia / Consolas），固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界；圈速、侧向 G、胎压等数值为示意值，档位与油压尚无车型适配，零百计时只使用模拟 OBD 车速，实机须接入受保护的 OBD 网关。

还有一层方法论上的取舍值得记录。本轮在动手之前先检索了可核验的 UI 设计 skill：本机 skill-installer 的 OpenAI curated 目录接口返回 HTTP 403，应用内浏览器的设计系统检索连接超时，本机 visualize skill 的说明明确其用于对话内可视化、不适用于修改现有项目页面。因此本轮没有安装或引用任何未经核验的第三方 skill，风格直接落在已有 HMI 工程里实现。这比先引入一个来路不明的设计系统再回退要省事得多。赛道数据侧可对照 SR-Data 圈速分析套件，赛道几何与圈速基准可参考 上海国际赛车场。

常见问题

赛道仪表的配色应该先定哪一层？

先定语义层，再定文字层，最后定背景层。语义色（青 / 琥珀 / 绿 / 红）绑定告警含义，一旦被装饰占用就失去可靠性；文字层要保证主读数与次级、三级文字有明确亮度落差；背景层只是把卡片与底条分出层次。顺序反了，改配色时会连带改掉信息层级。

JDM 主题和霓虹主题的核心区别是什么？

区别在动效的表达方式。JDM 用机械刻度、实体指针和珊瑚红 / 湖绿实色色块，靠 RPM 驱动分段换挡灯与指针、车速驱动进度块；霓虹遥测则用深色数码排版、青 / 蓝 / 粉色量化条和模块化信息区，靠速度和转速的分段色块推进。前者模仿机械表，后者模仿数码遥测。

切换视觉主题会重置计时或 OBD 数据吗？

不会。五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。这正是把主题限制在视觉层的目的——保证换主题时变量只有一个。

这五套主题能直接烧进固件吗？

不能直接移植。它们用系统字体渲染，且不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度。固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界，并完成实机验证。

本文数据来自星核火花赛车科技内部赛道 HMI 原型项目（kno）的《赛道 HMI 原型（kno 副本 · 统一厂商风）》README（2026-10 版）与《仪表 UI 风格与 skill 检索》（检索日期 2026-10-04）。五套主题共享的 OBD、计时与告警状态均为明确标注的模拟数据；「厂商」主题未做逐图参考分析，参考图仅以文字描述形式提供。文中的 skill 检索结果（HTTP 403、连接超时、visualize 不适用）为 2026-10-04 当次实测结论，仅代表当日状态。本原型不构成对 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度的验证。