车载 HMI 设计规范

面向设计师、人因工程师与车机工程师：让车里的每一次交互都能在不把眼睛长时间从路上挪开的前提下完成、可以随时被打断又接得回来；让除霜、危险报警、雨刮、灯光这类安全相关功能不必先在菜单里找；让驾驶关键的信息出现在驾驶员本来就在看的地方。

车载 HMI 的规范对象是车内那块屏和那些控件：仪表、中控屏、抬头显示、方向盘按键、旋钮与拨杆、车内语音、座椅与空调面板，以及它们共同构成的一次次交互。这些交互与手机上的交互有一个决定性的差别——用户的主任务不在屏幕上。屏幕上的任务再重要，也排在"看路、控制车辆"之后；产品对界面提出的每一项要求，都在从一件正在进行的、失败代价很高的实体任务里借用资源。

这个领域最常见的设计错误有三种，本规范的切分直接对着它们：一是把手机的交互密度整体搬进车里——多级菜单、需要读完才能选的列表、靠视觉动效表达状态，于是完成一件事要看好几眼屏幕；二是把物理控件当成成本项一并取消，把除霜、雨刮、灯光、危险报警塞进触屏菜单的第二层第三层，在最需要它们的时刻反而最难够到；三是把"信息展示出来了"当成"驾驶员知道了"，把驾驶关键的提示只放在中控屏上，而驾驶员的视线本来落在仪表和路面。

本规范由六条原则和 35 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（VH3-2 就是第三条原则下的第二条规则）。

范围声明本规范约束车内人机界面对驾驶员与乘员作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不指定组件、座舱域控方案或显示技术。采用本规范不能替代下列专项评估与合规判定：车辆功能安全（ISO 26262）与预期功能安全的判定、各法域的法规符合性认证（UN ECE 各项法规、GB 强制性标准及各属地准入要求）、仪表的法定标识与照明法规、座舱物理布置的人体工程尺寸与视野校核、无障碍与适老化的专项要求、隐私与数据合规。这些领域在本规范中只作为引用来源与范围排除出现：本规范不复述其数值，也不以其条文为自己的条款背书。

关于数值：本领域的公开指南中确有以时间为单位的判据（例如对单次注视时长与任务总占用的限制），但它们各自绑定特定的测试方法、任务类别、适用对象与自愿性说明，脱离这些条件引用等于伪造依据。因此正文一律不搬运数值门槛，只要求相关上限被显式定义、有测定方法、有依据出处、可被复核；产品实际采用的取值由《Design Token》承载，并分别受适用法规、所选评测方法与产品自身验证约束。来源与核验状态见 reference.md。

阅读入口：第 1 章把任务转为设计决定，第 2 章查规则，第 3 章查完整要求，第 4 章查术语，第 5 章查状态与组件，第 6 章做交付与验收。参数见 Design Token。

---

先确定车辆状态与操作主体¶

本规范的绝大多数义务只在车辆处于行驶相关状态且操作者是驾驶员时以完整强度生效。应用规则前必须先确定这两件事，否则会出现两类错误：把停车充电时的全屏视频当成违规，或者把副驾在用的地图当成驾驶员在用。

"行驶中"的具体判据（速度、档位、驻车制动、运动状态或其组合）由产品定义并记录在 veh.lockout.trigger，本规范不规定唯一判据，但要求判据被显式定义、可解释、在边界值附近不来回抖动（见 VH1-4）。

1. 六条原则¶

六条原则按规范对象切分设计责任：每条原则管辖一类对象上的义务，每条规则按其义务的直接规范对象归属唯一原则。对象不同，原则就不会互相替代——这是切分的依据，也是检验切分的方式。

为什么这样切分：前四条原则沿着"一次交互占用什么资源"这条线依次收窄——VH1 管这次交互本身要多少注视与操作，VH2 管够不够得到这个功能，VH3 管信息出现在哪个位置，VH4 管它什么时候出现、和别的东西怎么排队。这四件事在真实项目里由不同角色决定（交互设计、硬件与整车布置、显示分工、告警策略），归属清晰。VH5 单独成条是因为非视觉通道在车内被系统性高估：它常被当成"解决了分心问题"的答案，而实际上它引入的是另一类占用与另一组失效模式，需要自己的成立条件。VH6 单独成条是因为座舱与个人设备的根本差别——一辆车在生命周期里会被多个人开、多个人坐、还会被转手，把个性化和账户当成单用户问题处理是这个领域的持续错误。

两处最需要持续检验的边界，在此明示：VH1 与 VH2——"这个功能行驶中不该让人操作"（VH1-4，锁定判据）与"这个功能行驶中必须够得到"（VH2-1，可达性）看起来相反，实际管的是两类不同对象：VH1 管的是一次交互对注视资源的占用是否可接受，VH2 管的是一个功能在车辆控制上的必要性是否要求它绕开屏幕导航。除霜同时被两条触及——它不能被锁定（因为它是安全相关的车辆控制），也不该要求连续注视（因为它在行驶中被使用）；归属依据是义务的直接规范对象："必须有不依赖菜单导航的入口"归 VH2，"这个入口的操作不得要求连续注视"归 VH1。VH4 与 VH3——同一条提示信息，"它该出现在仪表还是中控"归 VH3（承载分工），"它现在该不该出现、和另外三条提示谁先"归 VH4（时机与仲裁）。这两处若在实践中反复出现归属争议，应当调整原则的切分，而不是增设中间层或补充说明。

互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A.7 的分类检验验证。检验不过，修改的是原则的切分。原则用于理解规则与裁决归属，本身不作为单独的判定条目；原则与具体条款的解读冲突时以适用条款为准，并记录需要澄清的歧义。

规则归属唯一，不等于机制不能复用。一套"当前驾驶负荷"的估计既是非必要信息的抑制条件（VH4-2）、也是交互深度收敛的输入（VH1-6）；一套"当前操作者是谁"的判定既决定乘客豁免是否成立（VH1-5）、也决定个性化写到哪个主体名下（VH6-3）；一套行驶状态判据既触发功能锁定（VH1-4）也影响显示分工（VH3-2）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

1.1 从一项任务开始设计¶

先选择一个真实成果，例如“前风窗起雾时开启除雾”，再决定入口、回执与验证。不要从屏幕布局或 Token 清单开始。

1.2 常见问题的方案选择¶

2. 规则的读法¶

2.1 每条规则的结构¶

一句话概括各部分的效力：规则正文规定要求；适用与边界条件共同限定要求的适用范围；设计应用、验证示例、反例与依据参考不另行增加义务。

规则写行为性质、不写实现方式：一项功能在行驶中必须能在不连续注视屏幕的条件下完成，这是产品行为；它用旋钮、用方向盘按键、用固定位置的常驻触控区还是用语音，是工程与整车方案——两者必须对得上，但不是同一份交付物。本规范也不规定物理尺寸、布置角度与操作力，那属于范围声明中排除的人体工程与法规范畴。

2.2 约束词¶

规则正文使用三级约束词：

• 必须：不满足即不符合本规范。缺了它，某条对驾驶员或乘员的承诺会在可预见的情境下失效——这是标「必须」的唯一依据。
• 禁止：与「必须」同等强度的反向表述，指明不得出现的行为；正文中的「不得」与「禁止」等价。
• 应当：默认遵循；确有理由偏离时，记录理由与替代做法，并接受同样的验证。偏离不需要审批，但需要留痕。「不应当」是「应当」的反向表述。

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束（VH1-6、VH4-6、VH5-3、VH5-5、VH6-6 含此类子句），规则标题与速查表的强度标注不替代子句约束力。正文中的「不能」仅用于能力或事实陈述，不表达义务。

强度表示约束力，不表示重要性。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而把车机做成一块不能用的板子。车载 HMI 被做坏的方式在两端都很密集：一端是把手机交互原样搬进来，行驶中让人翻三级菜单找除霜；另一端是因为怕被判分心而把行驶中能做的事砍到只剩音量——导航目的地不能改、空调温度要靠语音说三轮、副驾拿着屏幕什么也点不动。后者同样是没做对：把功能锁掉不等于降低了风险，它常常只是把交互赶到驾驶员的手机上去，而手机上的交互没有任何锁定。克制不等于阉割，安全不等于不可用。

2.4 规则速查：35 条¶

下表是全部规则的一句话记忆版，点击规则名可跳到第 3 章的完整正文。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句（VH1-6、VH4-6、VH5-3、VH5-5、VH6-6），判定以正文为准（见 2.2）。

VH1 驾驶任务优先

VH2 关键功能不藏在屏幕深处

VH3 信息落在对的位置

VH4 打断按后果排序

VH5 车内的多通道有成立条件

VH6 座舱是多人共用的

3. 规则详解¶

本章按六条原则展开全部 35 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一组件、不指定车型平台，也不要求新增独立交付文档。条款中提到的 veh.* 字段见《Design Token》。

3.1 VH1 驾驶任务优先¶

驾驶员在车里的注视、双手与注意力都是有限且已经被占用的资源。这条原则管的是一次交互向这些资源伸手要多少、在什么条件下必须撒手、以及撒手之后还接不接得回来。它不管这个功能该不该存在，也不管它放在哪块屏上——那分别是 VH2 与 VH3 的事。

VH1-1交互不要求连续注视必须¶

一句话：任何一件事都要能靠几次短暂扫视做完，而不是盯着看完。

适用车辆处于行驶相关状态时，驾驶员可操作或可被要求阅读的全部车内界面功能。

规则行驶中对驾驶员可用的每一项功能，必须能在一系列离散的短暂扫视中完成，禁止存在只能通过持续注视屏幕才能完成的步骤。产品必须声明其所采用的测试协议（记录在 veh.glance.method），协议须写明所用指标、单位、统计量、样本判定规则、任务起终点、受测人群与协议出处；判定按该协议的完整判定规则作出，不由一两个标量代替。产品必须记录所选协议的累计视觉占用上限（veh.glance.total_max），显式区分实际眼动的累计离路注视时长与遮挡法的累计开启时长。在协议之外，可另设项目的单次注视硬上限（veh.glance.single_max）；采用的每项判据均须附测量方法、指标、统计量与依据出处，本规范不规定数值。次数不等价于累计时长：注视次数可作为独立的设计约束，不得替代累计时长上限；单次最大值、均值与长注视占比是不同的统计量，不得互相换算；任务累计时长与这三者分别记录。遮蔽法等替代范式的结果不得被填写为实际的眼动测量结果，其适用范围按所选协议声明。上限的取值来源必须写明其绑定的测试方法、任务类别与适用对象——公开指南中的时间判据各自附带这些条件，脱离条件搬运数值不构成依据（见 reference.md）。不满足上限的功能按 VH1-4 处理：改造成满足上限的形态，或在行驶中限制。"驾驶员会自己注意路况"不作为通过依据。

边界条件本条不要求乘客侧界面满足同一上限（豁免的成立条件见 VH1-5），不适用于驻车状态，也不要求行驶中提供全部功能。本条约束的是完成任务所需的视觉占用，不约束驾驶员自愿的多余注视。设计层级的上限只能前置约束界面形态，不能代替完整任务的驾驶负荷验证。

设计应用把"读完才能选"改成"扫一眼就能选"。列表长度、单屏文字量、层级深度、需要比较的项数都是视觉占用的输入；减少任一项都能降低占用，增加控件尺寸通常不能。需要阅读的内容改由听觉承载时，其占用按 VH5-4 另行计入，不自动归零。

验证示例

