触觉交互设计规范

面向设计师与工程师：让触觉被感觉得到、认得出、来得及、降得下去、关得掉，并且不把用户的身体当作可以随意占用的输出通道。

本规范聚焦手机、手表、触控板、手写笔与游戏控制器上的振动触觉输出。一次触觉既可能确认操作，也可能传达边界、结果或质感；它的设计需要同时考虑语义、身体感受、设备能力与播放条件。

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

规范从两项体验承诺出发：用户能理解反馈，且能控制是否接受反馈。设备与身体接触时，振动可能造成打扰或不适；而成功、失败等业务含义需要通过稳定映射学习。这里不把“触觉唯一不可回避”“触觉完全没有天然含义”或“习惯化不可逆”当作科学前提：物理碰撞可以有直觉关联，语义也受情境影响。每条硬约束须说明缺失后哪项承诺会失效，平台建议与单项实验不自动构成通用强制要求。

本规范约束的是产品通过触觉对用户作出的承诺及其兑现机制的性质，不预设作动器类型、不指定具体 API 形态，也不规定波形的美学取向。它不是触觉效果库，不是硬件选型指南，也不替代人体工效学标准（ISO 9241-910/920）、无障碍专项评估、以及领域法规（车载 HMI、医疗设备、儿童产品）的独立审查。

第 1–3 章用于理解和核对要求，第 4 章统一术语，第 5 章帮助完成设计决策，第 6 章说明验证与交付。附录 A 提供检查清单，附录 B 说明证据边界。可配置决定见 Design Token，外部依据见 来源说明。

从具体问题开始：新增触觉点先读第 5 章；设备表现不一致查 H1、H4；反馈迟到或重复查 H3、H7；关闭、取消与中断查 H5、H6、H4-5。规则编号用于追溯要求，不要求设计者按 35 条依次填表。

---

1. 七条原则¶

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

同一个场景可以触及多条原则——一次"支付成功"的触觉同时涉及信号可觉察（H1-1）、语义映射（H2-2）、不得先于服务端确认（H3-4）、无作动器设备上的替代通道（H4-2 与 H5-1）——这不是分类错误：这些规则约束的是不同规范对象上的义务。

互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证（不同评审者能否对具体要求独立得出相近归属）；检验不过，修改的是原则的切分。

几组容易被误认为重复、实际规范对象不同的划分：

• H1 与 H4：H1 管人的一侧（这个强度对这个人在这个情境下够不够），H4 管设备的一侧（这台设备做不做得出这个波形）。同一次失败可以来自任一侧，处理方式完全不同。
• H5 与 H6：H5 管信息分工（不能只用触觉传达），H6 管身体自主权（用户有权拒绝触觉本身）。H6 允许用户关掉触觉，正是由 H5 保证关掉之后仍然可用。
• H1-2 与 H7-1：H1-2 管单次信号之间能不能被分辨（含最弱档与降级形态），H7-1 管同一效果族内一段时间的强度分布是否与重要性匹配。前者是感知问题，后者是预算问题。

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

2. 规则的读法¶

2.1 每条规则的结构¶

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

规则写行为性质、不写实现方式：能力不足时按定义好的路径降级是产品行为，用哪一颗作动器、调哪个驱动 IC 是工程方案——两者必须对得上，但不是同一份交付物。

正文中出现的数值是参考值，不是判定阈值。它们来自公开研究与平台文档（出处见附录 B），用于说明量级和方向。规则要求产品确定并验证自己的阈值，参考值用于在没有自测数据时提供起点，以及在评审时判断某个取值是否明显偏离已知量级。

2.2 约束词¶

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

• 必须：不满足即不符合本规范。缺了它，触觉要么感觉不到、认不出、来不及，要么变成用户无法摆脱的打扰——这是标「必须」的唯一依据（见附录 B）。
• 禁止：与「必须」同等强度的反向表述，指明不得出现的行为；正文中的「不得」与「禁止」等价。
• 应当：默认遵循；确有理由偏离时，记录理由与替代做法，并接受同样的验证。偏离不需要审批，但需要留痕。「不应当」是「应当」的反向表述。

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

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

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而堆震动、堆开关、堆提示。两侧都算没做对——两类失败都应纳入评审：每个按钮都震一下，重要的那次就再也叫不醒人了。反复刺激可能降低响应，过密反馈也可能互相遮蔽；这些情况需要通过长任务测试发现，不能仅靠接口调用成功判断。

2.4 规则速查：35 条¶

下表是全部规则的一句话记忆版。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句，判定以正文为准（见 2.2）。

H1 可感知

H2 可辨义

H3 有时序

H4 随能力降级

H5 不是唯一通道

H6 身体可控

H7 节制

---

3. 规则详解¶

本章按七条原则展开全部 35 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一实现，也不要求新增独立交付文档。正文中的数值为参考值，效力见 2.1 末段。

3.1 H1 可感知¶

触觉信号首先要被身体接收到。这个原则管辖的是信号的物理属性与人的感知能力之间的关系：够不够强、分不分得开、在真实使用姿势和环境里还成不成立、对不同的人是否同样成立。这一原则最常见的失效不是设计错误，而是验收错误——在安静的办公桌上、握在手里、由熟悉这个信号的设计者本人确认"能感觉到"，然后交付给在地铁里揣着手机、戴着手套、或者末梢感觉减退的用户。

H1-1信号可觉察必须¶

一句话：在真实使用情境里对真实用户可觉察，不以开发桌面为准。

适用所有承担信息传达职责的触觉信号。纯粹的质感修饰（不传达任何用户需要知道的信息）不适用本条，但仍受 H7 的总量约束。

规则每个承担信息传达职责的触觉信号，必须在产品声明的主要使用情境（见 Token haptic.context.usage）下对目标用户群可觉察，并有验证记录。可觉察性必须按情境验证，不得以单一情境（尤其是开发或演示环境）的结果推及全部情境。信号的强度、频率与持续时间必须在目标条件下共同验证。约 200–250 Hz 的敏感区间只可作为特定振动实验的方向性参考，不是所有身体部位、接触方式或作动器的默认频率。

边界条件本条不要求把每个信号都做强。它要求的是"在声明情境下可觉察"与"验证过"两件事；可以比较节奏、时长、包络与设备支持的参数调整，选择经验证且舒适的表现；不存在对所有硬件都更优的调整顺序。

依据与参考指部实验支持检测阈值随频率变化；Android 给出按键反馈时长的设计参考。这些都不证明统一的可感知下限。测量条件与来源见 reference.md 第 3 节。

设计应用为每个信号记录它被验证过的情境组合；在设计阶段就把"戴手套""放桌上""口袋里""环境有振动"作为待验证条件，而不是发布后的缺陷。根据能力与用户测试比较参数组合，避免只靠增大振幅补偿。

验证示例

• 用户侧：在声明的每一种情境下，先做探索性走查，再按预先设定的重复试次随机呈现有信号和无信号条件，记录命中、漏感、误报与不适；纳入目标群体的感知差异。单次触发只能发现明显问题，不能作为正式通过证据。
• 实现侧：检查每个信号是否有对应的情境验证记录；未验证的情境要么从声明中移除，要么在该情境下走 H5 的替代通道。

反例做不到——手机放在桌上时"消息已发送"的触觉完全感觉不到，用户反复重发；做过头——为了保证口袋里也能感觉到，把所有信号统一调到最强，握在手里时每次点击都像被弹了一下。

H1-2需要区分的信号可分辨必须¶

一句话：承担不同含义的信号，在最弱档与降级形态下也要能分得出，不只是波形不同。

适用产品中存在两个及以上承担不同含义、且用户可能需要区分的触觉信号时。

规则承担不同含义的触觉信号之间，必须在目标设备、用户所选的强度档（含最弱档）、声明情境与已定义的降级形态下仍可被用户区分。应当避免仅靠振幅的细微差别承担区分——节奏（脉冲数与间隔）、时长、包络或质感通常更稳定。采用单一维度（含仅振幅）编码的，须提供覆盖上述全部条件的可区分性证据；证据不足时增加其他维度或改用等价通道。可区分性必须经验证，并把“感觉是否不同”与“能否识别含义”分开：前者可用不提示语义的配对辨别；后者按产品实际提供的学习方式测试，记录教学内容与训练次数，不把未教学时猜错含义等同于感觉不可区分。

边界条件本条不要求产品内所有信号两两可分辨，只要求"用户可能需要区分"的信号对可分辨。同一语义类别内部为了表现力做的变体（如三档不同重量的碰撞感）不属于需要区分的信号对。

设计应用优先用节奏而非强度承担区分——两短一长和一次单击的差别，比"中等强度"和"略强于中等"的差别稳定得多。为每一对需要区分的信号记录它们的区分维度。

验证示例

