眼动交互设计规范

面向设计师与工程师：让"看"仍然是看，让"选"确实是选；让用户知道系统认为他在看哪、系统据此做了什么、这些数据去了哪里，并且在他用不了或不想用眼睛的时候仍能完成任务。

眼动进入产品有两条路径：显式的——把注视当作指点通道，用停留或配合手势、语音完成选择；隐式的——把注视当作注意力信号，用于渲染优化、内容排序、阅读度量、驾驶员监控、认知负荷评估。两条路径的设计对象不同，风险也不同，但共用同一组前提：

1. 眼睛首先是感知器官，其次才是输入设备。 只要睁眼观察，注视信号就可能持续产生，不能把它默认当成操作。Midas Touch、注视疲劳、"逃跑的光标"都是从这一条派生出来的，而不是各自独立的缺陷。
2. 注视位置的测量是概率性的，且会随时间退化。 精度受校准质量、佩戴变化、光照、瞳孔大小和疲劳影响。传统界面"点击目标即命中目标"的确定性假设在这里不成立。
3. 注视及相关眼部数据可能支持对兴趣、认知状态、身份或健康迹象的推断，但不等于能可靠读取这些状态。 隐私不是这份规范的附加章节，是一个独立的规范对象。

本规范由六条原则和31 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（E3-2 就是第三条原则下的第二条规则）。每条规则都回答三个问题：设计师决定什么，工程提供什么事实，用户如何知道它生效。

本规范约束的是产品对用户作出的体验承诺及其兑现机制的性质，不预设唯一的硬件方案、算法或 SDK。它不是组件库，不是实现架构，不构成安全、隐私或医疗器械合规证明。采用本规范不能替代无障碍专项评估、数据保护影响评估（DPIA）、人因测试、医疗与驾驶场景的领域合规，以及对未成年人和工作场所监控的专门审查。

本规范不覆盖：眼动作为研究方法（可用性测试中的热力图、注视轨迹分析）——其测量方法需按研究问题选取；ISO 15007 与 SAE J2396 仅针对驾驶员视觉行为，不能概括一般可用性研究；也不覆盖眼动的算法实现（瞳孔角膜反射、外观模型、标定算法）。

全文四章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；分类检验与验收见附录 A，数值依据见附录 B，选择尝试的状态与事实契约见附录 C。可配置参数见同目录 Design Token.md，来源与核验程度见 reference.md。

本文件用于设计交付与项目评审；【必须】表示本规范的产品要求，不表示被引厂商、论文或法律都提出了同等强度的要求。

---

使用入口与适用范围¶

先确定眼动在产品里承担哪项工作，再选规则与参数；不从“设备支持眼动”直接推导“所有元素都能看着点”。

一个产品可以包含多种形态，但每项能力须明确归属。参数见 Design Token。不适用项写明原因，不能用“不掌握原始数据”豁免应用自己控制的提交和反馈行为。

1. 六条原则¶

六条原则按规范对象切分设计责任：每条原则管辖一类对象上的义务，每条规则按其义务的直接规范对象归属唯一原则。

同一个场景可以触及多条原则——一次停留激活同时涉及触发机制（E2-2）、命中判定（E3-1）和进度回执（E4-3）——这不是分类错误：三条规则约束的是三个不同规范对象上的义务。

互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证；检验不过，修改的是原则的切分，而不是增设中间层或映射表。

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

2. 规则的读法¶

2.1 每条规则的结构¶

规则正文规定要求；适用与边界条件共同限定要求的适用范围；设计应用、验证示例、反例与依据参考不另行增加义务。

2.2 约束词¶

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

符合性判定以正文中的独立义务子句为单位；未显式标注约束词的正文承接规则标题强度：【应当】规则内的「禁止／不得」子句仍是硬约束。正文中的「不能」仅用于能力或事实陈述，不表达义务。

本规范正文中出现的所有数值门槛都带单位，并在附录 B 标明出处与核验程度。未标出处的数值不得作为合规判据——它是示例，不是要求。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而堆确认、堆反馈、堆开关。两侧都算没做对。

眼动交互被做坏的方式高度集中在"做过头"：因为用户一直在看，任何以注视为触发的反馈都会被触发得远比设计者预期频繁。一个在原型里"恰到好处"的高亮效果，在连续使用二十分钟后就是持续闪烁。评审时把这一侧当作默认怀疑对象。

2.4 规则速查：31 条¶

E1 注视不等于意图

E2 激活匹配错误代价

E3 精度有界且会退化

E4 反馈克制且可归因

E5 注视数据可见可控

E6 通道可退出且不独占

---

3. 规则详解¶

3.1 E1 注视不等于意图¶

眼睛的首要功能是采集信息。把注视信号翻译成用户意图，是系统作出的推断，不是用户作出的表达。本原则管辖这一层翻译：什么时候允许翻译、翻译出来的东西有多大效力、翻译错了怎么办。

E1-1观察态与控制态可区分必须¶

一句话：让用户随时能只看不选，并且知道自己现在处于哪一态。

适用任何以注视作为选择或激活通道的界面。

规则产品必须存在一个用户可以自由观察而不触发任何选择、激活或外部影响的状态，并且用户必须能够判断当前处于观察态还是控制态。进入控制态必须由用户可察觉的条件决定——显式信号、明确的区域边界或已声明的模式切换；禁止仅以"注视时长超过某值"作为观察态与控制态之间的唯一分界，除非该激活落在 E2-1 允许的最低代价档位。注视候选不得仅因目光移动就夺走键盘焦点、文本插入点或辅助技术焦点；需要接管时必须有明确的发起动作。

边界条件本条不要求把观察态做成一个独立的界面模式或全局开关。区域级的划分（可注视激活区与纯阅读区）、对象级的划分（只有被显式标记的对象参与注视激活）都满足要求，只要用户能判断。

设计应用把长文本、图像、视频画面等以观看为目的的内容置于注视激活的排除区；把可注视激活的对象在视觉上与之区分。跨模态方案可以用显式信号进入控制态，但仍须验证指向时刻、对象绑定和观察时无副作用，不能只因接入另一个通道就判为满足。

验证示例

• 用户侧：让用户在界面中自由阅读两分钟，统计非预期激活次数；询问他是否知道自己"什么时候会触发东西"。
• 实现侧：检查观察态下是否存在通往不可撤销动作的路径；检查排除区的判定是否随布局变化而失效。

反例做不到——整屏元素都可停留激活，用户读一段说明文字就跳转了页面；做过头——设一个必须手动打开的"眼控模式"总开关，用户每次想点一下都要先去开关那里，而开关本身还得用眼睛点。

E1-2注视不构成授权与知情必须¶

一句话：看过不等于同意，也不等于已读、已理解、已知情。

适用涉及授权、同意、告知义务、阅读确认、免责声明、风险提示的任何界面。

规则禁止以被动观看、注视覆盖率，或未经明确确认流程产生的候选事件，作为用户同意、已读、已知情或已理解的证据；禁止以"用户注视过该区域"为由降低、简化或跳过本应由显式操作完成的确认。注视可以作为视线是否落入呈现区域的产品度量，但不得作为用户是否负有相应知情后果的判据。

经由符合 E2-1 边界条件的主动分阶段确认流程完成的确认操作，可以作为用户对该具体请求所作决定的记录——这类记录须保留请求、决定、对象内容与确认方式，与原始样本、候选命中记录分开存放并按 E5 管理；但它只证明用户作出了确认动作，不得据此宣称用户已理解全部内容。请求或对象内容被替换后，旧的确认失效。

边界条件本条不禁止用注视信号改善告知设计——例如检测到用户未看关键条款时将其重新呈现。区别在于方向：用注视去加强告知是允许的，用注视去替代确认是禁止的。

设计应用需要确认的地方保留与被动观看可区分的确认动作（辅助技术例外见 E2-1）；如果产品用注视度量阅读覆盖率，把它写进内部指标，不写进用户的权利义务链路。

验证示例

• 用户侧：让用户目光扫过一份授权说明但不作任何操作，验证系统是否仍要求显式确认。
• 实现侧：检索"已读""已知情""已同意"等状态的写入路径，确认没有一条以注视事件为唯一来源。

