隔空手势交互设计规范

面向设计师与工程师：让系统判得清什么算输入、让用户知道自己此刻在哪个状态、让识别的不确定不变成不可挽回的后果。

隔空手势与触摸、鼠标、按键的根本差别不在"手势好不好记"，而在输入意图的判定方式：

鼠标和触摸提供按下、移动、释放等明确事件，但仍需设计取消与误操作处理。隔空手势还必须从连续运动中判断输入是否开始、属于谁、何时结束。

传感器一直在采集，用户一直在动，系统必须持续裁决"这个动作是不是给我的"。由此派生出两条贯穿全文的前提：误触发是这个模态的结构性属性，不是待优化的细节；跟踪丢失是正常状态，不是异常处理分支。任何把这两件事当边缘情况的设计，都会在真实环境里失效。

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

同一件事只写在一处。以"跟踪丢失"为例：丢失时系统采取什么行为、用户如何知道正在丢失、丢失是否导致已发生的改变无法撤销，分属三条不同规则（G5-1、G4-5、G6-2）——因为它们的规范对象不同，不是同一条义务的三种表述。

本规范约束的是产品对用户作出的交互承诺及其兑现机制的性质，不预设唯一的传感方案（光学、雷达、超声、可穿戴均适用），不指定具体 SDK 或手势识别算法。它不是手势词典，不规定"挥手表示下一页"；具体手势的形态标准化见 ISO/IEC 30113 系列与 ISO/IEC 14754。采用本规范不能替代无障碍、隐私、车载分心与领域合规的专项评估。

阅读入口：配置字段见 Design Token，评审时使用附录 A。

全文四章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；验证清单与论证边界见附录 A、B，外部来源对照见同目录 reference.md。

---

1. 七条原则¶

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

同一个场景可以触及多条原则——用户在交互区边缘做一个删除手势，同时涉及边界的可感知（G4-5）、低置信下的处置（G5-3）和不可逆动作的提交路径（G6-1）——这不是分类错误：三条规则约束的是三个不同规范对象上的义务。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证；检验不过，修改的是原则的切分。

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

2. 规则的读法¶

2.1 每条规则的结构¶

规则写行为性质、不写实现方式：手部离开视野后不得继续推进拖动，是产品行为；用卡尔曼滤波还是直接冻结，是工程方案——两者必须对得上，但不是同一份交付物。

2.2 约束词¶

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

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度，显式约束词优先；「不应当」是「应当」的反向表述。【应当】规则内的「必须／禁止／不得」子句仍是硬约束（G1-6、G2-5、G2-6、G3-4、G6-5、G7-5 含此类子句；其中 G2-6 的练习隔离同时含必须级与禁止级子句），规则标题与速查表的强度标注不替代子句约束力。

强度表示约束力，不表示重要性：「必须」决定产品能不能上，「应当」往往决定产品好不好用。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而堆确认、停留圈和提示。两侧都算没做对。隔空手势被做坏的最典型方式恰恰是后者：为了压住误触发，给每个动作套一个两秒的停留确认圈，把交互变成罚站——误触发率确实降了，交互也死了。

2.4 规则速查：39 条¶

下表是全部规则的一句话记忆版。速查不替代各条的适用条件与完整要求。

G1 输入成立可判定

G2 手势与意义的绑定

G3 身体代价有预算

G4 状态可感知

G5 识别不确定性显式化

G6 后果与手势解耦

G7 情境与他人

---

2.5 从任务到交互决策¶

先说明手势为目标用户解决什么问题，例如手部不宜接触屏幕、远距快速控制，或直接操纵空间对象。比较同一任务的手势与非手势路径，把发现、进入、纠错和退出一并计入成本；只比较一次识别的速度，不足以证明采用手势的价值。

下表是设计记录模板，不新增规则或统一数值。先选平台已有的标准输入模型，再决定确需自定义的部分。

最小交付包括：一条完整任务路径、动作与后果映射、状态与转换表、可解析配置、验证记录及来源。平台默认可以继承，但应标注平台、输入合同与适用条件。

---

3. 规则详解¶

本章按七条原则展开全部 39 条规则。其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一实现。

3.1 G1 输入成立可判定¶

传感器持续采集，用户持续活动，两者之间需要一条明确的界线：什么动作被当作命令。这条界线由产品定义、由机制执行、并且必须对用户可见。界线定得模糊，产品会在两个方向同时失败——既误触发，又"怎么做都没反应"。

G1-1参与状态显式化必须¶

一句话：让用户和系统对"现在是否在接收手势"有同一个答案。

适用所有以隔空手势作为输入通道的产品。

规则产品必须定义有限且可枚举的参与状态（至少区分"未参与"与"接收输入中"），并保证任一时刻系统对当前状态有唯一判定。进入与脱离必须各有明确条件，其中脱离条件必须至少包含一项用户可主动执行的方式。当前参与状态必须对用户可感知（感知要求见 G4-1）。禁止把"手出现在采集范围内"直接等同于"用户希望交互"，除非误触发后果已被 G6 约束到可接受范围并作为显式设计决定记录。

设计应用参与的进入可以是显式分隔动作、进入特定空间体积、注意力锚（注视或身体朝向）、其他模态触发，或以上组合；选择依据是误触发后果与使用频率，不是技术可行性。

验证示例

• 用户侧：让用户在不被告知的情况下靠近设备并自然活动，观察其能否说出"系统现在是否在听我的"。
• 实现侧：检查是否存在两个模块对参与状态判断不一致的窗口；状态切换是否作为事件被记录。

反例做不到——手一进画面就开始响应，用户放下水杯触发了下一页；做过头——每次交互前都要求先做一个两秒的举手确认，用户宁可去按物理按钮。

G1-2手势起止可判定必须¶

一句话：每次手势有明确的开始和结束，不靠从连续动作里猜。

适用以手势产生离散命令或连续控制的产品。本条各子款按其对象分别适用：分段要求适用于需要从动作流中识别出一次操作的输入；目标绑定要求适用于面向对象的操作；取消与进度重置要求适用于存在预览、拖动、停留、保持或其他尚未生效阶段的操作。无空间目标的命令可声明"目标绑定不适用"，但这不免除其命令起止与主动取消的要求。

规则每个手势必须有可判定的开始与结束条件。系统必须能区分"一次完整手势"、"尚未完成的手势"与"手势之间的过渡动作"，并且不得把过渡动作（收手、复位、切换姿势）识别为命令。产品必须显式声明所采用的分段依据：分隔动作、姿势变化、速度或位置阈值、时间窗口，或其组合。

边界条件本条不要求所有手势都使用同一种分段依据；不同后果等级可以采用不同依据（见 G6-5）。

规则（目标与取消）：面向对象的操作必须定义目标绑定时点，以及移动、注视转移、对象消失或内容变化后的处理。操作开始后，禁止把同一段手势静默转交给新目标。存在预览、拖动、停留或保持阶段时，必须定义生效前的主动取消条件；丢失跟踪不等于有效释放（G5-1）。停留进度必须绑定当前目标，目标改变后不得继承原目标的累计进度。

规则（连续映射）：连续控制必须声明手部运动如何映射为对象变化：位置、位移还是速度控制，所用坐标系、轴向、比例或增益、允许范围，以及释放后的停止或惯性行为。提供吸附时必须声明进入与退出条件，禁止静默换目标。长距离操作需要松手复位时，必须区分“暂停控制以重新放置手”的离合动作与提交动作；重新抓取前建立新基准，不得把复位位移补算为输入。双手控制必须定义两手角色及任一手丢失时的行为，不得静默降为单手并改变映射。

验证补充（连续映射）：拖动中转身、改变距离、松手复位、重定位坐标锚或丢失辅助手，检查对象是否跳变；速度控制在中立位置、退出和跟踪丢失时是否按约定停止。有效释放后已声明的惯性动画，与把丢失误当释放是不同情况。

依据与参考WCAG 2.5.2 Pointer Cancellation 解释了按下、释放、取消与撤销的区分。其直接对象是单指针输入；这里把可取消的操作阶段用于隔空交互，是本规范的设计推导，并不要求所有手势都采用释放触发。

验证补充：开始拖动 A 后看向 B、停留中换目标、在提交前主动取消；检查目标是否被偷换、进度是否被继承、取消后是否仍生效。