• 用户侧：先随机做同异配对辨别，再按产品实际引导教授含义并随机识别；分别记录觉察率、混淆矩阵与误判后果，按事先定义的验收标准评估。
• 实现侧：对每一对需要区分的信号，在目标设备、用户最弱档与已定义降级形态下建立混淆矩阵；不以"波形不同"判通过，也不以"只用了一个维度"直接判不通过——判据是上述条件下的可区分性证据是否成立。

反例做不到——"发送成功"和"发送失败"用的是同一个单击，只是失败的略强，用户全靠看屏幕；做过头——为了保证每个语义都能被区分，造出十几种节奏各异的信号，用户一个也记不住（同时违反 H2-4 与 H7-4）。

H1-3按声明情境校准应当¶

一句话：握在手里、放在桌上、揣在兜里、戴在腕上不是同一件事。

适用产品可能在多种握持方式、佩戴位置或环境条件下使用时。

规则产品应当声明其主要使用情境，并按情境校准信号参数；具备情境探测能力时，应当据此调整强度或改走其他通道。情境调整不得越过 H6-4 的安全上限，也不得在用户已降低强度或关闭触觉后以"情境需要"为由恢复（见 H6-2）。无法探测情境时，应当按声明的主情境处理，而不是按最有利于感知的情境假定。

设计应用把情境作为 Token 的一等公民（haptic.context）而不是实现细节；运动、佩戴类场景优先在设计阶段确定基准情境，而不是发布后补丁式加强。

验证示例

• 用户侧：同一信号在声明的手持、桌面、口袋条件下分别重复测试可觉察性与舒适度，不把一次试播当作通过。
• 实现侧：检查情境调整是否只做减弱与改道，不做无上限增强；检查用户设置是否始终优先于情境调整。

反例做不到——腕上设备沿用手机的信号参数，戴着完全感觉不到；做过头——检测到"可能在口袋里"就把所有通知提到最强，用户拿在手上时被吓一跳。

H1-4不假定个体一致应当¶

一句话：感知阈因人而异，单一强度不对所有人有效。

适用面向不特定用户群的产品。

规则产品不应当假定所有用户对同一信号有相同的感知；设备接触方式与个人感觉差异会影响体验，有人难以觉察，也有人感到不适。实际能力支持时，产品应当提供强度缩放或经验证的离散档位（要求见 H6-1），并且不得把"多数用户能感觉到"作为免除替代通道（H5-1）的理由。

设计应用把强度缩放当作基础设施而不是无障碍附加项；在用户研究的招募条件中显式纳入触觉感知差异，而不是默认参与者都"正常"。

验证示例

• 用户侧：在包含不同年龄段与已知感觉差异的参与者中测试同一组信号，记录觉察率与不适率两个方向的分布。
• 实现侧：提供调强能力时，确认它对声明覆盖的全部信号生效；仅能开关的设备不呈现虚假滑块。

反例做不到——按 25 岁工程师的手指标定全部参数，年长用户完全收不到提醒；做过头——为每个用户搞一套需要逐项校准的触觉配置向导，多数人在第三步就放弃了。

H1-5播放不等于送达必须¶

一句话：系统调用了作动器，不等于用户感觉到了。

适用任何把触觉作为通知、确认或提醒手段的场景。

规则系统禁止把"已调用触觉接口"或"作动器已执行"视为"用户已获知"。接口本身不能确认感知与理解，因此任何依赖用户获知的流程，其状态推进必须依据用户的实际操作或其他可确认的信号，不得依据触觉是否播放。一般信息按 H5-1 保留等价表达；涉及 H5-2 的重要信息同时保留可回查通道。

依据与参考这是触觉与视觉的关键差异之一——界面元素可以停留在屏幕上等待被看到，但界面已展示同样不等于用户已理解，触觉发生即消失，且是否被感知取决于设备当时是否与身体接触。多数误设计源自把触觉当成一次"投递"而不是一次"尝试"。

设计应用区分播放状态和业务知悉状态；允许记录“已尝试触觉提醒”，需要确认的业务状态依赖用户动作。

验证示例

• 用户侧：把设备放在桌面上触发一次需要用户响应的提醒，确认该提醒仍可在后续被发现和处理。
• 实现侧：检查是否以播放回执推进“用户已知悉／已同意”之类状态；播放引擎自身调度、结束或资源释放不属于此类状态。

反例做不到——"已通过震动提醒用户"后就把待办标记为已通知并停止后续提示，而设备当时在包里；做过头——每次触觉之后都追加一次弹窗确认"你感觉到了吗"。

H1-6避免干扰采集与周围环境应当¶

一句话：避免干扰采集与周围环境。

适用拍摄、录音、语音识别、惯性传感或安静共享环境中使用触觉。

规则触觉可能带来机械噪声和传感器扰动。产品应当在这些功能运行时验证影响，按结果选择抑制、减弱或改变时机；已经造成关键任务不可用的反馈不得继续发放。不得把振动产生的传感器信号误认作用户动作并形成重复触发。

设计应用分别在手持与硬桌面、录音与拍摄开启时比较结果；静音音频后仍检查机械振动声。

依据与参考Apple HIG 提醒触觉可能干扰相机、陀螺仪和麦克风。见 Playing haptics。

验证示例

• 用户侧：比较有无触觉的录音、拍摄和正常任务表现。
• 实现侧：注入振动扰动，确认不会反复触发动作；记录处理规则与适用设备。

反例做不到——录音开始反馈被录入音轨，语音检测又触发下一次反馈。做过头——为消除录音噪声，即使录音已经结束也永久关闭所有操作反馈。

3.2 H2 可辨义¶

触觉的业务含义需要学习；机械碰撞等物理类比可以帮助理解，但不能据此假定用户天然知道哪种信号表示提交成功。因此这个原则管辖的是信号与含义之间的映射关系本身：映射是否唯一、是否稳定、是否与用户已经在系统里学会的词汇一致、以及产品是否知道自己一共有多少个词。触觉词汇表和界面文案一样需要被管理，区别只是它没有拼写检查。

H2-1同义同信号、异义可分辨必须¶

一句话：同一含义在产品内始终是同一个信号。

适用所有使用触觉的产品。

规则同一含义在产品内必须映射到同一个触觉信号，不得因界面位置、模块归属或团队差异而改变；不同含义不得共用同一个信号，除非它们对用户而言确实无需区分（判定与验证见 H1-2）。为单个界面的表现力引入与全局映射冲突的一次性信号，属于违反本条。

边界条件同一含义在具备不同能力的设备上的降级表现允许不同，但必须落在同一语义映射内（见 H4-3）。这不构成对本条的例外。

设计应用把触觉映射的所有权收到设计系统层，而不是交给各业务模块自行决定；组件库内置触觉，而不是让每个调用点自己选。

验证示例

• 用户侧：在产品的三个不同模块触发同一含义的事件，确认用户不会认为发生了不同的事。
• 实现侧：按语义清单（H2-5）交叉检查各调用点的实际信号；出现同义异号或需要区分的异义同号即不符合。

反例做不到——首页的"添加成功"是双击，购物车的"添加成功"是单击，用户始终建立不起对应关系；做过头——为了绝对一致禁止任何模块使用触觉，只保留三个全局信号，连拖动吸附这类明显有价值的反馈也一并砍掉。

H2-2沿用系统语义，不挪作他用必须¶

一句话：平台已建立的触觉词汇是用户已经学会的，不要覆写。

适用运行在已建立系统级触觉语义的平台上（iOS 的 notification / impact / selection，Android 的 HapticFeedbackConstants 与预定义效果等）。

规则平台已建立语义的场景，产品必须优先沿用系统提供的对应信号；禁止把系统语义挪作他用——不得用表示错误的信号表示成功，不得用选择变化的信号表示不可逆操作完成。产品自有的信号必须与系统语义在含义上不冲突，且不得在同一场景类别下与系统信号构成竞争性映射。

依据与参考系统语义是用户在设备上跨应用反复习得的，其学习成本已经被平台支付；覆写它等于让用户在你的产品里重学一遍，并且会污染他们在其他产品里的理解。Apple HIG 与 Android 的触觉设计原则都把"与系统保持一致"列为首要建议。出处见 reference.md。

设计应用先把产品的语义清单与平台语义做一次对照，能对上的直接沿用；对不上的再考虑自定义，并按 H4 声明能力与降级。

验证示例

• 用户侧：让熟悉该平台的用户在不看屏幕的条件下判断刚才发生的是成功还是失败。
• 实现侧：逐条检查语义清单中沿用系统效果的条目，确认使用的常量与其语义相符。

反例做不到——用系统的 error 触觉表示"已加入收藏"，因为"那个手感更爽"；做过头——因为担心冲突，连按钮点击这类平台已有明确常量的场景也一律不用触觉。

