注视负责指向，另一模态负责提交
别名: MAGIC pointing · 注视加确认 · gaze pointing
概念解释
注视加确认把两件本来缠在一起的事拆开：注视只负责指出对象（移动光标、设置焦点、预览），提交交给另一条模态——鼠标键、触控板轻点、控制器扳机、捏合、空格、语音口令。Zhai、Morimoto 与 Ihde 的 MAGIC pointing 是这条分工的早期形态：注视把指针瞬移到附近，精细瞄准和点击仍由手完成。它不是停留选择（提交仍由时间积分完成），也不是看即选（提交仍由看完成）。
机制
眼睛擅长把中央凹迅速对准感兴趣的对象，不擅长声明“我要对这个对象负责”——后一句需要一个不容易被浏览污染的开关。手、指和声带提供的开关，其静息态是“关”：不按、不捏、不说，命令就不发。注视的静息态是“开”：一直在看。组合利用了这个不对称：用快的通道做指向，用默认关闭的通道做提交。
分工还改变误差的去向。注视的空间误差只影响焦点落在哪一块，提交动作可以在落点附近做小修正（MAGIC 的手部微调），也可以完全信任落点（某些 VR 里注视对准、手指捏合）。无论哪一种，假阳性从“看错了”变成“看对了但没按”，浏览被释放。
怎么研究
对照纯注视停留、纯手动指向、以及注视指向加手动提交，在二维获取、菜单选择和 VR 对象拾取上测时间、错误和主观迈达斯感。 自变量包括确认器类型（键、捏合、语音）、注视是否瞬移光标、是否允许手部微调。 MAGIC pointing 原论文用的就是这种对照。需要分开报“指向时间”和“提交时间”，否则组合看起来只是“差不多一样快”。还要记录确认器是否把注视拽离目标——那是另一条知识，但实验设计必须让它有机会出现，否则组合的真实代价测不到。
边界
没有第二条可用模态时，组合不成立：高位瘫痪且不能发声的使用者仍可能只能停留。第二条模态若延迟很高（云端语音）或识别很吵（嘈杂里的口令），提交会比指向还慢，组合的优势被吃掉。某些文化或场合不能出声、不能抬手，确认器的社会可接受性会否决技术上更快的方案。校准极差时，注视指向会落在错误对象上，再干净的提交也在提交错误对象。
怎么落地
- 默认让注视移动焦点或预览，用一条默认关闭的模态提交；不要把两者绑在同一次注视上。
- 在有手部微调的设备上，允许提交前对落点做小修正；在只靠捏合的头显上，把目标做得足够大以吸收注视误差。
- 验证：比较“只看”“只手”“看加确认”三条路径的完成时间与误提交，并确认浏览标签时不会发出命令。