设计应用为连续控制（拖动、缩放）设计明确的抓取与释放语义；释放的判定不应只依赖速度阈值，否则用户缓慢松手会被判为持续抓取。

验证示例

• 用户侧：让用户连续执行三次同一手势，观察复位动作是否被误识别为第四次。
• 实现侧：录制连续动作流，检查切分点与人工标注的一致性，特别关注收手段。

反例做不到——向右挥手翻页后收回手臂，被识别为向左挥手翻回；做过头——要求每次手势前后各做一个明确的"准备"和"结束"姿势。

G1-3未脱离不等于持续授权必须¶

一句话：没主动退出不代表一直同意，参与状态会过期。

适用参与状态可以持续超过单次手势的产品。

规则参与状态必须有失活条件：至少包括无有效动作的超时。用户静止、转身、离开采集范围、注意力转移或开始与他人交谈，禁止被当作继续同意接收命令。参与状态失活后再次交互，必须重新满足进入条件；若产品提供短时免代价重入，其宽限时长必须显式定义且有限。

依据与参考用户结束操作后，系统可能仍把日常动作解释为输入。参与失活用于限制这段误触发暴露时间；保持原姿势本身不能证明用户仍希望发出命令。

边界条件低后果功能可以免去独立的进入动作；没有跨动作参与会话时，参与超时不适用，但每次命令仍须重新满足主体、空间与分段判据，并在操作结束或识别超时后失效。存在参与会话时，超时后不得因先前进入条件仍然为真而在下一帧自动重入。重入宽限不得恢复旧候选的提交资格。

设计应用超时时长按误触发后果分级，不用统一值；失活时给出可感知提示，不要静默切换。

验证示例

• 用户侧：用户完成操作后转身与人说话两分钟，观察其手部动作是否触发命令。
• 实现侧：检查是否存在无超时的参与状态；宽限重入的时长是否可解析到具体值。

反例做不到——用户在客厅看完电视继续聊天，手势被持续解释为音量调节；做过头——五秒不动就退出，用户思考一下就得重新举手。

G1-4无意动作不成为输入必须¶

一句话：说话时比划、挠头、递东西，不该触发命令。

适用采集范围覆盖用户日常活动空间的产品。

规则系统必须区分命令性动作与非命令性动作，其判据必须显式定义、可测试，且不得仅依赖手势形态本身。命令性判据至少应结合参与状态（G1-1）、注意力指向、动作的空间位置或分隔动作中的一项以上。日常交流手势、无关操作与身体调整动作被识别为命令的比率，必须在真实使用环境中测量，并作为发布判据之一。

依据与参考这是隔空手势最著名的失败模式（Midas touch）。提高识别阈值改变的是误识别与漏识别之间的权衡，但仅靠形态分类不足以证明"这是一次命令"——这需要结合参与状态或情境判据，并在目标数据上验证其权衡结果。有效手段在架构层：加一层参与状态或注意力锚，把"是不是命令"和"是哪个命令"分成两次判定。

设计应用把命令判定与手势分类拆成两级；第一级尽可能保守，第二级才做形态区分。

验证示例

• 用户侧：在真实环境中记录一小时自然活动（含交谈、进食、使用手机），统计误触发次数与后果。
• 实现侧：确认命令判定不是单纯的形态分类置信度；关闭注意力锚后误触发率的变化量可被测量。

反例做不到——用户打电话时的比划触发了删除；做过头——要求用户每次都先注视摄像头三秒，正常对话中根本无法使用。

G1-5输入归属明确必须¶

一句话：明确此刻听谁的、听哪只手，换人换手有显式条件。

适用采集范围内可能同时出现多人、多只手，或同时提供多个输入模态，或同一动作会被多个事件源解释的产品。

规则系统必须在任一时刻明确当前输入的归属主体（哪个人、哪只手）以及所属的操作实例，并定义归属的建立、保持与转移条件。归属转移必须有显式条件，禁止因另一只手更靠近、更清晰或先被检测到而自动转移；另一个人或另一只手进入采集范围时，不得继承已锁定的目标或已累积的确认进度，坐标连续本身不构成主体相同的证据。归属主体离开或失活时，必须结束当前未完成的连续操作，不得由新主体接续（连续操作的中止行为见 G5-1）。

边界条件本条不要求产品支持多人；声明"单人使用"的产品，只需保证第二人出现时不发生归属转移或误识别即可满足。平台不提供主体证据时，用可验证的隔离或显式参与机制满足本条，不得虚构身份置信分数。第三方被采集本身的处置见 G7-3。

规则（多模态路由）：同时使用手势、注视、语音、触摸或控制器时，必须定义各输入在目标选择、操作与提交中的角色，以及竞争时的优先级。同一用户意图不得因多个入口同时响应而重复生效。应用失去输入焦点、系统接管、设备休眠或模态切换时，必须结束或挂起未完成操作；恢复后核对主体、目标和参与条件，禁止自动补发旧的提交事件。

规则（事件归一）：同一物理动作同时产生平台选择、抓取和自定义识别事件时，必须指定负责当前操作的事件来源，并把其余事件关联或排除；不得将同一意图重复解释为多个提交。防抖时长不能替代操作归属和副作用防重。

依据与参考Microsoft 交互模型指南 提醒混合输入模型可能产生竞争性的操作线索；W3C XAUR §3.8 讨论输入切换中的焦点丢失。上述来源支持问题与设计方向；事件防重和恢复条件是本规范的必要性推导。

验证补充：捏合过程中拿起控制器、唤出系统菜单后返回、两个入口同时确认；检查是否重复提交或沿用过期目标。

设计应用为多人场景定义仲裁规则（先到、显式接管、绑定指定主体），并让当前归属对在场所有人可见。

验证示例

• 用户侧：一人正在拖动对象，另一人从旁走过并抬手，观察拖动是否被劫持或中断。
• 实现侧：检查归属切换事件是否被记录；单手绑定期间另一只手的输入是否被正确忽略。

反例做不到——两人在场时系统在两双手之间来回跳，谁都控制不了；做过头——要求每次操作前先做人脸识别登录。

G1-6参与成本与场景相称应当¶

一句话：入口的代价配得上功能的价值，两头都别走极端。

适用定义参与进入方式的产品。

规则进入交互的动作代价应当与所要完成任务的价值和频率相称：高频低后果的操作应当有低成本入口；低频高后果的操作应当有足以辨明意图、对象与后果的参与条件——"更高成本"指判据更充分，不指动作更累或等待更久；对后果的保护主要由 G6 的提交约束承担。不得以"零成本入口 + 事后撤销"替代 G6-1 对不可逆动作的提交约束。

设计应用同一产品内可以有多级入口——快捷手势直达常用操作，完整参与流程用于其他操作。

验证示例

• 用户侧：测量常用操作从"想做"到"做成"的总动作时间，与触摸或语音路径对比。
• 实现侧：检查是否所有功能共用同一个高成本入口。

反例做不到——调音量也要先完成一套三步参与流程；做过头——为了快，把删除也放进了零成本快捷手势。

3.2 G2 手势与意义的绑定¶

自定义隔空手势通常缺少实体标签；可见对象和平台标准交互可以提供可供性与既有约定。用户能用的手势，等于他能发现并记住的手势——这个数量远比设计者估计的小。本原则管的是手势集本身：多大、怎么被发现、彼此差多远、含义从哪来。

G2-1手势集有界且可发现必须¶

一句话：手势数量有上限，用户不看说明书也能发现能做什么。

适用所有定义了手势词汇的产品。

规则同一情境下同时有效的手势数量必须有明确上限，并作为设计决定记录。用户必须能够在不阅读外部文档的前提下发现完成主要任务所需的全部手势；主路径禁止依赖只能通过文档、教程视频或口口相传得知的隐藏手势。

设计应用优先让手势对应可见对象上的直接操作（推、抓、拖），此类交互的可供性来自对象本身，可以降低记忆负担，仍需验证其可发现性；把需要记忆的姿势型手势留给少量高价值的全局操作。

验证示例

• 用户侧：给未经培训的目标用户一个任务，记录其在无提示条件下能发现并使用的手势数量。
• 实现侧：清点各情境下同时有效的手势数，检查是否超出声明上限。

反例做不到——十二个自定义姿势，用户只记得住两个，其余功能事实上不可达；做过头——每个界面都常驻一张手势速查图，遮住了内容本身。