H2-3语义可学习且稳定应当¶

一句话：让用户在真实操作中学会含义，不依赖猜测或背诵。

适用需要用户识别含义的信号，尤其是产品自定义的触觉词汇。

规则产品应当让用户在真实操作中通过稳定的事件、界面状态与触觉配对理解含义；验收采用的教学方式和训练量应当与产品实际提供的一致。不得把已经建立含义的信号悄悄改派给冲突的含义，也不得仅凭测试人员熟悉信号就宣称用户能够理解。必要的教学应当简短、可跳过，并提供不依赖触觉记忆的任务路径。

设计应用第一次吸附到目标时，触觉与可读的目标状态共同出现；需要额外解释时提供自愿体验入口。成功与失败通过结果状态学习，不让用户先背节奏词典。

验证示例

• 用户侧：区分首次使用、实际引导后与间隔一段时间后的识别结果；检查重要含义的误判，不用总体平均掩盖成功与失败的混淆。
• 实现侧：核对测试教学是否真实存在于产品；检查同一信号在不同场景的含义是否稳定。

反例做不到——内部人员熟记六种振动后测试全对，真实用户却从未得到任何学习线索；做过头——首次使用必须逐项背诵触觉词汇才能继续。

H2-4不用触觉传需要精确解码的信息必须¶

一句话：触觉带宽极低，不要用它编码数量、身份或文字。

适用考虑用触觉传达信息内容（而非仅传达事件发生）的场景。

规则禁止用触觉编码需要用户准确识别的数量、身份、序号或文本内容。例外只有一条：该编码方案已被明确声明为专用编码路径、用户已接受相应训练、且方案的可解码性已在目标人群上验证。此类专用路径按附录 B.2 属于本规范覆盖范围之外，其通道设计、训练与验收需要单独评估，本条的例外只是承认它存在，不代表本规范已为它给出充分要求。语义清单规模必须依据目标用户在实际情境下的识别表现确定，不设缺乏适用证据的统一数量上限；尤其检查高后果信号之间的混淆。

边界条件本条不禁止用触觉表达程度（强弱、快慢、远近）或过程（进行中、接近边界、完成）——这些是触觉擅长的连续量表达，不需要精确解码。它禁止的是把离散符号系统搬到触觉通道上。

设计应用需要传达"哪一个""几个""是谁"时走视觉或听觉；触觉只承担"发生了""到了""越界了"这类判定。

验证示例

• 用户侧：对所有需要区分的语义按实际学习条件随机识别，记录混淆与反应时间；长任务结束后复测。
• 实现侧：检查新增语义是否有对应的识别验证；精确编码是否声明适用人群、训练与验证结果。

反例做不到——用震动次数表示未读消息数量，用户数到第四下就乱了；做过头——因为担心超载，连"到达边界"这种单一判定也不敢用触觉表达。

H2-5语义登记在册必须¶

一句话：每个信号能在一份清单里找到唯一条目，新增先入册。

适用所有使用触觉的产品。

规则产品必须维护一份触觉语义清单，记录每个信号的含义、触发场景、所需能力（H4-1）与降级链（H4-2）；产品主动触觉调用必须能解析到清单中的唯一条目；标准组件自带反馈可按组件与运行平台登记，不要求逐次拦截系统内部实现。新增信号必须先入册再使用；清单必须可定位到实际使用的效果和配置，并作为设计与工程的共同依据，不得只存在于其中一方。

依据与参考这是把 H2-1 从主张变成可执行的机制。没有清单，"同义同信号"只能靠人记住，而触觉的不一致不会在任何自动化检查里报错——它只会在用户那里慢慢失效。

设计应用Token haptic.semantic.registry 引用语义清单；清单的信号条目、业务事实和实测记录本身不是新增 Token；组件库消费清单，业务代码不直接指定波形。

验证示例

• 实现侧：扫描代码中的触觉调用点，确认主动调用经统一映射引用清单；平台常量与波形可以存在于适配层，标准组件自身反馈应在映射中说明并避免重复追加。
• 实现侧：检查清单条目是否都填写了能力需求与降级链；缺失即不符合 H4-1、H4-2。

反例做不到——触觉散落在各业务代码里硬编码，没人说得清产品一共有几种震动；做过头——为清单建立一套需要三级审批才能新增条目的流程，团队干脆绕开它直接调平台 API。

3.3 H3 有时序¶

触觉是因果关系的一部分，不是一条可以延后送达的消息。用户按下按钮、手指越过刻度、支付完成——触觉之所以有意义，是因为它紧贴着那个事件发生。这个原则管辖的是触觉与用户动作、与视觉、与听觉之间的时间关系。它有两种需要区分的失效：延迟过大可能导致错误归因；早于事实的结果触觉则传达了尚未成立的结论。这与模态之间可能存在的微小输出偏移是不同问题。

H3-1因果绑定与延迟上限必须¶

一句话：迟到的触觉比没有触觉更糟，超时就放弃不补播。

适用作为对用户动作或系统事件的直接反馈的触觉信号。

规则每个反馈类触觉信号必须绑定到一个确定已发生的事件；产品必须为每类信号定义并验证起振延迟上限，使反馈仍可被正确归因。调度时已超上限且尚未提交的请求必须丢弃，不得延后补播——用户会把迟到的震动归因到它之后发生的任意动作上，从而建立错误的因果关系。延迟从所绑定事件成立计到设备实际起振；平台调用时刻只反映软件调度。提交前必须留出实测的起振耗时，不能把“截止前调用”当成“截止前起振”；无法证明仍在有效期时省略该直接反馈。Android 的 10–20 ms 指按键反馈的持续时间，不是起振延迟，也不应从点击时刻计算数秒后才成立的异步结果反馈。

边界条件本条不适用于主动通知类触觉（提醒、消息到达），那类信号本身不与用户当下的动作构成因果关系，其时机约束见 H6-2 与 H7-2。

依据与参考视触时序研究支持实际输出时刻需要测量，但阈值依赖任务与刺激。起振和拖尾同时受作动器、驱动与安装影响，不能由 ERM/LRA 名称推出固定延迟。见 reference.md 第 3 节。

设计应用按真实事件建立调度，并与配对视听共同核对实际时刻；设备不满足时选更合适效果或停播，不以修改数字代替验证。

验证示例

• 用户侧：在目标设备的低端档位上连续点击，确认触觉不会落到下一次点击上。
• 实现侧：记录软件调度延迟，并用加速度计、接触式拾振等实机测量校准事件到实际起振的分布与拖尾；无法观测硬件时标注估计范围。检查调度时已过期的请求被丢弃，不能取消的已提交短脉冲不宣称可撤回。

反例做不到——网络回包慢时把点击反馈排队，用户滑到下一屏时才震一下，以为自己误触了什么；做过头——为了压低延迟在事件确认前就触发（违反 H3-4）。

H3-2跨模态同步按场景验证必须¶

一句话：同一事件的视听触输出在实测同步窗内，不套用通用偏移值。

适用同一事件同时通过触觉与视觉或听觉表达时。

规则配对表达同一事件的触觉与视听信号必须落在产品为该模态组合、设备与任务验证的同步窗口内。窗口必须声明参考事件、计时方向和测量方法；目标是实际感知同步，不得仅以同一回调证明。时间戳必须来自可比较的时钟；跨设备时记录时钟对齐误差，不能直接相减两台设备的本地时间。窗口可以不对称，但不得把某项视触实验中的方向与数值直接用于音触、其他身体部位或设备。超过有效窗口且尚未提交的直接反馈按 H3-1 丢弃；已发出的信号无法撤回，须修正后续调度。

依据与参考Di Luca 与 Mahnan（2019）的 19 人 VR 指尖触碰实验报告触觉滞后视觉不足约 50 ms 时难以可靠检出，触觉先行容忍约 15 ms；论文同时讨论任务间差异。这些结果不能直接作为其他设备、身体部位或音触组合的验收阈值。见 原论文。

设计应用动画与触觉共用同一个触发时刻，而不是各自从各自的生命周期回调里触发；跨模态配对写进 Token（haptic.timing.sync.window）。

验证示例

• 用户侧：在真实速度下判断同步体验；慢放只用于分析，不作为感知验证。录屏不能证明实际起振。
• 实现侧：测量配对信号的实际输出时差与抖动，检查是否落入经验证的同步窗；共同事件源是实现参考而非充分证据。

反例做不到——触觉在按钮动画开始前 40 ms 就震了，用户感觉设备在自己动；做过头——为保证严格同步而把视觉动画也延后到触觉起振之后，整个界面变得迟钝。

H3-3连续交互中触觉跟随动作应当¶

一句话：拖动和滑动的触觉随过程走，不是结束时补一下。

适用拖动、滚动、滑动、刻度选择、吸附、缩放等连续交互。