• 用户侧：在产品选定的测定方法下（如遮蔽法或跟车任务），由未参与设计的被试完成该功能，记录每次扫视与完成整件事的总占用。
• 实现侧：检查每项行驶中可用功能是否有对应的测定记录与测定日期；检查新增功能与改版是否在上线前经过同一测定，并覆盖变更所影响的任务。

反例做不到——行驶中修改导航目的地要读完十几条候选并比较其中的路名；做过头——把所有列表砍到三项且不可滚动，用户要找的那个永远在第四项，于是他掏出手机操作，而手机上没有任何上限。

依据与参考公开指南中确有单次注视与任务总占用的验收判据，但它们分属不同测量协议、各带样本判定规则与自愿性说明（R01、R03、R07、R16；方法标准见 R04、R06）。风险方向的实证见 R19，其中「非特定离路注视本身不显著、查看后视镜甚至降低风险」是本条只约束完成任务所需占用而不约束任何注视的直接理由。

VH1-2任务可分段中断并从中断处继续必须¶

一句话：路况一变就能停下，路况好了从停下的地方接着做。

适用行驶中可用的多步任务，含目的地设置、通信、媒体检索、车辆设置与账户操作。

规则行驶中可用的多步任务，必须可以在任意两步之间被驾驶员主动中断，也必须能被系统按 VH4 的仲裁让位。中断时已完成的部分与未提交输入必须保留。恢复之前必须核验车辆状态、所涉对象与后续步骤是否仍然有效：仍然有效的从中断处继续；中断点已失效时（路口已驶过、候选已过期、所选对象已不存在），恢复到一个可解释的逻辑节点并说明原因，避免不必要的重输。仍有效的已完成部分禁止要求重做，也禁止把已失效的中断点强行恢复。中断点必须落在语义完整的边界上：禁止在一步的中途丢弃已输入内容，也禁止把中断处的半成品当作已提交而产生实际后果。恢复的有效期、恢复入口与过期后的处置必须显式定义（记录在 veh.lockout.resume.ttl）。

边界条件本条不要求无限期保留中断状态，也不要求已经产生物理后果的动作可以撤销；已经发生的物理后果须如实说明，输入保留义务不因此免除。涉及支付、外发通信等有外部后果的步骤，恢复时须重新确认而不是自动续做。保留数据与继续展示界面是两件事：车辆进入行驶相关状态时收起键盘或输入面板是合规的收敛（见 VH1-6），只要数据不因此丢失、也不因此被提交。

设计应用把长任务切成可以各自结束的段，每段结束时状态是干净的；不要把"用户中途走开"当成异常分支，那是本领域的常态路径。恢复入口应当出现在用户下一次自然会看的地方，而不是要求他记得去哪里找。

验证示例

• 用户侧：在输入目的地的第二步触发一次来电，通话结束后观察是否回到第二步且第一步的输入还在。
• 实现侧：对每个多步任务列出其中断点清单与各点的持久化范围；检查恢复过期后的表现是否与声明一致。

反例做不到——目的地输了一半，来了电话，回来要重输；做过头——三个月前的半截任务在每次上车时都弹出来问要不要继续，恢复提示本身成了打断源。

依据与参考R02 的 4.3.4.2 与 4.3.4.3、R03 第 5 章均要求交互序列可被中断且能从中断点或另一逻辑点恢复。两者都未规定恢复的有效期，本条的有效期要求是从承诺反推。

VH1-3系统不自行制造非请求的注视必须¶

一句话：不要用动画、自动跳转和倒计时把驾驶员的眼睛拉过来。

适用行驶中驾驶员视野内的全部显示位，含中控屏、仪表、抬头显示与氛围灯等具备信息表达能力的元素。

规则系统禁止在缺少驾驶相关必要性的情况下，通过动画、自动跳转、自动播放、内容轮播、倒计时、闪烁或显著的视觉变化把驾驶员的视线吸引到屏幕上。行驶中的界面变化必须由用户操作或已按 VH4-1 分级的事件触发。"系统没有要求用户看"不等于"用户不会看"：变化的视觉显著性本身构成注视诱导，显著性的允许范围由产品定义（记录在 veh.surface.motion.policy）并纳入 VH1-1 的验证。倒计时与自动推进尤其受限：它们把不看的代价转嫁给用户，禁止用于非安全相关的内容。

边界条件本条不禁止驾驶相关的必要变化——转向提示的更新、告警的出现、模式变化的呈现都不受本条限制，它们的时机与分级按 VH4 判定。本条也不要求界面完全静止。

设计应用区分"状态变了"和"要你现在看"。前者可以用低显著性的方式落到位，等驾驶员下次扫视时被发现；后者才需要显著变化，而它必须先通过 VH4-1 的分级。

验证示例

• 用户侧：行驶中不进行任何操作，记录一段时间内界面自行产生的显著变化次数及其触发来源。
• 实现侧：检查每一处动效与自动跳转是否能指名其触发事件与所属等级；无法指名的即为本条要防止的情形。

反例做不到——中控屏在行驶中循环播放促销卡片，或应用商店的更新提示带着动画滑出；做过头——为避免任何变化，把转向提示也做成静止的，路口过了才更新。

依据与参考R02 的 4.3.1.3 要求系统不以视觉方式娱乐驾驶员；R03 的 Annex 2 禁止行车中显示动态影像与滚动文字；R13 以动画帧率作为判据、R15 禁止动画元素与自动滚动文本，说明这类约束在平台层已被机制化。本条的「须能指名触发事件与所属等级」是本规范的设计推导。

VH1-4行驶中的限制有判据、可解释必须¶

一句话：锁掉一个功能要说得出依据，也要说得出什么时候能用。

适用任何在行驶中被锁定、灰显、收窄或改变形态的功能。

规则任何在行驶中被限制的功能，必须有显式的触发判据（记录在 veh.lockout.trigger）、显式的例外清单，以及对用户可见的解释——说明现在为什么不可用、什么条件下可用。

用于限制判定的每一项车辆运行事实必须带来源、采样时刻与有效性。未取得足以证明可以放宽的有效证据时，不开放驻车专属功能——未收到车速、休眠唤醒后读到的旧驻车值、档位与制动信号时间戳互相矛盾、零速但非驻车，都属于证据不足，禁止凭最后一次已知的"已驻车"长期解锁；此时车辆的关键控制仍须可达。连续量判据必须定义滞回，离散信号必须定义去抖或稳定判定，禁止在临界点反复通断；但任何一种稳定化处理都不得不当延迟本应生效的限制。自动化模式下的放宽同样须核对该模式下驾驶员的实际职责。锁定是可选的风险控制手段之一，不是默认策略：一项功能被锁定前，必须先评估它能否被改造成满足 VH1-1 的形态，并评估锁定后用户的实际替代路径——包括"用户会转到手机上操作"这一条，这条路径上没有任何限制，把它算作零成本是本条要防止的判断错误；但替代路径的评估不得用来豁免已经适用的禁用类要求，也不得把"用户会转用手机"当成已被证实的必然后果来抵消一项适用要求。落入适用法域、评分规程或企业标准的禁用范围的内容，按其要求锁定，本条不提供减免。VH2-1 清单内的安全相关功能禁止被信息娱乐的分心策略锁定；车辆自身的动作互锁仍然有效，例如运动中拒绝不允许的换挡请求。入口可达不表示任何状态下均可执行。

边界条件本条不规定"行驶中"的唯一判据，速度、档位、驻车制动、运动状态或其组合都可以，要求的是判据被显式定义并可解释。具备驾驶自动化能力的车辆，产品必须明确每种模式下人的监控与接管职责；自动化处于激活状态不自动解除本条的限制要求——驾驶员随时可能被要求接管，限制的放宽必须与该模式下驾驶员的实际职责相称，不与系统的营销名称相称。

设计应用先问"这件事能不能做成扫一眼就完成"，再问"要不要锁"。确需限制时，把解释与恢复条件写在用户会看到的地方，而不是只留一个灰掉的控件。

验证示例

• 用户侧：在临界车速附近反复通过，观察功能是否反复通断；点击被限制的功能，观察是否给出原因与恢复条件。
• 实现侧：列出全部被限制功能及其判据与例外；检查每项是否有"是否可改造"的评估记录。

反例做不到——一批设置在行驶中灰掉，既不说为什么也不说什么时候能用；做过头——只要车速大于零就锁掉几乎全部功能，包括副驾正在用的媒体检索，用户于是全程使用手机。

依据与参考R02 的 4.3.5.3 要求不供行车中使用的功能做到无法交互；R12、R14 说明限制集与驾驶状态的映射由整车厂配置而非平台常量，支持本条把判据与范围定为产品输入。「替代路径含用户转到手机」这一评估要求，本次未找到直接支持的公开来源，是从失效模式推导的设计判断。

VH1-5乘客豁免须有成立条件必须¶

一句话："我是乘客"这句话本身不是豁免依据。

适用以"当前操作者不是驾驶员"为由放宽行驶中限制的任何机制。

规则按"操作者是乘客"豁免行驶中限制的，必须有可陈述的判定依据，且依据必须强于一次声明式点击。判定依据、误判方向与误判后果必须显式记录（veh.occupant.role.evidence）。豁免的默认方向必须偏向保守：判定不成立或证据不足时按驾驶员处理。豁免的作用范围限于该乘客可触及的显示区域与输入设备；禁止让乘客侧的豁免改变驾驶位上的呈现（见 VH6-2）。操作者依据与内容暴露条件必须同时成立：可靠地判定操作者是乘客，不自动允许在驾驶员可见区域呈现驾驶中受限的内容——共享中控屏、可被驾驶员视线覆盖的区域与可能产生反射的呈现都属于暴露条件的一部分，须一并评估并记录。乘客侧具备独立且有效隔离的显示与输入时，该路径不因保守而被一律禁用。豁免机制本身禁止要求驾驶员参与确认——那把一次豁免变成了一次驾驶员操作。

边界条件本条不禁止把声明式确认用作多项证据之一，禁止的是把它作为唯一依据。本条不要求配备特定的乘员感知能力；不具备时，按不成立处理并保留驾驶员侧的限制，这是合规结果。

设计应用可用的证据包括操作发生的物理位置与视角、座椅占用状态、输入设备的归属、以及与驾驶员输入在时间上的互斥关系。证据组合的判定规则应当写下来并可复核，而不是散落在若干条件判断里。

验证示例

• 用户侧：由驾驶员从驾驶位尝试触发乘客豁免路径，观察是否成立。
• 实现侧：检查豁免判定的证据项与阈值是否可列出；检查证据缺失时的默认分支是否为"按驾驶员处理"。

反例做不到——一个"我是乘客"的勾选框解锁全部功能，驾驶员点一下即可；做过头——副驾侧屏幕在行驶中一律不可用，连音量都要驾驶员代劳，风险反而转移到了驾驶员身上。

VH1-6行驶状态变化时的收敛与恢复有定义应当¶

一句话：车动起来的时候，界面怎么收；停下来的时候，怎么放回去。

适用车辆在静止与行驶相关状态之间切换时的界面行为。

规则状态切换时界面的收敛与恢复行为应当被显式定义：哪些内容收起、哪些保留、恢复时回到哪一步（记录在 veh.lockout.transition）。收敛禁止丢失用户未提交的输入，也禁止把未提交内容当作已提交（见 VH1-2）；收起输入界面本身是合规的收敛手段，本条约束的是数据的存续而不是界面元素必须留在屏上；恢复禁止自动把用户带回一个需要长时间注视的界面，也不得在车辆刚停稳的瞬间自动展开大量内容——那个时刻驾驶员可能正在完成停车动作。状态在短时间内反复切换时（拥堵、走走停停）应当有抑制，避免界面反复变形；抑制的窗口由产品定义并记录依据。