反例做不到——用户视线经过隐私条款区域三秒，系统记为"已阅读并同意"；做过头——因为怕被误认为知情证据，索性不采集任何阅读度量，失去了发现"关键提示没人看"的能力。

E1-3隐式使用不改变任务状态必须¶

一句话：注意力驱动的适配可以改变呈现，不得改变结果或产生外部影响。

适用所有把注视用作注意力信号的隐式功能——注视点渲染、内容排序、动态提示、阅读度量、驾驶员/操作员状态监控。

规则由注视信号自动触发的适配，其作用范围必须限于呈现层：渲染精度、布局强调、提示时机、内容排序。禁止由未经用户显式确认的注视信号直接提交业务决定或产生未经授权的外部影响——包括不可撤销的动作、对外发送、支付，以及对持久业务状态的写入。为已披露目的进行的、受 E5 约束的必要度量记录（阅读覆盖率、命中日志）不因其属于"数据写入"而自动被本条禁止；但这类记录不得被转用为用户的确认或同意证据（见 E1-2）。当隐式功能的输出会进入影响用户的决策链路（如疲劳判定触发告警或干预）时，该输出必须按 E5-3 单独授权，并按 E5-6 处理。

边界条件安全关键场景的干预是例外，但例外必须显式：驾驶员监控系统在检测到闭眼时发出告警属于产品的安全承诺，应当在能力披露中说明，且其判据、误报率与用户可采取的动作要事先声明；这类例外不得被扩展用于非安全目的。

设计应用把"用注视调整呈现"与"用注视触发动作"在架构上分开——前者可以持续运行，后者必须经过 E2 的触发机制。

验证示例

• 用户侧：在启用注意力排序的列表中自由浏览，验证浏览行为不提交业务决定；披露范围内的必要度量单独核对。
• 实现侧：追踪隐式功能的所有写操作，区分必要度量与业务写入；确认不存在未授权副作用，已声明监测分支按其适用条件验证。

反例做不到——用户多看了某个商品两秒，系统把它加入了购物车；做过头——因为担心越界，连注视点渲染这类纯呈现优化也要求用户逐次授权。

E1-4注视意图推断可修正应当¶

一句话：系统猜你想选什么，要有不必重复困难命中的纠正路径。

适用使用概率命中、意图预测或注视轨迹预判来选择目标的产品。

规则系统对"用户想操作哪个对象"的判断应当作为可修正的假设呈现，并提供不依赖重复同一次困难注视的纠正方式；有其他可用通道时，优先使用非注视纠正。仅眼动可用时，可采用放大、分步消歧或独立撤销区。当候选目标之间的判定置信度不足以区分时，系统应当请求消歧或不作选择，不应当默认取最近候选并直接执行。

依据与参考在注视通道内纠正注视错误会形成闭环困境——用户为了改选而移开视线，恰好又触发了新的判定。这与「观察 vs 控制」的双重角色是同一个问题的两种表现（见 E1-1）。

设计应用有其他可用通道时用手势、按键或语音纠正；仅眼动可用时提供放大、分步消歧或独立撤销区，避免让用户重做原有的困难命中。

验证示例

• 用户侧：构造两个相邻的相似目标，让用户在系统选错后改选，记录改选耗时与二次错误率。
• 实现侧：检查消歧路径是否存在且不要求重复原有的精确命中；检查置信度不足时的默认行为。

反例做不到——选错了只能盯着正确目标再停留一次，而这一次又选错了旁边那个；做过头——每次选择都先弹出"你是要选 A 还是 B"，把本可以直接完成的选择变成两步。

E1-5状态推断有证据且允许未知必须¶

一句话：眼动指标不是心理状态的直接读数，证据不足就输出未知。

适用根据注视、瞳孔或眨眼等指标推断用户兴趣、负荷、情绪、疲劳或健康状态的功能。

规则产品必须区分测得的指标与推断的状态，说明推断适用的人群、任务和环境，并以独立参考验证错误率。仅凭注视时长或单次瞳孔变化不得宣称用户已理解、喜欢、焦虑或正在作弊。数据不足、条件超出已验证范围或存在无法排除的混杂因素时，必须允许输出未知或暂停推断；不得把无数据记成不专注。获得授权的要求见 E5-3，用于评价的限制见 E5-6。

依据与参考瞳孔响应同时受亮度、近距离注视和心理活动影响；从指标反推单一状态存在歧义（Mathôt, 2018）。本条的拒判与分群验证要求是基于这一测量边界的设计推论。

设计应用将“本段有效注视覆盖不足”与“你没有认真阅读”分开；在评估中控制亮度和内容难度，并报告模型在未见用户上的表现。

验证示例

• 用户侧：只改变屏幕亮度，检查系统是否将瞳孔变化直接解释成情绪改变。
• 实现侧：回放缺失数据与超出验证条件的输入，确认输出未知；记录误报、漏报和未知率，不能只展示整体准确率。

反例做不到——用户看向别处就被记为低专注度；做过头——把每次低置信度都做成要求用户回答的问卷。

3.2 E2 激活匹配错误代价¶

从"系统认为用户在看 X"到"系统对 X 执行了动作"，中间的机制是本原则的规范对象。E1 管能不能把注视当意图，本原则管确定要动作时用什么方式触发、参数怎么定。

E2-1触发方式按错误代价分档必须¶

一句话：不可撤销的动作不得由一次被动停留触发。

适用所有以注视参与触发的动作。

规则（配置生效）：每一次选择尝试绑定它开始时解析出的配置快照。影响命中判定、停留判据或动作风险档位的参数在尝试进行中被修改时，禁止把已经累积的样本追溯性地转换为一次激活：产品须择一声明——取消当前尝试并要求重新发起，或让旧尝试按其仍然合法的原配置结束、新尝试使用调整后的配置。关闭、撤权与风险保护的收紧先行拦截受影响的尝试。呈现类设置的变化不得被转化为用户的业务确认。

规则产品必须为可注视激活的动作定义错误代价档位，至少区分：可撤销且代价低、可撤销但代价高、不可撤销或产生外部影响。不可撤销或产生外部影响的动作，禁止由一次被动停留或注视进入直接触发，必须要求独立于眼睛的确认信号（手势、按键、语音、控制器；仅眼动可用时见下述边界条件），并在提交前允许取消。取消窗口不是免除确认的理由。可撤销但代价高的动作应当同样采用显式激活。档位与触发方式的对应关系必须事先声明，不得由界面逐处自行决定。

边界条件仅眼动可用的辅助场景，可以提供专门验证过的分阶段确认：先选择并呈现具体对象与后果，结束原有停留，再由用户重新发起独立的确认步骤，同时提供可达的取消路径。禁止复用同一次计时或让新出现的确认按钮继承旧目标的蓄力；仅将停留延长不满足本例外。本例外是本规范的包容性设计提案，须以目标用户的误确认测试验证，不代表平台已经保证可靠性。

依据与参考Tobii 的 XR 交互设计文档明确指出，注视配合显式激活信号是最可预测、最可控的交互状态，对于错误代价高的元素在多数情况下优于注视进入或停留激活；微软 HoloLens 2 指南同样建议以语音命令、手势、按键或延长停留来触发选择，而非直接对注视作出反应。两者支持将定位与提交分开，但未共同规定本规范的风险分档和禁止范围；后者是本规范的设计推论（见 reference.md §1、§9）。

设计应用把档位映射写进设计系统而不是逐个界面拍板；同一档位在全产品内触发方式一致，这样用户的预期才能迁移。

验证示例

• 用户侧：对每个不可撤销动作，验证被动浏览能否意外完成它；仅眼动辅助确认须另外测试分阶段流程。
• 实现侧：审查触发路径清单，确认不可撤销档位符合独立确认或已声明的辅助确认例外，且对象和后果不在确认后被替换。

反例做不到——"删除全部"和"展开列表"用同一个 800ms 停留触发；做过头——连切换标签页这种一步可回退的操作也要求"注视+语音确认"，用户完成一次浏览要说十几句话。

E2-2停留激活可中止且有进度必须¶

一句话：停留在完成前一直可以反悔，并且用户看得见还剩多久。

适用采用停留（dwell）触发的任何交互。