G2-2语义映射稳定必须¶

一句话：同一个手势在同一情境下只有一个意思。

适用所有定义了手势词汇的产品。

规则同一手势形态在同一情境下必须只绑定一个语义。允许同一形态在不同情境承担不同语义，但情境差异必须对用户可感知，且该感知不得仅依赖用户记忆当前所处的模式。手势的语义禁止随系统内部状态静默改变。

依据与参考这是模式混淆在手势模态中的形态。GUI 里模式有可见的视觉线索；手势没有输入设备的物理状态可依赖，模式错误往往到执行完才被发现。

设计应用让情境差异体现在被操作对象或空间位置上，而不是一个抽象的模式开关。

验证示例

• 用户侧：让用户在两个情境间切换后立即执行同一手势，观察其对结果的预期是否与实际一致。
• 实现侧：清点是否存在同形态多语义的组合，检查每组的情境区分依据。

反例做不到——同一个握拳动作在播放时是暂停、在列表里是删除，用户不知道自己在哪；做过头——为避免复用，给每个功能各配一个独立姿势，词汇量爆炸（违反 G2-1）。

G2-3形态差异足以区分必须¶

一句话：相近的手势不承担后果差别大的功能。

适用所有定义了手势词汇的产品。

规则手势之间的差异必须同时在两个层面成立：识别层面（系统能可靠区分）与执行层面（人能可靠做出区别）。二者只满足其一不算满足本条。后果等级差异大的两个动作，禁止绑定在形态相近的手势上；相近程度的判据必须显式定义并在目标用户中测量。

规则（平台冲突）：自定义与重映射后的手势必须检查与目标平台系统手势、辅助技术输入及日常交流动作的冲突。禁止拦截系统保留的退出或接管操作；升级平台或手势词汇后，必须复核相关冲突。

依据与参考Apple WWDC23：Design for spatial input 建议优先标准手势，自定义手势需与系统手势及常见交流动作区分。此为平台设计参考，不证明跨平台存在统一词典。

设计应用把后果重的动作放在形态上明显不同、且不容易被日常动作偶然构成的姿势上（见 G6-4）。

验证示例

• 用户侧：让用户连续执行相近的两个手势各二十次，统计其自身执行的可区分度与主观确信度。
• 实现侧：测量混淆矩阵，检查高后果动作与其最近邻手势的混淆率。

反例做不到——四指伸展是"保存"、五指伸展是"丢弃"，识别率还不错，但用户自己做不稳；做过头——为了区分度要求用户做出别扭的非自然姿势。

G2-4不假定通用直觉应当¶

一句话：手势含义靠目标用户验证，不靠设计者觉得自然。

适用定义或修改手势语义映射的产品。

规则手势与语义的绑定应当以目标用户群的实证为依据，不应当仅以设计团队的直觉判断"这个手势很自然"。产品应当考虑文化差异、惯用手差异，以及用户从既有设备（触摸屏、遥控器、鼠标）带来的既有预期对手势选择的影响。

依据与参考设计候选应纳入既有界面经验带来的预期，例如用户可能尝试在空中“点击”或“滑动”。既有经验会塑造用户预期，但这不构成对这些形态的跨设备优劣排名——候选手势的可理解性、可执行性、识别性与疲劳仍须在目标设备与目标人群上分别验证。因此实证的作用不是直接采纳用户提议，而是暴露设计者与用户之间的预期差。

设计应用把征引结果作为约束条件而非答案；用户高度一致提出的手势若不可用，至少要保证它不被绑定到相反语义上。

验证示例

• 用户侧：在目标用户中测试候选手势的语义猜测一致率与首次执行成功率。
• 实现侧：记录每个手势的选择依据与实证来源。

反例做不到——团队内部投票决定手势集，上线后发现主要用户群完全猜不到；做过头——把征引结果直接当规范，采用了一批做起来最累、识别最差的手势。

G2-5可自定义与可关闭应当¶

一句话：允许替换或关掉个别手势，但不能借此绕过后果约束。

适用手势集包含可能与用户日常动作冲突的条目，或面向差异较大用户群的产品。

规则产品应当允许用户关闭或重新映射个别手势。自定义不得改变动作本身的后果等级，也不得绕过 G6-1 对不可逆动作提交路径的要求；用户可以把删除换成另一个手势，但不得把它变成无需二次确认。关闭个别手势后，相应功能仍必须通过其他路径可达（见 G7-1）。

设计应用把"这个手势总是误触发"做成一次点击即可关闭的入口，而不是埋在设置深处。

验证示例

• 用户侧：让用户关闭一个高频误触发的手势，检查相应功能是否仍可用。
• 实现侧：检查自定义配置是否能突破后果等级映射与提交约束。

反例做不到——某个手势与用户的职业动作冲突，只能整体关闭手势功能；做过头——开放到用户可以把支付绑定在挥手上。

G2-6学习成本可重入应当¶

一句话：需要学的手势随时能再学一次，不靠首次引导讲完。

适用包含需要学习的姿势型手势的产品。

规则需要学习的手势应当有可随时重新进入的教学与练习入口，且该入口应当从使用现场可达，不要求用户中断任务去翻设置。教学应当提供做对与做错的即时区分，不只展示示意图。

规则（练习隔离）：教学中的练习动作必须限定在演示对象或可恢复的练习环境内，禁止产生真实发送、付款、删除或权限变更。进入与退出练习必须可感知，退出后不得把未完成练习手势接续为真实命令。

验证补充：练习确认手势后立即返回任务，检查真实对象与外部系统是否保持原状。

设计应用在识别连续失败时就地提供"看一下怎么做"，而不是仅在首次启动时播放一遍。

验证示例

• 用户侧：让用户在使用一周后重新找到某个不常用手势的学习入口，记录耗时。
• 实现侧：检查教学入口在主要使用场景中的可达步数。

反例做不到——首次启动播放一段引导视频，之后再也找不到；做过头——每次进入应用都强制重放教学。

3.3 G3 身体代价有预算¶

在隔空手势里，输入设备是用户的身体。它会累，精度有上限，形态因人而异，而且这些代价不会出现在任何日志里——它表现为用户悄悄不再使用这个功能。本原则把身体的可承受量当作硬约束，与延迟预算、内存预算同等对待。

G3-1主路径不依赖疲劳性动作必须¶

一句话：高频操作不要求抬臂过肩或长时间悬停。

适用所有以隔空手势作为常规输入的产品。

规则高频操作的主路径禁止要求抬手超过肩部高度、要求手臂在无支撑状态下长时间保持姿势，或要求大幅度全臂运动。产品必须为主路径声明动作预算（幅度、高度、单次保持时长），并在目标使用时长下验证其可持续性。

运动本身构成活动内容的情形另作评估（体感训练、康复、运动评估、演奏）：其身体负荷按该活动自身的目标与安全要求判定，不适用本条对"命令快捷操作"的预算；但进入、暂停与退出这些活动的控制动作仍适用本条，不得要求额外的疲劳性动作。

依据与参考悬臂疲劳（gorilla arm）不是耐力问题而是设计问题——无支撑悬臂可能导致疲劳与精度下降，其程度受姿势、动作负荷、任务时长与个体差异影响。有效对策是设计允许手臂获得支撑的动作（贴近身体的小幅动作、肘部有依托的姿势），而不是要求用户坚持。

设计应用把高频操作设计为在身体前方、肘部自然下垂位置即可完成的小幅动作；把需要大动作的手势留给低频操作。

验证示例

• 用户侧：让用户按典型使用强度连续操作，测量主观疲劳与后半程的执行成功率衰减。
• 实现侧：核对主路径的动作预算声明与实际交互所需动作是否一致。

反例做不到——每翻一页都要举手过肩挥动，用户十分钟后放弃；做过头——把所有动作压缩到极小幅度，导致识别不稳定、用户不敢动。

G3-2精度要求与人的能力相称必须¶

一句话：别把鼠标级精度要求搬到没有支撑的空中。

适用涉及目标选取、数值调节或位置控制的产品。

规则目标尺寸、稳定性要求与调节分辨率，必须在用户实际所处的支撑条件下可达成。产品必须声明主路径所要求的精度档位，无支撑条件下禁止把点级精度选取作为主路径。精度不足时，必须通过增大目标、提供吸附、改用相对调节或分级调节解决，禁止通过要求用户保持更稳来解决。