设计应用收敛的目标是降低占用，不是清空。被收起的内容应当在同一处以可预期的方式回来，而不是要求用户重新导航过去。

验证示例

• 用户侧：在低速拥堵路段行驶一段时间，记录界面因状态切换而发生形态变化的次数。
• 实现侧：对每一处收敛行为，检查其恢复路径是否被定义、未提交内容是否被保留。

反例做不到——起步瞬间界面整体切换，用户刚输入的内容消失；做过头——停车之后要手动逐层展开才能回到刚才被收起的东西，收敛变成了单向操作。

3.2 VH2 关键功能不藏在屏幕深处¶

有些功能与车辆控制直接相关：看不清前风窗时要除霜，故障停在路边时要开危险报警，下雨时要雨刮。这些功能被需要的时刻，恰好是驾驶员最没有余裕去找它们的时刻。这条原则管的是这类功能够不够得到、摸不摸得着、会不会移位、以及系统出问题时还在不在——不管它们的操作占用多少注视（那是 VH1），也不管相关信息显示在哪儿（那是 VH3）。

VH2-1安全相关功能不只存在于触屏菜单深处必须¶

一句话：除霜、危险报警、雨刮、灯光，不该先翻菜单才能找到。

适用全部具备车内人机界面的车辆，不论其自动化能力。

规则产品必须显式定义一份关键功能清单（记录在 veh.control.critical.set）。清单以功能＋动作为条目单位，每个条目必须记录：本车是否配备、收录或判为不适用的依据、免导航入口要求、可盲操作要求、以及该条目是驾驶员专属还是允许乘客协作（例如协助开启危险报警，不含换挡与车辆运动控制；对应 VH6-2）。

下列条目必须逐项核对并各自给出结论：转向信号（左／右开启）、换挡（前进／空挡／倒车位选择）、危险报警闪光灯（开启／关闭）、喇叭（鸣响）、前风窗与后风窗的除霜除雾（开启／关闭）、前雨刮与后雨刮及洗涤（开启／调速／关闭／喷洗涤液，手动模式）、前照灯与位置灯的手动控制（开／关，含远光开／关）、已配备的紧急呼叫（发起），以及适用法域与所参与的第三方评分规程另有要求的项。本车确实不配备某条目时记为不适用并写明依据（例如无后雨刮、无后风窗加热）；不适用是合格结论，本条不要求为凑清单虚构硬件，但不得以「未列入清单」代替这次核对。

清单内每一项禁止只能通过触屏的菜单导航到达：必须存在一个不依赖菜单层级、不依赖当前前台应用、不依赖屏幕解锁或唤醒的入口。入口的形态由产品选择——物理控件、方向盘固定按键、或屏上位置固定且常驻的直接控件都可以，本规范不指定形态，只要求入口不依赖上述四项。

音量、温度、座椅加热等普通高频功能另记在 veh.control.frequent.set，不进入关键功能清单：它们适用 VH2-2 的可盲操作要求，但不承受 VH2-6 的失效可达义务，也不受 VH6-2 对关键功能状态的乘客禁止——把它们混入关键清单会同时稀释关键项的可达性并误禁乘客调整自己一侧的共享状态。

边界条件本条不判定属地法规对物理控件的强制要求，也不替代任何第三方评分规程的评分判定（相关公开政策见 reference.md），产品仍须自行确认适用要求并可在清单中扩充。本条不要求所有功能都有免导航入口——清单之外的功能不受本条约束，清单的边界是本条以及 VH2-2、VH2-5、VH2-6 的判定单位。VH2-3 与 VH2-4 不以本清单为判定单位：前者适用于全部近手控件，后者适用于行驶中可被触发的全部车内输入，二者对清单外的控件同样成立。

设计应用把必查条目表做成一张逐行填写的核对表——功能、动作、是否配备、依据、免导航入口形态、盲操作特征、乘客协作范围——空行即缺口。清单一旦确定，它就成为 VH2-2、VH2-5、VH2-6 的共同作用对象，也成为 VH1-4 的锁定禁区。

验证示例

• 用户侧：在全屏第三方应用运行时、在车机刚上电时，分别计时到达清单内每一项所需的操作步数与是否需要看屏。
• 实现侧：调取清单及其依据表，逐条核对必查条目都已给出结论；对记为不适用的条目核对该硬件确实不存在。检查每一项的入口是否在任一前台状态下都可达；另取一台无后雨刮的车型验证「不适用」不被判为缺项，并验证乘客调整自己一侧的温度不因高频功能被误判为违反 VH6-2。

反例做不到——除霜位于"空调—更多—车窗"第三层，危险报警在屏幕顶部下拉栏里；做过头——把二十几项功能全做成物理按键排成一片，形成摸不出差别的按键海，反而无人能盲操作（见 VH2-2）。

依据与参考R08（Driver Engagement）§2.2.1–2.2.4 按功能＋动作逐项规定可判 pass 的实现方式，并区分直接物理输入、直接触控输入与不超过两步的菜单式触控输入——例如转向信号、换挡、危险报警、e-Call、喇叭、远光、雨刮（手动模式）与车辆辅助的设定车速要求直接物理输入，而外部灯光开关、前照灯高度调节、后风窗除霜可接受不超过两步的菜单式触控。本条的必查条目参照该表与 R23 的适用范围。R27（SD-203）§1 规定不存在的功能/动作一律记 N/A，本条的「不适用」处理沿用这一做法。

两处本规范比来源更强，须作为本规范自己的主张记录：其一，R08 允许部分条目使用菜单式触控，本条对清单内全部条目要求免菜单导航入口；其二，VH2-2 对清单内各项要求可盲操作，R08 只对「直接物理输入」类条目要求可凭触感发现位置。这两项加强的必要性与目标人群验证由产品承担，不得用该评分规程为其背书。R08 是消费者评级规程而非法规，其后果是评分而非禁售；未承诺参与该评级的产品不因不满足其判据而被判为「认证不合格」。R23 只管控件位置、识别、颜色与照明，不等于法规要求物理按键。

VH2-2关键控件可盲操作必须¶

一句话：手伸过去就能找到、能确认，不用低头看。

适用VH2-1 清单内功能的入口控件，以及行驶中高频使用的音量、温度等控件。

规则清单内的控件必须能在不注视的条件下被定位、识别与确认三件事都完成：定位依靠稳定的物理位置或可触觉区分的边界，识别依靠位置、形状或质感而非仅靠印刷与屏幕标识，确认依靠非视觉回执（见 VH5-3）。仅靠视觉标识区分的平整触控区不满足本条——手指摸不出边界的区域不构成盲操作入口。控件之间需要被区分时，其触觉差异必须是设计出来的而不是碰巧存在的，并且必须在戴手套等产品声明支持的条件下验证。

边界条件本条不规定控件的尺寸、间距与操作力，那属于范围声明中排除的人体工程与布置范畴；本条规定的是"可被非视觉地定位与识别"这一行为性质。本条不禁止在物理控件上叠加视觉标识。

设计应用触觉区分的手段包括位置基准（沿边缘、贴着某个固定物）、形状差异、表面质感差异与操作方式差异（旋、拨、按）。差异的数量有认知上限，把每个键都做成不同形状会让识别本身变成负担。

验证示例

• 用户侧：被试在不看的条件下从常规驾驶姿势触发清单内各项，记录成功率与首次触碰到目标之间的错误触碰。
• 实现侧：列出各控件的触觉区分特征；检查是否有仅靠印刷或屏幕标识区分的相邻控件。

反例做不到——除霜做成一片平整触控区，四个图标并排，手摸不出摸到了哪个；做过头——每个按键做成不同异形，形状记忆的负担超过了找按键本身。

依据与参考R08 §2.2.2 要求相关交互区可触觉识别或足够大且分隔；R01 的 V.I 与 R02 的 4.3.4.1 均要求驾驶员能保持至少一只手在转向控制上。本条不采用 R08 的尺寸门槛数值，因其与该协议的间距条款耦合且属另一体系（见 R25 的边界说明）。

VH2-3近手控件的功能绑定稳定且可知必须¶

一句话：同一个按键这次是什么、下次还是什么，要说得清。

适用方向盘按键、拨杆、中控旋钮等驾驶员不需要移动身体即可触及的控件。

规则承载 VH2-1 清单内条目的近手控件，其清单内绑定必须保持稳定，不因上下文、前台应用或临时模式改变；同一控件上的其他（非清单）绑定可以按预先明示的规则随上下文变化，但不得取消、遮蔽或移走清单内条目的入口。其余近手控件的绑定可以随上下文变化，但只能按产品预先明示并记录的规则改变（记录在 veh.control.nearhand.binding）：变化的触发条件、变化后的功能集合与复位路径都须事先确定，禁止随前台应用任意改变。任何随上下文变化的绑定，其当前功能必须能在不长时间注视的条件下被知晓（提示落在哪个显示位由 VH3-2 的分工定义）。临时模式（洗车、拖车、展示、维修等）可以改变非清单控件的绑定，但不得取消或移走清单内条目的入口。****同一控件禁止在 VH2-1 清单内功能与非清单功能之间动态复用——那让盲操作失去前提。绑定可被用户配置时，配置必须可复位，且复位后的默认绑定必须是确定的（见 VH6-3）。

边界条件本条不禁止上下文相关的控件，禁止的是变化不可知或不可预期。用户明确进入的临时模式可改变非关键绑定，但进入、当前绑定与退出必须可辨，关键入口保护仍成立。

设计应用把近手控件分成两类分别对待：一类永久绑定（音量、通话、清单内功能），一类上下文相关（媒体、导航、辅助驾驶）。两类之间的分界写下来，不随前台应用或账户改变。

验证示例

• 用户侧：在三种不同前台应用下按同一按键，记录行为是否一致或变化是否与用户预期相符。
• 实现侧：列出每个近手控件的全部可能绑定及其触发条件；检查是否存在跨清单边界的复用。

反例做不到——方向盘滚轮在媒体界面是音量、在导航界面变成缩放，用户按下去才知道；做过头——全部近手控件永久固定，用户最常用的新功能没有任何方式放到手边，只能去屏上找。

VH2-4误触在颠簸条件下的后果受限必须¶

一句话：车一颠碰到了，不能因此发生要紧的事。

适用行驶中可被触发的全部车内输入，含触屏、物理控件与手势。

规则车内输入必须按振动、颠簸与横向加速条件下会发生非预期触发这一前提设计，禁止以"驾驶员会小心"作为设计假设。会产生难以撤销后果的操作，禁止只由一次瞬时单点触发；其确认方式应当利用不易被颠簸复现的动作特征——特定位置、持续时长、方向性动作或二次动作，而不是仅靠加大控件。可逆操作在误触发生后必须有撤销路径，且必须能在不长时间注视的条件下使用。已产生物理后果或已外发的操作不承诺可恢复原状：此类操作须提供适用的中止、更强的防误触与如实的补救说明，禁止以"可撤销"表述超出实际能力的保障。

边界条件本条不规定控件尺寸、间距与操作力（见范围声明）。本条不要求所有操作都加确认——给低后果操作普遍加确认会稀释确认的意义，这是本条的反向失效；紧急与即时控制类动作禁止因通用的二次确认模板而产生不可接受的延迟。车内输入应当可由单手完成，且不要求驾驶员同时松开两只手离开主驾驶控制；本条不规定人体工程尺寸与布置数值。

设计应用先按后果给操作分档，再决定防误触手段。高后果、低频的操作可以要求更强的动作特征；低后果、高频的操作应当保持一次触发并保证可撤销。