规则停留触发必须提供表示进度的反馈，使用户在激活发生前知道正在蓄力以及大致还剩多久；注视离开目标必须立即停止累加，离开达到已声明的容差时限即清零，且取消必须可被用户感知。容差窗口内只可冻结进度，并且仅在回到同一对象、内容与动作均未改变时续接；不得把离开的时间计入停留。恢复后至少需要新的有效驻留区间，首个恢复样本不得补齐中断时间或直接提交。停留时长必须可配置，并按目标用户群、追踪性能与错误代价选取，不得强制所有用户和情境使用不可调整的硬编码值；经过验证的同类目标可以共用预设。产品必须声明所采用的停留时长及其依据。

边界条件本条不要求停留进度以环形进度条呈现，也不禁止在同一产品内对不同档位使用不同时长。它要求的是"蓄力可见"与"离开即止"，不指定表现形式。

依据与参考Penkar 等人的实验联合考察了停留时间、按钮尺寸与阅读内容位置，说明这些参数需要一起测试（见 reference.md §4.2）。停留时间与布局一起验证，不采用跨产品统一时长。

设计应用为熟练用户提供缩短停留时长的设置；对错误代价高的目标延长时长并不是好办法（Tobii 指南指出过长的停留令人紧张且不自然），应当改用 E2-1 的显式激活。

验证示例

• 用户侧：在蓄力过半时让用户移开视线，验证激活被取消且用户察觉到取消。
• 实现侧：检查停留计时是否在追踪丢失（E3-3）时暂停或清零，而不是继续累加。

反例做不到——没有任何进度提示，用户只知道"盯久了会自己触发"，于是全程不敢停留；做过头——每个可注视对象都持续显示一个转圈的进度环，整个界面像在呼吸。

E2-3多模态激活按发起时刻绑定必须¶

一句话：按声明的发起事件绑定对象，不让识别时延把 A 变成 B。

适用注视与手势、语音、按键或控制器组合的激活方式。

规则当激活信号来自其他通道时，系统必须以该信号发起时刻（或该时刻之前的一个声明时间窗内）的注视目标作为作用对象，不得以信号识别完成时刻的注视目标为准。该时间窗必须明确，并与所用信号的典型识别时延相容；不得无限追溯更早的注视目标。跨通道的时序对齐要求必须在自定义输入控件中同样成立。产品必须明确何种事件代表发起（如捏合开始、按键事件、语音中指向对象的片段），并使用可对齐的时间基准；不得把整段语音的起点统一当作指向时刻。样本过期、时间戳未知、对象内容已改变或无法唯一确定对象时，必须取消该次激活或请求消歧，并保留不依赖重复困难命中的纠正路径。平台已提供绑定结果时应当直接复用，不要求应用另行采集原始注视。

依据与参考这是被独立记录的失效模式，微软 HoloLens 2 指南称之为"leave before click"——研究显示在快速目标选择中，用户的注视会在手动点击完成之前就移开。语音命令的识别时延使这个偏差更大（见 reference.md §1）。

设计应用在输入管线中记录注视历史缓冲，激活信号到达时按其时间戳回溯取值；自定义手势要记录起始时刻或近似时长，而不是只上报识别结果。

验证示例

• 用户侧：让用户以自然速度连续选择多个相邻目标，统计选中对象与用户报告的意图对象的一致率。
• 实现侧：注入一个人为延长识别时延的语音信号，验证作用对象仍是发起时刻的注视目标。

反例做不到——用户看着 A 说"删除"，语音识别用了 700 ms，这期间视线移到了 B，系统删了 B；做过头——为了对齐时序把所有交互都延后到最长时延之后才响应，界面整体变得迟钝。

E2-4误触抑制与重复激活控制必须¶

一句话：眨眼、扫视、抖动和重复不得被读成激活。

适用所有注视激活通道。

规则系统必须抑制以下信号被判为激活：眨眼期间的注视中断、扫视途经目标、低于注视判定阈值的短暂停留、追踪抖动导致的目标间反复跳变。同一目标激活后必须存在重新激活门槛，防止未移开视线导致的连续重复激活。普通按钮必须等待有效离开后重新进入，或取得新的显式发起信号；计时冷却结束本身不得触发下一次提交。确需长看连发的步进控件必须单独声明重复模式、节奏和停止条件。一次选择尝试不得因事件重放、双通道回调或结果迟到而重复提交。抑制参数必须与所用设备的采样率和精度相容，并可配置。已声明并验证的主动眨眼编码按 E2-5 的辅助例外处理，不与自然眨眼中断混同。

设计应用注视判定的最短稳定时长、扫视速度阈值、眨眼容忍窗口分别配置（见 Design Token §三）；激活后主动将该目标移出可激活集合，直到注视离开并返回。

验证示例

• 用户侧：让用户以正常速度浏览一排可激活对象，统计误激活次数；让用户正常眨眼十次，验证无激活发生。
• 实现侧：回放包含扫视、眨眼与追踪抖动的注视数据，检查激活事件数是否为零。

反例做不到——用户眨了一下眼，界面判定注视中断又重新进入，停留计时重置或直接触发了激活；做过头——抑制窗口过长，用户有意的第二次选择被吞掉，只能等两秒再试。

E2-5不强制非自然眼动应当¶

一句话：不要求用户用眼球画符号来下命令。

适用注视作为主要交互通道的产品。

规则产品不应当要求用户执行非自然的眼球运动（特定方向的眼势、刻意的长时凝视、眨眼编码）作为完成主要任务的必要条件。此类交互可以作为可选的加速方式提供，但不得成为唯一路径。

边界条件本条不适用于以眼动为唯一可用通道的重度辅助场景——对完全失去其他运动能力的用户，眨眼编码和眼势可能是可行的沟通方式，此时它们不是"强制的不自然动作"，而是唯一的表达手段。区分依据是用户是否还有其他通道可用。

依据与参考微软 HoloLens 2 指南直接给出"避免强制非自然的眼动作为输入"这一条建议（见 reference.md §1）。刻意的眼球运动会加速视觉疲劳，且与阅读、观察等自然行为冲突。

设计应用把眼势留给熟练用户的快捷方式；主路径用注视+显式信号或停留。

验证示例

• 用户侧：验证每项主要任务都能在不使用任何眼势的情况下完成。
• 实现侧：检查功能清单中是否存在仅由眼势暴露的能力。

反例做不到——返回上一级要求"向左快速看两次"；做过头——为了避免眼势，把所有快捷操作都删掉，重度用户失去了效率手段。

E2-6激活绑定对象与操作含义必须¶

一句话：布局和内容变了，旧的停留进度不能触发新的动作。

适用包含滚动、动画、异步加载、列表复用、内容排序或移动目标的注视界面。

规则停留进度与跨模态确认必须绑定具体对象、输入来源和当时的操作含义，不得只绑定屏幕坐标或列表索引。目标被替换、遮挡、禁用、移出有效交互层，或动作后果改变时，必须取消或重新取得有效选择；不得把旧目标的进度转给新目标。输入来源切换或坐标空间重定位时，必须取消受影响的尝试并重新核对质量与几何。同一对象移动时，必须声明暂停、重置或经验证的跟随策略，并按样本对应的场景几何判定；不得用旧注视和新布局拼出一次命中。

依据与参考Apple 记录了悬停时突然出现关闭按钮会吸引视线并造成误关闭的问题（WWDC25）。对象与操作含义绑定是本规范对该类失效的工程化推论，不是原文 API 要求。

设计应用列表更新保留稳定对象标识；确认期间冻结会改变操作含义的局部内容。无需冻结整个界面，也无需长期留存注视轨迹。

验证示例

• 用户侧：停留过半时插入一行或出现浮层，确认用户不会意外选择顶替原位置的新目标。
• 实现侧：注入滚动、对象替换和过期样本，检查激活对象、动作含义及累计进度是否一致。

反例做不到——“展开详情”被替换成“删除”，旧计时走完后删除；做过头——只要有人在看就停止页面全部更新。

3.3 E3 精度有界且会退化¶

E2 管确定目标之后怎么触发，本原则管怎么确定目标：几何怎么设、精度怎么度量、不准的时候系统做什么。

E3-1目标几何按视角定义必须¶

一句话：尺寸和间距用度，不用像素；命中区可以大于可视尺寸。

适用所有可注视激活的界面元素。