规则连续交互中的触觉应当随交互状态实时变化，用于表达刻度、边界、吸附与阻力，而不是在交互结束时补发一次总结性反馈。分段类反馈的密度应当随交互速度自适应；不得在高速滑动时继续发放会叠成明显拖尾嗡鸣的离散脉冲——这种输出既失去分段意义，又落入 H4-4 禁止的 buzzy 表现。总量仍受 H7-2 约束。

设计应用把连续交互的触觉当作对物理阻尼的模拟而不是事件计数：接近吸附点时渐强，越过边界时突起，回到自由区时消失。

验证示例

• 用户侧：以极慢和极快两种速度完成同一次滑动，确认两种速度下的触觉都可用且不刺耳。
• 实现侧：在产品声明的速度范围内测量脉冲重叠、可辨别性与总量；检查是否有速度自适应或等效的密度控制。固定间隔仅在导致本条所禁止的失败（连成持续嗡鸣、失去分段意义）时记为不符合，不因"间隔固定"本身判失败。

反例做不到——长列表快速滚动时每经过一项震一下，滚到底手都麻了；做过头——为避免连成嗡鸣而完全取消滑动反馈，刻度选择器失去了它最有价值的部分。

H3-4触觉不得先于事实必须¶

一句话：结果没定就不要震，触觉在身体上，撤不回来。

适用表示结果、状态或后果的触觉信号。

规则表示结果的触觉必须在结果被实际确认之后播放，禁止基于乐观预测提前触发。外部操作的结果区分成功、失败与未知三态时，触觉只能表达已确认的成功或失败；未知状态不得播放表示成功的触觉，也不应当播放表示失败的触觉，而应当走可回查的通道说明当前状态未确定。未知也不得伪装为已确认失败。

边界条件本条不禁止表示"已受理""正在处理"的过程性触觉，只要它表达的确实是"请求已发出"这一已发生的事实，且与表示结果的信号在语义上可区分（见 H1-2、H2-1）。

依据与参考结果触觉发出后无法回收，错误提示可能导致用户停止核对或离开流程，因此结果语义必须有事实依据；这一要求同样不允许视觉把未知结果说成已成功。

设计应用把"乐观 UI"和"乐观触觉"分开决策；等待时可以显示已受理或处理中；业务成功必须以实际结果为依据，视听触保持语义一致。

验证示例

• 用户侧：在弱网或服务端失败的条件下完成一次支付或提交，确认没有先感到成功触觉再看到失败提示。
• 实现侧：注入成功、失败、回执丢失及重复回调，核对触发依据是否证明业务结果；进入响应回调或收到传输成功码本身不证明业务成功。

反例做不到——点击支付立刻播放成功触觉，随后弹出失败提示，用户已经把手机收起来了；做过头——把所有触觉都推迟到全部后续流程完成，连按钮按下的即时反馈也没有了（违反 H3-1）。

3.4 H4 随能力降级¶

同一段代码在不同设备上产生的触觉可以完全不是一回事：表现受作动器、驱动、安装、平台调校与接口支持共同影响。宽频不是连续变化的唯一实现条件，清脆与丰富表现也不能仅靠器件名称判断。这个原则管辖的是设备能力差异这一客观事实：设计必须承认自己不知道用户的设备能做什么，因此每个信号要声明它需要什么，做不到时按预先想好的路走，而不是听凭平台自由发挥。降级最危险的失败不是效果变差，是语义漂移——为了"还能感觉到"而把一个成功信号降成了一段长振，而长振在这个产品里恰好表示错误。

H4-1声明所需能力与支持状态必须¶

一句话：按效果、基元、振幅与包络能力判定支持，不只看器件型号。

适用面向多种设备形态或多种硬件档位发布的产品。

规则每个信号必须声明效果所需能力，并按目标输出设备与运行平台核验。能力档案至少区分无触觉、不支持、支持与未知；按需检查具体系统效果、组合基元、振幅控制、包络及输出位置。自定义包络还必须验证参数组合：频率范围、控制点数量与间隔、总时长及平台要求的结束条件，不能只检查接口是否存在。未知不得当作支持自定义效果；但平台预定义效果的“未优化／未知”不等于“无法播放”，可使用文档承诺且经产品验证的系统降级。运行平台或外设改变后必须重新判定受影响能力。

设计应用把目标设备能力作为设计阶段的输入而不是适配阶段的补救：在决定"这里要一个有质感的滚动反馈"之前，先确认目标设备矩阵里有多少比例能做到。

验证示例

• 实现侧：分别模拟无作动器、缺少一个必要基元、无振幅控制、包络不支持和未知支持状态；核对每条降级路径。
• 用户侧：在实际设备上验证降级质量，不以 API 返回支持代替感觉与语义验证。

反例做不到——按旗舰机的宽频作动器设计整套触觉，中低端机上全部退化成一样的嗡嗡声；做过头——为每一档硬件维护一套完全独立的触觉设计，四套语义清单互相漂移（违反 H2-1）。

H4-2降级链有定义，不静默失效必须¶

一句话：做不到时按定义好的路径降，不是悄悄不播或退化成嗡嗡响。

适用所有可能遇到能力不足、未知或无输出设备的信号。

规则每个信号必须有可解析、无循环的降级链，终点明确；能力条件不成立时禁止无定义地失效。末项可以为“不播放”，传达的信息由 H5-1 的等价通道保留，纯质感反馈可以直接省略。用于按键、选择等直接操作反馈时，禁止把清脆反馈降成明显拖尾的嗡鸣；主动来电、闹钟等注意提醒可以采用经验证的通断模式，仍受用户设置、时长和总量限制。不得把平台对预定义效果的降级承诺套用于自定义组合。

依据与参考Android 分别说明预定义效果的系统降级、自定义组合的能力检查与自行降级，并区分触摸反馈和注意提醒对 buzzy 的适用性。本规范把它们整理为可检查的降级合同，未声称平台没有降级机制。见 Android API 说明。

设计应用降级链写进 Token（haptic.capability.fallback.chain），由组件库统一执行，不交给业务代码逐处判断。

验证示例

• 用户侧：在最低能力设备上完成主要任务，确认没有出现"按了没反应"或"一直在嗡嗡响"的体验。
• 实现侧：对每个信号强制降级到每一档，逐档记录实际表现；核对不播放是否有明确原因和等价信息，直接操作反馈是否出现不合适的拖尾。

反例做不到——宽频纹理效果在 ERM 设备上直接不播，用户以为滑动没生效；做过头——为了"至少让用户感觉到点什么"，在低端设备上把所有信号都替换成 300 ms 长振。

H4-3降级不改变语义必须¶

一句话：成功降级之后还得是成功，不能变成错误。

适用所有存在降级链的信号。

规则降级后的信号必须仍落在原语义的映射范围内，禁止跨语义降级；降级链上的任一档都不得与语义清单中另一个需要用户区分的含义相同或近似到不可分辨（判定见 H1-2）。当某一档确实无法在不越界的前提下表达原语义时，正确的降级结果是"不播放并走替代通道"，而不是借用一个近似的其他信号。频率与强度的关系只在已声明的可比较效果族内判定，不跨族换算。

依据与参考这是 H2-1 在能力维度上的推论，但规范对象不同：H2-1 管的是设计时的映射，本条管的是运行时降级导致的映射漂移。后者不会出现在任何设计稿里，只会出现在低端设备的用户手上。

设计应用在语义清单上做一次跨档位的碰撞检查——把每个信号的每一档降级表现摊平，检查是否有两个不同含义落到了同一处。

验证示例

• 用户侧：在最低能力设备上，让用户区分成功与失败两类结果反馈。
• 实现侧：以用户能理解的语义为单位判定，不以 API 是否调用成功为判据；对用户需要区分的信号对逐档检查；降级后不可区分且仍承担区分职责的，记为不符合。

反例做不到——成功信号在窄带设备上降成一次较长的振动，恰好和错误信号一样，用户在低端机上完全分不清；做过头——为了绝对不碰撞，把降级链一律砍到只剩"不播放"，可用设备上的触觉也一并失去。

H4-4优先用平台预定义效果应当¶

一句话：自定义波形是例外不是默认，长振不是交互反馈。

适用平台提供了预定义触觉效果或基元的场景。

规则平台已提供对应预定义效果或基元时，产品应当优先使用，而不是自行合成波形——预定义效果由平台按各设备的作动器特性调校，跨设备表现更一致。自定义波形应当仅在预定义效果确实无法表达目标语义时使用，且必须同时给出能力声明（H4-1）与降级链（H4-2）。禁止用明显拖尾的长振替代短促的直接操作反馈；主动注意提醒的适用边界见 H4-2。