验证示例

• 用户侧：在产品声明支持的路面条件下行驶，记录非预期触发的发生位置与后果等级。
• 实现侧：列出全部难以撤销的操作及其触发条件；检查其中是否有仅需一次瞬时单点的。

反例做不到——路面一颠手蹭到屏幕，导航整条路线被取消且无从撤销；做过头——每次调整空调温度一度都要二次确认，用户改用语音，而语音路径本身没做好（见 VH5-1）。

VH2-5关键入口不因个性化、主题或更新而消失必须¶

一句话：车主换了皮肤、车机升了级，除霜还在原来的地方。

适用VH2-1 清单内功能的入口，在主题切换、布局自定义、驾驶模式切换、账户切换与软件更新前后。

规则清单内功能的入口位置与操作方式，禁止被主题、皮肤、用户自定义布局、驾驶模式、账户切换或软件更新改变到需要重新学习的程度。个性化系统禁止把清单内入口作为可被用户移除、隐藏或降级的对象。确需变更位置时，必须按一次行为变更处理：有依据、在生效前告知、并给出过渡。跨账户切换时，清单内入口的位置禁止随账户改变。

边界条件本条不冻结界面演进，也不禁止改进布局；约束的是未经告知的位移与把关键入口交给个性化处置这两件事。

设计应用把清单内入口放在一个受保护的布局区域内，该区域不参与个性化的自由排布，也不随主题改变其结构。

验证示例

• 用户侧：切换全部可用主题与驾驶模式，再切换账户，记录清单内入口的位置是否变化。
• 实现侧：检查个性化配置的可操作对象集合是否排除了清单内入口；检查更新流程是否包含入口位移的检出与告知。

反例做不到——一次更新之后除霜从固定栏移进了新的空调卡片；做过头——为求稳定而冻结全部界面，连明显更好的改进也不做。

VH2-6系统未就绪、故障或升级期间关键功能仍可达必须¶

一句话：屏幕没起来、正在升级，安全相关的功能不能跟着一起没有。

适用车机启动过程、应用崩溃、显示失效、软件升级、系统降级与低电量保护等非正常状态。

规则上述状态下，VH2-1 清单内功能必须仍然可达，其可用性禁止依赖信息娱乐系统或中控屏处于正常工作状态。产品必须为每一项显式定义在各类失效下的可达路径与失效告知方式（记录在 veh.control.critical.fallback）。升级期间使清单内功能不可用，仅在三项条件同时成立时才允许：该功能已被逐项明确列出并经专项分析认可；车辆处于允许该维护的驻车状态；且已确保车辆在此期间不能进入依赖该功能的使用状态。开始之前必须说明受影响的功能、影响范围与预计的恢复条件，并允许用户选择开始时机；用户选择了开始时机不代替上述三项条件。升级失败后必须维持相应的使用限制，并提供实际可行的恢复路径；禁止在用户不知情的状态下进入使关键功能不可用的过程。

边界条件本条不判定功能安全等级划分、冗余架构与失效率要求，那属于范围声明中排除的功能安全范畴。本条要求的是可达路径被定义并被验证，不是要求特定的硬件冗余方案。

设计应用把清单内功能的控制链路与信息娱乐链路在设计上分开考虑，即使它们共用硬件。启动过程中，先让清单内入口可用，再加载其余内容。

验证示例

• 用户侧：冷启动后立即尝试触发清单内各项，记录从上电到各项可用的时间；在升级过程中重复。
• 实现侧：对每一类失效注入，检查清单内各项的实际可达性与是否给出失效告知。

反例做不到——车机启动的几十秒里除霜与危险报警都点不了，且屏幕上没有任何说明；做过头——为求冗余给每项功能做两套入口，两套状态不一致，用户要猜哪套是真的（一致性要求见 VH3-6）。

3.3 VH3 信息落在对的位置¶

车里有好几个可以显示东西的地方，它们与驾驶员视线的关系完全不同：仪表在视线下方一点，抬头显示叠在视线上，中控屏要转头，语音不占视线。这条原则管的是哪类信息该落在哪个位置、每个位置最多承载多少、以及在光照与失效条件下它是不是还成立。它不管这条信息现在该不该出现（那是 VH4），也不管操作它要花多少注视（那是 VH1）。

VH3-1驾驶关键信息不只出现在中控屏必须¶

一句话：驾驶员的视线不在中控屏上，别把要紧的东西只放那儿。

适用车辆处于行驶相关状态时呈现给驾驶员的全部信息。

规则产品必须显式定义一份驾驶关键信息清单（记录在 veh.surface.critical.set），清单内的每一项禁止只出现在中控屏。它们必须出现在驾驶员执行驾驶任务时视线本来就会经过的位置——仪表或抬头显示——或由适合该信息的非视觉通道承载（听觉、触觉；通道成立条件见 VH5-2）。依法须持续视觉呈现的信息不得以一次提示音替代。清单至少覆盖：车辆状态与故障告警、驾驶自动化的当前生效模式与接管请求、即时的转向与车道指引、以及适用法域要求由仪表承载的项。信息在中控屏上"也有"不得替代它在主位上的呈现。

边界条件本条不规定各项信息在仪表与抬头显示之间的具体分配，那由 VH3-2 定义；不规定仪表的法定标识、符号与照明要求（见范围声明）；也不要求把清单内每一项都同时放到多个位置——分工是默认，冗余需要理由。

设计应用清单的确定依据是"错过它会怎样"，与 VH4-1 的分级依据同源但用途不同：VH4-1 决定它什么时候出现，本条决定它出现在哪里。两者应当引用同一份后果评估，而不是各做一次。

验证示例

• 用户侧：让被试在正常驾驶姿势下报告清单内各项的当前值，记录需要转头的项。
• 实现侧：对清单逐项列出其呈现位置；检查是否存在仅在中控屏上的项。

反例做不到——胎压异常只在中控屏的车辆信息页里显示一个小图标；做过头——把所有信息都复制一份到仪表，仪表变成第二块中控屏，真正的告警淹没其中（信息量上限见 VH3-2）。

依据与参考R01 的 V.D 要求视觉密集的显示尽实际可能靠近驾驶员前方视线；R02 的 4.3.2.4 同旨；R08 的 §2.1.1.3 要求灯光与辅助驾驶的状态位于驾驶员直接视线内；R03 的 Annex 1 给出安装位置的角度范围。本规范不采用其中的角度数值，那属范围声明中排除的布置与视野校核。

VH3-2每个显示位的承载分工显式定义必须¶

一句话：仪表、抬头显示、中控、语音各管什么，事先写下来。

适用车内全部显示位与输出通道，含仪表、抬头显示、中控屏、副驾屏、后排屏、语音、听觉提示与触觉。

规则产品必须为每个显示位与输出通道显式定义它承载哪类信息、不承载哪类信息，以及信息量上限（记录在 veh.surface.role）。分工必须覆盖"同一信息在多处出现时哪一处是主位"。分工随情境变化时（进入自动化模式、进入倒车、进入充电），变化规则必须预先定义，禁止由各模块在运行时自行争抢显示位。缺少分工定义时，信息会按功能上线的先后顺序而不是按驾驶相关性落位——这是本条要防止的失效形态。

边界条件本条不规定分工的具体内容，不同车型与不同硬件配置的合理分工不同；要求的是分工被作出、被记录、被一致执行。本条不禁止情境相关的重排。

设计应用分工定义至少写清四件事：该位置承载的信息类别、最大并存条目数、哪些类别明确不落在此处、以及情境变化时的重排规则。新功能接入时对照分工判断落位，而不是反过来为新功能修改分工。

验证示例

• 用户侧：在同时发生导航转向、来电与车辆提示的场景中，记录各显示位实际呈现的内容是否符合分工。
• 实现侧：调取分工定义；抽取若干功能检查其实际落位是否与定义一致，以及信息量是否超过上限。

反例做不到——每个新功能上线时自行决定往哪块屏上放，仪表上最终并存六个来源不同的提示条；做过头——分工被定死到连夜间简化视图、倒车重排这类明显合理的情境变化都无法实现。

VH3-3抬头显示不遮挡也不误配真实场景必须¶

一句话：叠在路面上的东西，位置对不上就不如不叠。

适用具备抬头显示或其他叠加于驾驶员前方视野的显示能力的车辆。

规则抬头显示的图形禁止遮挡驾驶员需要看到的真实场景要素，也禁止在与真实场景的配准不成立时继续以贴合场景的形式呈现。配准误差超出产品定义的容差、或定位与感知置信不足时，必须降级为不声称空间对应的呈现形式，或撤除该图形；禁止让位置错误的引导继续叠在路面上。抬头显示的信息量上限、可用显示区域与允许的动态程度由 VH3-2 的分工约束，动效受 VH1-3 约束。

边界条件本条不规定投影距离、视场角、亮度与虚像位置的取值，也不判定风窗光学特性与相关法规要求（见范围声明）。本条不要求所有抬头显示都具备场景配准能力——不声称空间对应的呈现形式不受配准要求约束。

设计应用把"贴合路面的引导"与"固定位置的数值"当成两类分别管理：前者依赖配准与置信，必须有降级路径；后者不依赖，但占用显示区域并受信息量上限约束。降级要能被用户察觉，否则用户会继续按贴合的方式解读。

验证示例

• 用户侧：在定位精度下降的路段（隧道、高架桥下、密集城区）观察引导图形的表现。
• 实现侧：检查配准容差与置信阈值是否有取值与依据；注入定位丢失，观察是否降级或撤除。

反例做不到——转向箭头贴在路面上但偏了一条车道，驾驶员照着走进了错误车道；做过头——因为担心配准出错，抬头显示只保留数字车速，等于放弃了这个显示位（分工要求见 VH3-2）。

VH3-4可读性按实际光照条件验证必须¶

一句话：夜间、逆光、强光下读不出来，等于没显示。

适用车内全部视觉显示，含仪表、抬头显示、中控屏与物理控件上的照明标识。

规则可读性必须在产品声明支持的实际光照条件范围内验证，验证条件至少覆盖：正午直射与逆光、夜间、隧道进出时的快速明暗变化、后方车辆前照灯造成的反射与眩光。声明支持的条件范围、验证方法与结果必须被记录（veh.surface.legibility.conditions）。自动亮度调节的存在不构成本条已满足的证据——调节过程本身发生在驾驶员需要读取信息的那几秒。对比度、字形、触控目标与间距必须绑定实际显示位、观看距离、物理尺寸与测试条件，不把 CSS 像素直接作为车机的物理尺寸。

边界条件本条不判定照明与光度的法规符合性（见范围声明）。产品必须覆盖目标使用范围内可预见的光照条件；不可覆盖时须有可靠替代承载或明确的运行限制，不能以缩窄声明排除日常逆光、夜间或隧道。偏光镜片下的可读性应当被评估并记录结论，本规范不要求其必然通过。

呈现要求：安全状态必须同时有文字、符号或位置编码，不只靠颜色表达。长地名、多语言和单位切换后，对象、动作、数值与单位不得被截成易混淆的片段；必要时缩短次要说明，禁止缩小关键文字以强行塞入。触控范围、可见边界与相邻操作的间距须在实际面板、观看距离、驾驶姿势及振动条件下校验。旋钮或按键导航须有可辨焦点，焦点不得随列表刷新跳到另一个动作。各项取值与显示位绑定在 veh.visual.*，不能以一套全车字号或颜色替代情境验证。

设计应用把可读性当成显示位的属性而不是配色的属性：同一套配色在仪表上成立、在中控屏的安装角度下可能不成立。夜间方案不是把亮度调低，它是一套单独需要验证的呈现。