规则可注视激活目标的最小尺寸与最小间距必须以视角（度）定义，并声明所依据的观察距离或显示几何；仅以像素、点或物理长度定义而不声明距离条件的规格不满足本条。命中区与可视尺寸可以分离——命中区允许大于可视元素，但相邻目标的命中区不得重叠到无法区分。产品必须声明其采用的最小视角值及依据，分别检查投影后的宽与高；三维目标还须明确可见表面、遮挡与深度仲裁。注视射线穿过的隐藏对象不得仅因命中排序靠前而激活。

边界条件本条不规定跨产品通用下限。HoloLens 2 的 2° 是该设备的厂商建议，不是生理硬阈值。Apple 官方讲稿要求为每个元素提供至少 60 pt 的目标空间，可由可视尺寸与间距共同满足；其固定比例 3D 对象参考换算为约 2.5°（见附录 B）。采用平台标准控件及动态缩放时，可以通过可追溯的平台显示几何约定满足要求，不必让设计师另填物理距离。头显、桌面遥测式眼动仪、车载 DMS 的可达精度不同，取值必须按自身设备的实测精度确定。

依据与参考2° 视角在 60 cm 观察距离处约为 2.1 cm（换算见第 4 章）。目标相对测量误差过小时通常更难区分；误差并非固定半径的圆，也不能仅凭尺寸推导绝对命中率。目标间距、偏差、抖动和判定方法需要联合实测。

设计应用在设计工具中以角度网格而非像素网格布局注视界面；同一份设计用于不同距离的设备时重新换算，而不是等比缩放像素值。

验证示例

• 用户侧：在设备实测精度下测量目标选中率与误选率，而不是只看设计稿的尺寸标注。
• 实现侧：检查布局系统是否保留了距离参数；检查响应式布局在极端尺寸下是否把目标压到阈值以下。

反例做不到——沿用移动端的 44 pt 触摸目标规格做注视界面，用户怎么看都选不中；做过头——把命中区扩到极大以求"好选"，结果相邻目标的命中区互相覆盖，选中的总是排序靠前那个。

E3-2精度是可观察的运行状态必须¶

一句话：系统自己要知道现在准不准，并据此改变行为。

适用所有依赖注视位置作出判定的功能。

规则系统必须维护有依据的追踪可用性状态，可来自实测误差、有效性标记、校准验证或平台提供的质量等级，并记录其依据、覆盖区域与时效；未测得数值时必须允许“未知”，不得伪造逐帧精度。以角误差表达质量时，数值越小越好，超过误差上限才是不足；准确度、精密度、数据丢失率不得混为一个指标。双眼融合、单眼使用或输入源切换时，必须按对应人群和设备条件验证；不得把缺失的一只眼当零坐标参与平均，也不得用头部方向静默冒充眼动位置。质量不足或未知时必须定义行为——至少包括：停用注视激活、扩大目标并验证仍可区分、切换到替代通道三者之一（对应行为见 E6-3）。精度状态的变化必须能够被产品逻辑读取，禁止在精度已知不足时仍按标称精度继续判定命中。系统对精度的估计与对用户的告知是两件事：本条要求前者存在，告知要求见 E4-1。

边界条件本条不要求向应用层暴露精度的具体数值——出于 E5-2 的考虑，暴露等级（可用/降级/不可用）可能是更合适的粒度。它要求的是系统内部有这个状态且行为随之改变。

依据与参考追踪精度会因光照变化、佩戴位置移动、瞳孔大小变化和疲劳而退化，这是被反复记录的现象；微软指南提到光照变化时精度会有一定下降并可能需要重新校准（见 reference.md §1、§4）。标称精度不能代替目标用户在实际使用条件下的验证（测量口径见附录 A.3）。

设计应用把精度估计接入布局与判定，而不只是接入一个"请重新校准"的提示；精度分档而非连续值更容易在产品逻辑中使用。

验证示例

• 用户侧：在人为制造的低精度条件下（改变光照、移动佩戴位置）使用产品，观察是否仍要求用户完成需要高精度的操作。
• 实现侧：注入退化的精度估计，验证命中判定与目标几何确实随之改变。

反例做不到——校准后就再不评估精度，用户戴了两小时头显后怎么都选不准，产品毫无反应；做过头——精度轻微波动就弹出重新校准提示，用户每隔几分钟被打断一次。

E3-3追踪丢失是明确状态必须¶

一句话：丢了就是丢了，不外推、不猜测、不静默沿用上一个位置。

适用使用注视位置判定选择、命中与激活的功能。纯渲染预测不受本条禁止外推的约束，但预测值不得被复用为有效的操作证据。

规则失效与计时按下表分条裁决，不由一个"丢失超时"统辖；首个无效、过期或时间无法解释的样本出现时即停止累计与激活，不必等到丢失时限到达。数据源停止发送事件时同样必须检测新鲜度到期，不得依赖“收到无效样本”才发现断流。取消、撤权、对象失效与计时达标同时待处理时，先处理阻断条件，再决定是否允许提交。

禁止在追踪丢失期间外推注视位置继续判定命中，禁止沿用最后一次有效注视点作为当前注视点。****恢复有效追踪只恢复有效选择的资格：未取消的短断可按契约接续，已取消的尝试必须重新开始；不得自动完成此前未完成的提交。失效状态必须可被用户察觉（要求见 E4-1）。

依据与参考须区分可用信号、短暂无效和持续失效，不能把不可用信号静默折叠为有效选择。OpenXR 的有效性、追踪标记与时间信息提供部分实现依据，但不是本规范状态模型的一一映射（reference.md §3.1）。

设计应用在首个无效、过期或无法解释的样本出现时即停止激活计时，不必等到追踪丢失提示的时限才防误触。区分短暂中断（眨眼、瞬时遮挡）与真正丢失，前者由 E2-4 的抑制窗口吸收，后者进入失效态；两者的时限分别配置。

验证示例

• 用户侧：让用户用手短暂遮挡眼动相机或闭眼数秒，验证不产生任何激活，且恢复后状态清晰。
• 实现侧：回放包含追踪中断的数据流，检查中断期间的命中判定数是否为零。

反例做不到——追踪丢失后系统沿用最后位置，用户闭眼休息时停留计时走满，触发了一次操作；做过头——一次 100 ms 的眨眼中断就整屏变灰提示"追踪已丢失"。

E3-4校准成本与收益相称应当¶

一句话：先判断是否真有偏移，再校准；不把猜测的意图当校准真值。

适用需要用户配合完成校准的产品。

规则产品应当在漂移达到影响任务的程度时才要求重新校准，并优先采用低打断的质量检查；隐式纠正只有在参考目标可靠且改善得到验证时才使用；不应当以固定时间间隔无条件要求重新校准。无论采用何种纠正方式，不得把概率命中后选中的对象直接当成用户实际注视的真值；共享设备切换用户或跨设备导入档案后，必须重新验证后才可用于该用户，不得沿用他人的拟合结果。校准的触发条件与所需时长应当对用户可预期。首次校准是否可跳过、跳过后的可用范围，应当明确声明（对应 E6-3 的未校准行为）。

依据与参考眼动报告指南要求说明校准方法、验证判据与重校准触发条件（reference.md §4.4）。它未证明“隐式纠正总是更好”；该方案需在本产品中证明收益。

设计应用校准与验证分开，尽可能用未参与拟合的参考点检查关键区域。若用自然交互修正偏移，保留修正前的参数并比较效果。重新验证失败时，只有仍适用于当前用户和条件且验证合格的档案可以恢复；否则降级到不依赖校准的路径。

验证示例

• 用户侧：连续使用 30 分钟，记录被要求重新校准的次数与每次的中断时长。
• 实现侧：检查重新校准的触发条件是否包含精度判据，而不只有计时器。

反例做不到——漂移已大到用户选不中任何东西，系统仍不提示校准；做过头——每十分钟强制一次五点校准，用户三分之一的时间在盯圆点。

3.4 E4 反馈克制且可归因¶

E3 管系统内部怎么算命中，本原则管系统把这件事怎么告诉用户。眼动的反馈设计有一个独特约束：触发频率由用户的眼球运动决定，而眼球运动的频率远高于任何手动输入。

E4-1注视回执可归因必须¶

