自动驾驶人机交互设计规范

面向设计师、人因工程师与系统工程师：让驾驶员随时知道现在谁在开、这套系统能开到哪、什么时候轮到自己；让每一次控制权移交有预算、有依据、有终态；让系统失效时有一个已经定义好的安全归宿，而不是把方向盘丢回给一个来不及准备的人。

自动驾驶产品不只呈现界面。驾驶辅助与自动驾驶功能按已定义的人车分工执行部分或全部动态驾驶任务，改变车辆的物理状态，并影响车内乘员与车外道路使用者。因此设计对象不只是仪表与中控的画面，还包括人和系统怎么分工、控制权怎么移交、驾驶员凭什么判断系统的状态与意图、以及系统开不下去的时候会把车带到哪里。

本规范由七条原则和36 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（A4-2 就是第四条原则下的第二条规则）。每条规则都要回答三个问题：设计决定是什么、系统提供什么事实、用户如何知道结果。填写参数、发出提示和实际控制生效，分别验证。

同一件事只写在一处。以"接管"为例：接管请求如何分级升级、时间预算耗尽后系统做什么、系统凭什么判定人已经接管，这三件事属于同一条义务，写在同一组规则里（A2-2、A2-3、A2-5）；而接管请求发出时驾驶员是否处于可接管的状态，是另一个规范对象上的义务，属于 A3。

本规范约束的是产品对驾驶员与乘员作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不指定具体传感器方案或算法形态。

本规范不是安全论证，也不构成型式认证。它不替代 ISO 26262（功能安全）、ISO 21448（预期功能安全）、UN R155/R157 及各属地的准入要求，也不替代无障碍、隐私、数据合规与产品责任的专项评估。规范正文不复述法规的具体数值——时间窗、速度区间、减速度上限这类量随属地与法规版本变化，正文要求明确适用场景、时序与验证依据；具体取值由 Design Token.md 承载，分别受适用法规、所选评测和产品验证约束。更长的接管时间不必然更安全，预算还受系统剩余可控时间限制。来源与核验状态见 reference.md。

全文四章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；适用性、待检验事项、验证清单与应用示例见附录 A—D。

---

先确定适用等级与运行角色¶

本规范同时讨论驾驶辅助与自动驾驶的人机交互；标题中的“自动驾驶”不表示所有功能都属于 ADS。应用规则前，必须按功能、模式、运行设计域与销售属地确定适用范围，不能给整辆车贴一个等级后套用全部规则。

术语依据：SAE J3016 官方范围说明、NHTSA 分级说明；中国项目另核 GB/T 40429-2021。这些资料不直接裁定交通事故法律责任。UN R157 只用于其适用的 ALKS，不能作为全部 L2—L5 功能的共同准入依据；L2 DCAS 的相关依据单列为 UN R171，全自动车辆另见适用的 欧盟 ADS 法规。

A2 中的“接管请求”默认指系统请求人接手完整驾驶任务。L2 提醒与主动安全介入采用各自的响应定义；A4 的系统最小风险要求适用于承担该能力的模式，不因此要求每种低阶辅助功能独立停车。

1. 七条原则¶

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

同一个场景可以触及多条原则——一次接管超时同时涉及移交的时间预算（A2-2）、驾驶员状态的判定（A3-2）和最小风险策略的执行（A4-1）——这不是分类错误：三条规则约束的是三个不同规范对象上的义务。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，检验方式是让不同评审者对具体要求独立判断归属，看能否得出相近结果；检验不过，修改的是原则的切分，不是加一层中间说明。

原则用于理解规则与裁决归属，本身不作为单独的判定条目。当原则与具体条款的解读出现冲突时，以适用条款为准，并记录需要澄清的歧义。

规则归属唯一，不等于机制不能复用。驾驶员状态监测既是 A3 的直接对象，也是 A2-6 判断"能不能移交"的输入和 A4-1 触发最小风险策略的条件；同一套多模态告警通道既承载 A2-3 的接管升级，也承载 A5-2 的意图表达——机制天然一物多用，义务各归各位。

2. 规则的读法¶

2.1 每条规则的结构¶

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

规则写行为性质、不写实现方式：接管请求要分级升级并在预算耗尽时进入已定义的终态，这是产品行为；用什么传感器判定手在方向盘、用哪条 CAN 报文触发降级，是工程方案——两者必须对得上，但不是同一份交付物。

2.2 约束词¶

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

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

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束。正文中的「不能」仅用于能力或事实陈述（如"不能保证驾驶员已恢复情境意识"），不表达义务。

强度表示约束力，不表示重要性：「必须」决定产品能不能按本规范交付，「应当」往往决定这套系统好不好用、会不会被关掉。

2.3 依据与效力¶

自动驾驶的设计要求需要区分来源：同一条要求，可能是法规硬指标、可能是评测协议的评分项、可能是研究结论、也可能是产品自己作出的承诺——这四者的效力不同，改动它们的代价也完全不同。把它们混在一起写，会出现两种典型事故：把法规下限当成产品可以自由标定的参数；或者把一条自定承诺当成法规义务，在没有必要的地方锁死设计空间。

因此每条规则标注依据与效力，取值四类：

约束词与依据标注是两个正交属性，不构成层级。约束词回答"不满足它算不算不符合本规范"，依据标注回答"这条要求在本规范之外是否还有强制力"。一条【承诺】来源的规则完全可以标「必须」——它的意思是：只要你声称遵循本规范，这条就是硬的，即使没有任何法规逼你这么做。

一条规则可以带多个标注（如【法规】【承诺】）；必须说明哪部分有外部依据、哪部分是本规范扩展，不能用一处法规引用为整条自定要求背书。已读历史版本不等于已完成现行性与属地适用核验。来源只有目录或摘要时，只支持范围判断，不支持具体义务。所有标注的来源、版本与核验状态见《reference.md》；未标注核验状态为"已读原文"的来源，落地前必须回原文核对。

2.4 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而堆告警、确认和降级。两侧都算没做对。在这个领域，"做过头"造成的后果不比"做不到"轻：多余的告警制造警报疲劳，让真正重要的那次接管请求被忽略；过度保守的降级让驾驶员学会绕过系统或干脆关掉它——一个被关掉的安全功能，安全收益为零。

2.5 规则速查：36 条¶

下表是全部规则的一句话记忆版。速查不替代各条的适用条件与完整要求；判定以正文为准。

A1 模式可共识

A2 控制权有归属

A3 驾驶员状态是输入

A4 降级有终态

A5 证据校准信任

A6 车外影响有交代

A7 长期可治理

---

3. 规则详解¶

3.1 A1 模式可共识¶

让驾驶员对"现在是什么模式、这套系统能开到哪、什么时候会还给我"与系统保持一致。这条原则针对的核心失效不是理解错了意图，而是模式混淆——人以为车在开，车以为人在开。

A1-1模式唯一且持续可辨必须¶

一句话：任一时刻只有一个生效模式，状态是常驻的，不是一闪而过的提示。

适用提供一种以上驾驶自动化模式，或同一功能存在启用、待命、降级等多种状态的产品。

规则任一时刻必须有且仅有一个生效的驾驶自动化模式，且该模式的当前状态必须持续可辨，不得仅在切换瞬间提示一次。模式指示必须出现在驾驶员正常驾驶视野可及的位置；产品使用多块显示屏时，各屏对模式的表述必须一致，禁止出现相互冲突的状态显示。模式名称、功能可用性与当前控制归属必须分别判定：可用不等于已激活，正在请求激活不等于系统已接手。事实过期或显示链路中断时，必须标示状态不可确认并执行已定义的显示降级，不得用最后一帧维持“正常工作”的印象。子功能的启停（如自适应巡航与车道居中的组合）必须归结到已定义的模式集合中表达，禁止让驾驶员从多个独立开关的状态自行推断当前处于哪种模式。

边界条件本条不要求模式指示占据固定的大面积区域，也不要求每种模式都有独立配色；它要求的是"任何时候看一眼就能确认"，具体形式由产品决定。短暂的过渡态（如激活中、退出中）可以存在，但必须被显式表达为过渡态，不得表现为两种模式同时生效。

依据与效力【法规】UN R171 §5.5.4.1 对适用 DCAS 的状态与信息表达作出要求；UN R157 的 ALKS 要求仍待原文核验。【承诺】跨屏一致与统一模式归纳由本规范明确提出。S04、S05。

设计应用把模式指示放在与速度同级的常驻位置；用形状、位置与文字的组合表达状态，不只依赖颜色；组合功能给出一个用户能说出口的名字，而不是让人读三个图标做逻辑与运算。

验证示例

• 用户侧：在行驶中随机打断，请驾驶员用一句话说出现在谁在负责转向、谁在负责速度；答不上来或答错，即为不通过。
• 实现侧：验证模式状态由统一的状态源驱动，多屏渲染取自同一真值；注入显示链路延迟或单屏故障，验证不会出现两屏状态不一致而无任何提示。

反例做不到——车道居中被静默降级为仅车道保持，仪表上没有任何持续差别；做过头——每次模式变化都全屏接管画面并强制停留数秒，驾驶员为了看清路况反而分心。

A1-2运行设计域事先可知必须¶

一句话：让驾驶员在用之前就知道这套系统在什么条件下能用、什么条件下不能。

适用功能存在运行设计域限制的产品，即在部分道路、天气、光照、速度或地理范围内不可用或表现受限。

规则产品必须以驾驶员可理解的方式说明每种模式的运行设计域边界，并使该说明在车内可复查（复查入口要求见 A5-1）。系统必须能在激活前告知本次是否满足条件；不满足时必须说明缺的是哪一类条件，禁止仅显示"当前不可用"而不给出类别。运行设计域的判定依赖外部数据（地图、天气、施工信息）时，必须定义该数据的时效要求，禁止使用超出时效的数据判定可用性。运行中必须持续复核依赖条件；条件未知不得默认为满足，须执行已定义的复核或降级。短时抖动可采用有依据的持续判定或恢复滞回，但不得以去抖为由延迟已经必要的减险动作。