验证示例

• 用户侧：在声明覆盖的各光照条件下，由被试读取清单内信息并记录读取失败与需要多次注视的情形。
• 实现侧：调取验证记录与覆盖的条件清单；检查改版后是否重新验证。

反例做不到——白色文字置于浅色地图底图上，正午直射下不可读；做过头——为兼顾极端条件而全时段采用最高对比配色与最大字号，夜间刺眼且单屏信息量骤降，用户被迫翻更多页。

依据与参考R10 要求考虑夜间亮度与阳光下对比被冲淡；R01 的 V.E 就文本可读性引用 ISO 15008。车内字符可读性的适用范围见 R28；Web 对比度可作辅助检查（R25），不能代替实车评估。偏光镜片一项本次未找到可引用的公开测试方法与通过判据，故本条只要求评估并记录结论。

VH3-5显示失效是明确状态并有回落位置必须¶

一句话：屏黑了要能看出来是屏黑了，要紧的信息有别处可去。

适用任一显示位或其数据源发生黑屏、冻结、局部丢失、刷新停止或数据中断时。

规则显示失效时，系统必须让驾驶员能够识别出这是失效而不是正常状态——冻结画面与正常画面在视觉上不可区分，是本条要防止的最危险形态。落在失效显示位上的驾驶关键信息（VH3-1 清单内的项）必须有预先定义的回落位置（记录在 veh.surface.fallback），回落必须被告知。禁止在数据源失效时继续显示最后一次已知值而不加标注；数值不可用时应当明确表达为不可用，而不是保留一个看起来正常的数字。

边界条件本条不要求所有显示位都有回落位置，只要求 VH3-1 清单内的项有；也不要求瞬时抖动触发失效流程——失效的判定窗口由产品定义并记录依据。清单内的项不得以"登记为无回落"通过本条：要么给出有效的替代呈现，要么指向经专项分析确定的受限使用或降级处置——后者表示原有的呈现承诺不能维持，须如实说明，而不是把缺口写成一项合法配置。

设计应用把"数据陈旧"设计成一种可表达的状态，而不是二选一的有值或无值。回落路径的设计要考虑目标显示位的信息量上限（见 VH3-2），回落不应把目标位置一并压垮。

验证示例

• 用户侧：注入仪表数据源中断，观察驾驶员能否在数秒内察觉；注入中控屏冻结，观察是否可辨。
• 实现侧：对每个显示位注入黑屏、冻结与数据中断，检查失效标识与回落是否按定义发生。

反例做不到——仪表数据源断开，车速定格在最后一个值，驾驶员以为显示正常；做过头——任何一次瞬时丢帧都弹出全屏失效提示，把一次显示抖动变成一次打断（打断的分级见 VH4-1）。

VH3-6同一事实在各显示位不互相矛盾必须¶

一句话：仪表说还能跑 80 公里，中控不能说还能跑 20。

适用同一事实在两个及以上显示位或通道上同时呈现的情形，含语音播报与投屏、手机应用中的同一数值。

规则同一事实在多处呈现时，各处的值与状态必须一致。不一致必须被检出。显示主位只定义呈现的优先位置，不决定哪个值为真：每类关键事实必须另行定义其权威来源、适用条件、采样时点与陈旧判据（veh.surface.authority）。检出不一致时，先核对各实例的来源与采样时点，只把有证据表明已过期的实例标注为陈旧；无法裁决时呈现为"冲突／不可核验"，并按该信息的降级策略处理。禁止仅因某个值出现在主位就把另一处正确且更新的值判为陈旧，也禁止在仍有可靠证据的情况下无区别地把全部实例转为不可用。禁止让用户在两个都声称正确的值之间自行判断。刷新速率不同导致的短暂不一致，其容差与判定窗口必须显式定义（记录在 veh.surface.consistency.tolerance）。语音播报的关键值须可被核对。

边界条件本条不要求所有显示位以相同速率刷新，也不要求把不同粒度的表达（如"约 80 公里"与"78 公里"）判定为矛盾——粒度差异的允许范围应当在容差中说明。

设计应用矛盾通常来自各显示位分别从不同链路取数。让同一事实只有一个产生方、各显示位只做呈现，比事后比对更可靠；确实存在多个来源时，比对与处置必须是显式的一步。两处显示一致不证明其共同上游仍然有效——一致性检查与新鲜度检查是两件事。

验证示例

• 用户侧：在续航、胎压、模式状态等项上同时观察多个显示位，记录不一致的发生与持续时间。
• 实现侧：注入单一数据源延迟，检查是否被检出并按定义处置。

反例做不到——仪表与中控给出相差数倍的续航，两处都不说明哪个是当前值；做过头——为求一致把所有显示位的刷新压到最慢的那个通道，转向提示因此延迟到路口之后。

3.4 VH4 打断按后果排序¶

车里想说话的模块很多：车辆自身、导航、通信、媒体、第三方应用、驾驶自动化系统。它们各自都觉得自己重要。这条原则管的是谁能说、什么时候说、同时想说的时候谁先说、以及说完之后用户回不回得去。它不管这条信息显示在哪儿（那是 VH3），也不管响应它要花多少注视（那是 VH1，但本原则的 VH4-5 对响应动作另有约束）。

VH4-1提醒分级依据后果与剩余时间必须¶

一句话：分级不靠模块自己觉得重要，靠错过它会怎样。

适用车内全部提醒、告警与主动打断，含第三方应用与投屏来源。

规则每一类提醒必须被分入预先定义的等级，分级依据是错过它会导致什么后果与留给驾驶员响应的时间还有多少（记录在 veh.alert.level）。禁止以发起模块的业务重要性、用户的订阅或付费状态、商业价值或到达顺序作为分级依据。等级决定通道、时机、可否被抑制、可否被延后与可否被覆盖。分级必须由一处统一定义，禁止各模块自行声明自身等级；第三方来源可申请等级，但等级由统一定义方判定。每类主动提醒还必须说明面向谁、帮助其作出什么行动；没有可陈述收益的非必要提醒不得在行驶中主动出现。

边界条件本条不规定等级的数量与命名，也不规定各等级对应的具体呈现形式。适用法域对特定告警的等级另有强制要求时，以适用要求为准并在定义中标注。

设计应用等级的数量要与实际可区分的呈现形式数量相称。分级评估应当与 VH3-1 的清单确定共用同一份后果评估。

验证示例

• 用户侧：让被试区分不同等级的提醒，记录能否分辨其紧迫程度。
• 实现侧：调取分级定义与全部提醒的等级归属；检查是否存在由发起模块自行设定的等级。

反例做不到——第三方应用把自己的推送标成最高级，与车辆安全告警走同一通道；做过头——分成九个等级，实际运行中只用到两级，其余七级各带一套时机规则却从不触发。

VH4-2高负荷时段抑制非必要信息必须¶

一句话：人正忙着开车的时候，营销、推荐和"你有新消息"先等等。

适用驾驶负荷升高的时段，含复杂路口、并线、匝道、恶劣天气与低能见度条件。

规则高负荷时段必须抑制非必要信息。产品必须显式定义负荷的判据与抑制范围（记录在 veh.load.suppress.scope）。判据可采用道路情境、车辆动态、驾驶员输入频度，或已有的驾驶员状态监测能力。抑制范围至少包含：营销与推荐内容、非驾驶相关的社交与消息提示、评分与调研请求、以及可延后而不产生后果的系统提示。抑制解除后禁止批量补发：被抑制的内容必须按其自身时效重新判定是否还值得发生，过时的不再发出。

边界条件安全相关告警不在抑制范围内——抑制的对象是非必要信息，不是全部信息。不具备负荷判定能力时，仍必须采用显式的、保守的行驶中抑制规则（如以车辆动态与道路等级替代，或在全部行驶相关状态下抑制本条所列类别），这是合规结果，不是豁免；"按常规时机与并发数量处理"不满足本条——数量上限约束的是同时出现多少条，不约束它出现在哪一刻，一条非必要提示同样可能恰好落在并线的那几秒里。

设计应用把"可抑制"作为每类信息的一个显式属性，在其定义时确定，而不是在运行时临时判断。抑制与丢弃是两回事：抑制之后要么在合适时机以其自身时效重新判定，要么明确丢弃并说明。

验证示例

• 用户侧：在复杂路口与匝道路段记录出现的非必要提示数量；解除后记录是否发生集中补发。
• 实现侧：检查每类信息是否标注可抑制属性；注入高负荷状态，检查抑制范围是否与定义一致。

反例做不到——正在并线进匝道时弹出年度用车报告；做过头——把负荷判据设得极宽，导航的路口提示被当作可抑制内容一并压掉。

依据与参考R15 要求仅在与驾驶员需求相关时才发通知；R02 的 4.3.5.1 要求行进中自动禁用与驾驶无关且可能显著分散注意力的视觉信息。R22 报告的交互后残留成本，是本条要求把抑制窗口与交互结束时点分开考虑的理由。「解除后不批量补发」本次未找到直接来源，是从承诺反推。

VH4-3多来源提醒有仲裁，不并发争抢必须¶

一句话：三个模块同时想说话，得有人决定谁先说。

适用来自车辆系统、导航、通信、媒体、第三方应用与驾驶自动化系统的提醒同时或相近时间发生的情形。

规则全部提醒必须经由一处统一的仲裁决定呈现顺序、并发上限与通道分配；禁止各来源直接占用输出通道。仲裁规则必须预先定义且稳定，其输入是 VH4-1 的等级与时效，不是到达顺序或发起方身份。同一时刻的听觉通道禁止同时播放两条语义不同的提示；视觉通道的并发上限由 VH3-2 的信息量上限约束。仲裁必须处理"更高等级的提醒在低等级提醒播放过程中到达"的情形，并预先定义是否打断、如何打断。接管请求、车辆故障与碰撞相关提示也必须进入同一套仲裁定义，逐项记录时限与替代通道。

同一事件须按事件标识和条件变化去重。被打断内容恢复前必须重验时效，禁止重播已经驶过路口的转向指令；告警去重、过期与解除条件写入 veh.alert.arbitration.rule。

边界条件本条不规定仲裁的具体算法与优先级表的取值；不要求仲裁必须集中在单一软件组件内，要求的是规则集中定义且各来源不能绕过。

设计应用仲裁的输出不只是"谁先"，还包括"另一条怎么办"——延后、降级到其他通道、还是丢弃。三种处置都要有定义，只写优先级不写处置的仲裁在真实并发下会退化成丢弃。

验证示例

• 用户侧：构造转向提示、来电与车辆提示同时发生的场景，记录实际呈现是否可分辨。
• 实现侧：检查是否存在绕过仲裁直接播放的路径；对被让位的提醒检查其后续处置。

反例做不到——转向提示、来电铃声与低电量提示叠在一起，一句都听不清；做过头——严格串行排队，紧急告警排在一条冗长的语音播报之后。

VH4-4车辆安全告警不被信息娱乐层遮蔽必须¶

一句话：全屏应用、投屏和第三方界面不能盖住车辆自己的告警。

适用车辆运行第三方应用、投屏、视频播放或全屏内容时。

规则车辆自身的安全相关告警禁止被全屏应用、投屏、第三方界面、视频播放或系统动画在视觉上遮蔽，也禁止在听觉上被压过。呈现层级与音频优先级必须在机制层强制，不依赖各应用自觉让位。第三方运行环境与投屏接入前，其可占用的显示区域、音频通道与可申请的最高等级必须被显式限定并记录（veh.alert.thirdparty.limit）。第三方来源禁止呈现与车辆自身告警在形式上难以区分的内容。