一句话：让用户能看出系统认为他在看哪，从而识别偏移。

适用所有注视参与选择的界面，以及注视功能可能失效的场景。

规则当注视参与选择时，系统必须让用户能够判断当前被系统认定为注视对象的是哪一个；当系统处于精度不足或追踪丢失状态（E3-2、E3-3）时，必须让用户能够察觉，而不是让用户把系统的失效误认为自己的操作失误。回执可以附着在目标对象上，不要求呈现连续的注视光标。

边界条件本条不要求呈现注视点坐标或注视轨迹。附着在目标上的状态变化（轻微高亮、边框、尺寸变化）满足要求，且通常优于连续光标。可被抑制的只限附加效果（附加动画、展开、常规音效）；候选的可辨认性、蓄力与取消的回执、失效与关闭的回执不在可抑制范围内。本条不要求产品报告用户实际注视方向与系统判定之间的真实偏差——可呈现的只是系统所认定的对象；没有可靠的偏差测量依据时显示"未知"，不得给出一个方向指示。

依据与参考微软 HoloLens 2 指南明确建议不要把光标之类的元素直接绑定到用户的注视上——投影注视信号的微小偏移会产生"逃跑的光标"效应，用户越想看清光标，光标越跑（见 reference.md §1）。这是把"可归因"做成"连续光标"的典型代价。

设计应用用目标态而非光标态承载回执；失效状态用与正常态明显不同的表现（而不是简单地"什么都不发生"，那与"我没看准"无法区分）。

验证示例

• 用户侧：在存在系统性偏移的条件下使用产品，观察用户是否能意识到"系统认为我在看旁边那个"并作出补偿。
• 实现侧：检查追踪丢失与精度不足时是否有区别于正常态的呈现。

反例做不到——精度漂移后毫无提示，用户以为是自己的问题，反复用力盯着目标看导致眼疲劳；做过头——一个跟随注视的高对比度光标，用户视线被自己的光标吸引，形成追逐。

E4-2反馈有时序与抑制条件必须¶

一句话：轻量回执及时出现，展开与动画按情境延迟、抑制。

适用所有对注视作出视觉、听觉或触觉反馈的界面。

规则注视反馈必须定义出现时序与抑制条件，并区分基本命中回执和附加内容展开。轻量、稳定的高亮可以即时响应有效命中；会展开内容、移动布局或播放声音的反馈必须设置与情境相称的延迟或抑制，避免扫视途经与纯阅读触发干扰。反馈强度应当克制，不使用高频闪烁效果；可调时序可以继承平台已验证的行为，不强制应用重复叠加延迟。

依据与参考微软 HoloLens 2 指南反复强调这一点——不要用即时的弹出效果或悬停音效压垮用户，"subtlety is key"；同时指出反馈本身是必要的，用于表明系统工作正常（见 reference.md §1）。这条规则的两侧张力最强：完全没有反馈用户无从判断，反馈稍重就变成骚扰。

设计应用浏览中的连续悬停音效默认关闭，离散激活的声音回执按用户需求配置；参考 Apple 对即时高亮与延迟展开的区分（reference.md §1.3）；把"用户连续使用二十分钟"作为反馈设计的评审条件，而不是只看单次交互的截图。

验证示例

• 用户侧：让用户连续使用 20 分钟后评价干扰程度；记录每分钟触发的反馈次数。
• 实现侧：回放含大量扫视的注视数据，统计反馈触发次数与实际停留次数之比。

反例做不到——目光扫过一排图标，每一个都弹出放大并播放音效；做过头——为了不打扰彻底取消注视反馈，用户完全不知道系统有没有在响应自己。

E4-3交互状态可区分应当¶

一句话：悬停、蓄力、已激活、已取消，各是各的样子。

适用采用多级注视交互状态的界面。

规则注视进入、停留蓄力中、激活完成、蓄力被中止这几种状态应当在呈现上可区分；同一状态在产品内的表现应当一致。触发已发出与业务结果必须分开：等待结果时不得显示“已完成”，结果无法确定时不得显示“失败”并自动重发。状态不得只靠颜色区分；减少动态效果时仍须保留对象、进度、取消与结果的辨认线索。停留蓄力的进度表现要求见 E2-2。

设计应用把状态集合定义在设计系统层面（对应 Design Token §五），而不是逐个组件设计；中止态需要一个明确的表现，"回到初始态"往往不足以让用户确认中止发生了。

验证示例

• 用户侧：让用户描述刚才发生了什么（"我选中了""它在数数""被取消了"），检查描述与实际状态是否对应。
• 实现侧：枚举状态转换矩阵，确认每种转换都有对应的呈现。

反例做不到——蓄力中和已激活看起来一样，用户不知道要不要继续看着；做过头——四种状态用四套完全不同的动画，界面在用户浏览时像在放动画片。

E4-4悬停展开可到达可关闭必须¶

一句话：新内容出现后，用户能移过去阅读、操作，也能关掉。

适用由注视展开的说明、菜单、浮层与隐藏控件。

规则展开内容必须有可发现的起点，并允许用户从触发目标移到新内容而不使其提前消失；用户阅读或操作期间必须保持可用。遮挡内容时必须提供可达的关闭方式。展开不得突然抢占当前操作目标，不得以移动文字或按钮迫使用户追着界面看。替代输入也必须能够访问同一信息，不得把注视悬停作为唯一入口。

边界条件非交互提示可在用户离开触发与展开区域后关闭；不要求所有浮层永久常驻。网页适用 WCAG 1.4.13 时仍须逐项满足该成功准则的原文条件和例外。

依据与参考W3C 对悬停或焦点产生的附加内容提出可关闭、可悬停和持续可用要求；本条将其转化为注视移入新内容时的交互检查（WCAG 1.4.13）。

设计应用触发器与展开内容组成连续可达区域；短暂移出时冻结关闭计时。关键标签保持位置稳定，减少布局跳动。

验证示例

• 用户侧：展开菜单后移眼到最后一项并选择，再通过替代输入打开和关闭菜单。
• 实现侧：检查触发区到内容区的过渡路径、遮挡处理与关闭条件，不把正常移入内容判成退出。

反例做不到——用户一看提示正文，提示就因离开图标而消失；做过头——看过一次的所有提示都常驻遮住页面。

3.5 E5 注视数据可见可控¶

前四条原则管交互，本原则管数据。它的规范对象是注视数据本身——采集了什么、推断出了什么、留了多久、去了哪里。这是眼动区别于所有传统输入通道的地方：注视及眼部数据可能支持超出当前操作的个体推断，风险取决于数据内容、粒度、关联信息与用途。其他输入轨迹也可能泄露个人特征，不能据此认为它们没有推断风险。

E5-1采集与用途披露且绑定必须¶

一句话：说清采什么、推断什么、干什么用；用途之外要重新授权。

适用所有采集注视数据的产品。

规则产品必须在用户作出授权前，以可理解的方式说明：采集哪些注视数据、据此作出哪些推断、用于什么目的、保留多久、是否离开设备。采集目的必须与实际用途绑定——将已采集的注视数据用于披露目的之外的用途，必须重新获得授权，不得以"已获得眼动追踪授权"覆盖新用途。

边界条件本条不要求把技术细节（采样率、算法）向用户披露。它要求的是用户能理解"系统会知道我什么"。

设计应用用途分项列出而不是打包成一句"用于改善体验"；把"交互所需"与"分析、推荐、监测"分开陈述，这是 E5-3 逐项授权的前提。

验证示例

• 用户侧：让用户在阅读披露后复述"系统会知道关于我的什么"，检查与实际采集范围的差距。
• 实现侧：核对实际的数据流向与披露内容；检查新增用途时是否触发了重新授权。

反例做不到——授权页只写"本应用使用眼动追踪功能"；做过头——把技术规格全文塞进授权页，用户看完仍不知道系统会知道什么。

E5-2原始注视默认不外流必须¶

一句话：应用默认拿不到注视点坐标，只拿它需要的那一层。

适用向第三方应用、插件或外部服务提供注视能力的平台与系统。

规则系统必须对注视数据的暴露粒度分级，至少区分：不暴露、区域或对象粒度、注视点坐标。默认暴露级别必须是满足功能所需的最低级别；向应用暴露注视点坐标必须经过独立于"启用眼动功能"的授权。应用请求更高粒度不构成提升默认级别的理由。