设计应用远距指向的角度抖动会随距离放大，同一手部抖动在近场可接受、在远场不可接受；近场直接操作与远距指向应当采用不同的目标尺寸标准。

验证示例

• 用户侧：在真实距离与姿势下测量目标选取成功率与耗时，含站立与就座两种姿势。
• 实现侧：检查目标尺寸是否随交互距离与输入模型（近场／远场）变化。

反例做不到——把桌面级的小控件原样搬进空中，用户反复选错相邻项；做过头——所有控件都放大到屏幕的四分之一，一屏放不下三个功能。

G3-3单手可完成应当¶

一句话：核心路径单手能走完，且不假定惯用手。

适用可能在用户另一只手被占用的场景中使用的产品。

规则核心任务路径应当可以单手完成，且不应当假定用户使用特定的惯用手。需要双手的手势应当限于确有必要的操作（如双手缩放），并应当有单手替代路径。

设计应用识别模型与交互布局都需要支持左右手对称；不要把左手的镜像动作识别为另一个语义（除非该语义差异是显式设计并对用户可见，见 G2-2）。

验证示例

• 用户侧：让用户一手持物完成核心任务；分别用左右手各测一次。
• 实现侧：检查是否存在只在某一只手上识别率显著下降的手势。

反例做不到——抱着孩子的用户无法使用任何功能；做过头——为保证单手可用，取消了双手缩放这类明显更好用的交互。

G3-4连续使用有上限并可休息应当¶

一句话：长任务提供可支撑的姿势或替代模态，不要求持续保持。

适用预期单次使用时长超过数分钟的产品。

规则产品应当为连续手势使用声明时长上限，并在接近或超过时提供可支撑姿势、分段完成方式或替代模态。禁止设计要求用户在整个任务期间持续保持某一姿势的交互——保持姿势的成本随时间非线性上升，且用户无法中途放下手。

设计应用把长过程拆成可暂停的段落，允许用户放下手而不丢失进度（状态延续要求见 G5-1）。

验证示例

• 用户侧：让用户完成一次完整的典型长任务，记录中途放弃与主动切换模态的次数。
• 实现侧：检查是否存在必须保持姿势才能维持的状态。

反例做不到——要求用户全程保持捏合姿势直到上传完成；做过头——每两分钟弹出一次"建议休息"打断工作。

G3-5身体差异不构成排除必须¶

一句话：手小、震颤、缺指、义肢的人也要能完成任务。

适用所有以隔空手势作为输入通道的产品。

规则手部尺寸、关节活动范围、震颤、指节缺失、义肢或佩戴物（手套、饰品、绷带）导致的识别与执行差异，不得使用户无法完成任务。产品必须验证在这些条件下的可用性；识别层面无法覆盖的情况，必须由 G7-1 的非手势路径保证功能可达，且该路径不得是功能受限的替代品。

边界条件本条不要求手势识别覆盖全部身体条件——那不现实。它要求的是：识别覆盖不到的地方，功能仍然可达。这也是 G7-1 存在的原因之一。

设计应用把可调参数（手势幅度容差、防抖强度、停留时长）开放给用户，而不是只提供一套按平均手型标定的配置。

验证示例

• 用户侧：在包含相关身体条件的用户中测试核心任务完成率。
• 实现侧：检查识别失败时是否自动、可感知地暴露非手势路径。

反例做不到——震颤用户始终无法完成停留确认，且没有别的入口；做过头——把所有阈值放宽到人人可用，误触发率随之失控（应当用可调参数解决，不用统一放宽解决）。

3.4 G4 状态可感知¶

手势交互没有机械反馈：手指按下去有阻力、鼠标点击有声响，这些在空中都不存在。用户对系统状态的全部判断，来自产品主动给出的反馈。反馈缺失时，用户的默认策略是重复动作——这会同时放大误触发与挫败感。

G4-1三态各有反馈必须¶

一句话：在范围、已锁定、已提交，三种状态要分得开。

适用所有以隔空手势作为输入通道的产品。

规则系统必须让用户区分适用的三个反馈层次：在范围（手部处于产品有效交互区且输入可用）、已锁定（当前候选目标或全局命令已明确，但尚未生效）、已提交（动作已经生效）。采集到手不等于已参与，参与状态按 G1-1 表达；全局手势没有空间目标时，锁定的是命令，不得虚构目标选中。某层次确实不存在时记录不适用，不得为了凑齐三态人为加入停留或确认步骤。反馈形式不限，只要目标用户能稳定区分。

规则（结果状态）：三态是反馈层次，不是完整状态机。存在异步执行时，必须另外区分处理中、失败、结果未知与已取消；请求发出或收到回执不等于动作已生效。已提交反馈必须来自真实结果；未决或失败状态不得被历史成功提示遮蔽。结果未知时的核对与防重见 G6-2。

依据与参考反馈层次缺失会造成如下可预见的失败：用户不知道是"没看见我"、"看见了但没选中"还是"选中了但没成"，只能反复重做。对存在这些阶段的任务，三者对应不同的下一步动作；混同可能诱发错误重试。这是本规范的交互模型，不是平台统一标准。

设计应用三态可以分配在不同通道上——在范围用光标或手部可视化，已锁定用对象高亮或吸附，已提交用声音加对象的实际变化。

下表是包含候选与异步提交的任务示例；简单本地操作可直接从有效输入进入结果，不人为等待。参与状态与执行结果分别管理，退出参与不抹掉已发生的结果。

规则（状态事实与竞争）：输入参与、数据有效性、操作阶段与执行结果必须分别判定。界面必须能把反馈关联到当前操作的主体、目标、动作、事件顺序与真实结果；这些是运行事实，不是 Token。取消、失活或数据失效与尚未生效的提交竞争时，必须先拦截不再满足条件的提交；若外部后果已经发生，则反馈实际结果并提供真实可用的撤销或补救，禁止声称“已取消”。迟到的旧操作回执不得覆盖新操作状态，已确认的失败或未决结果不得被“重新跟踪到手”清除。

验证示例

• 用户侧：在每种状态下暂停，让用户描述系统当前的状态与自己的下一步。
• 实现侧：检查三态是否有独立的可观察表现，可使用同一元素的形态、文字或对比度变化，但必须通过辨识验证。

反例做不到——只有一个小圆点，用户永远在猜；做过头——三态各配一套动画加音效，操作一次响三声。

G4-2反馈延迟有上限必须¶

一句话：反馈慢到破坏因果感时，降级为离散反馈而不是没反馈。

适用所有提供动作反馈的产品。

规则产品必须为反馈声明端到端延迟预算（自动作发生至用户可感知反馈）。延迟超出预算时，必须降级为明确的离散反馈（如"正在处理"的状态指示），禁止表现为无反馈。跟随性反馈（手部可视化、光标）的延迟一旦超出预算，禁止继续以跟随形式呈现——滞后的跟随比没有跟随更具误导性，用户会据此调整动作，导致过冲与震荡。

降级不得只停显示而继续累计输入：若此时无法向用户提供可供闭环判断的当前量，必须暂停该连续控制的新增业务更新，并明确已保留的值、尚未生效的部分与可用的退出方式；恢复时重新建立控制基准。仍有经验证可靠的对象自身反馈通道时可以继续——单一显示通道失效不等于整体反馈失效。

设计应用分别测量跟随反馈与结果反馈；前者参与连续动作纠正，后者用于判断是否生效，不用一个平均值代替两者的预算。

验证示例

• 用户侧：人为注入延迟，观察用户是否出现过冲、反复修正或重复执行。
• 实现侧：测量各类反馈的端到端延迟分布（不只是均值），检查超限时的降级行为是否触发。

反例做不到——手部光标滞后半秒，用户越修正越偏；做过头——为压低延迟牺牲识别质量，反馈快但经常是错的。

G4-3连续动作有连续反馈必须¶

一句话：拖动缩放时持续显示当前值，不是结束才告诉结果。

适用包含拖动、缩放、旋转、滑动调节等连续控制的产品。

规则连续控制在动作进行期间必须持续反馈当前值或当前位置，使用户能够在提交前判断是否达到目标并据此调整。禁止仅在动作结束后一次性呈现结果。连续控制必须有明确的释放语义，且释放的判定对用户可感知（起止判定见 G1-2）。