边界条件本条不要求向驾驶员完整披露内部判定逻辑或传感器阈值，也不要求逐项列举全部边界情形；它要求的是驾驶员能形成一个大致正确的可用性预期。产品可以只披露对使用决策有影响的类别。

依据与效力【法规】中国项目参考工信部联通装〔2025〕45号第二部分（一）的系统边界、安全响应与告知要求。【实践】L3Pilot CoP-ADF 的框架列有 ODD 与用户理解主题，具体问题卡仍待精读。【承诺】外部数据时效门控是本规范的具体化要求。S07、S12。

设计应用把"为什么现在不能用"归到少数几个可说清的类别——道路类型、天气与能见度、车道线质量、速度区间、地理范围；用一次行程前的可用性预览代替一路上反复的失败尝试。

验证示例

• 用户侧：让从未阅读手册的驾驶员在三种典型不可用场景下说出原因类别，看是否与系统判定一致。
• 实现侧：将地图或天气数据置为过期，验证系统拒绝据此判定可用，而不是沿用旧数据继续放行。

反例做不到——功能在雨天悄悄不可用，驾驶员反复按激活键而得不到任何原因；做过头——激活前弹出一份长列表要求逐条确认，驾驶员每次出发都点掉它。

A1-3可预见的退出有预告必须¶

一句话：要退出，先预告；预告说的是"即将"，不是"已经"。

适用系统能够提前判定即将离开运行设计域的情形，如接近匝道、进入施工区、道路等级变化、地理围栏边界。

规则对可预见的运行设计域退出，系统必须在退出发生前发出预告，并且必须定义该预告的最短提前量。预告的表述必须指向"即将退出"及所需的驾驶员准备，禁止用退出后的通知替代退出前的预告。预告发出后至实际退出之间，系统必须维持所声明的可用控制；若期间能力进一步下降，必须转入已定义的降级路径并告知，禁止为兑现预告而维持已无法支持的能力。突发的、无法提前判定的失效不适用本条，按 A4 处理。

边界条件本条不要求所有退出都有相同的提前量——不同触发条件的可预判时长本就不同；它要求的是每一类可预见退出都有已定义、已公布的最短提前量。提前量的具体取值不得低于适用法规的下限（取值承载于 ad.mode.exit.advance_notice）。

依据与效力【承诺】按可预见事件定义预告提前量。【法规】适用 ALKS 的 UN R157 过渡时序须单独核验；该来源尚未取得可读原文，不据二手转述填入秒数。S05。

设计应用把预告和接管请求区分开——预告是"前面路要变了，准备一下"，接管请求是"现在请接手"；两者的通道、措辞与紧迫感应当不同，避免驾驶员把每次预告都当成紧急事件。

验证示例

• 用户侧：在预告发出到实际退出之间打断，请驾驶员说出还有多久、需要做什么。
• 实现侧：遍历各类可预判退出触发条件，验证实际提前量不低于声明值；验证预告期内功能未被静默削弱。

反例做不到——车开到匝道口才提示"功能已退出"；做过头——把每一个轻微的置信度波动都做成预告，驾驶员在一路预告中学会无视它。

A1-4激活与退出需要明确动作和回执必须¶

一句话：别让一个含糊的动作打开自动驾驶，也别让人不知道它什么时候关了。

适用所有可由驾驶员启停的驾驶自动化功能。

规则激活必须由明确、专用且不易误触的驾驶员动作触发，禁止由可能出于其他意图的单一动作直接激活。每一次激活与退出必须给出回执，回执必须包含发生了什么与由谁触发（驾驶员操作、系统判定、还是外部条件）。系统主动退出时，回执必须说明原因类别。模式切换必须有可感知的回执，不得仅在后台改变分工；回执已发出不等于已证明驾驶员理解。

边界条件本条不要求激活必须是多步确认；一个专用控件加一次明确的状态回执即可满足。

关于恢复类操作：仅当该模式与该输入类型本身允许恢复、且恢复不会把未被接受的责任加到驾驶员身上时，可以简化重复信息，但恢复本身必须可辨。"能否简化回执"与"能否自动恢复"是两个问题，前者不预设后者：按适用规则需要独立驾驶员动作才能恢复的制动覆盖，不得自动恢复。输入覆盖、辅助停用与重新激活须分别定义，不同踏板与不同模式不共用一套恢复逻辑。

依据与效力【法规】适用 DCAS 的制动覆盖与恢复条件见 UN R171 §5.5.3.4.1.1，不外推到所有模式或踏板输入。S04。【承诺】明确动作、回执与恢复可辨由本规范提出；ALKS 的具体条件另行核验。

设计应用把激活的物理控件与调节类控件分开；回执优先用非视觉通道承担一部分（提示音或方向盘触觉），让驾驶员不必移开视线也能确认。

验证示例

• 用户侧：在系统自主退出后不作任何提问，观察驾驶员多久意识到自己已经在完全手动驾驶。
• 实现侧：枚举所有可能触发激活的输入路径，验证不存在可由其他意图动作意外激活的路径。

反例做不到——拨杆的某个方向同时承担巡航恢复与自动驾驶激活，驾驶员误触后并不知情；做过头——每次激活都要求二次确认弹窗，驾驶员在起步阶段被迫低头操作。

A1-5命名与宣称不超出实际能力必须¶

一句话：名字和宣传也是界面，它们塑造的心智模型会在路上被兑现。

适用功能命名、界面文案、宣传材料、销售话术与车主手册。

规则功能命名与对外宣称禁止暗示超出实际自动化等级的能力。对要求持续监视的 L2 功能，不得暗示可以脱离道路监视；对要求后援用户介入的 L3 功能，不得暗示永远无需接手。界面、宣传、销售话术与手册中的功能名称和能力描述必须可相互核对；不同渠道的名称必须解析到同一功能、ODD 与分工版本。

边界条件本条不禁止使用品牌化名称，也不要求名称中包含自动化等级；它要求的是名称与配套表述不制造超出实际能力的预期。

依据与效力【法规】中国项目参考工信部联通装〔2025〕45号第四部分（九）的营销宣传规范要求。【承诺】跨渠道与能力版本一致由本规范提出；其他属地需另列具体依据。S07。

设计应用为每个功能维护一句"能力短句"，同时用于界面副标题、手册首段与销售物料；名称评审与运行设计域评审在同一次会上做，避免命名先行、能力后补。

验证示例

• 用户侧：向未接触过该产品的人只展示名称与宣传语，请其描述这套系统能做什么、自己需要做什么，比对与实际能力的差距。
• 实现侧：核对界面名称、手册、官网与销售物料中的能力表述是否解析到同一份能力描述与版本。

反例做不到——需要全程监视的辅助功能被命名为暗示无需监视的名字；做过头——名称冗长到需要读三行才知道是什么功能，驾驶员在菜单里找不到它。

3.2 A2 控制权有归属¶

让"谁在开"这件事在任何时刻都有确定答案，并让答案的每一次改变是一次有预算、有依据、有终态的移交。移交有硬性时间预算，等待不是免费的。

A2-1分工与责任显式必须¶

一句话：每个模式下谁负责横向、纵向、道路响应和失败后援，分别写清楚。

适用所有驾驶自动化模式。

规则产品必须为每个模式明确定义横向控制、纵向控制、目标与事件探测响应（OEDR）、动态驾驶任务后援四项的归属，并单列碰撞迫近时的紧急安全介入。禁止把一般道路监视、失败后的后援和瞬时 AEB 介入合并成含糊的“应急”。分工必须与该功能的自动化等级一致，并以用户可理解的方式呈现（见 A5-1）。L4/L5 的乘员不是默认后援用户；远程人员的角色另按 A2-7 定义。

边界条件本条不要求界面上持续显示四项分工的完整表格；它要求的是这份定义存在、一致、且驾驶员能查到。日常呈现可以收敛为一句话。

依据与效力【实践】SAE J3016 是分级与术语的 Recommended Practice，不能标为法规；现有证据为其官方范围说明，并以 NHTSA 官方分级说明交叉核对。L3Pilot 提供开发检查框架。【承诺】将分工做成统一、可复查的产品定义。S01、S02、S12。

设计应用把四项分工做成产品定义的一张表，供命名、手册、界面文案与测试用例共同引用，避免各处各写一套。

验证示例

• 用户侧：请驾驶员判断"这个模式下我可以把视线离开路面吗"，看回答是否与声明等级一致。
• 实现侧：核对每个模式的四项分工定义与实际控制权分配、与对外声明的等级三者一致。

反例做不到——宣称需要驾驶员监视，但界面允许并鼓励长时间的车内娱乐操作；做过头——把分工做成一张需要逐格阅读的矩阵图放在首页。

A2-2移交有方向、发起方与时间预算必须¶

一句话：每一次移交都要定义谁发起、给多久、到点做什么。

适用任意两个模式之间的控制权转移，包括人→车、车→人，以及自动化模式之间的切换。

规则产品必须为每一条可达移交路径定义方向、发起方、前置条件、计时起点、时间预算、完成判据与未完成时的行为，并使每条路径有稳定的标识，其时间与完成策略按该标识绑定——同一源模式与同一触发原因可能有多个目标，不得仅按模式名匹配预算。时间预算按方向分型，不混用：人→车激活与自动模式间切换用"处理时限"，系统请求车→人移交用"接管预算"，驾驶员主动输入用"生效时限"；人→车方向的最小准备时长是下限，不得当作最长响应预算。即时生效的路径写明其"及时生效"的验证界限与来源，不为了填满表格而人为加入等待；禁止边不填预算。人→车激活失败时必须保留原有分工并说明失败，禁止显示已激活；自动模式间切换失败必须留在仍有效的原模式或进入已验证的降级路径。系统请求车→人移交时，必须按触发原因定义预算、期间可维持的控制与未响应处置；需要系统后援的路径必须指向 A4 已定义的策略与目标，不得以超时推定人已接手，或无策略地释放控制。准备时间、剩余可控时间、升级与后援执行必须在同一可信时序上验证。预算必须同时满足适用时序约束、人因验证与系统剩余可控时间；无可行窗口时必须调整运行条件或后援设计，禁止仅延长倒计时——增加倒计时本身不构成更安全。