依据与参考visionOS 采取的做法是在用户点击之前不向应用提供注视位置信息，眼动数据在设备本地处理（见 reference.md §1、§5）。这个设计的价值在于它证明了大量注视交互功能不需要应用知道注视点在哪——系统层完成命中判定，只把结果交给应用。

设计应用把命中判定放在系统层而不是应用层，这是同时满足本条与 E3-2 的最直接架构；应用只收到"哪个对象被选中"。

验证示例

• 用户侧：检查用户能否得知某个应用正在以何种粒度获取注视数据。
• 实现侧：审计应用侧可获取的注视接口，确认默认级别与授权门槛。

反例做不到——启用眼动功能等于把注视点坐标流开放给所有应用；做过头——粒度限制到应用连"用户选中了哪个按钮"都拿不到，注视交互无法实现。

E5-3推断类型逐项授权必须¶

一句话：交互所需的注视，和情绪、负荷、身份推断，不得捆绑授权。

适用从注视或相关眼部数据推断注意力、兴趣或其他用户状态的产品；仅用于当前命中、悬停和渲染的信号处理不属于持久用户画像。

规则产品必须把交互所需的注视使用与从注视推断用户状态分开授权，并对推断类型逐项授权，至少区分：注意力与兴趣、认知负荷、情绪、困倦或疲劳、身份识别、健康相关迹象。对可选的分析、画像与一般眼控功能，默认必须为不启用任何推断；禁止以启用眼动交互为条件强制开启状态推断，禁止以推断的授权覆盖新增的推断类型。

受专门法规约束的监测能力另按其适用分支处理：产品须先识别具体的产品类别、法域与所适用的条款，分别定义监测、告警、记录与二次评价各自的启停权限，并如实说明哪些能力依法不可由用户关闭。该例外只覆盖经证实必须保留的能力，不得扩展到营销、情绪分析或事后考核；"这是安全功能"本身不构成豁免，须指得出具体依据。

依据与参考注视及相关眼部数据可能被用于身份或状态推断，用户对这些用途未必有预期；这属于需要评估的风险，不代表推断已经可靠。风险随表征和用途变化，不能假定去名坐标、区域事件或本地处理天然无风险（见 reference.md §5）。授权不能代替 E1-5 的有效性验证，也不能使法律禁止的用途合法化。

设计应用身份识别类推断（注视行为可用于再识别）在产品文案中单独陈述，不与"个性化"合并；健康迹象类推断需要额外评估是否触发医疗器械或健康数据的监管要求。

验证示例

• 用户侧：验证用户能否只启用注视交互而不启用任何状态推断，且交互功能不受影响。
• 实现侧：检查推断模块的启用条件是否与交互模块解耦。

反例做不到——开启眼控的同时默认开启了情绪分析，用户毫不知情；做过头——把"注视点渲染需要知道你在看哪"也做成一项需要用户勾选的推断授权，授权页有十七个开关。

E5-4采集状态可见必须¶

一句话：正在被读取，用户看得出来。

适用所有采集注视数据的产品。

规则注视数据正在被采集或被应用读取时，用户必须能够得知。指示方式可以是持续的或事件性的，但必须存在且用户可发现。禁止在无任何指示的情况下后台采集注视数据。

边界条件系统级的必要功能（如注视点渲染、无障碍导航）可以不使用持续指示，但必须在设置中可查、在能力披露中说明，且该豁免不适用于任何 E5-3 意义上的状态推断。

设计应用参照摄像头与麦克风指示器的既有心智模型；区分"系统在用"与"某个应用在用"，后者应当能追溯到具体应用。

验证示例

• 用户侧：让用户在使用中判断"现在有没有东西在读我的眼睛"，检查判断正确率。
• 实现侧：枚举所有采集路径，确认每条都有对应的指示或落在已声明的豁免内。

反例做不到——某个后台应用持续读取注视流，界面上毫无痕迹；做过头——屏幕角落常驻一个大号闪烁的眼睛图标，本身就成了注意力干扰源。

E5-5分项留存与可删除必须¶

一句话：原始注视、注视事件、校准档案、推断结论，各有各的保留期。

适用任何持久化注视相关数据的产品。

规则产品必须分别定义以下数据的保留期限并分别管理：原始注视样本、注视事件（命中、停留、激活）、校准档案、推断结论。每一类的保留条目须写明起算事件（采集时刻、事件发生时刻、档案更新时刻或其他），以及是否持久化、有界内存的处理窗口与例外引用；仅被读取不延长保留期。用户必须能够查看已保留的数据类别并请求删除；存在法定保留义务时，说明保留理由、期限与受限处理范围；删除推断结论不得由系统从保留的原始数据、副本或备份中重建；但在授权仍然有效、且用户未停用该类推断的前提下，系统按已披露规则从新采集的数据形成新的结论不属于"重建"——删除与停用是两件事，须分别提供并分别说明其效果；承诺删除时，必须同步处理该结论在下游画像、缓存、接收方副本中的实例，并说明备份的清理周期与恢复后的再删除机制。眼部图像与瞳孔指标如被采集，必须单独列为一类并单独定义保留期，不得并入校准档案。关闭注视功能不等于删除已保留数据，两者必须分别提供并分别说明。

依据与参考这四类数据的敏感度、有用期与重建能力都不同：校准档案是设备配置，注视事件是交互日志，原始样本是可用于再识别的生物行为数据，推断结论是关于人的判断。用一个保留期覆盖四类，要么过度保留原始数据，要么损失必要的配置。

设计应用原始注视样本按必要性最短保留。校准档案可独立保留，也必须支持用户主动删除或账户清除。

验证示例

• 用户侧：删除推断结论后继续使用，分别验证两件事：系统未从旧数据或其副本恢复该结论；以及在用户另行停用该类推断之后，即便有新数据也不再形成该类结论。
• 实现侧：检查四类数据的存储位置、保留期与删除路径是否分离。

反例做不到——所有眼动数据打包进一个"使用数据"桶，保留期一年；做过头——每次会话结束都清空校准档案，用户每次使用都要重新校准。

E5-6不作对用户不利的单方判断应当¶

一句话：注意力数据不悄悄变成考核、监考或风控依据。

适用注视数据可能进入对用户产生不利后果的判定链路的场景——工作场所监控、在线考试监考、学习评估、保险与信贷、内容合规。

规则由注视数据得出的注意力、专注度或状态判断，不应当在用户未被明确告知的情况下用于对该用户产生不利后果的判定。确需用于此类判定时，必须单独披露判据、误判可能性与申诉路径，并接受相应的领域合规评估（本规范不替代该评估）。适用法律禁止的用途不得因取得同意或提供申诉而开放；参见 reference.md §5.4、§5.5。

边界条件安全关键场景的实时干预不在此列——驾驶员困倦告警的目的是保护用户本人，与用于事后评价该驾驶员是两回事。即时干预不免除有效性、必要性与领域审查；其日志若被转用于考核，仍重新落入本条。法律例外需按具体条文核对，不能仅凭“安全”标签推定成立。

依据与参考欧盟 AI Act 第 5(1)(f) 条对工作场所与教育机构中的情绪推断设有禁止与特定例外；并非所有注意力或困倦指标都自动属于该条的情绪识别。具体适用范围与例外须核对实际用途，不能仅凭“安全”标签开放（见 reference.md §5.5）。

设计应用把"用于帮助用户"与"用于评价用户"在数据流上物理隔离；后者的存在本身要对用户可见。

验证示例

• 用户侧：查看一次状态判断，验证用户能发现其用途、纠正错误并找到申诉路径。
• 实现侧：追踪注视派生指标的所有消费方，确认没有一条通向对用户的评价性判定而未经披露。

反例做不到——在线考试系统用注视偏离次数直接判定作弊并取消成绩，学生不知道判据也无从申诉；做过头——因为担心合规风险，连"这段内容大多数人没看"这类聚合的产品度量也一并放弃。

3.6 E6 通道可退出且不独占¶

前五条原则假设注视通道在工作。本原则管它不工作、用不了、或不该继续用的时候：用户在什么条件下依赖这个通道，以及每种条件下的退出路径是什么。