边界条件本条约束的是遮蔽，不禁止第三方应用使用全屏；也不要求车辆的每一条提示都强制打断第三方内容——只有安全相关告警受本条保护，其余按 VH4-1 的等级与 VH4-3 的仲裁处理。

设计应用为安全告警保留一个第三方内容无法占用的显示区域与音频路径，并让这个保留在机制上成立而不是靠约定。第三方内容的视觉语言（配色、图标形式）应当与车辆告警可区分。

验证示例

• 用户侧：在投屏全屏导航状态下触发车辆告警，观察其可见性与可听性。
• 实现侧：检查第三方接入协议中对显示区域、音频通道与等级申请的限定；尝试从第三方侧申请超限资源。

反例做不到——投屏进入全屏后车辆制动系统故障提示被压在下层；做过头——每条低等级车辆提示都强制打断投屏画面，用户因此关掉全部车辆提示，连安全告警一并失去。

VH4-5提醒的响应动作不要求复杂屏上操作必须¶

一句话：让人知道一件事，不该顺带要求他做一次精细点击。

适用行驶中呈现给驾驶员并需要或期待其响应的全部提醒。

规则需要驾驶员响应的提醒，其响应动作必须能在不长时间注视、不精细指点的条件下完成。禁止把"知道了"设计成必须命中屏上小目标的操作。仅告知性的提醒禁止要求任何响应，且必须能自行消解；其存续时间不构成操作期限。响应存在多个选项时，选项数量与呈现方式受 VH1-1 的注视占用上限约束；选项超过该上限时必须改由非视觉通道承载或延后到车辆静止。

告警的阅读确认、提示音暂缓与故障解除必须分开；故障条件持续存在时，禁止因点击“知道了”将车辆状态呈现为正常。持续指示与再次提醒条件记录在 veh.alert.response.path。

边界条件本条不规定响应控件的尺寸（见范围声明），不禁止提供屏上响应入口——禁止的是把它作为唯一路径。

设计应用给需要响应的提醒配一条近手路径（方向盘按键或语音），把屏上入口作为补充。需要记忆或比较多个选项时，先减少比较维度；是否延后由占用测定决定，不以统一条目数替代测试。

验证示例

• 用户侧：在行驶中触发各类需响应提醒，记录完成响应所需的注视次数。
• 实现侧：列出全部需响应提醒及其响应路径；检查是否存在仅有屏上小目标一条路径的。

反例做不到——提醒要在屏幕角落点一个小叉才消失；做过头——所有提醒都不需要响应且数秒后自动消失，包括那些确实需要驾驶员作出选择的。

VH4-6打断后可回到被打断的任务应当¶

一句话：提示看完了，刚才在做的那件事还在。

适用一次打断结束后的界面状态处置。

规则保留被打断任务已完成部分的义务由 VH1-2 单独承载（必须级），本条不重复规定、也不另行加强。本条只管打断结束之后的两件事：其一，用户应当能回到被打断的任务与其状态——禁止在结束后把用户留在与打断内容相关的界面而不提供返回入口；其二，恢复动作本身不得要求超出 VH1-1 上限的注视占用。恢复方式、恢复入口与恢复的有效期应当预先定义，其取值沿用 VH1-2 已定义的 veh.lockout.resume.ttl，不另设一套。

边界条件本条不要求自动跳回——自动跳回本身可能违反 VH1-3。要求的是返回路径存在且代价低；由用户决定何时返回是合适的默认。

设计应用把"刚才在做什么"作为一个持续可见的低显著性线索，而不是一次自动跳转。车辆已停稳时，用户可能已经转向别的事，此时自动跳回反而是干扰。

验证示例

• 用户侧：在媒体检索过程中触发来电，通话结束后记录返回原任务所需的操作数与是否保留输入。
• 实现侧：对每类打断检查其结束后的落点与返回入口。

反例做不到——通话结束后停在通话记录页，此前的检索内容消失；做过头——打断一结束就自动跳回原界面，哪怕此时车已停下、用户正在看别的东西。

3.5 VH5 车内的多通道有成立条件¶

语音、听觉与触觉在车里常被当成分心问题的答案：不用看屏幕，所以没问题。这条原则管的是这个答案在什么条件下才成立——通道要有冗余、不可用时要是明确状态、回执要真的能被感知、认知占用要被计入、指代在行驶中要收紧。输入、确认、失败与恢复均须在实际座舱噪声、乘员和通道组合下成立。

VH5-1语音不作为唯一路径，也不作为分心豁免必须¶

一句话：加了语音不等于这件事就安全了，也不等于别的路径可以取消。

适用产品声明可通过语音完成的全部车内功能。

规则行驶中可用的功能禁止只有语音一条路径，也禁止以"提供了语音"作为该功能满足 VH1-1 的依据。语音交互占用听觉、语言与认知资源，其占用必须与视觉占用分别测定并一并计入（见 VH5-4）。语音路径必须能区分待唤醒、聆听、处理中、已生效、失败与已取消；允许用户中止或切换输入，已明确的对象与输入不要求重说。低置信时先澄清对象，不猜测执行；连续识别失败时提供替代入口或结束本轮，不强迫用户无限重复。

边界条件本条不要求每个功能都有同等便捷的非语音路径——替代路径可以更慢、步骤更多，但必须存在且在行驶中可用，或明确落在 VH1-4 的限制范围内并给出解释。本条不适用于产品明确声明为车辆静止时才可用的功能。

设计应用为语音功能设计替代路径时，替代路径本身要过 VH1-1 的检验；把一个违反 VH1-1 的深层菜单摆在那里充当"另一条路径"，两条路径都不成立。

验证示例

• 用户侧：在语音服务不可用的条件下尝试完成各项功能，记录哪些无法完成。
• 实现侧：列出全部声明支持语音的功能及其非语音路径；检查是否有仅语音可达的项。

反例做不到——行驶中修改目的地只能靠说，说不清就没有别的办法；做过头——为满足"不唯一"给每个语音能力配一套同样深的屏上菜单，这套菜单本身违反 VH1-1。

依据与参考R08 的 §2.1.1.4 要求允许以语音判 pass 的功能另有替代控件；R01 的 Phase 1 明确不覆盖语音，因此不能以其视觉-手动验收结论为语音路径背书。R21 与 R22 报告免提与手持通话的认知负荷差异很小，且车载语音系统的负荷均值处于量表中上区间，是本条「语音不作为分心豁免」的核心依据。

VH5-2通道不可用是明确状态并有回落必须¶

一句话：麦克风没了、蓝牙断了，要能看出来，也要有别的做法。

适用麦克风、扬声器、触觉执行器、网络连接与识别服务的不可用或降级。

规则通道不可用或降级时，必须是一个对用户明确的状态，禁止表现为"没有反应"。每个通道必须有预先定义的回落路径（记录在 veh.channel.fallback），回落必须被告知并说明变了什么。禁止在通道不可用时静默丢弃已经触发的驾驶相关提醒——落在该通道上的 VH3-1 清单内的项必须改由其他通道承载。告知本身受 VH4 约束：它是一次打断，须按其等级处理，且禁止对同一次不可用反复告知。

听觉通道的音量与通道分配不得不当掩蔽必要的告警：评估对象包括车内提醒之间的相互掩蔽，以及车外可听信息（警笛、鸣笛、施工与倒车提示）被座舱噪声、媒体播放与产品自身输出共同掩蔽的情形。掩蔽评估的判据是目标声音能否被识别，不是混音优先级表上的次序；评估条件须覆盖产品声明支持的座舱噪声范围与常见媒体音量。

边界条件本条不要求所有通道都有回落——非关键功能可以定义为无回落，前提是受影响的功能与提醒被指名说明。承载 VH3-1 清单内项或 VH2-1 清单内功能的通道不适用"无回落"：须给出有效的替代承载，或指向经专项分析确定的受限使用处置。瞬时抖动是否构成不可用，其判定窗口由产品定义。

设计应用把通道状态做成系统可查询的显式状态，让各功能在发起前判断，而不是发出去之后等超时。用户侧的表达应当说明后果（"现在不能用语音改目的地"），而不只是报告部件状态。

验证示例

• 用户侧：断开网络与麦克风，尝试触发语音功能，记录用户能否在几秒内知道发生了什么以及该怎么办。
• 实现侧：对每个通道注入不可用，检查回落是否按定义发生、被影响的提醒是否改道。

反例做不到——语音助手因网络中断完全不应答，用户连按三次唤醒键；做过头——每次连接抖动都播报一次服务不可用，一趟车播十几次（总量约束见 VH4-3）。

VH5-3非视觉回执承担确认职责应当¶

一句话：操作生没生效，要能不看屏幕就知道。

适用行驶中驾驶员发起的操作，尤其是 VH2-1 清单内功能与安全相关操作。

规则行驶中的操作，其"是否生效"应当能在不看屏幕的条件下知晓——听觉提示、触觉反馈或可被听见与感觉到的实际状态变化（风机声、雨刮动作）都可以。禁止把仅存在于屏上的视觉变化作为 VH2-1 清单内功能或安全相关操作的唯一回执。回执必须表达实际结果而不是"收到了输入"：禁止在动作实际生效之前给出表示已生效的回执。触觉信号须在路面振动背景下可感知、可区分；连续调节不以密集回执占满注意力。

受理、执行中、已生效、失败与结果未知必须可区分，记录在 veh.channel.receipt.mode。命令已发出但回执丢失时，不得以动画完成或超时推定成功；先查询实际状态，再决定是否安全重试。重复按键、语音与触控并发时，系统须合并同一意图或按已定义顺序裁决，不重复发起支付、通信或相互抵消的开关动作。受理反馈与生效回执分别定义时限和测量起终点，不混用。

边界条件本条不要求每次操作都有独立的人工回执——功能自身产生的可感知变化即是合格回执，且通常优于额外添加的提示音。连续调节类操作不要求每一步都有回执。

设计应用先看这个功能有没有天然的非视觉回执，没有再补。补的时候用既有的系统语义而不是自创。

验证示例

• 用户侧：蒙屏条件下触发清单内各项，记录被试能否判断操作是否生效。
• 实现侧：列出清单内各项的回执形式；检查是否存在仅有屏上视觉变化的项，以及是否存在早于实际生效的回执。

反例做不到——按了除霜，只有屏上图标变色，手上耳朵上没有任何变化；做过头——每一次音量微调都给一次震动加一声提示音，连续调节变成一串噪声。

VH5-4免手交互的认知占用一并计入必须¶

一句话：手没动、眼没离，脑子还在忙，这也是占用。

适用语音、听觉与其他不占用手部与视线的交互路径。

规则免手与免视交互的资源占用必须被独立评估并计入该功能的总占用，禁止把"手没离方向盘、眼没离路面"直接判定为占用可接受。产品必须为这些路径定义占用的测定方法、适用范围与上限（方法记录在 veh.load.cognitive.method，接受条件记录在 veh.load.cognitive.max），并说明该方法的局限。免手不等于免注意——这是本条存在的全部理由。测定结果必须与视觉路径的测定结果一并用于判断该功能是否满足行驶中可用的条件（见 VH1-1、VH1-4）。

边界条件本条不指定认知负荷的测量方法，也不采纳任何一种测量范式作为规定；要求的是方法被选定、被记录、被一致地用于同一产品内的比较。本条不要求跨产品可比。相关公开研究的结论各自绑定其任务与被试条件，引用时须一并说明（见 reference.md）。