设计应用把被操作对象本身作为反馈载体优于额外的数值显示——对象跟着手动，用户不需要在两处之间分配注意力。

验证示例

• 用户侧：让用户把数值调到指定目标，记录过冲次数与修正次数。
• 实现侧：测量当前值与反馈的一致性、端到端延迟、尾部卡顿、过冲与修正次数；不以"刷新率与采样率相等"作为通过标准——两者不必相等，判据是端到端可闭环。

反例做不到——挥手调音量，松手后才知道调到了多少；做过头——在手边浮动一个精确到小数点后两位的数值面板，遮住了被调节的内容。

G4-4反馈不独占视觉应当¶

一句话：主要状态至少有一条非视觉通道。

适用用户视线可能不在显示区域的产品。

规则主要状态反馈应当至少有一条非视觉通道（听觉、触觉、中空触觉，或被控物理对象自身的可感变化）。在用户视线必须投向别处的场景中（驾驶、烹饪、手术、大屏远距操作），非视觉反馈为必须（见 G7-6）。

依据与参考隔空手势最有价值的场景恰恰是手不方便碰、眼睛不方便看的场景——而这类场景对视觉反馈的依赖是自相矛盾的。中空触觉是这一缺口的直接解法，但受设备与作用范围限制；听觉在多数场景中是更现实的选择。

设计应用非视觉通道不必承载全部信息，承载状态切换即可——"锁定了"与"提交了"用两种短促、可区分的声音就能覆盖大部分需求。

验证示例

• 用户侧：让用户在不看屏幕的条件下完成核心任务。
• 实现侧：检查静音条件下是否仍有可区分的状态反馈，或产品是否明确声明该场景不适用。

反例做不到——车载手势控制的全部反馈都在中控屏上，用户必须低头确认；做过头——每个微小动作都伴随提示音，副驾驶要求关掉整个功能。

G4-5边界可感知必须¶

一句话：快出界、已出界，用户要在发生时知道，不是靠没反应推断。

适用交互区存在有效空间边界的产品（即绝大多数产品）。

规则用户接近交互区边界、以及已经离开交互区，必须可被感知。已离开的反馈必须与"系统故障"和"动作未被识别"相区分——三者要求用户采取的下一步动作完全不同。禁止以无反应表示越界。

能确定原因时给出对应的提示；只能确定"输入当前不可用"而无法确定原因时，必须如实表达原因未知，并给出稳妥的恢复或切换入口——禁止在原因未知时虚构"太远""光线不足"一类确定诊断。本条要求区分的是已知事实，不要求传感器具备它并不具备的诊断能力。

设计应用接近边界时给出渐进式提示（手部可视化渐隐、方向指示），而不是在越界瞬间才突然失效。

验证示例

• 用户侧：让用户主动把手移出交互区再移回，观察其能否说出发生了什么以及如何恢复。
• 实现侧：检查越界、跟踪丢失（G5-1）与识别失败三种情况是否有区分的表现。

反例做不到——用户站得稍远，所有手势都没反应，以为功能坏了；做过头——手每靠近边缘一点就弹出一个警告框。

G4-6反馈不过载应当¶

一句话：反馈强度配得上动作后果，不对每次微动都大声提示。

适用所有提供动作反馈的产品。

规则反馈的强度与显著程度应当与动作的后果相称。高频低后果的操作应当使用轻量、可被忽略的反馈；醒目反馈应当留给状态切换与高后果动作。产品不应当为满足 G4-1 而对每一次微小位置变化施加醒目提示。

依据与参考本条是 G4-1 的配平项。三态反馈被做过头的典型结果是：所有反馈同等醒目，于是全部沦为背景噪声，真正重要的那次提交确认被忽略——这与告警疲劳是同一机制。

验证示例

• 用户侧：连续使用后询问用户是否注意到某次关键状态变化。
• 实现侧：清点单位时间内的反馈事件数与其中醒目级别的占比。

反例做不到——提交与移动用同一种弱提示，用户不知道自己已经提交；做过头——每帧位置更新都伴随音效与动画。

3.5 G5 识别不确定性显式化¶

手势识别可能输出标签、分数或概率估计，均不等同于用户意图事实。产品必须显式决定如何处理这种不确定性：偏向哪一侧、多不确定时停下来、丢失时怎么办、能力下降时往哪退。这些决定不做，就会被默认值代替——而默认值往往是"取最高分类结果并执行"，这在高后果动作上是不可接受的。

G5-1跟踪丢失是正常状态必须¶

一句话：丢失时的行为预先定义且安全，禁止拿最后一帧继续推进。

适用所有依赖持续跟踪的产品。

规则跟踪丢失必须作为正常运行状态处理，而非异常分支。产品必须为每类进行中的操作定义丢失时的行为，且该行为必须是安全的默认：冻结当前值并等待、回滚到操作开始前状态，或按已定义的宽限时长等待重获。禁止以最后一帧的数据继续推进操作；禁止在丢失后自动提交进行中的动作。丢失必须对用户可感知（见 G4-5），且重获跟踪后的接续行为必须明确定义，不得静默跳变。

依据与参考持续跟踪失效会破坏连续控制所依赖的位置与动作证据。手离开视野时，最后一帧的速度矢量若被外推，会产生一次用户完全没有做出的大幅动作——在拖动、删除、滑动确认类交互上，这直接造成不可预期的后果。遮挡（另一只手、身体、持物）、光照突变、超出范围都会产生同一现象，且在真实环境中频繁发生。

规则（数据资格）：产品必须声明每类操作所依赖的数据及其有效性判据：所需的关节或方向、时间新鲜度上限、平台提供的有效性与跟踪标记如何解读、以及部分丢失时的处置。有数值不等于跟踪有效——坐标存在但所需数据无效或过期时，不构成可用输入；平台另有主动跟踪标记时，须声明其与有效标记的组合判据。缺少某类标记的 API 使用其实际提供的姿态有效性或标准输入事件，不伪造标记，也不默认旧坐标有效。失效之后的平滑、旧值沿用与外推只能用于显示，不恢复操作资格，也不构成提交依据；已通过平台与产品有效性判断的正常姿态估计不因其为"估计"而一概禁止。

规则（重获）：允许接续时，必须核对仍为同一主体、目标与操作，并重新建立当前手位置与对象位置的控制关系；无法核对时取消候选或要求重新开始。

设计应用为连续操作准备操作起点快照，使回滚成为可选项；宽限时长按操作类型分别设定，不用统一值。

验证示例

• 用户侧：在拖动过程中把手移出视野再移回，观察对象是否发生用户未预期的位移或提交。
• 实现侧：注入跟踪中断，检查是否发生外推；检查重获后的位置是否发生跳变；改变输入主体或目标后，旧操作是否被错误接续。

反例做不到——手被遮挡瞬间，被拖动的对象飞到屏幕外并提交；做过头——任何一帧丢失都立即整体回滚，正常使用中操作不断被打断（可按操作后果采用有限宽限，期间不继续更新）。

G5-2偏置方向显式且分级必须¶

一句话：识别基础值可以共享，后果放行策略必须分级验证。

适用所有基于分类或阈值判定手势的产品。

规则产品必须显式声明识别的偏置方向（宁可漏识别还是宁可误触发），且该声明必须按动作后果等级分级，禁止仅凭一个未验证的全局阈值放行所有后果。识别器可以共享基础阈值，但各等级的放行策略与误触发验收必须独立定义；额外确认不得被高置信替代。不可逆、对外产生影响或涉及资金的动作，禁止采用偏灵敏的设置。偏置方向的选择必须作为设计决定记录，并可随场景（见 G7-5）调整。

依据与参考在识别器和数据分布固定时，调整判定阈值通常带来误触发与漏识别的权衡；改进模型、数据或参与机制可能同时改善两者，不能断言二者无法同时优化。分数也不天然是校准后的概率。scikit-learn 阈值调优文档 将统计预测与行动决策分开，并要求避免在训练数据上直接调阈值；它支持方法，不提供手势产品的阈值。

设计应用把阈值与后果等级映射绑定（见 Design Token 的 gesture.recognition.confidence.threshold 与 gesture.commitment.risk.mapping），而不是在代码里散落若干魔数。

验证示例