E6-1存在等效替代路径必须¶

一句话：每项能用眼睛完成的任务，都有不用眼睛的完成方式。

适用所有提供注视交互的产品。

规则产品的每一项主要任务必须存在不依赖注视的完成路径，且该路径必须与注视路径功能等效——不得是功能缩减的路径。替代路径必须是可发现的，不得要求用户先通过注视通道找到它。

边界条件本条不适用于以眼动为唯一可用输入的专用辅助设备——对这类产品，要求"不依赖注视的路径"没有意义。但即便在这类产品中，E6-3 的降级行为要求仍然成立（追踪失效时用户如何求助）。

依据与参考设计中需要同时考虑两种可能交叉或随情境变化的处境：一类是只能用眼睛的（重度运动障碍用户，这是 COGAIN 一系工作的出发点），一类是用不了眼睛的（眼球震颤、显著斜视、部分眼镜与角膜条件、强光环境）。同一个产品需要同时容纳这两类人，这就是本条与 E6-2 必须同时存在的原因。

设计应用把替代路径当作主路径来测试，而不是当作应急出口；注视路径的快捷性可以更高，但可达功能不能更多。

验证示例

• 用户侧：禁用眼动追踪后完成全部主要任务，记录无法完成或显著更差的环节。
• 实现侧：枚举功能清单，标注每项的非注视路径入口。

反例做不到——某个设置只能通过注视菜单进入，眼动失效时用户被锁在外面；做过头——为了"等效"把注视路径削减到与键盘路径完全一致的步骤数，注视的速度优势被抹掉了。

E6-2生理与佩戴差异不构成排除必须¶

一句话：眼震、斜视、单眼、义眼、镜片、下垂眼睑，不等于用不了产品。

适用所有提供注视交互或注视相关功能的产品。

规则产品必须在设计与测试中覆盖会影响眼动追踪可用性的生理与佩戴条件，至少包括：眼球震颤、斜视与双眼视差异、单眼或义眼、上睑下垂、矫正镜片与隐形眼镜、瞳孔大小异常、深色虹膜与睫毛遮挡。对追踪不可用的用户，产品必须提供 E6-1 的替代路径且不降低其可达功能；追踪质量下降但可用的用户，产品必须提供可调整的参数（停留时长、目标尺寸、抑制窗口）而不是仅提供一组固定值。

依据与参考这一条与 E6-1 是同一枚硬币的两面。把眼动当作无障碍能力提供的产品，如果本身没有无障碍设计，会产生一个特别的失败：为无障碍而建的通道，把另一部分残障用户排除在外。

设计应用把可调参数暴露在设置中；设备支持时提供单眼校准与简化点位，不宣称软件能补足硬件不可追踪的条件。测试条件按设备机理与目标人群说明依据，不把某一种虹膜颜色或诊断标签当作必然不可用的结论。

验证示例

• 用户侧：招募覆盖上述条件的参与者进行可用性测试，而不是只用研发人员自测。
• 实现侧：检查参数可调范围是否覆盖低精度用户所需的取值。

反例做不到——校准流程要求双眼同时稳定注视，眼震用户永远通不过第一步且没有跳过入口；做过头——为了兼容把默认停留时长设到 3000 ms，所有用户都被迫使用最慢的配置。

E6-3降级行为已定义必须¶

一句话：未校准、精度不足、追踪丢失，各自的行为事先写清楚。

适用所有依赖注视的功能。

规则产品必须为以下状态分别定义并声明系统行为：从未校准、校准已过期或漂移超限、精度低于阈值、追踪暂时丢失、追踪不可用（硬件故障或权限被关闭）。每种状态的行为必须明确到激活许可、进行中进度、持续命令、替代入口、用户回执和恢复条件。质量未知、用户暂停、应用失去可交互状态也必须有确定行为；应用进入后台或被遮挡到不可交互时取消相关选择并停止持续命令，返回前台不恢复原计时。仅眼动可用时，必须预先安排失效求助路径，例如可用的独立开关、照护者入口或已授权求助机制；不得把求助按钮放在已失效的唯一通道里。禁止在未定义的状态下沿用正常态的判定逻辑。

设计应用把适用状态做成一张状态表放进设计交付物（对应 Design Token §四、§七）；每种状态的用户可见表现由 E4-1 承接。

验证示例

• 用户侧：逐一构造适用状态，验证产品行为与声明一致且用户知道自己该做什么。
• 实现侧：检查状态判定的优先级——多个状态同时成立时取最保守的行为。

反例做不到——权限被关闭后界面照常显示可注视激活的元素，用户盯着毫无反应；做过头——五种状态五套完全不同的界面，用户每次遇到都要重新学一遍。

E6-4用户可分范围关闭必须¶

一句话：能只关推断、只关激活，而不是只有全开和全关。

适用所有提供注视功能的产品。

规则产品必须允许用户按范围关闭其自身实际控制的注视功能，至少可分别关闭：注视激活（保留系统级导航与无障碍用途）、状态推断（E5-3 各项）、数据留存与上传。关闭必须即时生效，关闭后产品必须按 E6-3 的相应降级行为运行而不是失去功能。禁止把关闭入口本身置于只能通过注视到达的位置。

能力由平台托管时，产品说明其继承范围与实际可控边界，并指向平台的控制入口——不得承诺它并不具备的关闭权限，也不得以"由平台负责"回避其自身实际掌握的那部分。依法不可关闭的监测能力按 E5-3 的适用分支说明，并与可选能力分别呈现。

依据与参考iPhone 官方指南将 Eye Tracking 与 Dwell Control 分开设置，证明指点与停留激活可解耦。它不证明平台已提供本规范全部用途开关；应用的实际关闭能力须按所采用的平台接口核对（见 reference.md §1.4）。

设计应用关闭项的粒度与 E5-1 披露的用途分项对齐，用户才能把"我不想要哪件事"映射到"关哪个开关"。

验证示例

• 用户侧：让用户表达"我不想让它分析我的情绪，但眼控要留着"，观察能否在设置中完成。
• 实现侧：验证关闭后相关数据流确实停止，而不只是界面不再展示结果。

反例做不到——只有一个"眼动追踪"总开关，用户为了不被分析情绪只能放弃全部眼控功能；做过头——十七个开关分布在四个层级的设置页里，用户找不到该关哪个。

E6-5持续负荷有预算应当¶

一句话：长时间注视控制有成本，产品要认这笔账。

适用预期会被连续使用较长时间的注视交互产品。

规则产品应当为持续的注视控制定义负荷预算——连续使用时长、单任务内的停留激活次数——并在超出时改变行为：提示休息、切换到更省力的触发方式、或放宽参数。提示不应当阻断进行中的任务。产品应当避免要求用户长时间维持精确注视作为完成任务的条件。

边界条件本条针对注视作为控制通道的负荷，不针对屏幕使用时长本身（后者是更广的问题，不在本规范范围）。对以眼动为唯一通道的辅助场景，提示休息可能并不适当——此时本条转化为"提供更省力的触发方式"。

依据与参考微软 HoloLens 2 指南指出，强制用户选择过小的目标会引发眼部调节的紧张感，令人疲劳与烦躁；过长的停留时长同样被描述为"straining and unnatural"（Tobii）。这两处都把疲劳归因于设计参数而非使用时长本身——这正是产品可以负责的部分（见 reference.md §1）。

设计应用空间界面的高频目标放在舒适视野内，减少频繁大幅转眼、转头与深度切换；距离、朝向和缩放变化后仍验证可选性（reference.md §1.3）。把负荷预算与 E2-1 的档位联动——高频重复的低代价操作最值得提供更省力的替代触发；连续注视输入（如注视打字）设置自然的段落停顿。

验证示例

• 用户侧：连续使用 30 分钟后测量主观疲劳与选择错误率的变化，而不是只测首次使用的成功率。
• 实现侧：检查是否存在需要维持精确注视超过声明时长的必经流程。

反例做不到——注视输入界面没有任何停顿设计，用户连续输入十分钟后错误率翻倍且眼睛酸胀；做过头——每五分钟弹出"请休息一下眼睛"，打断正在进行的工作。

E6-6连续控制可分步完成必须¶