边界条件L2 的握持、注视与直接控制告警分别建模，不沿用 L3 的“请求后才需要接手”心智模型；L2 监督、L3 后援与 L4／L5 乘员请求分别依据各自的职责分工，不共享同一套默认移交假设。紧急避撞、严重故障与常规 ODD 退出不能共享未经区分的时间参数；紧急处置不得为等待完整移交流程而延迟。

依据与效力【法规】适用 ALKS 的 UN R157 时序仍须原文核验；L2 DCAS 的告警类型见 UN R171 §5.5.4.2。【承诺】按方向分别定义失败结果及预算可行性检查。S05、S04。

设计应用移交矩阵的每条边绑定触发原因、预算与结果。不可达边显式禁用，激活失败回到原有分工；计划内退出与紧急故障使用各自的时序配置。

验证示例

• 用户侧：比较预期与非预期请求、不同次任务和长期使用者的接管时间及操控质量，不只测平均反应时。
• 实现侧：遍历允许与禁止的边，分别注入激活失败、预算耗尽和切换中故障，检查结果、记录与界面分工一致。

反例做不到——超时后系统直接解除控制并鸣笛，把一辆按原速行驶的车交给一个仍在低头的人；做过头——把预算设得极长以求"更安全"，系统在明知无法处理的状态下继续行驶更久。

A2-3接管请求分级升级且不止一个通道必须¶

一句话：接管请求随时间加码，且不能只靠看屏幕。

适用车→人方向的接管请求。

规则系统请求车→人接管时，必须定义分级升级的触发时刻、通道与语义，至少使用两个感知通道且包含非视觉通道。升级策略必须按适用法规与风险情况确定，不以固定逐级播放阻碍紧急告警。媒体、来电与免打扰不得阻断接管请求；多个安全告警并发时依 A5-6 仲裁，禁止以“接管优先”为由压制更紧迫的碰撞警报。接管请求不得由普通偏好设置关闭。

边界条件本条不规定使用哪些具体通道；触觉、听觉、约束系统的组合由产品决定。本条不要求每一级都增加新通道，但要求有效升级的紧迫感可区分；对并发更紧迫警报仍按 A5-6 处理。

依据与效力【法规】适用 ALKS 的模态与升级要求需核验 UN R157 原文。【实践】NHTSA DOT HS 812 555 的 Multimodal Messages 讨论多通道告警。【承诺】本条的双通道底线与 A5-6 的冲突处置是产品要求，不泛化成所有 L2 握持提醒的法规要求。S05、S11。

设计应用为接管请求保留专用的触觉与听觉模式，不与任何其他通知复用（保留关系见 ad.notify.haptic.reserved）；升级的物理强度递增，让驾驶员不需要解读内容就知道更急了。

验证示例

• 用户侧：让被试从事典型次任务（手机、进食、与后排交谈）并把媒体音量调到常用上限，测量从首级请求到有效响应的时间分布，而不只测均值。
• 实现侧：验证接管请求在免打扰、通话中、后排娱乐占用音频通道时仍按定义的通道与时刻发出。

反例做不到——接管请求只是仪表上一个红色图标，驾驶员正低头看手机；做过头——每一次轻微的置信度下降都触发座椅振动与蜂鸣，驾驶员最终把系统关掉。

A2-4人的输入始终被识别必须¶

一句话：转向和制动在任何模式下都能被认出来，退出方式不需要学。

适用配有驾驶操纵装置、允许车内驾驶员控制的自动化模式。无驾驶操纵装置的无人驾驶产品使用 A4-5 的乘员停车与求助流程。

规则驾驶员的转向、制动与加速输入在任何模式下都必须被系统识别，并按已声明的语义处理；每一种输入对应的语义（覆盖控制、临时干预、调整或经允许的不执行）必须事先定义并可查；不得把必须生效的制动或转向覆盖配置为无效。至少一种退出方式必须是驾驶员在不查阅任何说明的情况下可以完成的。禁止要求驾驶员通过组合操作、菜单层级或长按序列才能退出自动驾驶。系统因稳定性控制等安全机制抑制驾驶员输入时，抑制的范围与条件必须事先定义，禁止在未定义的情形下静默削弱驾驶员输入。

边界条件本条不要求任意轻微的方向盘扭矩都必须判定为接管——误判为接管同样危险；它要求的是判定阈值与语义被定义、被公布，且存在一条无需学习的退出路径。

依据与效力【法规】UN R171 §5.5.3.4 规定适用 DCAS 的驾驶员覆盖语义；ALKS 另核 UN R157。【承诺】本规范要求所有已提供的输入路径有明确语义，不从“输入已识别”推定整个移交已完成。S04、S05。

设计应用把"踩制动即退出"这类符合既有驾驶习惯的路径作为无需学习的那一条；把调整类操作与接管类操作在物理上分开，减少语义混淆。

验证示例

• 用户侧：让未受训练的驾驶员在行驶中退出自动驾驶，记录首次尝试的成功率与耗时。
• 实现侧：遍历输入类型与幅度区间，验证每一种都落在已定义的语义上，不存在未定义区间。

反例做不到——退出需要在中控屏找到二级菜单；做过头——把方向盘上任何微小扰动都判为接管，系统在颠簸路面反复退出。

A2-5移交完成以证据判定必须¶

一句话：倒计时归零不等于人接管了。

适用车→人方向的移交。

规则系统请求车→人移交时，必须定义并记录可核验的接管证据，禁止仅以倒计时、按键确认或手在方向盘判定完成。判据必须覆盖有效操控和可用的注意力恢复证据，并说明传感器只能支持何种结论；视线回正不等于已证明完整情境意识。证据不足且预算耗尽时执行 A2-2 的已定义处置，不得记录为成功移交。驾驶员主动转向、制动等覆盖输入仍须按 A2-4 及时处理，不得为了等待监测结论而阻止依法应生效的操作。控制覆盖、辅助退出、移交成功与事后操控质量必须分别记录。

边界条件双类证据用于系统请求移交的产品完成判据，不替代属地对制动、转向与停用的具体规定，也不证明事故法律责任已经转移。驾驶员主动覆盖后仍存在风险时，按适用安全策略响应。

依据与效力【实践】ISO/TR 21959 系列的主题涉及接管状态与实验设计，现有证据仅含官方目录，未将其作为具体判据来源。【承诺】双类证据、事件区分与不可阻碍有效覆盖由本规范提出，需项目验证。S16。

设计应用分别表达“已响应您的操作”“辅助已退出”与“接管流程结束”，只在真实发生时给对应回执；停止不再需要的接管播报，保留仍相关的风险提示。

验证示例

• 用户侧：比较手在、视线恢复、已理解交通局面与稳定操控的时间差，检验完成判据是否误判。
• 实现侧：单类证据不得被记作完整移交成功；同时验证主动制动与转向覆盖不被等待第二类证据阻断。

反例做不到——检测到方向盘扭矩即判定接管成功并解除所有告警；做过头——在驾驶员已明确接管并操控数秒后仍持续告警，干扰其处置。

A2-6不向不具备条件的人移交应当¶

一句话：人不在状态时别甩方向盘，那不是移交，是弃置。

适用具备系统后援或驾驶员无响应处置能力，且已确认驾驶员无法有效介入的模式。

规则已确认驾驶员无法有效介入时，系统应当选择其能力和适用规则允许的后援路径，不把形式化接管确认当成安全措施。禁止因请求已播放完毕而解除控制。是否提前进入失效处置必须满足适用法规的触发和时序条件；不得以单次微睡、困倦提示或监测未知状态直接代替无响应确认。告警应当说明当前动作，人的恢复与主动覆盖仍按 A2-4、A2-5 处理。

边界条件困倦、微睡、睡眠与无响应的检测和处置可以不同；“非瞬态”不自动等于立即停车。监测不确定时按 A3-3 限制依赖该结论的能力，不能虚构驾驶员就绪。

依据与效力【评测】Euro NCAP Driver Engagement §1.4、Assisted Driving §4.2.3 区分驾驶员状态与无响应处置。【承诺】避免无效责任移交是本规范要求；不把评测响应写成通用的立即启动 MRM 义务。S08、S09。

设计应用把"驾驶员状态"作为移交决策的显式输入接进移交矩阵，而不是让它只驱动告警。

验证示例

• 用户侧：在模拟无响应处置中，验证乘员理解车辆动作与求助方式。
• 实现侧：分别注入短暂分心、困倦、微睡、监测未知与已确认无响应，确认触发和计时符合各自定义。

反例做不到——对一个已被判定为睡着的驾驶员发出接管请求，超时后解除控制；做过头——一次短暂的低头就触发最小风险策略，车辆在正常路况下无谓地减速停靠。

A2-7远程协助不冒充驾驶接管必须¶

一句话：远程有人帮忙，不等于有人在远程开车。

适用提供远程建议、乘员支持、远程停车或远程驾驶能力的产品。

规则产品必须区分远程建议、服务沟通与直接车辆控制，明确每种角色能观察什么、提出什么、执行什么，以及授权与失联后的行为。远程建议必须由车辆按当前状态与运行约束复核，过期建议不得直接执行。直接远程驾驶如被提供，必须单独定义操作员资格、连接条件、控制权归属、接管回执与断链处置。乘员的客服通话、停止请求或一次确认不得被解释为授予远程驾驶权限；等待远程响应不得延迟必要的车端减险。远程请求与回执必须关联车辆、当前控制会话和具体请求；重复请求不得重复触发动作，重连后必须核对当前状态，禁止重放已经失效的驾驶指令。多方同时请求控制时，必须按已定义的权限与仲裁规则确定唯一有效控制来源；客服权限不得扩展为控制权限。

边界条件本条不要求产品提供远程驾驶。仅提供远程建议的产品，不得在界面称“远程驾驶员已接管”；无该能力时记录不适用。