依据与参考Android 的触觉设计原则把"优先使用预定义常量与效果"列为第一条，并明确要求避免 legacy one-shot 振动（在低性能作动器上会产生 buzzy 表现）。出处见 reference.md。

设计应用在设计评审时把"这个能不能用系统已有的效果表达"作为默认问题；自定义提案需要说明它换来了什么。

验证示例

• 实现侧：清点自定义波形的数量与理由记录；检查代码中是否存在 legacy 长振接口调用。

反例做不到——为了"有自己的品牌手感"，把所有系统效果换成自研波形，结果在半数设备上不如系统效果；做过头——因为只用预定义效果，连产品真正需要的连续吸附反馈也放弃了。

H4-5播放中断与恢复有定义必须¶

一句话：中断后只在仍有效的同一次交互内按预定次数恢复，不补播旧事件。

适用使用自定义播放引擎、连续反馈，或可能遇到后台挂起与外设断连时。

规则产品必须区分未播放、已提交、已结束、被抑制、中断与失败等自身可观测状态；未知不得记为已完成。中断后不得自动补播已过时的离散事件。允许恢复持续效果时，必须先核验交互仍有效、用户仍允许、设备仍可用，再按当前交互状态创建输出。恢复尝试只在仍然有效的同一次持续交互内进行，且次数与终止条件必须预先定义；达到上限或该交互已失效时停止自动恢复，并保留无触觉的任务路径。同一次交互内的帧更新不重置计数；只有新的、独立的交互才可开始新的恢复周期。离散的旧事件不因恢复而重放。

设计应用把播放生命周期归属于具体交互；离开交互使旧请求失效。引擎重建只是准备能力，不是再次播放的理由。

依据与参考Apple Core Haptics 文档描述中断及重建播放器的机制。恢复语义与有限重试是本规范的设计要求，见 准备播放 与 resetHandler。

验证示例

• 用户侧：拖动中切后台，再返回时不出现旧震动；新的操作仍可反馈。
• 实现侧：注入挂起、引擎复位、断连与恢复失败，检查旧事件失效和有界重试。

反例做不到——来电打断后把刚才所有点击重新震一遍。做过头——每次恢复前要求用户重新开启触觉，普通中断也增加操作负担。

H4-6输出位置与接收对象明确必须¶

一句话：输出位置与接收对象明确。

适用同一产品可以向多个设备、多个控制器或多个振动位置输出时。

规则每个信号必须绑定当前交互的接收对象、设备及需要的位置。改变输入设备、控制器归属或连接状态后必须核对路由，禁止误发到其他用户设备或向所有设备广播。带方向含义的输出须验证左右与位置映射；目标不可用时使用明确的替代路由或不播放，禁止擅自换到不等价的位置。

设计应用直接操作反馈优先对应正在操作的设备；多设备提醒按事件标识去重。位置影响语义时，把位置能力与降级一同登记。

依据与参考Apple Game Controller 使用 locality 指定振动位置，证明多位置输出可实现；对象绑定与防误发是本规范的推导。见 WWDC20 控制器能力。

验证示例

• 用户侧：切换手柄、左右手或手机与外设，确认反馈位置符合预期。
• 实现侧：交换两位玩家的设备归属并断连目标设备，检查路由与去重。

反例做不到——玩家 A 操作后，玩家 B 的手柄震动。做过头——每次点击前弹出设备选择器，尽管当前交互对象已经明确。

3.5 H5 不是唯一通道¶

触觉是一个瞬时的、无法回看的、可能根本没被接收到的通道（见 H1-5）。它在无需注视界面的场景下有优势——不需要用户看向哪里，也不需要占用听觉——但速度优势不等于可以承担独占的传达责任。这个原则管辖的是触觉与其他通道之间的信息分工：触觉可以第一个到达，但不能是唯一到达的那个。这也是 H6 得以成立的前提——用户有权关掉触觉，正是因为关掉之后什么也不会丢。

H5-1触觉不得是唯一通道必须¶

一句话：震动里携带的信息，必须还有一个非触觉的等价表达。

适用所有通过触觉传达信息的场景。

规则在本规范覆盖范围内的通用产品中（见附录 B.2），任何通过触觉传达的信息必须有等价的非触觉表达；禁止出现因用户关闭触觉、设备无作动器、能力降级到"不播放"（H4-2）或信号未被感知（H1-5）而导致信息丢失或功能不可用的情况。以触觉为主通道的专用设备不适用本条，其等价性要求按 B.2 单独评估。等价表达必须承载同样的信息，而不只是提示"发生了某事"。

边界条件本条不要求每次触觉都伴随一次视觉或听觉提示。等价表达可以存在于用户可主动查看的界面状态中，不必与触觉同时发生——要求的是信息不丢失，不是通道数量翻倍。纯质感修饰（不传达任何信息）不适用本条。

依据与参考XAG 110 明确建议游戏的重要线索具有其他输出方式；本规范将等价信息保留作为通用产品的体验承诺。WCAG 1.3.3 约束依赖感官特征的操作说明，不能直接称为“一切仅触觉设计均违反 WCAG AA”。见 XAG 110 与 W3C 解释。

设计应用设计触觉时同步回答"关掉它之后，用户从哪里知道这件事"；答不上来说明这个信息还没有归宿。

验证示例

• 用户侧：关闭全部触觉后完成同一组任务，确认所有信息仍可获得。
• 实现侧：逐条检查语义清单，标注每个信号对应的非触觉等价表达；空缺即不符合。

反例做不到——静音模式下靠震动区分来电与闹钟，关掉触觉后两者完全无法区分；做过头——每次触觉都配一个 toast，界面被确认提示淹没。

H5-2安全关键信息需并存可查通道必须¶

一句话：触觉是瞬时的，错过就没了；重要的事要留得住。

适用涉及安全、不可逆后果、时限或费用的提示。

规则此类提示使用触觉时，必须同时存在一个可回查的通道——用户在错过触觉之后仍能主动找到该信息的状态、记录或入口。触觉在这类场景中可以承担"最快到达"的角色，但不得承担"唯一到达"或"一次性到达"的角色。可回查通道的存在必须独立于触觉是否播放成功。需要当下响应的信息还必须在响应期限内可达，事后可查不代替及时表达。

边界条件本条不要求可回查通道与触觉同时呈现，也不要求它常驻在主界面上；要求的是用户在事后能主动找到它。

设计应用把这类提示的状态落到持久的界面对象上（列表项、状态区、通知中心），触觉只作为它的前置提醒。

验证示例

• 用户侧：在触觉发生时把设备放在另一个房间，事后确认用户仍能发现并处理该事项。
• 实现侧：对安全关键类信号逐条检查其可回查通道；仅有瞬时呈现的记为不符合。事后可回查不替代"当前可被及时响应"的表达，两者分别检查。

反例做不到——手表计时结束只振动一次，用户当时未感知，之后界面上没有任何表明它已结束的状态；做过头——把每一条提示都变成不可消除的常驻横幅。

H5-3触觉是强化而非替代应当¶

一句话：触觉降低确认成本，不替代确认本身。

适用需要用户作出判断或确认的流程。

规则触觉应当用于降低确认成本与提高定位效率——让用户不必低头看屏幕、不必二次核对、不必等待视觉反馈——而不应当用于替代必要的说明或确认步骤。涉及不可逆后果的操作，不得以触觉反馈代替用户可读的确认信息。

设计应用为每个触觉点写清它属于哪一类收益、替代了什么具体成本（一次低头、一次视觉搜索、一次二次核对）；这同时也是 H7-4 要求的说明。

验证示例

• 用户侧：按该触觉点所声明的收益，在有无触觉两种条件下比较相应指标（视觉注视次数、完成时间、错误率或主观负担）；单一指标无差异不能证明它没有任何收益——须对照其声明的是哪一项成本。

反例做不到——删除操作只给一次触觉，没有任何可读确认；做过头——认为触觉不能替代任何东西，于是在已有清晰触觉反馈的滑动刻度上仍强制弹出数值确认框。

H5-4全关条件进入常规验收必须¶

一句话：触觉全部关闭时能跑完主要任务，这要被真的测。

适用所有使用触觉的产品。

规则产品必须把"触觉全部关闭"作为常规验收条件之一，覆盖全部主要任务路径；该条件下不得出现信息缺失、流程阻塞，也不得人为增加劝返、确认一类的惩罚步骤。判据是"目标用户能否在任务所要求的时间内取得必要信息"，不是"动作数与开启时完全一致"——通道转换本身带来的合理查看或操作差异（例如改为主动查看一次状态，见 H5-1）不计为违反，但须验证其可达性与负担；把信息藏在二级历史页、来不及响应的，不能以"可回查"通过。此项验收不得仅在无障碍专项中执行，也不得以"默认开启所以不影响多数用户"为由跳过。

