结论：当原型扩展到 5 块屏 × 5 套主题 × 全部副视图之后，人工目检一定会漏。capture.mjs 用 Playwright 遍历这个矩阵、输出 52 张预览，并把六类检查写成断言——其中最关键的一条是：用 getBBox() 逐项检测每个 <text> 是否越出画布，把「文字出界」从肉眼问题变成可回归的失败。
为什么人工目检在 5×5 矩阵下必然漏
5 块屏乘以 5 套主题，再乘上每块屏的副视图，需要核对的画面数量在几十到上百量级。人工看图的失效方式很规律：前十几张会认真比对，之后注意力衰减，最后只看「有没有明显崩掉」。而越界的文字往往只差几个像素——恰恰是最不容易被肉眼抓住的那类问题。
更麻烦的是回归：一旦改了某个令牌或布局推导规则，理论上所有尺寸都要重看一遍。人工流程做不到这一点，于是问题会以「上个版本还好好的」的形式在下游暴露。
遍历矩阵与产出
脚本按「屏幕 × 主题 × 副视图」三重循环遍历，每张画面截图输出到 previews/，同时执行断言。最终产物是 52 张预览加一份断言结果——前者用于人工确认视觉意图，后者用于机器判定是否回归。
运行方式上有一个实际操作细节：node 不在系统 PATH 上，必须用完整路径调用，因此脚本入口固定写明了解释器路径，避免在不同机器上以不同的 Node 版本跑出不同结果。
六类自动断言
| 断言 | 检查什么 | 为什么重要 |
|---|---|---|
| viewBox 原生像素 | SVG viewBox 是否等于各板原生分辨率 |
防止某个尺寸悄悄套用了别的画布 |
| 文字越界 | 所有 <text> 的 getBBox() 是否超出画布 |
最容易被肉眼漏掉、也最影响可读性 |
| undefined 泄漏 | SVG 内容中是否出现字符串 undefined |
数据绑定失败的典型症状 |
| 默认主题 | 默认主题是否为 pro、主题切换是否生效 | 防止切换逻辑静默失效 |
| 状态推进 | OBD 回放推进、计时完成、断连状态、路书翻页 | 验证交互状态机而非静态版式 |
| 移动端溢出 | 移动端是否出现横向溢出 | 预览页本身的可用性 |
getBBox 为什么是关键一条
浏览器渲染文本时，元素的实际包围盒由字体度量决定，而不是由设计稿里的数字决定。所以「设计上放得下」和「渲染后放得下」是两件事。getBBox() 返回的是渲染后的真实尺寸，用它逐项比对画布边界，才能把这类问题从主观判断变成布尔结果。
这条断言的直接收益是：改了字号、字距或字体之后，脚本会立刻告诉你哪些画面出界，而不需要人再逐张看。它同时也解释了为什么「换字体」必须重跑校验——字体一换，字宽就变，原本贴边的文本可能立刻越界。
字体是隐性风险
原型使用的是系统字体（Bahnschrift / Microsoft YaHei / Impact / Georgia / Consolas）。这些字体在桌面浏览器上可用，但不一定允许嵌入式再分发。因此固件移植前必须重新选定字体，并重跑一次越界检测。
这类风险的特点是「在原型的阶段看不出来，在移植阶段集中爆发」。把它写进校验清单，而不是留到移植时才发现，是这套流程设计上比较值的一点。
自动校验证明不了什么
边界必须写清楚。这套校验只覆盖原型层的布局与状态逻辑，不证明：ESP-IDF/LVGL 的点屏、SPI/DSI 实际帧率、实车 PID 支持，以及计时精度。所有画面数值均为模拟数据并永久标注 DEMO，档位与油压尚无车型适配，实机须接入受保护的 OBD 网关。
另外两项待实机确认的项：3.5 寸现有固件 DEMO 已采用横屏坐标，但尚未移植这套 UI；1.64 寸的横屏旋转与触摸映射仍待实机验证。浏览器里的通过，不等于屏幕上的通过。
实测之后的链路可以这样分工：赛道上的实时状态由 SR-Telemetry 实时遥测云 以低于 500 ms 的延迟推给场边教练；像 肇庆国际赛车场 这类高差明显的场地，更适合用来验证坡度相关信息的显示优先级。
FAQ
为什么不能靠设计师人工看预览图？
因为 5 块屏 × 5 套主题 × 副视图是上百量级的画面，人工注意力会衰减，而文字越界往往只差几个像素。改一次规则就要全部重看，人工流程无法回归。
getBBox 检测的是什么？
检测渲染后的真实文本包围盒。字体度量与实际渲染尺寸只有在浏览器里才能确定，所以「设计上放得下」不等于「渲染后放得下」。
为什么换字体要重跑校验？
因为字宽会变。原本贴边的文本在换字体后可能立刻越界，必须重跑一次越界检测。
自动校验通过了能直接上实机吗？
不能。它只覆盖原型层的布局与状态逻辑，不证明 ESP-IDF/LVGL 点屏、SPI/DSI 帧率、实车 PID 支持与计时精度；1.64 的横屏旋转与触摸映射也仍需实机验证。
参考资料
- 项目 06 ——
D:/AI/PROJECTS/kno/capture.mjs（Playwright 自动校验脚本）、previews/（52 张预览） - 项目 06 ——
D:/AI/PROJECTS/kno/README.md（校验清单与已知限制） - 项目 04 ——
research/instrument-matrix.md（风格覆盖规则与 52 张预览口径）
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
{“@context”:”https://schema.org”,”@graph”:[{“@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”为什么 HMI 原型不能靠设计师人工看预览图？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”因为 5 块屏乘以 5 套主题再加副视图是上百量级的画面，人工注意力会衰减，而文字越界往往只差几个像素。改一次规则就要全部重看，人工流程无法做回归。”}},{“@type”:”Question”,”name”:”getBBox 越界检测到底检测什么？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”检测渲染后的真实文本包围盒。字体度量与实际渲染尺寸只有在浏览器里才能确定，所以设计上放得下不等于渲染后放得下。”}},{“@type”:”Question”,”name”:”为什么更换字体后要重跑越界校验？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”因为字宽会变。原型使用系统字体（Bahnschrift、Microsoft YaHei 等）且不一定允许嵌入式再分发，移植前必须重选字体并重跑文字边界检测。”}},{“@type”:”Question”,”name”:”自动视觉校验通过后能直接上实机吗？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”不能。这套校验只覆盖原型层的布局与状态逻辑，不证明 ESP-IDF/LVGL 点屏、SPI/DSI 实际帧率、实车 PID 支持与计时精度；1.64 的横屏旋转与触摸映射仍需实机验证。”}}]}]}
发表回复