依据与效力【实践】Waymo 的公开运营说明区分远程协助与控制；现有证据仅包含页面可见摘要，不据此推定全部技术机制。【承诺】授权、建议时效、断链与回执要求由本规范提出。S14。

设计应用分别显示“正在联系支持”“已连接支持”“车辆正在执行停车请求”，每条只对应已发生的事实。

验证示例

• 用户侧：让乘员说明当前谁在控制车辆，确认客服接通不会被误解为驾驶接管。
• 实现侧：注入远程响应超时、旧建议重发、位置变化与连接中断，验证车端不会等待失去时效的指导。

反例做不到——客服接通就显示“人工驾驶中”；做过头——每次常规路径选择都等待远程确认。

3.3 A3 驾驶员状态是输入¶

把人的可用性当作系统的输入量来设计，而不是当作一个默认成立的假设。这条原则的规范对象是驾驶员的注意力、能力受损与响应能力本身——它既被监测，也被作为 A2 与 A4 的判定依据。

A3-1监测能力与自动化等级相称必须¶

一句话：让人做后援，就得真的知道人在不在状态。

适用任何要求驾驶员承担监视或应急后援责任的模式。

规则模式要求驾驶员承担后援责任时，产品必须具备与该责任相称的驾驶员状态监测能力，并明确定义所用的监测通道。仅依靠方向盘扭矩或周期性交互确认，不足以支持"驾驶员正在监视驾驶环境"的结论——这类间接手段可以作为补充，不得作为唯一依据。不具备相称监测能力时，产品必须相应收窄所提供的模式，禁止提供依赖于无法验证的驾驶员状态假设的功能。

边界条件“相称”指监测能验证该模式实际依赖的状态，并非所有模式必须识别全部失能成因。L3 不要求持续道路监视，但仍需与后援角色相称的可用性检测；L4/L5 不因乘员失去注意力而触发驾驶员接管流程。

依据与效力【法规】UN R171 §5.5.4.2 对适用 DCAS 规定驾驶员参与监测。【评测】Euro NCAP Driver Engagement 规定检测覆盖与评分条件。【承诺】“能力须支持责任假设”的跨模式要求由本规范提出。S04、S08。

设计应用先确定要区分哪些驾驶员状态，再倒推需要什么监测能力；不要先选传感器再宣布能测出什么。

验证示例

• 用户侧：让被试以"手扶方向盘但视线离开前方"的方式驾驶，验证系统能否区分该状态与正常监视。
• 实现侧：核对每个模式所依赖的驾驶员状态假设，逐一确认存在可验证该假设的监测通道。

反例做不到——依靠每隔一段时间的方向盘扭矩确认来支撑"驾驶员在监视"的宣称；做过头——为一个仅提供纵向辅助的低阶功能强制要求完整的眼动追踪。

A3-2状态分级与响应阶梯必须¶

一句话：分心、困倦、失能是不同的东西，响应也应该不同。

适用具备驾驶员状态监测能力且以该监测支持驾驶安全或自动化分工的产品。

规则产品必须区分瞬态注意力偏离、困倦或能力受损、微睡或睡眠、无响应以及未知／不可判定状态。每类均须定义检测依据、持续或复核条件、恢复条件和相应响应。

每一项判定按四态之一表达，且各类判定可以并存：已证实存在／在本检测范围内已证实未出现／未知／不适用。禁止把「未检测到异常」直接判为「确认正常」——系统可以输出的只是「当前声明的检测范围内未见该项异常」，不得表述为对注意力或健康状况的整体保证。「未知」由证据缺失、通道冲突、覆盖不足或数据过期产生，是对判断能力的描述，不是一种人体状态；某一通道转入未知时，仍然有效的其他异常结论不因此被消除。空值与字段缺失不得被隐式解释为正常。响应必须匹配风险，允许不同状态共用提示或处置机制，但不得忽略触发、紧迫性与升级条件的差别。对确需自动处置的无响应状态，定义通向 A4 的路径；禁止将所有非瞬态状态一律映射为立即停车。状态解除必须基于已验证的恢复或误报排除证据，不得仅靠固定时长自动清零。

边界条件本条不规定各状态的判定阈值——阈值随传感方案与人群而变，由产品定义并验证。本条不要求覆盖全部可能的失能成因；它要求的是分级存在、性质被区分、响应可追溯到级别。每一条解除路径都必须到达一个已定义的状态，不得停在无名状态上。

依据与效力【评测】Euro NCAP Driver Engagement v1.2 的定义、§1.2—1.4 区分检测类别与响应；它不要求所有状态各自独占一种响应。【承诺】未知状态与误报排除的显式建模由本规范提出。S08。

设计应用把响应阶梯写成一张状态 × 响应的表，与 A2 的移交矩阵共用同一套状态定义，避免两处各定义一套。

验证示例

• 用户侧：验证驾驶员能区分注意力提醒、休息建议与无响应处置。
• 实现侧：逐类验证触发、升级和恢复；普通后视镜查看、传感器未知与困倦不得被误归为同一种失能。

反例做不到——不同风险只得到同样的提示，且升级条件、复核方式与处置路径也没有区别（共用提示形式但状态判定与响应逻辑正确的实现不因此失败）；做过头——把每一次正常的后视镜查看都计入分心累积，驾驶员被持续打扰。

A3-3监测不可静默关闭，降级要告知必须¶

一句话：监测掉线时，依赖它的功能也要相应收窄。

适用具备驾驶员状态监测能力且以该监测支持驾驶安全或自动化分工的产品。

规则驾驶员状态监测在支持它的模式下必须默认启用，且禁止通过一次普通设置操作关闭。监测子系统降级（部分通道不可用）或整体不可用时，系统必须告知驾驶员，并按已定义的规则处置依赖它的功能——降级可用、禁止激活或提前退出，三者必须择一定义，禁止在监测失效后维持原有的自动化程度而不作说明。禁止在监测不可用期间继续声称驾驶员正在被监视。

边界条件本条不禁止为特定合法情形（如维修模式、法规不允许监测的属地）提供关闭路径；这类路径必须与该情形绑定，并伴随对可用模式的相应收窄。

依据与效力【评测】Euro NCAP Driver Engagement v1.2 §1.1 的评分前提包括每次行程默认启用、不能以瞬时单次按键停用。【承诺】把依赖监测的功能与降级状态联动，不将这一评测门槛冒充所有市场的准入法规。S08。

设计应用把"监测能力"作为模式可用性判定的一个输入条件，与运行设计域条件放在同一个判定入口，避免出现两套独立的可用性逻辑。

验证示例

• 用户侧：遮挡监测摄像头，验证驾驶员能否得知发生了什么以及哪些功能因此受限。
• 实现侧：分别注入单通道失效与整体失效，验证功能收窄行为与定义一致。

反例做不到——摄像头被贴住后系统照常提供需要人做后援的模式；做过头——任何短暂的遮挡（如驾驶员抬手）都立即退出自动驾驶。

A3-4提醒匹配注意力，不制造警报疲劳应当¶

一句话：让人真正需要的那次提醒还能被听见。

适用面向驾驶员的所有非安全关键提醒与状态提示。

规则提醒应当在驾驶员的响应能够改变结果时发出，并应当定义非安全关键提醒的频率上限与合并规则。禁止用提高提醒频率或强度来替代对误报率的改进。提醒的强度应当与其紧迫性相称，避免低紧迫提醒占用为高紧迫场景保留的通道与模式（保留关系见 A2-3）。产品应当测量真实使用中的提醒频次与驾驶员响应率，并把持续走低的响应率视为设计问题而非用户问题（回流要求见 A7-2）。

边界条件本条不适用于接管请求与安全关键告警——它们的触发由 A2-3 与 A4 约束，不受频率上限限制。本条不要求减少提醒总量本身；它要求的是每一次提醒都能被响应。

依据与效力【实践】NHTSA DOT HS 812 555，印刷页 65（Minimizing Annoyance of Auditory Messages）讨论紧迫性匹配与减少误报。【承诺】频率配置、合并与响应率回流是本规范的落实要求。S11。

设计应用为提醒设定优先级并做仲裁，而不是让每个功能模块各自决定何时发声；把可以合并的提醒合并成一次表达。

验证示例

• 用户侧：在长时段真实驾驶中记录提醒次数与驾驶员响应率随时间的变化，观察响应率是否衰减。
• 实现侧：验证非安全关键提醒的频率上限与合并规则被实际执行，而不只写在文档里。

反例做不到——非安全关键的状态提示（如可用性变化、功能就绪提醒）高频重复，驾驶员一周后关掉了它；做过头——为了不打扰而把真正需要驾驶员知道的限制也一并静音。安全告警的误报另由 A5-6 与 A7-2 处理，不适用本条的频率上限。

A3-5座舱监测数据用途受限必须¶

一句话：为安全采集的数据，只用于安全和已告知的用途。

适用为驾驶员状态监测而采集的座舱内影像、生理或行为数据。

规则产品必须定义座舱监测数据的处理位置、用途白名单与留存期限，并向驾驶员告知。用途白名单禁止包含与安全功能和已告知的产品改进无关的目的。原始影像应当在车端完成处理并即时丢弃；确需离车传输的，必须限定于已告知的用途，定义留存期限，并提供可理解的说明。禁止把监测数据用于对驾驶员个人的评价性用途而不作明确告知与授权。

边界条件本条不禁止为改进监测算法而使用数据——这属于可告知的产品改进用途；它要求的是范围明确、期限明确、告知在先。事故相关记录按适用法规单独确定记录对象与留存期限；不得因此无限保留全部座舱原始影像。告知不等于取得全部处理或外发所需的法律依据。

依据与效力【承诺】用途白名单、处理位置与留存透明由本规范提出。属地数据保护、事故记录与传输条件须在项目中另列具体法规；未据抽象的“各属地规定”宣称已经核验合规依据。

设计应用把"数据不离车"作为默认，把任何离车传输做成需要单独说明的例外；在监测功能的设置页同处呈现用途与期限，而不是散落在隐私政策里。

验证示例