依据与参考这条把 H5-1 从一项声明变成一项可执行的验收。经验上，等价表达最容易在后期新增功能中被遗漏，而这类遗漏只有在全关条件下才会暴露。

设计应用把触觉全关加入回归测试的设备/设置矩阵，与深色模式、大字号同等对待。

验证示例

• 实现侧：在触觉全关的配置下跑一遍主要任务的回归；缺陷按常规缺陷处理，不降级为体验建议。

反例做不到——只在有触觉的设备上验收，新功能上线后关闭触觉的用户完全收不到某类提示；做过头——为覆盖全关条件，在关闭触觉的用户界面上到处补加冗余提示，反而比开启触觉时更嘈杂。

3.6 H6 身体可控¶

设备与身体接触时，振动可能引起不适；无障碍指南尤其提醒关注有慢性疼痛或感觉处理差异的用户。这个原则管辖的是触觉对身体的影响与用户对它的控制权。用户对自己身体被如何使用的决定权，优先于产品的任何体验目标或商业目标。

H6-1可关、可调、可分类关必须¶

一句话：产品内能关闭；支持调强时提供真实调节，多用途时可分类关。

适用所有使用触觉的产品。

规则产品必须提供应用内完全关闭触觉的入口。具备可用强度控制或经过校准的强弱效果时，必须提供相应调节；有两种及以上用途时，必须允许分别关闭这些类别，至少把直接操作反馈与主动提醒分开。调节界面必须与实际能力一致：不支持连续调强时可以提供已验证的离散档位，只有通断能力时明确仅支持开关，不提供无效滑块。关闭必须在播放入口生效并停止可取消的进行中输出；不得仅把平台参数设成 0 就假定无输出。

依据与参考XAG 110 建议关闭、强度调节与替代通道；Game Accessibility Guidelines 明确游戏内关闭的必要性，并建议细调与分用途控制。它们是游戏领域设计参考，不是所有平台必须有连续滑块的统一标准。Android 组合基元的 scale=0 仍可能输出，见 自定义效果文档。

设计应用优先提供简单开关；有多用途与调强能力时逐步增加相应控制。预览只由用户主动触发，使用实际路由与限幅，不因每次打开设置自动震动。

验证示例

• 用户侧：让用户只关闭通知类触觉、保留操作反馈，确认设置生效且不影响其他类别。
• 实现侧：分别验证关闭、弱档及新增信号；在没有振幅控制的设备上检查非零参数是否被映射为满强度，不能满足弱档承诺时停播或选已验证替代效果。

反例做不到——只有一个"震动 开/关"，想保留按键反馈就必须忍受全部推送震动；做过头——把触觉设置拆成十几个独立开关铺满一整屏，没人找得到自己要的那个。

H6-2系统设置优先必须¶

一句话：系统级的静音、专注、触觉设置不得被绕过。

适用运行在提供系统级触觉、静音或专注模式设置的平台上。

规则产品必须按平台对当前用途规定的设置与调用策略执行；静音不等于关闭所有触觉，专注也不必然屏蔽主动操作反馈。系统级设置必须优先于产品自身设置：产品可以在系统允许的范围内进一步收紧，禁止提供"覆盖系统设置"的选项或以任何方式绕过。用户关闭触觉后，产品不得以"重要提醒""安全相关""仅此一次"为由恢复播放；此类信息按 H5-1、H5-2 走其他通道。情境探测（H1-3）导致的调整同样不得越过用户设置。

边界条件本条不排除平台自身定义的例外通道（如系统级紧急警报），那类通道的行为由平台而非产品决定，产品不得自行仿制。

设计应用优先采用遵守系统策略的语义接口与通知通道；平台不开放设置查询时遵守其调用合同，不声称能读取所有系统状态。

验证示例

• 用户侧：开启系统专注模式后触发各类事件，确认产品行为符合系统设置。
• 实现侧：检查是否存在忽略系统状态的直接调用路径；存在即不符合。

反例做不到——用户在系统里关闭了触觉，应用仍以"关键通知"名义震动；做过头——系统开启专注模式后连用户主动点击的操作反馈也一并停掉，界面变得没有响应感。

H6-3不为商业目的发起触觉禁止¶

一句话：不用震动做营销、留存、催促和注意力争夺。

适用所有未由用户当前操作触发的主动触觉。

规则禁止为营销、促活、留存、限时催促或注意力争夺而发起用户未请求的触觉。主动触觉必须对应用户已订阅的事件或用户委托的任务进展；产品不得通过触觉制造紧迫感，也不得把触觉作为提升打开率的手段。这一禁止不因用户"未明确拒绝"而放松——未拒绝不是同意。

依据与参考这是本规范对非请求式身体打扰的设计立场，依据是主动提醒的可预期性与用户控制承诺；不声称触觉是唯一不可回避通道，也不将其写成已有行业禁令。

设计应用在触觉方案评审中把"这个事件是用户订阅的吗"作为主动触觉的准入问题；未经请求的促销、召回、内容推荐不配触觉；明确订阅的事件仍须核对用途与系统通知设置。

验证示例

• 实现侧：清点全部主动触觉的触发来源，逐条确认对应用户已订阅的事件或已委托的任务；找不到对应的即不符合。

反例做不到——用户未订阅时，购物车商品降价就震动，倒计时结束前再震一次；做过头——把用户明确订阅的、有时限的重要提醒也一并去掉触觉，导致真正需要的提醒错过。

H6-4强度与时长受安全上限约束必须¶

一句话：上限来自身体和设备，不由体验目标决定。

适用所有触觉输出，包括自定义波形与连续触觉。

规则触觉的强度与持续时间必须受上限约束，上限依据设备或平台允许的输出边界、接触条件与目标人群的适用评估确定，不得由产品的体验目标或强调需要放宽。禁止使用长时连续触觉制造压力、催促或阻碍用户完成操作。连续或重复触觉必须有包含重复与间隔的总历时上限，并有自动停止条件；用户关闭、取消或结束所属交互时必须立即发出停止请求，并在设备实测停止时限内结束可取消的输出。不得承诺撤回已经发出的短脉冲；普通滑动更新不是取消动作，不应被一律当作停止。

边界条件本条不针对以持续触觉为核心功能的专用设备（按摩、康复、专业触觉显示），那类产品的上限由其领域规范确定；专用设备的停止机制亦须按其领域标准验证。

设计应用把经设备规格与产品评估确定的上限写进可解析策略，并在输出层强制（haptic.intensity.limits.ref、haptic.texture.duration.max、haptic.playback.stop.max_latency）；平台不开放物理幅值时，记录接口控制边界与可测输出，不编造数值；频次配额或舒适性测试不是人体安全认证。

验证示例

• 实现侧：构造越界配置和运行中达到上限两种情况，确认前者被拒绝，后者按已验证策略停止或抑制；不以任意裁剪未知波形宣称语义仍正确。
• 实现侧：在连续触觉中关闭开关、取消或离开交互，测量停止时限；正常拖动更新仍按 H3-3 反馈。

反例做不到——错误提示用 2 秒持续强振"引起重视"，用手不便的用户无法快速消除；做过头——把上限压到几乎无法感知，H1-1 不再成立。

H6-5关闭不得成为惩罚必须¶

一句话：关掉触觉之后不掉功能、不加惩罚步骤、不反复劝返。

适用产品提供触觉开关或强度调节时。

规则用户关闭或调低触觉后，产品禁止移除功能、人为增加惩罚性步骤、降低响应质量，或反复提示重新开启。通道转换带来的合理查看差异按 H5-4 的口径验证其可达性与负担，不以动作数完全相同为统一判据；减少多余步骤仍是默认方向。关于触觉的引导至多提供一次性说明，不得在每次启动、每次相关操作或每次重新进入设置后重复劝返。关闭状态必须在应用自身可持久化范围内保留，重启或配置重载不得重置；提供备份恢复或跨设备同步时，必须定义偏好恢复与冲突规则，防止旧的开启值覆盖较新的关闭决定。全新安装且无备份时无法恢复旧偏好，不宣称能恢复；设备特有强度档需重新适配。

依据与参考这是 H6-1 的兑现条件。一个可以关闭但关闭后被持续骚扰、或被悄悄改回来的开关，等于没有开关；而对因疼痛而关闭触觉的用户来说，重复劝返本身就是持续的负担。

设计应用把触觉设置纳入与隐私设置同级的"用户已作决定不再询问"处理；恢复设置时显式保留该项。

验证示例

• 用户侧：关闭触觉后完成代表性长任务，确认没有重复劝返、功能缺失或人为障碍，并记录通道转换的合理负担。
• 实现侧：重启并重载配置，确认关闭状态保持；产品提供备份恢复或跨设备同步时，再检查相应路径。