• 用户侧：分别在高后果与低后果动作上测量误触发与漏识别的实际发生率与用户反应。
• 实现侧：检查每个后果等级是否有明确的放行策略与验证记录，是否用高分绕过确认。

反例做不到——所有手势共用一个置信阈值，删除和翻页一样容易被误触发；做过头——为压制误触发把全部阈值调到极高，正常操作十次有三次没反应。

G5-3低置信不冒充确定必须¶

一句话：拿不准时不执行高后果动作，也不静默猜一个。

适用识别结果附带置信信息的产品。

规则识别置信低于该动作对应阈值时，禁止直接执行高后果动作。系统必须采取以下之一：维持原状并给出可感知提示、呈现候选供用户选择、或要求补充确认。禁止静默采用最高分候选执行，也禁止把低置信结果呈现为已确定的识别结果。

边界条件本条不要求向用户暴露置信数值。它要求的是行为上的差别对待——用户不需要知道是 0.6 还是 0.9，需要知道的是"系统不太确定，请再来一次"和"系统确定了"。

设计应用已绑定目标时，可保持当前值并提示等待辨识；命令尚未确定时，显示候选或提供选择，不能称为“已锁定”。只在需要用户判断时请求确认。

验证示例

• 用户侧：制造模糊手势输入，观察系统是否执行了用户未预期的动作。
• 实现侧：检查高后果动作路径上是否存在绕过置信判定的分支。

反例做不到——模糊动作被判为删除并直接执行；做过头——稍有不确定就弹确认框，正常使用中确认框不断（应按是否已有有效目标选择维持、候选或取消，见设计应用）。

G5-4识别条件可被知道并改善应当¶

一句话：识别变差时告诉用户原因，且是他能动手改的原因。

适用识别质量受环境条件显著影响的产品。

规则当光照、遮挡、距离、动作速度、佩戴物等条件导致识别质量下降时，产品应当以用户可采取行动的方式告知。提示应当指向具体的改善动作（靠近一点、把手抬高一点、避开逆光），不应当只呈现"识别失败"或技术性错误码。

设计应用把提示与 G4-5 的边界提示统一在同一套反馈语言里，避免用户需要学习两套错误表现。

验证示例

• 用户侧：在逆光、部分遮挡、过远三种条件下，观察用户能否自行恢复到可用状态。
• 实现侧：检查各类识别下降是否被区分，还是统一归为一种失败。

反例做不到——始终只显示"未识别到手势"，用户不知道该往前走还是该开灯；做过头——持续显示一个识别质量仪表盘，用户被迫时刻监控传感器状态。

G5-5降级路径预先定义必须¶

一句话：能力下降时怎么退，提前定好顺序，不在运行时临时决定。

适用识别能力可能在运行中下降的产品（即绝大多数产品）。

规则产品必须预先定义识别能力下降时的降级顺序，可选层级包括降低精度要求、缩小同时有效的手势集、切换到更粗粒度的交互、切换模态与停止手势输入。降级必须对用户可感知，且降级后仍可达的功能范围必须明确。禁止在能力不足时继续以完整手势集运行并依赖用户反复重试。

边界条件本条不要求产品实现全部降级层级；它要求所采用的层级是预先定义的、有顺序的，并且最末一级落到 G7-1 的非手势路径上。

设计应用把降级触发条件（连续失败次数、持续丢失时长、环境条件）与降级动作在配置层显式绑定（见 Design Token 的 gesture.recognition.degradation.order 与 gesture.fallback.auto_fallback.trigger）。

验证示例

• 用户侧：逐步恶化识别条件，观察用户是否在每一级都仍能完成任务或明确知道该改用什么。
• 实现侧：遮挡摄像头，检查系统是否进入已定义的降级态而非持续报错。

反例做不到——摄像头被挡住后应用完全无响应，也不提示还能怎么操作；做过头——识别稍有波动就直接切到语音，用户被反复切换模态。

3.6 G6 后果与手势解耦¶

误识别在这个模态里是常态。因此规范真正要保护的不是识别准确率，而是误识别的后果规模。本原则管的是手势与其造成后果之间的耦合强度：后果越重，这条链路上就越不能只有一个手势。

G6-1不可逆动作不由单次手势提交必须¶

一句话：删除、发送、支付不能一挥手就成立。

适用可通过手势触发不可逆动作、对外产生影响的动作或涉及资金的动作的产品。

规则不可逆动作、对外发送或发布、支付与资金转移、权限变更，禁止由单次手势直接提交。此类动作必须经过异模态的第二通道确认（语音、按键、触摸或人工操作），或与被确认对象显式绑定的二次手势确认。外部结果已发生后可做补救，不等于从未产生过后果，不得以此豁免确认。确认必须绑定具体对象、内容、当前状态与后果，不得是泛化的"确定吗"；等待确认时关键条件改变或确认失效，必须重新确认。确认不替代平台身份验证与权限检查。

依据与参考无意动作可能触发外部后果。二次确认用于让用户判断具体对象与后果；只有识别分数更高、动作更久或更累，都不能代替这次判断。

设计应用可完整恢复且无外部影响的低后果动作可以直接生效并提供撤销；对外发送与付款等动作先确认。倒计时发送期间的按钮是取消尚未发送的请求，不是撤销已发送的消息。

验证示例

• 用户侧：让用户在有旁人干扰的环境中使用五分钟，检查是否发生非预期的不可逆动作。
• 实现侧：清点所有不可逆动作的触发路径，检查是否存在单手势直达的分支。

反例做不到——挥手即删除邮件，且无法恢复；做过头——连切换歌曲都要求二次确认。

G6-2撤销可达必须¶

一句话：可恢复的改变有真实撤销，且撤销不只依赖手势；不可恢复的后果不冒称可撤。

适用手势可触发状态改变的产品。

规则对于可恢复的状态改变，产品必须提供真实有效的撤销，且撤销路径不得仅依赖手势输入本身——如果识别正在失效，用户恰恰无法用手势撤销。撤销窗口的时长必须显式定义，可按动作类别分别设定。已提交且确实不可撤销的动作，必须在提交前被 G6-1 覆盖；提交后不得以撤销入口暗示可以恢复。

规则（结果未知与恢复）：异步操作超时或回执丢失时，必须先核对实际结果；未确认失败且无法保证不重复生效时，禁止把用户重复手势当作新的相同请求直接重发。取消未提交动作、撤销已生效改变与补救外部影响必须分开反馈。撤销必须说明范围，并保护其他用户或入口在此后产生的有效修改。

验证补充：模拟动作已生效但回执丢失，再重复手势；检查是否只生效一次。用其他入口修改对象后撤销手势操作，检查后续修改是否被抹掉。

设计应用把撤销放在非手势通道上（物理按键、语音、屏幕控件）；即使手势识别完全失效，撤销仍然可用。

验证示例

• 用户侧：在识别质量恶化的条件下，让用户撤销刚才的误操作。
• 实现侧：检查撤销入口是否依赖手势；检查界面上的撤销提示与实际可撤销范围是否一致。

反例做不到——误触发了删除，撤销手势也识别不出来，用户只能眼睁睁看着；做过头——为所有操作维护无限撤销栈，性能与存储代价失控。

G6-3误触发成本有上限必须¶

一句话：单次误识别的后果有上限，反复误触发要能被察觉并收敛。

适用所有以隔空手势作为输入通道的产品。

规则单次误识别可造成的后果规模必须有明确上限，并作为设计决定记录（数量、金额、影响范围、可见性）。产品必须声明连续操作的累计影响上限、统计窗口与超限行为，且不得靠重新参与或切换模态绕过。产品必须具备察觉反复误触发的机制，并在达到阈值后采取收敛动作：提高识别阈值、缩小手势集、提示切换模态或暂停手势输入。禁止把误触发的识别与处理完全交给用户。

依据与参考单次可接受的影响，重复累积后可能不可接受。持续遮挡、干扰或日常交流动作可能导致成簇误触发，因此需要同时限制单次影响与累计影响。

设计应用把"用户连续撤销三次同类操作"当作误触发信号，而不是等待用户去设置里关闭功能。

验证示例

• 用户侧：制造持续误触发条件，观察系统是否在用户抱怨前自行收敛。
• 实现侧：检查是否存在单次即可造成大规模影响的手势路径；检查收敛机制的触发阈值是否可解析到具体值。