• 用户侧：让驾驶员在车内查找"摄像头拍到的东西去哪了"，看是否能在合理步骤内得到答案。
• 实现侧：审计实际的数据流向与留存，核对与告知的用途白名单一致。

反例做不到——座舱影像用于与安全无关的产品分析而未告知；做过头——为规避风险而完全不记录任何监测事件，导致 A7-2 的改进闭环无法建立。

A3-6监测覆盖经过分组验证必须¶

一句话：测不到与人没注意，是两种不同的事实。

适用以驾驶员或乘员状态检测触发功能限制、安全告警或控制变化的产品。

规则产品必须声明检测覆盖条件，并针对目标用户与实际使用条件验证：包括身高与坐姿、肤色、眼部特征、常见眼镜或遮挡、昼夜与逆光。验证必须分组记录误报、漏报、不可判定比例和检测延迟，禁止用总体准确率掩盖特定群体或场景的持续失效。覆盖不足时采用 A3-3 的可理解降级，不得把传感器失效呈现为用户违规。恢复必须重新验证必要通道与条件。

边界条件本条不要求采集可识别身份的长期生物特征档案；群体验证、运行检测和个性化识别是不同目的。合成或实验数据的局限须记录。

依据与效力【评测】Euro NCAP Driver Engagement v1.2 §1.1.1 包含驾驶员变异与遮挡覆盖。【承诺】分组错误分析和“不把检测失败归责于人”的要求由本规范提出。S08。

设计应用遮挡导致不可用时提示调整遮挡或使用受限模式，避免反复要求驾驶员“集中注意”。

验证示例

• 用户侧：用常见眼镜、不同座椅位置与夜间条件检验提示是否可理解。
• 实现侧：核对每个声明覆盖组的结果；验证传感器未知不会被记成分心处罚。

反例做不到——深色眼镜导致持续“分心”告警；做过头——每次上车强制采集全套身份信息才能使用基础辅助。

3.4 A4 降级有终态¶

规定系统开不下去之后会发生什么。在行驶中的车辆上，停止不是一个状态，等待不是安全的；能力不足时系统必须把车带到一个已经定义好的终态。

A4-1每种失效有目标最小风险状态必须¶

一句话："停下来"要说明停在哪、怎么停。

适用设计上承担系统后援、最小风险机动或驾驶员无响应处置的模式。L0/L1/L2 的一般辅助退出按实际能力另定安全响应，不宣称具备未实现的 ADS 后援。

规则产品必须为该模式每一类已识别的失效定义触发条件、剩余能力、处置路径和目标终态，并说明无法到达首选目标时的替代结果。MRC 必须是降低风险后的稳定停止状态，包含位置类别与驻车保持；减速至爬行或暂时低速保持属于过程态，不得标为已到达 MRC。最小风险机动与为迫近碰撞采取的紧急机动必须分别定义，紧急处置不得等待 MRM 告知结束。执行必须有进展监测、最长时长与未达目标的继续减险措施，不得超时后释放全部控制。告知必须区分预计停靠点与已确认可达位置，不得保证一定驶入路肩。停车后仍按 A4-5 处置。

边界条件失效后的目标必须在剩余能力与道路条件下可实现，不以列出理想停车位置代替安全论证。若产品无法提供所声明的系统后援，应收窄模式或 ODD；本条不承诺所有物理故障下均能避免损害。

依据与效力【法规】欧盟 (EU) 2022/1426 第 2 条（15）明确 MRC 的稳定停止定义，适用范围限该法规覆盖的全自动车辆；ALKS 的 UN R157 最小风险机动要求仍待原文核验。S19。【实践】L3Pilot CoP-ADF 的框架列有 MRM 主题，具体问题卡仍待精读。【承诺】过程态与终态区分、替代目标和进展监测是本规范要求；不把 L2 紧急功能的爬行响应命名为 MRC。S05、S12、S09。

设计应用把失效模式清单与目标状态清单做成一张对照表，作为设计、测试与安全论证的共同输入；空格代表未设计的路径。

验证示例

• 用户侧：在最小风险策略执行期间询问乘员"车在做什么、会停在哪"，验证告知是否足以让人不做危险干预。
• 实现侧：遍历失效模式清单，验证每一项都有已定义的目标状态与最长执行时长，并逐项验证其输出确实生效——另加三项注入：失去首选停靠点、到达时限仍未到达目标状态、停稳后的驻车保持。"有定义但输出未生效"不通过。

反例做不到——传感器失效后系统只是解除控制并显示故障图标；做过头——对可以降级继续行驶的轻微失效直接执行停车，在高速路上制造新的风险。

A4-2等待不是终态必须¶

一句话：没人回应的时候，时间到了就得自己把车安置好。

适用承担系统后援的模式已请求人介入，而后援用户未在预算内有效响应。L2 告警与低阶功能退出按开篇适用说明另定。

规则禁止把"等待驾驶员响应"作为一个可以无限持续的状态。时间预算耗尽时，系统必须进入 A4-1 定义的最小风险策略，禁止继续维持原有自动化程度，也禁止解除控制而不执行任何策略。等待期间系统必须继续执行已声明的控制功能并持续升级请求（升级要求见 A2-3），禁止在等待期内静默削弱控制能力。驾驶员未响应不得被记为默认同意继续。

边界条件本条不禁止在最小风险策略执行开始后仍接受驾驶员的有效接管——主动覆盖与产品附加中止窗口分别见 A2-4、A4-3 与 ad.fallback.abort.window。本条针对的是"预算耗尽后没有已定义行为"这一情形。

依据与效力【法规】ALKS 未响应后的具体机动和启动时点须核验 UN R157。【承诺】禁止无限等待、超时有已定义处置以及不推定默认同意，是本规范的跨场景要求。S05。

设计应用在状态机中把"等待接管"画成一个带强制出口的状态，出口时刻等于时间预算，出口指向最小风险策略；没有出口的等待状态即为设计缺陷。

验证示例

• 用户侧：构造驾驶员完全无响应的场景，验证乘员能理解接下来会发生什么。
• 实现侧：验证等待状态存在强制出口，且出口行为与定义一致；验证等待期内控制能力未被静默削弱。

反例做不到——请求持续告警但车辆保持原速行驶，直至撞上前方状况；做过头——在驾驶员已经开始有效接管的过程中仍强行进入最小风险策略。

A4-3降级有依据、可预期、可解释应当¶

一句话：不为走完层级而增加风险，让车里的人明白发生了什么。

适用系统能力下降，需要选择继续受限运行、转换模式或进入最小风险处置的情形。

规则降级应当沿已验证的路径进行，并说明当前能力与人的责任。是否经过中间模式必须同时考虑剩余能力、风险与目标模式对人的要求；不得只因为“中间等级存在”就依次进入。禁止静默把 L3/L4 降为要求持续监视的 L2。增加驾驶员责任的模式转换必须满足 A2 的条件；无法完成时转入适用后援路径。严重故障可以直接减险并同步告知。最小风险机动中的主动覆盖按 A2-4 处理，不得以可选“中止窗口”取消适用法规要求的人工覆盖。

边界条件有中间模式不等于该模式此刻适用，也不意味着驾驶员已经准备好。可恢复性与风险降低优先于界面流程的连续性；所选路径仍须可说明、可记录。

依据与效力【实践】L3Pilot CoP-ADF 的 HVI 与 MRM 框架供选材，具体控制转换问题卡仍待精读。【承诺】中间模式适用性、不得静默增加人的责任由本规范提出，不宣称行业规范要求机械逐级降级。S12。

设计应用把降级路径与告知文案一并设计，让每一级的说明回答同一组问题——现在谁在开、还能开多久、我要做什么。

验证示例

• 用户侧：在降级各阶段检验驾驶员能否说出自己的责任，尤其测试 L3 转 L2。
• 实现侧：中间模式不可用或人未准备好时禁止进入；严重故障允许走已验证的直接减险路径。

反例做不到——从完全自动直接跳到无任何辅助，中间没有任何说明；做过头——把每一次微小的能力波动都表达为一次降级告知，驾驶员在一路告知中失去对严重降级的敏感度。

A4-4物理后果不承诺撤销必须¶

一句话：撤销在物理世界不存在，能给的是预告、中止窗口和误触发抑制。

适用系统自主发起的、会改变车辆运动状态的机动，如变道、绕行、紧急制动、驶离主路。驾驶员中止条款仅适用于有对应操控能力的模式；无人驾驶乘员使用 A4-5 的停车请求。

规则产品禁止以"可撤销""可恢复"的表述描述已经执行的物理机动。对可预判且需要用户形成操作预期的自主机动，系统必须在执行前给出预告；提供驾驶员中止能力时必须定义窗口、输入和安全条件。无人驾驶乘员无需逐次批准驾驶机动，也不把其停车请求解释为立即中断任意机动。对不可预判的紧急机动（如紧急制动、紧急避让），不要求预告，但必须定义误触发抑制条件，并在事后向驾驶员说明触发原因。禁止把"事后可以回到原车道"当作"这次变道可以撤销"来呈现。

边界条件本条不要求为每一次常规变道设置人工确认——那会使系统不可用；它要求预告、中止能力的边界与承诺一致，不把新机动当作撤销旧机动。紧急机动的抑制条件不得严到延误必要的介入。

依据与效力【承诺】本规范提出。已发生的车辆运动无法撤回：在有外部物理后果的领域，撤销不是一个可提供的能力，能提供的只有执行前的窗口与执行后的解释。

设计应用把"预告—可中止窗口—执行—事后说明"作为自主机动的统一节奏；事后说明用于校准信任，不用于免责。

验证示例

• 用户侧：在自主变道的预告期内让驾驶员尝试中止，记录成功率；询问其是否认为刚才那次变道"可以取消"。
• 实现侧：核对界面与文案中不存在对已执行机动的撤销承诺；验证误触发抑制条件按定义生效。

反例做不到——界面提供一个"撤销上一次变道"的按钮；做过头——为求稳妥而给每次变道都加长预告，系统在密集车流中错过所有可行的变道时机。