反例做不到——关闭触觉后每次启动都弹"开启触觉获得更好体验"，重载配置后自动恢复默认；做过头——因为不能提示，连首次进入时"本应用使用触觉反馈，可在设置中调整"这一句说明也不给。

3.7 H7 节制¶

多个功能各自适度的反馈，叠加后仍可能造成过度打扰或互相遮蔽。H7 管理产品共享输出的频次、总时长与优先级，并通过长任务测试检查其实际收益。预算用于约束打扰，不能保证所有关键提醒都会被感觉到。

H7-1强度匹配重要性与频率必须¶

一句话：越频繁越轻，越重要越强，不因为"想被注意到"提级。

适用产品存在多档强度可选时。

规则在同一设备、可比较的效果族与同一类任务内，信号强度应当与事件的重要性正相关、与发生频率负相关：高频事件（滚动、选择、按键）应当优先使用该族中经验证仍可觉察、可辨别且舒适的较弱信号，只有重要且低频的事件才使用较强信号。跨不同效果族之间不作强度排序。禁止仅因为某个功能"希望被注意到"而提升其强度档位——提级必须依据事件对用户的实际后果，并记录理由。渐进式交互（拖动、吸附、接近边界）可以在过程中逐步增强，但峰值仍受本条与 H7-3 约束。

依据与参考Android 的触觉设计原则明确要求把事件的重要性与频率同强度关联，并对渐进式交互给出逐步增强的建议。出处见 reference.md。

设计应用在语义清单上把"频率"作为一列，与强度档位一起评审；两列的相关性一眼可见，异常项自然浮出。

验证示例

• 实现侧：统计各信号的实际触发频率，与其强度档位做对照；高频高强度的条目逐条要求理由。

反例做不到——列表滚动的每一格都用中等强度，滚三屏手就麻了；做过头——把所有信号压到同一最弱档，重要提醒和滚动刻度感觉完全一样（同时违反 H1-2）。

H7-2总量有上限，超限合并或丢弃必须¶

一句话：密集触发时合并或丢掉，不排队补播。

适用可能在短时间内密集触发触觉的场景。

规则产品必须定义同类信号的最小间隔、单位时间上限及共享计量范围；重叠范围必须同时满足，不得通过拆分信号组或重建播放器重置预算。一次语义效果内的多个脉冲不得拆成多次业务事件来混淆计数，输出总时长仍单独受限。超出上限时必须合并或丢弃，禁止排队补播（过期直接反馈见 H3-1；主动提醒也不逐条补偿堆积的历史事件）。合并规则必须明确（取已定义优先级的信号、取最新、抑制后续），并保证合并后的结果不会造成语义误导。批量事件（批量导入完成、多条消息同时到达）必须按事件组而非按条目发放触觉。

设计应用把节流放在输出层统一处理，而不是让每个功能自己判断"我震得多不多"——单个功能永远觉得自己不多。

验证示例

• 用户侧：一次性触发大量事件（如同时收到二十条消息），确认触觉是一次而不是二十次。
• 实现侧：从多个调用入口并发触发同一作用范围的信号，确认共享上限不能被绕过；实现位置不单独作为判据。

反例做不到——群消息刷屏时逐条震动，手机在桌上跳；做过头——节流窗口设得过长，用户连续的两次不同操作只得到一次反馈，误以为第二次没生效。

H7-3最强级是稀缺资源必须¶

一句话：被指定为保留输出的那一组信号限定用途和频次，并保留其他有效信息通道。

适用产品指定为高显著性保留输出的档位或效果集合——即 Token 中 level.max.reserved_for 所约束的那一组输出，无论其在枚举中被称作"强"还是被实现为某个自定义效果。判据是"是否被指定为保留输出"，不是枚举项的字面名称；产品未指定保留输出时，本条不适用，但也不得存在事实上长期承担该角色却不受配额约束的输出。仅有一种轻点击或某效果恰好是普通效果中最强，不自动构成保留输出。

规则保留输出必须有明确限定的用途清单（如不可逆后果、安全提示、需要立即中断当前动作的事件），并必须有单位时间的配额上限；超出配额时必须降级或改走其他通道，不得继续发放。用途清单为空时，产品不得指定保留输出，也不得让任何输出事实上承担该角色。这一档的稀缺性必须被主动维护——频繁使用可能降低显著性，但不得把习惯化描述为永久不可恢复，也不得用提高振幅替代信息通道设计。

依据与参考这是"确认疲劳"在触觉通道上的同构问题：真正重要的那一次之所以有效，靠的是此前的克制。本规范以配额约束打扰，但配额数值及净收益仍需长任务测试，不是已有生理学安全阈值。

设计应用把保留输出的用途清单作为评审对象；新增申请要说明它比清单上已有的项目更重要还是同等重要。

验证示例

• 实现侧：清点保留输出（按 level.max.reserved_for 的登记，而非按枚举名称）的调用点与实际触发频率；用途在清单外的、或频率超配额的，逐条处理。另需检查是否有未登记但实际承担保留职责的输出。

反例做不到——所有错误提示都用保留输出，用户每天遇到十几次，真正的安全提示被当成又一个表单校验失败；做不到（另一种）——把最显著的效果实现为一个名为"中"的自定义效果，以此绕开配额；做过头——设立保留输出却因为"怕滥用"从不使用，安全提示与普通提示手感相同。

H7-4默认不加，加了要说清换来什么应当¶

一句话：新增触觉的默认答案是"不加"。

适用新增触觉点的设计决策。

规则新增触觉的默认答案应当是"不加"；提出新增时应当声明它属于哪一类收益，并按该类的口径说明：

说明不得只援引一般性理由（"触觉提升体验""竞品也有"），也不得把质感类提案写成功能成本改善。无法按所属类别给出说明的触觉点，应当不加或先做对照验证。

边界条件本条不禁止以质感与愉悦为目的的触觉。它要求的是这类提案同样接受总量预算（H7-2、H7-3）的审视，并且明确自己属于哪一类——把质感提案说成功能必需，是本条真正要拦的东西。

设计应用把这条做成设计评审的一个固定字段，而不是一次讨论；并在持续使用中比较触发量与任务收益，避免预设改善幅度。

验证示例

• 用户侧：功能成本改善类做有无对照，观察其所声明的那项指标（视觉注视次数、操作时长或错误率）是否确有差异；质感类按主观评价与触发量预算核对，不以功能指标判定成败。
• 实现侧：检查语义清单中每个条目是否填写了收益类别及对应说明；空白项或类别与说明不匹配的，在下一轮评审中重新审视。

反例做不到——每个新组件上线都顺手带一个触觉，一年后产品有四十种震动；做过头——把所有质感类触觉一律否决，产品的触觉只剩下三个功能性提示，交互显得生硬。

H7-5并发信号按语义取舍必须¶

一句话：并发信号按语义取舍。

适用多个信号可能重叠、同一事件可能被多层组件重复触发，或连续效果与提示共用输出端时。

规则产品必须定义重复事件去重、不同事件的优先级以及重叠时的合并、抢占或抑制规则。优先级依据用户任务与后果，不由振幅自动决定。禁止未经验证地叠加需要区分的信号而改变其含义；被抢占的离散事件不补播，持续过程仅在仍有效时按 H4-5 恢复。仲裁不得越过用户设置、时长及总量上限。

设计应用先去除同一业务事件重复调用，再处理不同事件的竞争。系统控件自带反馈时，避免业务层再追加一遍；需要混合的游戏效果单独验证。

依据与参考平台支持混合不代表混合后仍可辨义。Apple 控制器文档描述播放器叠加；本条的语义仲裁来自 H1-2 与 H2-1 的必要性推导。

验证示例

• 用户侧：持续质感中触发错误或边界，验证关键含义仍可识别且无突发强振。
• 实现侧：同时触发成功与失败、组件与业务层重复事件，检查去重、优先级和配额。

反例做不到——一次提交成功被控件、业务和通知层各震一次，像三次结果。做过头——把不同业务事件都当作重复，连续两次真实操作只反馈一次。

---

4. 术语和定义¶

---

5. 从任务到触觉方案¶

本章提供设计方法，不新增强制条款。先确定用户需要知道什么，再决定是否输出、输出什么，以及无法输出时怎么办。

5.1 场景选型¶

平台含义必须先核对。“通知反馈”这一 API 名称不表示拥有后台推送权限，“impact”也不表示业务成功。具体机制的适用条件见 来源说明。

5.2 六步完成一个信号的设计¶