反例做不到——一个误识别的手势清空了整个列表；做过头——一次误触发就永久禁用该手势，用户不知道功能去哪了。

G6-4确认动作不与常用动作同形必须¶

一句话：用来确认的手势，形态上要和高频手势明显分开。

适用使用手势作为确认通道的产品。

规则用于确认高后果动作的手势，与高频操作手势之间必须有显著形态差异（差异判据见 G2-3），且不得是日常活动中容易偶然构成的姿势。确认手势禁止是高频手势的延续、重复或轻微变体——用户在连续操作的动作流中很容易自然地走到那个形态上。

设计应用让确认动作在动作维度上与常用动作正交——常用动作若是水平方向的，确认就不要也是水平方向的变体。

验证示例

• 用户侧：让用户连续快速执行高频操作，统计是否偶然触发确认。
• 实现侧：测量确认手势与其最近邻高频手势的混淆率，以及在自然活动录像中的偶然出现率。

反例做不到——单指点是选择、双指点是确认删除，用户手抖一下就删了；做过头——确认手势设计得极其罕见和别扭，用户每次都要试三遍。

G6-5后果分级决定交互形态应当¶

一句话：保护强度配得上后果，不以动作更累或耗时更长证明更安全。

适用包含多个后果等级动作的产品。

规则动作的后果等级应当决定其提交路径的保护强度：后果越重，越应当采用清晰对象预览、显式确认或第二通道。增加停留时长或动作幅度不天然提高安全性，且仍受 G3 的身体预算约束。禁止为设计一致性而给所有动作统一提交形态——统一到低成本一侧会违反 G6-1，统一到高成本一侧会让高频操作不可用。

设计应用把后果等级作为手势集的一个维度显式建模（见 Design Token 的 gesture.commitment.risk.mapping），让交互形态从等级派生，而不是逐个功能拍板。

验证示例

• 用户侧：验证各等级的错误提交率、后果范围和恢复成本，并测量额外确认是否妨碍正常任务；不以耗时更长证明更安全。
• 实现侧：检查是否存在后果等级与提交成本倒挂的动作。

反例做不到——所有操作都是"指一下就执行"，包括清空回收站；做过头——所有操作都套用最高等级的三步确认，产品慢到不能用。

3.7 G7 情境与他人¶

隔空手势发生在开放的物理空间里：有旁人、有变化的光线、有被占用的双手、有正在开车的主任务。这些不是"边缘场景"，而是这个模态的常态使用条件。本原则管的是交互所处的环境，以及环境中不是用户的那些人。

G7-1非手势路径必须存在必须¶

一句话：每个功能都有不用手势也能到达的入口。

适用所有以隔空手势作为输入通道的产品。

规则手势可达的每一项功能，必须存在至少一条不依赖手势的可达路径。该路径必须同时满足三类情况的需要：身体条件导致手势不可用（见 G3-5）、双手被占用、识别能力失效（见 G5-5）。非手势路径不得是功能受限的替代品——允许操作效率不同，不允许功能缺失。手势输入必须可被用户完全关闭，关闭后全部功能仍然可达。

边界条件本条的功能等价针对以动作发出命令的任务。手部运动测量本身构成活动本质时（如动作评估），不要求用按钮伪造同等测量结果；必须说明不适用条件，并为进入、暂停、退出及结果访问保留可用入口。

规则（可用的替代）：替代路径必须在目标情境下实际可用；例如双手被占用时，只有触摸按钮不足以覆盖该条件。切换入口必须在识别失效时可发现、可操作，并保留仍有效的对象与进度；无法接续的部分必须说明。

依据与参考WCAG 2.5.4 Motion Actuation 明确涉及对摄像头做出的手势，要求替代控件与可关闭，并列出辅助接口和本质性活动例外。它直接适用于 Web；本规范对其他产品的采用属于设计要求，不等于取得 WCAG 合规证明。WCAG 2.5.7 另要求适用的拖动功能提供无需拖动的单指针操作，不能仅以“换一只手拖动”作为替代。

设计应用把非手势路径当作主路径设计、把手势当作加速器，而不是相反。

验证示例

• 用户侧：完全关闭手势输入，让用户完成全部核心任务。
• 实现侧：清点功能矩阵，检查是否存在仅手势可达的功能。

反例做不到——某项设置只能通过一个特定手势打开；做过头——为保证等价，把每个手势都在界面上配一个等价按钮，界面被按钮淹没（等价路径不要求同一入口形态）。

G7-2采集状态可见必须¶

一句话：传感器什么时候在采集，用户能知道，且关不掉这个指示。

适用使用摄像头、雷达、深度传感器或麦克风阵列进行手势采集的产品。

规则传感器处于采集状态时，必须存在对在场人员可感知的指示，且该指示不得被产品配置或应用关闭。采集范围、采集内容类别与保留策略必须可查询。手势识别所需的原始感知数据，其保留期限必须独立于产品的其他数据保留策略明确声明。

规则（最小采集）：能够由平台标准输入事件完成的功能，不得仅为实现同一功能而额外索取原始图像或完整手部骨架。确需这些数据时，必须说明用途、处理位置、接收方、授权拒绝或撤回后的行为。骨架与派生特征不因未保存图像而被视为匿名；用于诊断、个性化或训练的留存须分别声明，不继承“允许本次交互”的许可。

依据与参考WebXR Hand Input 的隐私与安全章节 将手部数据作为具有隐私风险的输入处理。这里的最小采集与用途区分是产品设计要求，不把该工作草案的 API 行为套用到所有设备。

边界条件本条不要求指示形式为特定形态（指示灯、屏幕图标、物理遮蔽件均可），要求的是在场人员可感知且不可被关闭。

设计应用物理级指示（硬件联动的指示灯、机械快门）优于软件绘制的图标——后者的可信度取决于软件本身。

验证示例

• 用户侧：让在场的非用户判断设备当前是否在采集。
• 实现侧：检查是否存在任何配置路径可以关闭指示；检查原始数据的实际保留期与声明是否一致。

反例做不到——一个常开摄像头，没有任何在采集的迹象；做过头——屏幕上常驻一个大幅的隐私横幅，遮挡内容且用户很快学会忽略。

G7-3第三方不被当作用户必须¶

一句话：路过的人不触发命令，也不被默默留存。

适用采集范围可能覆盖非用户人员的产品。

规则出现在采集范围内的非用户人员，其动作禁止被识别为命令（归属判定见 G1-5），且其可识别的个人信息不得在无明确依据的情况下留存。产品必须声明第三方进入采集范围时的处置方式。共享或公共场所部署的产品，必须在部署环境中提供采集范围的可知方式，使非用户能够知道自己是否处于采集中。

依据与参考本条与 G1-5 的规范对象不同：G1-5 管"输入算谁的"（系统判定），本条管"不是用户的人被采集了怎么办"（第三方权益）。前者错了是功能问题，后者错了是权益问题。

设计应用把非用户的检测结果用于抑制误触发（他们的动作不作为输入），而不是用于识别他们是谁。

验证示例

• 用户侧：让第二人在用户身后活动，观察是否影响交互。
• 实现侧：检查非归属主体的数据是否进入持久存储；检查采集范围在部署环境中是否可被在场者知晓。

反例做不到——身后走过的人挥手换掉了正在播放的内容；做过头——为区分用户与旁人而对所有在场者做人脸识别与建档。

G7-4社会可接受度纳入设计应当¶

一句话：公共场合的手势不让人做起来觉得尴尬或让旁人误解。

适用可能在公共或共享场所使用的产品。

规则面向公共或共享场所的手势，其动作幅度与形态应当考虑执行者的社会成本：不应当要求用户做出在该场景中显得异常、引人注目或可能被旁人误解的动作。同一功能在私人与公共场景中应当允许不同的手势幅度（场景适配见 G7-5）。

依据与参考社会可接受度不是舒适度问题而是可用性问题——用户不会在公共场合做让自己尴尬的动作，该功能事实上不可用，且这不会体现在实验室测试中。

设计应用把公共场景的手势设计成贴近身体的小幅动作，把大幅动作留给私人场景。

验证示例

• 用户侧：在真实公共环境（而非实验室）中观察用户是否实际使用该手势。
• 实现侧：检查是否为公共场景提供了幅度更小的替代手势。