A4-5停车后仍有乘员与救援处置必须¶

一句话：车停稳了，乘员仍需要知道下一步。

适用最小风险停车、无响应停车，以及无人驾驶产品的中止行程或故障停靠。

规则产品必须定义停稳后的驻车保持、危险状态提示、再次起步条件、乘员求助和救援联络。界面必须区分“正在寻找停靠点”“已停稳”“已联系到支持”，不得把停止运动显示为救援已完成。不得仅因网络恢复或故障提示消失自动恢复行驶；重新启动须满足模式条件、现场风险检查与已定义的授权。无人驾驶乘员必须有可发现的停车请求与求助入口，不要求其操纵方向盘；请求收讫和实际停车分开反馈。

涉及乘员的系统停车，必须定义紧急离车的能力与入口：可发现的离车入口、乘员可理解的本地说明，以及主交互入口不可用时（主屏失效、断网、供电异常）仍然可行的路径；适用法规要求的解锁、车门或紧急出口能力必须落实。解锁、开门与"此刻下车是否安全"是三件事，必须分别判定与表达；不得把"等待客服接通"或"网络恢复"作为离车的唯一阻塞条件。是否自动解锁、在什么时刻自动解锁，按现场风险与适用要求确定。应当提供当地救援人员可获取的车辆识别、固定车辆与联系运营方资料。

边界条件停车位置可能仍有危险；不得无条件自动开门、引导走向车流或保证下车安全。紧急通信的触发依据可以来自适用法规或有效预授权；断网时须有本地可用说明与替代求助途径。

依据与效力【法规】欧盟 (EU) 2022/1426 附件 II §5—6 对适用全自动车辆的恢复条件、乘员停车请求和求助有要求；§6.3 明确紧急情境下安全时的自动解锁条件与停稳后的离车手段。失电、断网和不同乘员条件的验证是本规范的产品要求。S19。【实践】Waymo I-PACE 2026-06 应急指南展示了车辆识别、联络和停用等独立救援环节。【承诺】乘员入口、状态回执与重新启动门控是本规范要求，不照搬某一车型的机械操作。S15。

设计应用在停靠后持续保留车辆位置、求助状态与下一步提示；救援资料匹配车型及软件版本，并可脱离车内登录读取。

验证示例

• 用户侧：让初次乘坐且手机无网的乘员完成停车请求与求助，确认理解停车不等于可以立即下车。
• 实现侧：在封闭或静态试验条件下，验证断网、主屏失效、供电异常、支持无人接听与链路恢复时的驻车、紧急离车路径及重新启动条件；同时验证临近车流时不把"可以开门"误导为"可以安全下车"。面向儿童与行动受限乘员的适用差异单列记录，不以平均完成率掩盖缺口。

反例做不到——停车后黑屏，只剩“行程结束”；做过头——为了快速疏散而在高速车道中自动打开所有车门。

3.5 A5 证据校准信任¶

让驾驶员与乘员对系统的能力、意图与感知形成有依据的判断。目标是校准信任——既防止过度信任导致的脱离环路，也防止信任不足导致功能被关掉。这条原则的呈现受一条本领域独有的硬约束：注意力预算。

A5-1能力与局限在使用前披露且车内可复查必须¶

一句话：说明书里说过不算，开车时找得到才算。

适用所有驾驶自动化功能。

规则产品必须在驾驶员首次使用某功能前披露其能力与局限，并且必须提供车内的复查入口，使驾驶员在后续任何时候都能查到该功能负责什么、不负责什么、在什么条件下不可用。披露内容必须与 A2-1 的分工定义、A1-2 的运行设计域说明解析到同一份能力描述。禁止把关键局限只写在车主手册或购车文件中而车内无从查得。复查入口在行驶中的呈现受 A5-4 约束。

边界条件本条不要求首次使用前的披露是一次强制的完整阅读；它要求的是关键局限被主动呈现过，而不是等待驾驶员自己去找。

依据与效力【法规】中国适用产品的边界与告知要求见工信部联通装〔2025〕45号第二部分（一）。【实践】L3Pilot HVI 讨论用户理解。【承诺】首次披露与车内复查共用能力版本由本规范提出。S07、S12。

设计应用把能力描述做成一份单一来源，供首次引导、车内帮助、手册与官网共同引用；车内复查入口做成停车时可深入、行驶中只给一句话的两级结构。

验证示例

• 用户侧：让使用该产品一段时间的车主说出这个功能的三条局限，看与实际是否一致。
• 实现侧：核对各处能力描述引用同一来源与版本。

反例做不到——关键局限只在手册第若干页；做过头——首次使用前要求逐页翻阅并逐条勾选确认，驾驶员在停车场里点了十分钟。

A5-2系统意图与依据可见必须¶

一句话：让人知道车要做什么、为什么，而不是被动承受。

适用系统自主决定的、驾驶员可感知的行为，如减速、变道、绕行、保持不动。

规则系统必须对已定义类别的自主行为表达意图，并在可行时说明原因类别。可预见行为在发生前或同时表达；紧急避撞允许事后说明，不得为讲解延误动作。原因必须来自可核验的事件和状态，归入有限、可理解的类别。原因缺失或不确定时必须如实表达，禁止以生成式说明补出未发生的依据。因不确定而采取保守行为时，应让驾驶员区分感知受限、规划等待与故障；呈现时序与负载受 A5-4、A5-6 约束。

边界条件本条不要求解释每一次微小的速度调整；产品定义需要表达意图的行为类别。本条不要求披露内部算法或置信度数值——置信度的呈现由 A5-3 与 ad.evidence.confidence.exposure 决定。

依据与效力【实践】L3Pilot CoP-ADF §4.5 提供 HVI 与信任评审问题。【承诺】原因有据、类别有限和紧急事后说明由本规范提出；说明不是对完整算法推理的承诺。S12。

设计应用把原因类别做成一个封闭集合，界面、语音与事件记录共用；用同一套类别写事后的事件回放，减少驾驶员的学习成本。

验证示例

• 用户侧：在系统无明显外因减速后询问驾驶员原因，比对其判断与系统实际依据。
• 实现侧：按常规与紧急两类分别验证。常规行为：意图表达的时序在行为之前或同时。紧急行为：验证控制动作未被讲解延误，且事后给出的原因与实际依据一致。两类的原因类别都落在封闭集合内。

反例做不到——车在空旷路面突然减速，什么也不说，驾驶员以为系统故障并从此不再信任它；做过头——每一次跟车距离的微调都播报一次原因。

A5-3感知呈现区分已探测、低置信与未覆盖必须¶

一句话：别把没看到的地方画成空旷的路面。

适用向驾驶员或乘员呈现系统感知结果的可视化。

规则感知可视化必须区分三种情形：已探测且置信度充分、已探测但置信度不足、以及未被覆盖或不可探测。禁止把未覆盖区域渲染为空旷、安全或无目标的样子——这是一种会直接造成过度信任的呈现。可视化中省略的目标类别必须可查，禁止让驾驶员从"画面上没有"推断"现实中没有"。可视化的精细程度不得超过实际感知能力所支持的水平。必须定义动态证据的时效与断流呈现；冻结或过期画面不得继续冒充当前感知。

边界条件本条不要求可视化呈现全部感知结果——那既不可读也无必要；它要求的是不制造"系统看到了一切"的印象。产品可以选择不做感知可视化，本条则不适用。

依据与效力【承诺】本规范提出。依据是可视化保真度与信任校准之间的关系：呈现得越完整、越确定，驾驶员越倾向于把它当作事实。

设计应用给未覆盖区域一个明确的视觉表达（如渐隐、留白、边界线），而不是让它与"空旷道路"共用同一种呈现；在可视化附近提供一句关于"不显示什么"的说明。

验证示例

• 用户侧：在存在未被探测的目标的场景中，询问驾驶员"系统现在看到了什么"，比对其理解与实际感知范围。
• 实现侧：核对渲染逻辑中未覆盖区域与空旷区域使用不同表达。

反例做不到——把只有前向感知的系统画成一幅四周清晰的俯视图；做过头——满屏标注不确定度与探测框，驾驶员无法在一瞥中读出任何有用信息。

A5-4信息呈现受注意力预算约束必须¶

一句话：行驶中不呈现需要长时间盯着看才能完成的事。

适用人需承担道路监视、操控或即将接管时的车内交互。L3 次任务按其许可条件与接管就绪要求评估；L4/L5 乘员娱乐不机械套用驾驶员离路视线预算。

规则产品必须按模式、座位和任务定义交互可达性与注意力预算，并记录测量方法、样本、统计口径和判定条件。视线预算至少描述单次离路分布与任务累计离路时间，不得用任意百分位代替所选准则的完整测试条件。超预算任务须延后、锁定或提供经验证的替代路径；语音不自动免除认知负荷、误识别恢复和驾驶表现测试。任务应可被驾驶中断，并在安全时恢复，禁止用长语音或连续追问阻挡接管。核心控制逐项定义输入要求与可达路径；只有被适用法规、所选评测或产品承诺列为直接物理输入的功能，才按该要求判定，禁止把所有直接触摸输入一律判为不合格。安全告警抢占和跨通道时序按 A5-6。

边界条件NHTSA 2013 文件是针对原装车内视觉—手动次任务的自愿性准则，不能充当 L3 接管时限、所有驾驶画面的统一阈值或语音安全证明。Euro NCAP 的控制要求按功能不同；直接物理输入与直接触摸输入是不同的评测定义。

依据与效力【实践】NHTSA 2013 最终准则 §VI.E.14 给出视线测试判据；NHTSA 人因资料区分视觉、手动和认知负荷。【评测】Euro NCAP Driver Engagement v1.2 §2.2—2.3 分功能规定输入形式。【承诺】替代路径须实测且任务可中断。S10、S18、S08。

设计应用把"行驶中可达"作为每个功能的显式属性，而不是默认全部可达；为被锁定的任务提供语音或副驾路径，而不是简单地禁用。

验证示例