1. 定义收益：说明用户在哪个任务时刻遇到确认、定位或质感问题；写出没有触觉时的基线。没有触觉仍能完成任务，是比较方案的起点。
2. 定义事实与含义：写清触发依据、取消条件和有效期。把按下、受理、处理中、成功、失败、未知分开；不要让一种结果触觉承担整个流程。
3. 选择最小表现：先检查系统组件与平台语义效果。只为需要区分的含义增加词汇；强弱与节奏是候选表现，不是已经成立的感知结论。
4. 确定设备与接触条件：列出实际输出设备、手持或佩戴方式及能力条件。每个候选效果写出降级终点，包含不播放；无需为不可控制的频率强行配置数值。
5. 组合控制与预算：明确关闭、分类关闭、时效、总量、并发取舍及停止。多项限制同时生效，优先级高不能免除这些限制。
6. 提出证据与失败处置：分开验证配置、输出机制与用户体验。先写通过标准再测试；不通过时选较简单效果、缩小适用范围或不播放，不以加大强度作为唯一修复。

5.3 最小设计记录¶

以下内容可以放进现有设计稿、工单或效果清单，不必建立独立流程。规则编号、Token 名称服务于追溯，运行事件标识与测试结果不做成配置项。

5.4 交付责任¶

设计负责语义、收益、可理解性、等价信息与控制入口；工程负责能力适配、时钟、去重、预算与停止机制；测试和研究负责在目标设备与人群上取得相应证据。同一人可以承担多个角色，但不能用“配置已写好”代替执行证据。

交付时带上可解析的效果引用、适用条件、尚未通过的情况和失败处置。无需向用户展示波形参数、接口名或预算字段；用户看到的是“操作反馈”“提醒”“关闭”和真实有效的强度选择。

6. 验证、验收与持续使用¶

6.1 三类证据¶

实机测量覆盖冷启动、预备状态、负载、后台切换与目标外设。统计方法记录样本数、分布、尾部延迟和测量误差；只报平均耗时会掩盖迟到的反馈。预备引擎可减少延迟，但不保证起振，也不允许提前表达结果。Apple prepare() 说明预备状态会结束，紧接播放前才调用也未必改善延迟。

6.2 最小场景矩阵¶

6.3 用户研究的最小纪律¶

• 觉察与猜测分开：随机混入无触觉试次，记录漏感和误报；避免让参与者看见测试人员按按钮后猜测。
• 感觉不同与知道含义分开：先做必要信号对的辨别，再采用产品真实引导测语义识别；记录成功误判为失败和失败误判为成功各自的后果。
• 阈值预先确定：按任务后果定义样本、试次、通过标准和不确定性处理，不提供跨产品统一百分比。少量试播可筛选候选，不能证明全部目标人群有效。
• 收益按声明验证：对比无触觉、最小必要反馈和候选方案；比较对应的错误、时间、查看负担或质感评价。改变试验顺序以减少练习效应。
• 长任务与退出权：观察短期新鲜感之后的累积负担；参与者随时可以暂停或关闭。记录设备接触、学习条件、个体差异和失败样本，不要求忍受不适完成试验。

6.4 验收决定¶

不把全部指标平均成一个总分。关闭后仍输出、虚报结果、误发到其他用户设备、预算可绕过等违反适用硬要求的失败，不能由满意度高分抵消。感知、时序与收益按预设的产品标准判断；证据缺失记为待验证。

使用中观察抑制、超时、中断、配置错误、用户关闭与不适反馈。抑制率高可能是设置被正确遵守，也可能是设计过密；不以“提高播放率”为优化目标。调试记录尽量只保留事件类型、效果标识、输出目标类别和原因，不复制业务正文。设备能力、接触条件、效果或目标用户改变时复核受影响证据；详见附录 A。

---

附录 A：验证清单¶

本清单用于自查与评审，不新增义务。每项对应正文中的具体规则，判定以正文为准。

分类检验（用于检验原则切分，见第 1 章）：取任意一条规则的具体要求，交给三名未参与撰写的评审者独立归属到七条原则之一；出现分歧的条目，检查的是原则的切分而不是评审者的理解。

信号级检查（对语义清单中的每个条目）：

• 含义与信号对应清楚，需要区分的含义不混淆，产品内一致（H2-1）
• 与平台系统语义不冲突（H2-2）
• 声明了所需能力（H4-1）
• 有降级链，末项明确；直接操作反馈不降成拖尾嗡鸣（H4-2）
• 降级链各档不与其他语义碰撞（H4-3）
• 传达信息时有对应的非触觉等价表达；纯质感标为不适用（H5-1）
• 在声明的每种情境下按下表的层级验证过（H1-1、H1-3、H1-2）
• 记录了收益类别（功能成本改善／质感与愉悦）及对应说明（H7-4）
• 强度档位与触发频率的关系合理（H7-1）

感知与体验验证（各项证据分别记录；语义识别依赖必要的觉察与辨别，舒适性和任务收益另行判断。纯质感不要求语义识别，不能因为没有功能收益就否定其质感目标）：

重新验证触发（命中任一项时，相关层级的既有结论作废，须重新验证并在证据中记录触发原因）：

• 信号参数、效果族或降级链发生变更
• 目标设备、作动器或系统行为改变，导致能力核验结果改变
• 新增或调整声明情境
• 语义清单新增条目，或已有条目的含义改变
• 强度档位映射或平台缩放行为改变
• 目标人群扩展到原验证未覆盖的群体

未触发时沿用既有结论；结论作废期间不得以"曾经验证过"充当证据，也不得因缺少新证据就把该信号当作已通过。

系统级检查：

• 触觉全关条件在常规验收矩阵中，覆盖主要任务路径（H5-4）
• 存在应用内关闭入口；强度与分类控制匹配实际能力和用途（H6-1）
• 遵守当前用途对应的系统设置与调用策略，无绕过路径（H6-2）
• 强度与时长上限在实际输出前强制（H6-4）
• 共享预算在所有入口生效，超限为合并或丢弃（H7-2）
• 保留输出（level.max.reserved_for）有用途清单与配额，且无未登记却事实上承担保留职责的输出（H7-3）
• 全部主动触觉可追溯到用户订阅的事件或委托的任务（H6-3）
• 无以触觉播放回执认定用户已知悉或同意的状态迁移（H1-5）
• 结果类触觉的触发点在结果确认之后（H3-4）

故障注入：

• 强制把能力探测结果置为"未知"，确认自定义能力不被当作已支持，允许的系统降级仍可用（H4-1）
• 强制每个信号降级到每一档，逐档记录实际表现（H4-2、H4-3）
• 注入延迟使触觉超出上限，确认丢弃而非补播（H3-1）
• 一次性触发大量同类事件，确认按定义合并或丢弃（H7-2）
• 重启、重载配置后保持关闭；提供备份恢复或跨设备同步时检查其冲突处理（H6-5）

补充的故障与长任务验证：

• 自定义基元 scale=0、无振幅控制两种设备路径均验证“关闭确实不输出”（H6-1）
• 中断、复位、切后台、取消后不补播旧事件，新的有效操作能继续（H4-5）
• 更换控制器与交换用户归属，反馈不发错设备或位置（H4-6）
• 多类事件竞争和同一事件重复投递，语义与总量仍正确（H7-5）
• 录音、拍摄、硬桌面和传感器使用期间验证机械干扰（H1-6）
• 完整任务中比较有无触觉的错误、时间、混淆、不适与用户负担；反馈过少导致的操作困难同样记录（H1-1、H1-2、H5-3、H7-4）

评审证据应记录设备与运行环境、接触条件、目标人群、学习方式、实际效果与配置、通过标准及失败样本。可使用现有测试记录，不要求另建文档。软件自动检查用于验证门控与状态，实机测量用于验证物理起停与输出特性，用户测试用于验证觉察、辨别、语义识别、舒适性与任务收益；三者不能互相替代，感知层级之间也不能互相替代（见上文层级表）。

---

附录 B：论证边界与来源¶

B.1 约束词的判据¶

标「必须」的依据是缺失后可预见地破坏可理解、可用或可控制的体验承诺。每条按具体适用条件判断；本规范的强制性不等于法律或国际标准的强制性。

B.2 适用范围¶

本文涵盖通用产品中的振动触觉输出。专用触觉阅读与编码设备可参照语义和控制原则，但其通道设计与训练需要单独评估，不能机械套用 H5 的通用产品前提。力反馈、阻抗、外骨骼、热刺激、电刺激、超声与静电触觉的特有要求不在覆盖范围内。车载、医疗与儿童产品需要领域评估，本文不证明其安全或合规。

ISO 9241-920 的公开摘要明确包含要求与建议，并覆盖更广的触觉输入输出与编码。此处仅采用公开摘要，未读取受限全文，因此不判断它是否已经覆盖本文每一项机制，也不宣称本文是唯一成体系的规范。平台文档的代码示例只是实现参考，不以其中的错误处理直接决定产品行为。

B.3 来源与条款对照¶

可点击来源、获取状态、数值条件与未解决事项见 reference.md。

---

实施验收场景¶

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

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