设计应用降低认知占用的手段与降低视觉占用的手段不同：缩短单话轮、结论先行、减少需要在脑中比较的选项、避免要求用户记住上一步的内容。屏幕上的"少显示"不自动等于语音上的"少负担"。

验证示例

• 用户侧：用选定方法比较同一功能的语音路径与屏上路径的占用，记录两者的差异方向。
• 实现侧：检查是否存在仅因"是语音"而跳过占用评估的功能。

反例做不到——一段需要驾驶员在脑中比较四个选项的语音交互，因为不用看屏而免于评估；做过头——因为认知占用难以测量，就把语音限制到只能执行单个固定指令，用户转而使用手机语音。

依据与参考R21 的量表显示免提通话与手持通话评分接近，其结论指向免提并未消除认知负荷；R22 在 257 名被试与 10 款量产系统上报告负荷均值与范围，并报告练习五天后困难交互仍然困难、交互结束后仍有可观察的残留。这两项来源提供的是方向与效应存在性，不提供可直接采用的合格线，故本条要求方法、基线、适用范围和接受条件被记录并一致使用（另见附录 B.4 第 1 条）。

VH5-5行驶中的指代与融合收紧应当¶

一句话："把这个设成目的地"在行驶中要指得准，指不准就别猜。

适用行驶中涉及指代表达（"这个""那儿""刚才那家"）或跨通道绑定的操作。

规则行驶中的指代绑定应当比驻车时更严：解析不成立时禁止猜测执行，必须回退到显式选择或明确告知无法解析。涉及难以撤销后果时，必须在执行前让用户确认具体对象与动作；确认本身满足 VH4-5。融合窗口应当不长于驻车时的窗口；确需不同取值时，必须记录等待成本、误绑定后果和行驶情境验证结果。禁止仅为提高融合成功率而延长窗口，也禁止把不同乘员或已过期对象的输入拼成一次指令。回退路径同样接受视觉和认知占用验证，超出接受条件时延后到驻车。窗口、对象有效期和超时处置记录在 veh.channel.fusion.window。

边界条件本条不禁止行驶中使用指代表达——禁止的是解析不成立时的猜测。本条不要求提高识别精度，要求的是失败侧的行为收紧。

设计应用把"解析不成立"设计成一条正常路径而不是异常分支：它在行驶中的发生率本来就更高。回退路径的成本要低到用户愿意走，否则用户会重复尝试原路径。

验证示例

• 用户侧：在指代对象不明确的场景下发出指代指令，记录系统是否执行了某个未被确认的对象。
• 实现侧：检查行驶中与静止时的绑定阈值与融合窗口是否有差异；检查是否存在低置信下的静默执行。

反例做不到——"导航到这儿"在指代不清时选了地图中心点，把用户带往另一处；做过头——行驶中一律不接受任何指代表达，用户每次都要念完整地址，单话轮长度反而超标。

3.6 VH6 座舱是多人共用的¶

一台手机通常只有一个主人，一辆车不是。它在生命周期里会被多个人开、多个人坐，还会被出租、被共享、被卖掉。这条原则管的是谁在开、谁在操作、偏好记在谁名下、乘客能动什么、以及人下车之后车里还留着什么。把座舱当成单用户设备处理，是这个领域持续发生的一类错误。

VH6-1谁在驾驶与谁在操作分别判定必须¶

一句话：这两件事不是同一件，判定依据也不一样。

适用全部涉及使用者身份或角色的机制，含个性化、豁免、权限与数据归属。

规则"谁在承担驾驶任务"与"谁在操作这个界面"必须分别判定、分别记录，禁止用其中一个推定另一个。前者决定本规范义务的适用强度（见开篇的状态表），后者决定豁免是否成立（见 VH1-5）与个性化写到谁名下（见 VH6-3）。两者的判定依据、置信与失败处置必须显式定义（记录在 veh.occupant.role.*）；判定失败时按"驾驶员在操作"这一更保守的假设处理。承担监控或接管职责的人仍按驾驶员处理，不因账户、座位标签或模式名称而自动获得乘客权限。

边界条件本条不要求配备乘员识别或座位感知能力；不具备时按保守默认处理，并在 Token 中记录判定能力的实际范围。本条不要求把角色判定结果向用户展示。

设计应用把角色当成两个独立字段而不是一个"当前用户"。登录的账户、插入的钥匙、坐在驾驶位的人、正在触摸屏幕的人，可能是四个不同的答案。

验证示例

• 用户侧：由非车主驾驶该车，观察推荐、偏好与数据归属的表现。
• 实现侧：检查是否存在把账户身份直接当作驾驶者的代码路径；检查判定失败时的默认分支。

反例做不到——谁登录就认为谁在开车，车主把车借出后所有行程与偏好都记在车主名下；做过头——每次上车要求全体乘员逐一确认座位与身份才能使用任何功能。

VH6-2乘客操作不改变驾驶位的关键呈现必须¶

一句话：副驾在选歌，不能把驾驶员的导航翻页了。

适用副驾屏、后排屏、共享中控屏与乘客设备接入的全部操作。

规则乘客操作禁止抢占驾驶位的 VH3-1 关键信息或驾驶员正在使用的输出通道，禁止移动 VH2-1 的关键入口或操作标记为驾驶员专属的动作。明确允许乘客协作的非运动关键动作，必须通过已验证的入口与权限执行；后排及儿童界面另受 VH6-6 的范围限制。乘客可影响的范围必须显式定义（veh.occupant.scope.passenger）。普通高频功能不因进入 veh.control.frequent.set 而自动成为驾驶员专属功能。空调、车窗、媒体音量等共享状态可按权限调整，但影响驾驶员的变更必须让驾驶员可知，呈现仍受 VH4 的分级与仲裁约束。

边界条件本条不禁止乘客参与导航目的地的选择等协作行为——要求的是这类变更以提议而非直接生效的形式到达驾驶员，且提议本身按 VH4 处理。共用同一块屏时，本条要求的是驾驶位呈现不被抢占，不要求硬件上分屏。

设计应用把乘客侧的操作结果分成三类：只影响乘客侧的（立即生效）、影响共享车辆状态的（生效并告知）、影响驾驶员任务的（作为提议）。三类的边界写下来。

验证示例

• 用户侧：乘客在副驾侧进行连续操作，同时记录驾驶位显示与音频通道的变化。
• 实现侧：列出乘客侧可触发的全部动作及其影响范围；检查是否有直接改写驾驶位呈现的路径。

反例做不到——副驾在中控屏上检索媒体，驾驶员的导航被切走；做过头——副驾除了看之外什么都不能做，于是驾驶员在行驶中替他操作，风险反而升高。

VH6-3个性化绑定到主体并可复位必须¶

一句话：学到的偏好记在人身上，不是记在这辆车上，而且能清零。

适用系统学习得到的偏好、习惯、推荐、常用目的地与自适应行为。

规则个性化必须绑定到可识别的主体——账户、钥匙、用户档案，或明确标记的"未识别使用者"；禁止把个性化作为车辆本身的属性积累。绑定的主体、绑定依据与识别失败时的处置必须显式定义（veh.occupant.profile.binding）。每一类个性化必须可被复位，复位必须及于据其派生的配置。主体不确定时按"未识别使用者"处理，禁止归入最近一次识别到的主体。匿名偏好只绑定本次使用期，禁止以共用匿名档案跨使用期累积；座椅或后视镜的记忆恢复不得在行驶中无提示地改变驾驶姿势和视野。

边界条件本条不要求强制登录，也不要求具备生物识别能力。座椅、后视镜等与人体位置相关的记忆项可绑定到位置档案而非账户，前提是该档案本身可复位且不被用作行为画像。

设计应用把"这辆车学到的"与"这个人的偏好"分开存放。前者应当只包含与车辆本身相关的项（保养周期、胎压基线），后者随主体走并可整体清除。

验证示例

• 用户侧：由第二位使用者驾驶一段时间后，检查第一位使用者的推荐是否被污染；执行复位后检查派生配置是否同步消失。
• 实现侧：列出全部个性化项及其绑定主体；检查是否存在无主体绑定的累积项。

反例做不到——车记住了"这个时间通常去某地"，换人开还这么推荐；做过头——每次上车都要求登录，不登录连座椅与空调记忆都不给用。

VH6-4共享与租赁车辆默认更保守必须¶

一句话：不知道上一个人是谁的车，默认就不该记住任何人。

适用用于共享、租赁、网约、试驾、展车与企业车队的车辆。

规则这类车辆的默认配置必须比私人车辆更保守：默认不建立持久的个人档案、默认不保存通讯录与通话记录、默认不保存目的地历史、默认不保存账户凭据、默认不启用需要长期个人数据的推荐。运营形态必须是一个显式的产品配置项（记录在 veh.occupant.tenancy.mode），禁止以"用户可以自己去关"替代保守默认。用户主动开启的个性化必须与使用期绑定，期满按 VH6-5 处置。

边界条件本条不禁止共享车辆提供个性化——要求的是它默认关闭、由用户在知情下开启、并与使用期绑定。本条不判定运营方与制造方之间的数据责任划分。

设计应用把使用期作为一个一等对象：开始时清空，结束时清除并给回执。座椅位置等本次驾驶所需的设置可以在使用期内保留，它们与行为画像不是一类。

验证示例

• 用户侧：以租赁形态首次使用，检查是否有任何来自上一位使用者的痕迹；连接手机后检查默认同步范围。
• 实现侧：检查 veh.occupant.tenancy.mode 是否实际改变默认值集合，而不只是一个标记位。

反例做不到——租的车默认把手机通讯录同步进车机并长期保留；做过头——共享车辆连座椅与后视镜位置都不允许在本次使用期内记住，每次上车重调一遍。

VH6-5离车后的个人数据可清除且清除可核验必须¶

一句话：还车之后，通讯录、去过的地方和账号得能真的删掉。

适用使用者结束使用、车辆归还、账户注销与车辆转手的全部情形。

规则使用者结束使用后，其在车内产生的个人数据必须可被清除，且清除必须及于派生物——设备配对记录、通讯录与通话记录、消息、目的地与轨迹历史、账户与凭据、语音样本与唤醒记录，以及据这些数据生成的推荐与个性化配置。清除必须有可核验的完成回执：说明清除了什么、还剩什么、何时完成。离线或部件未上电导致的延迟清除必须显示为待执行而不是已完成。产品必须提供一条在车内可完成的清除路径，禁止只提供需要另一台设备或联系客服才能走完的路径。

清除范围、触发条件、各存储位置及失败处置记录在 veh.occupant.data.lifecycle。本地数据已清而云端撤销尚未完成时，分项显示“本车已清除／远端待处理”；下一位使用者不得访问待清除数据。删除请求挂起期间阻止后台同步将数据重新写回，解除配对与撤销访问凭据分别核验。

边界条件本条不判定各法域数据法规的符合性（见范围声明）。因法定留存义务或安全事故调查而不能删除的项，必须被指名说明，不得笼统表述为"部分数据保留"。本条不要求清除车辆自身的运行与故障记录。

设计应用把清除设计成一次可跟踪的处置而不是一次点击：列出范围、执行、给回执、对未完成项说明原因与预期完成条件。清除入口应当出现在还车与转手这些用户实际会经过的时刻，而不是埋在设置深处。

验证示例

• 用户侧：执行清除后重新配对手机、打开导航与语音记录，检查是否还能看到此前的内容。
• 实现侧：对每一类数据检查清除是否及于其派生的个性化配置；断开网络后执行清除，检查状态是否显示为待执行。