反例做不到——在地铁上要求用户举手过头挥动；做过头——把所有手势都缩小到公共场景标准，私人场景下识别率反而下降。

G7-5环境变化触发适配应当¶

一句话：光线、噪声、姿势变了，配置跟着变，不是一套走天下。

适用使用环境条件会显著变化的产品。

规则产品应当根据环境条件（亮度、噪声、空间尺寸、用户姿势、是否手持物品）调整识别参数、反馈通道与有效手势集。适配的触发条件与调整内容应当预先定义，并对用户可感知；禁止在用户不知情的情况下改变手势的语义映射（见 G2-2）——调整参数与调整语义是两件事。

设计应用环境适配应当作用在阈值、反馈通道和手势集大小上，不作用在手势含义上。

验证示例

• 用户侧：在明暗、安静与嘈杂条件间切换，观察用户是否需要改变自己的操作方式，以及是否被告知。
• 实现侧：检查适配是否改变了任何手势的语义绑定。

反例做不到——白天可用，晚上开灯前完全不能用，且没有提示；做过头——环境略有变化就切换整套手势集，用户永远不知道现在哪些手势有效。

G7-6不与安全关键任务争注意力必须¶

一句话：驾驶等场景下，手势不得要求看屏幕或长时间脱离主任务。

适用在驾驶、操作机械、医疗操作等安全关键场景中使用的产品。

规则本条保护的是正在进行的安全关键主任务，约束的是与之竞争注意力的次要手势任务。在此范围内，手势交互禁止要求用户将视觉注意力从主任务上移开，禁止要求双手同时脱离主任务控制，禁止要求持续保持超出短暂时长的姿势。此类场景的反馈必须包含非视觉通道（见 G4-4）。可用手势集必须限制在无需视觉确认即可完成的范围内；"需要选择目标"不构成统一禁令——判据是该选择是否分走主任务所需的资源（在影像判读这类本身即为视觉主任务的场合，选取目标可能并不使注意力离开主任务）。若手势直接承担安全关键主任务本身的控制，不属于本条的次要任务情形：须转由该领域的专门交互设计与功能安全评估处理，本规范不以"具备非视觉反馈"证明其适用。识别失败时，禁止要求用户持续重试；重试上限与降级条件必须由领域评估确定。无法证明重试可接受时，不追加重试，转到经评估可用的替代方式或推迟次要任务（见 G5-5）。

边界条件本条规定的是交互形态的必要条件，不替代该领域的分心评估、功能安全与法规合规专项——那些有各自的测量方法与限值，本条不给出具体的时长阈值。非视觉不等于没有认知负荷；应评估完整任务及失败恢复对主任务的影响。美国 NHTSA 官方指南目录 可定位视觉手动分心测试程序，但该指南是自愿性指导，不能直接充当所有法域或隔空手势的认证。

设计应用作为次要任务时，优先采用少量、粗粒度、无需移开主任务视线的动作；是否允许目标选择，依据完整任务对主任务注意力的影响判断。

验证示例

• 用户侧：在模拟主任务负荷条件下测量视线离开主任务的次数与时长，以及主任务绩效的变化。
• 实现侧：检查是否存在需要视觉确认才能完成的手势路径；检查失败重试策略。

反例做不到——驾驶中的手势菜单要求在中控屏上瞄准选项；做过头——提供冗长语音说明替代视觉菜单，虽然不要求看屏幕，仍持续占用主任务注意力。

---

4. 术语和定义¶

---

附录 A：故障注入验证清单¶

对涉及识别可靠性与环境条件的规则，验证方式是故障注入：制造会破坏承诺的场景，测试失败即意味着相应承诺失效。写不出这类测试的候选规则不应进入规范。下表是示例子集而非穷尽清单。数字为故障注入样例，不是发布阈值；高后果动作只在沙盒、模拟器或测试对象上验证。

最后一行不能省：否则产品可能通过全部防误触发测试，却慢到没人愿意用。除故障注入外，还应分别验证分类（不同评审者能否对具体要求独立得出相近归属）与用户价值（误触发是否真的下降、任务是否真的更快完成），三者不能互相替代。还应当用完整任务走查检验覆盖面——沿"靠近、进入交互、发现可用手势、执行、纠错、离开"过一个真实案例，检查是否存在重要设计要求无处归属。

---

A.1 指标与发布记录¶

阈值由目标产品预先定义；本表给出测量口径，不提供通用数字，也不构成一套已经通过用户验证的验收标准。

Consumed Endurance（CHI 2014，作者机构页面） 提供基于姿势负荷估计手臂疲劳的方法；NICE（2023，作者机构摘要） 重新检验了 CE 的适用性。二者作测量方法参考，不能取代目标用户测试。

每次验证记录设备、SDK、实际配置快照、任务与用户样本、环境、预设门槛、实际结果、不适用项及处理责任人。识别器、词汇、输入路由或默认配置变化后，重验受影响旅程；不要仅用总体识别准确率作为发布依据。

---

A.2 验收记录与通过条件¶

每条适用义务分别记录：规则子句 → 场景与前置条件 → 注入事件 → 预期状态和后果 → 用户可见反馈 → 实测证据 → 结论与责任人。结论采用通过、未通过、不适用（附理由）；未执行不计为通过。“应当”条款偏离时附理由与替代验证，不用总分抵消硬约束失败。

自然活动误触发统计须报告暴露时间、参与人数、环境分层与不确定性，不以零事件直接宣称零风险。延迟测量注明采样事件、时钟对齐方法与终点；日志只保留证明行为所需的事实，不默认录制完整感知流。支持判断的事实不足、依赖缺失或硬约束失败时，限制或停用受影响能力；证据只对已测的设备、输入模型、用户和任务范围成立。

---

附录 B：论证边界与适用范围¶

B.1 约束词的判据¶

标「必须」的唯一依据是必要性：缺了这条要求，产品对用户的某条承诺会在可预见的情境下失效。判断一条规则用三类论证：

只有必要性论证成立的规则才标「必须」；只满足质量或效率的降为「应当」或逐出规范。具体识别算法、传感器选型与性能工程不进入规范。

B.2 适用范围与已知弱处¶

本规范的适用范围是：以手部或上肢的隔空动作作为输入通道之一的交互式产品，涵盖头显、车载、大屏、公共终端、家电与工业场景。它不覆盖：手势识别算法与传感器工程、手势形态本身的标准化（见 ISO/IEC 30113 系列与 ISO/IEC 14754）、无障碍专项评估、隐私与数据保护合规、车载分心的测量与限值、功能安全与领域法规。G7-6 规定交互形态的必要条件，不给出时长阈值——那属于领域专项。

如实说明三点弱处：

1. 本规范未给出任何具体数值阈值。停留时长、延迟预算、置信阈值、交互区尺寸都写成"必须显式声明并验证"，而不是给出数字。原因是这些值强依赖传感方案、使用距离、用户姿势与场景，现有资料不足以支持跨产品统一数值；引用的厂商数值绑定特定硬件与输入模型（见 reference.md）。这是有意的取舍，代价是本规范不能直接当作验收表使用——数值必须由各产品自行确定并纳入 Design Token。

2. 失败论证主要是可预见反例、平台警告与场景研究。未取得足以支撑项目失败归因的一手复盘，不把产品退场归因于某一交互缺陷，也不把模拟反例写成已发生事故。来源及读取范围见 reference.md。

3. 本规范的原则切分未经外部评审者的分类检验。互斥与穷尽目前仍是待检验的主张。已知的两处高风险边界：G1-5（输入归属）与 G7-3（第三方处置）的划分、G4-5（边界可感知）与 G5-4（识别条件告知）的划分。这两处在实际评审中若反复出现归属分歧，应当调整原则切分而非增加交叉引用。

B.3 待验证议题¶

以下问题尚需完整任务走查检验，不作为独立规则：

• 手势集跨产品一致性：平台内的既有约定与冲突复核已由 G2-3、G2-4 承载；现有资料不足以支持跨所有平台的统一手势词典。
• 多用户同时反馈：暂由 G1-5 与 G4-1 共同承载。仅在明确支持多人同时交互的产品中才成为独立义务。
• 误触发后果的对外可见性：暂由 G6-3 的后果上限承载。走查发现承载不足时按附录 A 的分类检验升格。

外部来源对照见同目录 reference.md。

---

实施验收场景¶

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

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