• 用户侧：按所选协议测量完整任务及纠错路径；语音任务同时检验驾驶表现、负荷和安全告警中断后的恢复。
• 实现侧：逐项核对控制清单、所依据的版本与真实入口；分别测试 L2、L3 请求接管、L4 乘员场景的内容门控。

反例做不到——把除霜和危险警示灯放进触摸屏的二级菜单；做过头——行驶中锁定几乎所有功能，驾驶员改用手机完成同样的事，风险反而更高。

A5-5不以免责声明替代设计应当¶

一句话："请始终保持注意"不能用来抵消一个诱导分心的界面。

适用所有面向驾驶员的提示、条款与引导文案。

规则产品禁止以提示文案、条款确认或免责声明替代对已知风险的设计处置。已知会诱导驾驶员脱离监视的界面或功能，应当在设计上处置，而不是补一句提醒了事。要求驾驶员确认的条款应当限于其能够理解并据以行动的内容；禁止把驾驶员对条款的一次点击作为其后续行为责任的转移依据来设计功能。

边界条件本条不禁止提供必要的法律声明——它们有独立的合规目的；它禁止的是用声明替代设计处置。

依据与效力【承诺】本规范提出。依据是"做过头"侧的一种常见形态：把责任前移给用户，而不是移除风险。

设计应用在设计评审中对每一条拟新增的警示文案追问一句——如果这句话被无视，我们的设计还成立吗？答案为否时，改设计而不是改文案。

验证示例

• 用户侧：观察驾驶员在多次遇到同一条警示后的阅读与响应行为，测量其有效性衰减。
• 实现侧：清点产品中依赖"已提示"作为唯一风险处置的功能点。

反例做不到——在明知会被长时间注视的界面上加一句"请注意路况"就上线；做过头——因担心责任而在每次激活时要求签署式确认，驾驶员形成机械点击的习惯。

A5-6安全告警有仲裁与通道失效策略必须¶

一句话：最紧迫的动作听得清，多种信号说同一件事。

适用接管、碰撞、驾驶员状态和车辆故障等安全告警共享视觉、听觉或触觉通道的产品。

规则产品必须定义安全告警之间的优先级、抢占和恢复规则，按风险紧迫性处理并发事件；不得以统一“安全级”让多段语音同时播放。仲裁必须保留仍需用户行动的信息，过期请求不得在危险解除后补播成新的命令。对同一事件的多通道输出，必须定义语义对应、时间容差、送达证据以及单通道失效时的替代路径；向队列写入不等于实际送达；设备输出也不等于用户已感知、已理解或已行动，这些证据不得互相替代。显示冻结、声音不可用或触觉失效时，不得继续假设原有提醒能力成立；无法满足必需告警能力时限制依赖它的模式，并执行适用降级。

边界条件本条不规定跨产品统一的毫秒值或固定优先级表；由安全分析与人因验证共同确定。紧急控制动作不得等待界面渲染成功，也不得靠增加音量掩盖信号冲突。

依据与效力【法规】UN R171 §5.5.4.1.4、§5.5.4.2.2.3 对适用 DCAS 的信息优先级及紧急系统告警作出规定。【实践】NHTSA DOT HS 812 555 印刷页 47—48 讨论多模态消息。【承诺】送达证据、过期丢弃、同步容差和通道故障门控由本规范提出。S04、S11。

设计应用同时触发前向碰撞告警与接管请求，先清楚表达即时动作，保留当前模式与仍有效的接管状态；取消已失效的补播。

验证示例

• 用户侧：在通话、媒体与并发安全告警下，检验驾驶员能否正确识别最先需要采取的行动。
• 实现侧：注入屏幕冻结、音频占用、通道延迟和消息过期，测量实际输出，核对降级与日志。

反例做不到——接管语音与碰撞语音重叠；做过头——为等三个通道完全同步而延迟紧急告警。

3.6 A6 车外影响有交代¶

规范对象是车外道路使用者。系统的行为改变的不只是委托者的处境，还有没有与产品建立任何关系的人的处境。

A6-1本车自动驾驶状态对外可辨应当¶

一句话：依属地要求让外面的人知道这车正在自己开。

适用在允许或要求标示自动驾驶状态的属地运行的产品。

规则产品应当按适用属地的要求，使本车处于自动驾驶状态这一事实对车外可辨；属地已规定标识形式的，必须采用规定形式，禁止自创可能与法定标识混淆的表达。执行最小风险策略期间，必须使用适用属地规定的危险状态信号（要求见 A4-1）。

边界条件本条不要求在未作规定的属地主动增加对外标识——过早自创标识可能与后续法定形式冲突。

依据与效力【承诺】只在属地允许范围内提供附加外部状态表达；法定灯光标志的具体要求由项目核验。【实践】ISO/TR 23049 与 ISO/PAS 23735:2025 的官方目录、范围说明可供选材；后者针对单模式 L4/L5 ADS 专用车辆，未读全文。S13、S16。

设计应用把对外信号的属地差异作为配置项（见 ad.external.applicability），而不是在软件里硬编码单一市场的做法。

验证示例

• 实现侧：核对各销售属地的标识要求与实际实现一致；验证最小风险策略期间的危险信号按规定发出。

反例做不到——在有明确要求的属地不作任何标示；做过头——自创一套显眼的对外灯语，在未作规定的属地造成其他道路使用者误解。

A6-2对外信号只表达自身，不发出指令必须¶

一句话：不要对行人说"你走"，那是在转移责任。

适用任何面向车外道路使用者的显示、投影、灯语或声音。

规则对外信号的语义必须限于表达本车自身的状态与意图（如"正在减速""将要停车""处于自动驾驶状态"）。禁止发出针对他人的指令或通行许可，包括但不限于"请通行""安全""可以过"这类表述及其等效的图形与灯语。禁止使用会被理解为本车已确认对方安全的表达。对外信号的词汇集合必须事先定义并可查，禁止临时生成新的对外表达。

边界条件本条不禁止表达"本车正在让行"这一自身状态——它与"你可以走了"的区别在于前者陈述本车行为，后者对他人的处境作出保证。这一区分必须在具体措辞与图形上经过验证，不能仅凭设计者自认。

依据与效力【承诺】“只表达本车、不提供跨车道通行保证”是本规范的风险控制选择。ISO/TR 23049 与 ISO/PAS 23735:2025 全文未核，不能把本条写成 ISO 明令禁止或研究一致共识。S13、S16。

设计应用把对外词汇集合做成一份可评审的清单，每一条都用"这句话如果被理解为许可会怎样"来检验。

验证示例

• 用户侧：向未接触过该产品的行人展示每一种对外信号，记录其理解；若信号让其相信其他车道也安全、无需自行观察或收到通行许可，即不通过；正确理解“本车正在让行”本身不作为失败。
• 实现侧：核对对外信号实现落在已定义词汇集合内。

反例做不到——在车头投影一条斑马线或显示"请通行"；做过头——取消一切对外表达，包括本可减少误解的减速意图信号。

A6-3交互行为可预期，不训练错误期待应当¶

一句话：让行要稳定，别让路人学会一套在别的车上会出事的习惯。

适用与车外道路使用者存在交互的行为，如路口让行、并线协商、行人穿越处的减速。

规则同类场景下的交互行为应当稳定、可预期，其关键参数（起始距离、减速方式、恢复条件）应当事先定义。产品应当评估其交互行为在被反复经历后可能形成的行为期待，避免训练出一种在其他车辆上不成立、因而会增加风险的习惯。禁止为提升自身通行效率而设计会诱使他人误判的行为。

边界条件本条不要求行为在所有场景中完全一致——不同场景的安全裕度本就不同；它要求的是同类场景内的稳定性与可预期性。

依据与效力【承诺】稳定表达与避免诱导误判由本规范提出。外部 HMI 的长期期待迁移仍需直接研究证据；不再用未列出的“混合交通研究”证明一致共识。

设计应用把让行行为的参数纳入配置与评审（见 ad.external.yield.behavior），而不是留给策略层自由发挥。

验证示例

• 用户侧：在同一路口重复观察不同交通条件下的让行行为，评估其一致性；访谈经常遇到该车型的行人对其行为的预期。
• 实现侧：核对同类场景的行为参数落在已定义范围内。

反例做不到——同一路口有时提前很远停下、有时贴近才刹，行人无法形成预期；做过头——一律采取极度保守的让行，在密集路口造成拥堵并诱使其他车辆强行超越。

3.7 A7 长期可治理¶

规范对象是跨行程、跨驾驶员、跨版本存续的效应。一次软件更新可以在一夜之间改变整个车队的行为，而驾驶员的心智模型不会同步更新。

A7-1行为变更不静默生效必须¶

一句话：一次升级改了车的开法，驾驶员要在用之前知道。

适用改变驾驶行为特征、移交条件、运行设计域或驾驶员责任的软件更新。

规则影响驾驶行为、ODD 或责任的更新必须在受影响功能再次使用前告知变化；更新执行本身还必须满足适用的安装前、安装中、安装后告知和安全条件。安装前说明预计耗时、功能不可用范围与必要准备；安装后明确成功、失败或恢复到哪一版，不得把下载完成显示为功能已更新。行为说明、功能版本、ODD 与地图依赖必须与实际生效配置一致；地图或云端配置只要改变这些行为，也须进入变更判断。跨用户车辆应把关键变化送达实际使用受影响功能的人。

边界条件不改变驾驶行为与责任的更新可以简化再次使用前告知，但不能据此跳过适用的 OTA 安全执行条件。是否需要批准、备案或召回按属地另核；用户同意更新不替代准入。

依据与效力【法规】UN R156 §7.2.2 规定适用 OTA 的安全执行、失败恢复和更新前后信息；中国项目另核工信部联通装〔2025〕45号第三部分。【承诺】实际驾驶员再次使用前的行为告知与云端变更联动由本规范提出。S06、S07。

设计应用分别呈现“待安装—安装中—验证后生效”的状态；向再次使用功能的驾驶员提供简短变更说明，已有效收到的内容无需机械重读。

验证示例