反例做不到——还车时的"删除用户"只清了首页头像，蓝牙配对与导航历史仍在；做过头——把清除做成不可撤销的一步且不加确认，用户误触后失去本次行程正在使用的导航（误触约束见 VH2-4）。

VH6-6后排与儿童乘员的可操作范围显式应当¶

一句话：后排能改什么、不能改什么，要事先定下来。

适用后排显示与控件、以及可能由儿童使用的车内界面。

规则这些位置上的可操作范围应当被显式定义（记录在 veh.occupant.scope.rear、veh.occupant.scope.minor）。相关操作禁止改变车辆的运动相关状态与 VH2-1 清单内功能的状态，禁止在未经驾驶员或监护人授权的情况下发起支付、外发通信或改变账户设置。儿童适用的默认配置应当独立定义，而不是从成人配置继承后逐项收紧——继承式收紧会在新增功能上默认放开。后排内容的音频输出不得占用驾驶员正在使用的通道（见 VH6-2）。

边界条件本条不要求系统具备识别乘员年龄的能力；不具备时按位置与显式配置（如儿童模式）处理，而不是按推断处理。本条不判定未成年人保护的法规要求（见范围声明）。

设计应用把后排定义成一个独立的权限域而不是驾驶位功能的子集。新功能接入时默认不进入后排域与儿童域，由一次显式决定加入。

验证示例

• 用户侧：在后排尝试改变导航、驾驶辅助设置与账户设置，记录实际可达范围。
• 实现侧：检查后排与儿童配置是否为独立定义；新增功能后检查其在两个域中的默认可用性。

反例做不到——后排屏可直接修改导航目的地并开启驾驶辅助功能；做过头——后排除播放已选内容外什么都不能做，连音量与亮度都要驾驶员代劳。

4. 术语和定义¶

本章定义本规范使用的设计对象。任务是具有可核验结果的一段交互；中断只暂停推进，不自动撤销已发生的结果。

5. 运行状态与组件契约¶

本章把规则转为可交接的设计对象。状态名称用于设计与工程沟通，不要求在驾驶界面显示这些枚举。

5.1 不把不同状态揉成一个“可用”¶

车辆情境的证据至少包含来源、采样时点与有效性；具体速度和档位判据在车型预设中定义。AOSP 的 Parked、Idling、Moving 说明区分暂时静止与驻车的必要性，但平台示例不代替车型判据；应用应消费平台下发的有效限制集（R12、R14）。

5.2 核心转换¶

5.3 六个组件的三问契约¶

每个组件交接都回答：需要哪些事实、用户操作改变什么、凭什么证明生效。

状态文案说后果和下一步，例如“语音暂不可用，可用方向盘按键调节”，不只显示错误码。行驶界面保留最小信息；详细技术诊断在驻车后可查。

6. 最小交付与验收¶

6.1 一张设计记录¶

以下模板按单项任务填写。已有车型预设可直接引用，只说明差异；不把全部 Token 变成驾驶员设置项。

任务与成果：谁，在什么车辆情境下，达到什么实际结果？
范围与排除：哪些功能动作、显示位、乘员、语言与使用条件？
方案选择：固定控件／触屏／语音／驻车处理为何适合，替代方案代价是什么？
事实与权限：结果来自哪里，谁可发起，谁可改变，未知时怎么办？
主路径与异常：起步、中断、误触、断网、回执丢失、乘客并发、使用期结束。
配置：采用哪些车型预设，调整哪些字段，决定方、依据、生效条件与依赖是什么？
验证：规则编号 → 参数 → 台架证据 → 用户任务结果；未验证项与允许使用范围。

6.2 三种证据分别交付¶

每个结果记录任务起终点、车辆与硬件条件、预设标识、受测人群、方法、基线、判定规则、实际结果和证据位置。注视、认知负荷与驾驶绩效分别报告，不无依据地加总成一个“安全分”。视觉排版、语音播报、操作路径或硬件条件改变后，对受影响的证据重新检查。

6.3 验收结论与否决项¶

• 通过：在明确的任务、人群、硬件与环境范围内，适用要求有证据。
• 受限：只允许驻车或已验证的功能范围，限制由机制执行；未通过的关键控制不能靠“研究试用”开放。
• 不通过：存在底线失效，或关键判据、能力、证据缺失。

关键控制被界面锁死、把陈旧值当当前值、告警被遮蔽、未知结果被误报成功、把个人数据暴露给下一位使用者，任一出现即阻断受影响范围的验收，不能以平均完成率抵消。附录 A 用于逐项注入；还须配对测试“做过头”：过度锁定、重复确认、过量回执、恢复提示骚扰与过宽告警。

附录 A：故障注入验证清单与分类检验¶

本清单用于检验条款是否真的生效，不新增义务。逐项注入，记录系统的实际行为；记录"不适用"是合格结果，记录"没测"不是（四种状态的区分见附录 C.2）。清单中的注入应当在产品声明支持的车辆状态与光照条件下进行，注入条件与结果一并记录。

危险注入优先在模拟器、台架与封闭试验场进行。黑屏、冻结、抬头显示错位、误触诱发与告警掩蔽一类注入，禁止在开放道路上随意执行；确需在实际道路条件下取得证据时，须有专门的安全方案、明确的终止条件与随时可用的中止手段，并逐条记录其环境与终止条件。受测人群应覆盖目标用户在年龄、语言与熟悉程度上的差异，不以少数年轻熟练者的结果外推。

A.1 视觉占用与任务中断

A.2 关键功能的可达性

A.3 信息落位与显示失效

A.4 打断与仲裁

A.5 通道与多模态

A.6 多乘员与数据残留

A.7 分类检验

用于检验第 1 章的切分是否成立：取 10 至 15 条具体要求（可来自本规范条款，也可来自真实评审意见），让至少三名未参与撰写的评审者独立判断其归属原则。归属分歧集中在某两条原则之间，说明这两条原则的规范对象没有切开——此时应当调整原则的切分，而不是增设中间层或补充映射说明。已知需要重点检验的两处见第 1 章的明示：VH1 与 VH2（占用与可达性）、VH3 与 VH4（落位与时机）。本附录的评审人数与分歧判据是本规范建议的内部检查法，不是经文献验证的标准。

附录 B：论据边界与来源类型¶

B.1 约束词的判据

标「必须」的唯一依据是：缺了它，某条对驾驶员或乘员的承诺会在可预见的情境下失效。下列三类论据提供不同支持，不是三种独立的强制性来源；单有一条实现参考或一次失败记录不足以决定标「必须」——

标「应当」的五条（VH1-6、VH4-6、VH5-3、VH5-5、VH6-6）都是取舍问题而非底线问题：偏离可能有正当理由，但要留痕并接受同样的验证。其中 VH5-3 不规定回执的具体形式，VH6-6 不要求具备年龄识别能力。这五条各自内含禁止级子句（见 2.2），子句的强度不因规则标题为「应当」而降低。

B.2 本规范未做的事

不给注视时长与任务时长的数值门槛，不给控件尺寸、间距与操作力，不给显示亮度与对比度的取值，不给认知负荷的测量范式，不给物理控件的形态与数量，不给告警等级的数量与命名。这些是产品、法规与专项评估的决定；本规范只规定这些决定必须被作出、必须有依据与测定方法、必须可被复核，以及哪些取值与做法不被允许。

本规范也不做以下判定，采用本规范不能替代它们：车辆功能安全与预期功能安全的判定，各法域的法规符合性认证，仪表法定标识与照明的符合性，座舱物理布置的人体工程与视野校核，第三方评分规程的评分结果，无障碍与适老化的专项要求，以及隐私与数据合规的法律判定。

B.3 数值的使用条件

本领域的公开指南中确有以时间为单位的判据。它们各自绑定特定的测试方法、任务类别、适用对象与自愿性说明：适用于哪类任务、用哪种方法测得、对谁适用、是强制还是自愿，各不相同。本规范因此采用一致的处理方式——正文只要求上限被显式定义、有测定方法、有依据出处、可被复核，具体取值由产品在 veh.glance.* 与 veh.load.* 中承载，并分别受适用法规、所选评测方法与产品自身验证约束。引用某份指南中的数值时，必须一并写明该数值在原文中的适用条件与来源编号；取不到原文的，不引用其数值。

B.4 本规范证据最薄的三处

明确列出，不用条款语气掩盖：

1. VH5-4 有方法标准，但没有跨产品通用的接受门槛。免手交互仍有占用这一点有公开研究支持，但"占用多少算可接受"没有跨产品的公认判据，也不能直接由方法标准推导出通用合格线。ISO 17488 的 DRT 可用于评估次任务认知负荷对注意的影响（R29），不直接预测事故风险；产品仍须选择基线、受测人群、统计方法与接受条件，不能只填方法名称。
2. VH2-1 的清单边界依赖判断。"哪些功能属于安全相关"在不同法域、不同评分规程与不同车型上的答案不完全一致，本规范给出的是一份必查条目表与"每个条目必须给出结论并记录依据"的要求，不是一份完备清单。产品可以扩充条目；不得跳过必查条目的核对——本车不配备时记为不适用并写明依据，这与「把条目从清单里删掉」是两回事。
3. VH1-5 的乘客判定缺少公开的效果证据。"什么样的证据组合足以判定操作者是乘客"，本次检索未发现可直接采用的公开判据与误判率数据。本规范因此只规定默认方向必须保守、依据必须可陈述，不规定采用何种感知手段，也不声称任何一种组合已被验证有效。

B.5 来源

完整的来源对照、核验状态与检索记录见 reference.md。规范中的条款不因为某个产品这样做过就成立；产品做法是"这类机制在真实产品中可行"的证据，不是"应当这样要求"的依据。同样，某份指南中存在一条数值，只证明该指南在其自身适用条件下作出了该规定，不证明该数值适用于本规范的全部适用对象。

附录 C：适用范围的确定¶

本附录是开篇状态表的应用参考，用于在具体项目上确定本规范各条的适用强度，不新增义务。

C.1 先回答的五个问题

两份清单（veh.control.critical.set 与 veh.surface.critical.set）是本规范最重要的两处产品输入：它们一旦定得过窄，本规范的多数保护随之落空；定得过宽，则 VH2 与 VH3 的要求会扩散到不需要它们的功能上，稀释真正关键项的可达性与可辨性。清单的确定依据必须被记录，并在功能增删时复核。

C.2 不具备某项能力时怎么办

本规范多处提到的能力（驾驶员状态监测、乘员识别、抬头显示、触觉执行器、场景配准）不是本规范要求配备的。记录时区分四种状态，不互相代替：

not_applicable 与 disabled 在条件成立时可接受；unconfigured 不能通过配置验收。unknown 是合法运行状态，正确执行其保守分支可以通过验证，但不能将未知事实记为已知。判断的分界是"这条的触发条件成立吗"，不是"我们有没有这个部件"：没有抬头显示可以把配准容差记为不适用；没有乘员识别不能把驾驶位保护记为不适用——后者的触发条件（存在驾驶位界面）仍然成立，处理方式是按 VH1-5 的"证据不足时按驾驶员处理"执行。不具备某项能力而该条仍适用时，在 Token 中记录该能力的实际范围，并在受影响的条款上记录"按保守默认执行"。不得以记"不适用"遮蔽本应实现而未实现的功能。

---

实施验收场景¶

以下场景把已有条款转成可复核的验收输入，不另设通用性能阈值。按产品适用能力选取，补充真实设备、用户、输入序列和证据；不适用记录原因，未执行不得记为通过。

每个场景分别核对配置的有效值、执行记录与用户可理解的结果。保留版本、目标、事件时点、失败范围和恢复结果；外部结果未知不填作成功或失败。