一句话：拖动、滚动和调值有不必持续精确注视的完成方式。

适用注视参与拖拽、滚动、滑杆调节、缩放或其他持续操作的产品。

规则主要任务必须有不依赖持续精确注视或保持按住的完成方式，例如先选对象再选目的地、步进按钮或输入数值。连续控制必须定义开始、停止、取消及追踪失效后的行为；通道切换时保留可保留的任务状态，不得自动提交尚未确认的改变。注视滚动必须让用户知道作用区域，并在离开触发区域或信号不可用时停止；恢复追踪后不得自动续跑旧命令。

边界条件表达轨迹本身不可替代的创作任务可说明限制，并提供其他可用输入；不能以“拖动是我们的交互方式”为由声称拖动必不可少。替代路径的功能范围见 E6-1。

依据与参考WCAG 2.5.7 明确列举眼控用户在拖动上的困难，并要求网页提供单指针且不拖动的路径；只有键盘替代并不充分（W3C）。本条对原生界面的延伸是本规范的设计要求。

设计应用列表排序提供“上移／下移”，滑杆旁提供数值输入；阅读区域按需要启用边缘注视滚动，密集设置列表优先保留明确滚动控件。

验证示例

• 用户侧：仅使用单次选择完成调值与移动，再在自动滚动中移开视线或关闭追踪，验证能停止并保住位置。
• 实现侧：检查失效事件是否清除持续命令；键盘、单指针与眼控路径分别验证。

反例做不到——排序只能按住并用眼睛拖到细小缝隙；做过头——为避免拖动误差，彻底取消用户熟悉的拖动能力。

---

4. 术语和定义¶

---

附录 A：分类检验与验证要点¶

A.1 分类检验¶

本规范的原则切分主张互斥且穷尽。检验方式：取一条具体要求，让不同评审者独立判断它应归属哪条原则，看是否得出相近归属。检验不通过的两种情况与处理：

• 一条要求同时合理归属两条原则——说明两条原则的规范对象有重叠，修改的是原则的定义或规则的粒度，不是增设"交叉引用层"。
• 一条要求无法归入任何原则——说明切分不穷尽，需要新增原则或扩展某条原则的规范对象。

已知的易混淆边界，供检验时参考：

A.2 故障注入验证要点¶

以下条件下逐条走查规则，是本规范建议的最低验证集：

1. 强光/暗光切换——精度退化路径（E3-2、E3-4、E6-3）
2. 佩戴位置移动（头显下滑、坐姿改变）——漂移路径（E3-4、E4-1）
3. 相机遮挡 3 秒——追踪丢失路径（E3-3、E2-2 计时、E6-3）
4. 连续使用 30 分钟——反馈过量与疲劳路径（E4-2、E6-5）
5. 注入 500 ms 语音识别时延——多模态时序（E2-3）
6. 禁用眼动追踪——替代路径完整性（E6-1、E6-3）
7. 正常眨眼 10 次、快速扫视一排目标——误触抑制（E2-4）
8. 只授权交互、不授权推断——授权解耦（E5-3、E6-4）
9. 删除推断结论后继续使用——不自动重建（E5-5）
10. 覆盖生理条件的参与者测试——排除性检验（E6-2）
11. 停留途中插入行、遮挡或替换目标——对象与操作含义绑定（E2-6）
12. 有效标记仍在但时间戳过期、未知或跨时钟错位——新鲜度与时序（E2-3、E3-3）
13. 展开菜单后移眼到其内部——内容可达与关闭（E4-4）
14. 只用单次选择完成拖动类任务，并中断自动滚动——连续控制替代（E6-6）
15. 改变亮度、制造缺失数据与切换用户——推断未知、校准档案隔离（E1-5、E3-4）
16. 无失效回调而直接停止发送样本——新鲜度看门狗停止计时（E3-3）
17. 蓄力中缩短阈值、撤权与阈值达成同时到达——不追溯激活、阻断先行（E2-1、E3-3）
18. 激活后继续看、重复事件与结果迟到——重新发起和单次提交（E2-4、E4-3）
19. 单眼失效、源切换、坐标重定位与后台恢复——质量重新验证、旧计时失效（E3-2、E6-3）
20. 输入文字时浏览别处、关闭动画与仅颜色反馈——焦点不被抢占、状态仍可辨认（E1-1、E4-3）

上述时长与次数是故障注入示例，不是设备通过测试的充分条件。

A.3 评估口径与验收记录¶

产品应当在测试前写明目标人群、设备与运行环境、任务、允许的错误后果及接受标准。下表是建议的记录模板，不规定统一通过率或样本量；测量方法参考 Dunn 等人的报告指南，交互验收口径为本规范补充。

最小验收记录可用：规则编号 → 适用／不适用及理由 → 配置快照与依据 → 用户侧结果 → 实现侧证据 → 未解决问题与替代做法。无需为每条规则创建单独文档。交互运行中的数据最小化仍按 E5 执行，评估需求不是长期收集生产原始轨迹的理由。

A.4 验收分开裁决¶

硬性失败单独判定：失效期间激活、撤权后仍提交、未经确认产生外部影响、复用进度提交新对象、重复提交、未授权推断或外流，在适用测试中出现即不通过，不能被平均成功率抵消。性能和人的门槛由项目提前设定，并报告样本量、分母和不确定性；测试中零次严重错误不证明真实使用绝无风险。

结论使用“通过／限定范围通过／不通过”，明确适用条件、未验证部分、替代路径及未解决问题。输入设备、检测方法、几何、目标人群或任务条件变化时，重验受影响的证据。不要以一份填完的参数表宣称产品已通过实测。

附录 B：数值门槛的出处与核验程度¶

正文与 Token 的数值参考均不构成跨设备阈值。外部原文中的建议强度与本规范的约束强度分开判断，完整记录见 reference.md。

停留时间仍按人群、任务、几何和设备实测选择，不提供通用默认值。

附录 C：选择尝试的状态与事实契约¶

本附录具体化 E2、E3、E4、E6 的行为要求，供设计、工程与测试共同使用。平台托管的部分可以引用平台保证，不要求应用复制平台内部实现。状态名是语义，不是必须向用户显示的术语。

C.1 四类状态分别记录¶

权限、追踪质量和结果各有自己的状态，不能用一个“加载中”同时掩盖。用户通常只需看到当下最有用的反馈，例如“已暂停，可使用按键”“正在保存”“暂无法确认是否保存成功”。

C.2 停留状态转移¶

判定顺序为：关闭／撤权／对象失效／场景不可交互 → 信号有效性与新鲜度 → 质量与候选歧义 → 激活条件 → 请求去重 → 结果回执。反馈动画完成不参与授权和完成判定。

C.3 时间如何累计¶

时间窗口采用半开区间：中断时长小于窗口时允许保留，达到窗口即结束；0 表示立即取消。有效停留达到所需时长即可进入提交检查。精度误差则按声明的统计口径比较，不能套用时间窗口的规则。

• fixation.min_duration 是候选成立判据，dwell.duration 是激活计时。自定义实现须声明停留从候选成立后开始，还是包含已经核实的候选判定区间；两者不得被无意相加或重复累计。推荐从候选成立后计时，平台托管时按其事件语义验证。
• 有效时间依据单调时钟与已验证的样本覆盖区间累计，不能按渲染帧数、回调次数或标称采样率计算。两次样本之间的最大可计时间须有已验证上限，长缺口不得整段计入。
• 有效离开、短断保留和持续失效提示分别计时。进入冻结后按最初中断时刻计算上限，不能用重复无效样本不断延长。
• 仅重新收到有效样本不足以证明中间一直在看同一目标；已清零的尝试从头开始。连续控制的命令一旦停止，必须重新发起。

C.4 最小运行事实¶

一次尝试需要能核对：尝试标识、输入来源、发起和样本时间语义、候选对象与动作快照、当时配置、质量依据、有效累计时长、冻结或取消原因、提交标识与真实结果。自定义空间命中另记录坐标空间及场景关联；平台托管时只保留应用可取得的事件和契约引用。

这些是机制验证所需的事实，不是长期收集眼部原始数据的许可。原始轨迹可在授权测试环境中回放；生产记录应尽量使用最小离散事件并按 E5 约束留存。

---

实施验收场景¶

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

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