• 用户侧：夜间升级后换另一位驾驶员，检验其首次使用前能得知影响自身操作的变化。
• 实现侧：注入安装中断、版本组合不兼容、地图改变 ODD 与说明未同步，验证不会显示虚假的成功或继续开放不兼容功能。

反例做不到——一次夜间更新改变了变道的激进程度，驾驶员在高速上才发现；做过头——每次无关更新都强制弹出更新说明并要求确认。

A7-2真实使用回流改进必须¶

一句话：脱离、误报和被关掉的功能，是改进的第一手证据。

适用已投入实际使用的驾驶自动化功能。本条的回流义务不由产品是否对用户提供事件查询决定：面向用户的查询是一项可选能力，不提供它不减免本条对运行回流的要求，提供它也不扩大数据收集范围。

规则产品必须在用途与留存边界内建立实际使用回流，覆盖模式退出、接管请求与响应、最小风险策略、功能关闭、告警误报及可用性异常。指标必须说明事件定义、暴露量（如功能使用小时或请求次数）、ODD、软件版本与人群范围；不得仅凭退出次数多就判定系统更危险，也不得把次数少等同于更安全。功能被大量关闭或响应率持续走低必须进入问题分析，不得仅归因于用户习惯。驾驶状态与控制变化记录应使用可关联的时序，并区分检测、用户操作与系统执行；产品体验日志不替代法定事件记录或事故报告。

边界条件本条不要求采集与上述事件无关的行车数据；范围应当限于能支持改进判断的最小集合。

依据与效力【实践】L3Pilot CoP-ADF §4.5.4 的生产后评价涉及不利行为适应。【法规】中国适用产品的事件事故报告见工信部联通装〔2025〕45号第二部分（四），其范围与产品指标不同。【承诺】暴露量、版本与事件口径的要求由本规范提出。S12、S07。

设计应用把"这个功能被多少人关掉了、关掉之后是否再开"作为固定的产品指标，与故障率并列。

验证示例

• 实现侧：核对回流数据覆盖本条正文所列的全部事件类别（模式退出、接管请求与响应、最小风险策略、功能关闭、告警误报、可用性异常）；正文增删类别时本项自动随之调整。检查是否存在长期高关闭率的功能未进入改进流程。

反例做不到——只统计系统故障率，从不统计驾驶员主动关闭率；做过头——为了指标好看而使功能难以关闭。

A7-3个性化绑定正确主体且可复位必须¶

一句话：一辆车不止一个司机，设置不该跟着车走。

适用会随使用而变化或可由驾驶员调整的功能设置与个性化行为。

规则个性化设置必须绑定到已识别的驾驶员主体，禁止在未识别驾驶员的情况下沿用上一位驾驶员的个性化设置来影响驾驶行为。未能识别驾驶员时，必须回到产品定义的默认值。产品必须提供复位入口，并说明复位的生效范围。每个可调字段必须给出允许取值域；其中任一合法取值都不得使本规范的适用硬约束失效。系统从驾驶行为中学习偏好时，必须可关闭，且关闭后不得从历史数据重建已被停用的个性化。

边界条件本条不要求必须具备生物识别级别的驾驶员识别；使用钥匙、账户或座椅记忆等既有手段均可，但必须定义识别失败时的默认行为。

依据与效力【承诺】本规范提出。依据是共用车辆场景下的一种真实失效：后一位驾驶员在不知情的情况下继承了前一位的激进设置。

设计应用把"影响驾驶行为的设置"与"影响舒适体验的设置"分开管理，前者在识别失败时回到默认，后者可以宽松处理。

验证示例

• 用户侧：以未被识别的身份上车，验证影响驾驶行为的设置回到默认且驾驶员可得知。
• 实现侧：逐项检查可调字段的允许域，验证边界值与组合取值均不违反正文硬约束；验证关闭学习后不发生重建。

反例做不到——上一位驾驶员设定的高激进度跟车策略在换人后继续生效；做过头——每次上车都要求完整身份验证才能使用基础功能。

A7-4正视技能退化与过度依赖应当¶

一句话：长期不开的人，接管时不是一年前的自己。

适用长期、高频使用的驾驶自动化功能。

规则产品应当评估长期使用对驾驶员手动驾驶技能与情境意识的影响，并把该影响作为设计输入，而不是使用者的个人问题。移交与接管的设计参数（A2-2 的时间预算、A2-5 的证据要求）应当按长期使用者的实际表现校准，而非仅按新用户或受训测试者的表现校准。对仍要求人监视的模式，产品禁止以鼓励脱离监视的表述或功能设计提升使用率。

边界条件本条不要求产品承担对驾驶员技能维持的责任，也不要求设置强制的手动驾驶时段；它要求的是把这一效应纳入设计参数的校准依据。

依据与效力【实践】NHTSA DOT HS 812 555 印刷页 34 讨论脱离环路、警觉性与技能问题；L3Pilot CoP-ADF 印刷页 148 提出生产后不利行为适应评价。【承诺】纳入长期用户并据实校准是本规范要求；这些材料不证明所有长期用户都会退化。S11、S12。

设计应用在参数校准的被试样本中纳入长期使用者，而不只用初次接触者；把接管表现随使用时长的变化作为一项长期观测指标。

验证示例

• 用户侧：比较长期使用者与新使用者在同一接管场景中的响应时间与操作质量分布，按风险相关分组与失败分布校准，不用总体均值掩盖某类用户的缺口。
• 实现侧：核对参数校准所依据的被试构成中包含长期使用者。

反例做不到——用受训测试者的接管表现确定时间预算，实际用户普遍不够用；做过头——强制要求驾驶员定期手动驾驶一段里程才能继续使用，用户改为规避系统。

---

4. 术语和定义¶

本章只定义本规范正文使用且可能产生歧义的术语。分级、运行设计域等术语的权威定义以 SAE J3016 及适用属地法规为准，本章的表述用于本规范内部的一致理解，不替代来源定义。

---

附录 A：适用性与不替代声明¶

本规范适用于：面向驾驶员与乘员的自动驾驶人机交互设计，覆盖模式认知、控制权移交、驾驶员状态、降级与终态、信息呈现、对外沟通与长期治理七类对象上的体验承诺及其兑现机制。

本规范不替代：

• 功能安全与预期功能安全论证——ISO 26262、ISO 21448 的危害分析、安全目标分解与验证活动；符合本规范不构成任何安全论证。
• 型式认证与准入——UN R155/R156/R157 及各属地法规的要求；本规范正文不复述法规数值，产品的实际取值必须以属地现行版本为准。
• 数据保护与隐私合规——A3-5 只规定用途受限的设计要求，不构成合规评估。
• 无障碍评估——A3-6、A4-5 覆盖部分人群差异与乘员入口，但未穷尽听觉、视觉、运动功能受限者的专项要求。A2-3 的多通道要求出于冗余目的，不等同于无障碍设计。
• 对外部道路使用者的安全论证——A6 只规定沟通与行为可预期性的设计要求，不评估避撞性能。

---

附录 B：待检验事项¶

1. 法规适用性仍需项目核验。UN R157 原文获取受阻，保留为未完成项；UN R171、R156 本次读取的是指定版本，不声称已经覆盖所有后续修订、销售市场与车型。中国通知附件及其他属地要求也未完成逐条映射。状态见 来源清单。
2. 受限标准未读全文。SAE J3016、ISO/TR 21959、ISO/TR 23049、ISO/PAS 23735 等只核到公开范围或目录；不能据此声称已验证其具体阈值与禁令。
3. 原则切分与粒度。36 条规则尚需跨评审者归类和真实项目试用，尤其是 A2-7 与 A4-5 的远程支持边界、A3-6 与 A5-6 的检测和送达能力边界。
4. 量值须经项目验证。未给出通用接管秒数或跨模态同步毫秒值。产品必须给出本模式、ODD、软硬件版本和目标人群下的依据。
5. 长期与外部行为证据。告警疲劳与长期使用已补具体资料，但 A6 的跨车型期待迁移、无人驾驶乘员无障碍和本规范新增承诺仍需专项验证。

附录 C：验证清单¶

每个产品评审记录功能、模式、ODD、属地、软件／硬件版本、规则适用性和证据位置。结论取通过／不通过／待验证／不适用；未验证不能写作通过。不适用须说明角色或能力原因。

危险条件用仿真、台架或受控封闭场地构造；不让普通用户在开放道路上故意失能或制造碰撞风险。用户理解、实际操控、软件事件与车辆运动分别验证，任一层通过都不替代其他层。

C.1 验收条件与证据分层¶

测试前明确功能、角色、人群、道路与环境范围，约定测量方法、样本构成、重复试次、失败定义及判据。性能与用户理解报告分布、尾部和分组差异，不只报告均值；被中断、失败和无法判定的试次不得从分母中静默删除。规则中的验证示例用于构造用例，不是跨产品统一的样本数或通过率。

硬约束违例不得用其他项目高分抵消，例如超时直接释放控制、把未知当就绪、未停稳即显示已停车。缺少证据记录为待验证；缩小适用范围后，重新检查该范围的完整依赖，不能把未通过项简单改成不适用。

C.2 关联事实与故障注入¶

围绕 A1-1、A2-2、A2-5、A2-7、A4-5、A5-6 与 A7-2 验证时，同一流程记录功能与模式标识、行程标识、移交路径标识和本次请求标识；分别保存发生时间、接收时间、来源、有效性与控制回执。策略字典定义“应该怎么做”，运行事实记录“这次做了什么”，两者不得混写。事实至少区分请求收讫、控制生效、告警输出、用户响应和目标达成；接管成功另带完成证据，停车成功另带运动与驻车证据。

注入迟到、乱序、重复、断流、恢复和相互矛盾的消息，确认旧回执不能结束新的移交，重复指令不能造成重复机动，画面冻结不能显示为实时。对时误差或证据缺失超过可接受范围时，将受影响结论标为不可确认并执行对应降级；不通过界面推断车辆状态。

附录 D：从设计决定到可验证旅程¶

以下示例帮助组合正文已有要求，不提供可直接装车的时间标定。

---

实施验收场景¶

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

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