多模态融合交互设计规范

面向设计师与工程师：当一次输入或一次输出由两个以上通道共同构成时，让"这个"指得准、让等待有边界、让冲突可裁决可撤销、让同一个意图只被执行一次，并且在某个通道用不了的时候任务仍然做得完。

多模态融合把多个通道的片段组成一次输入，或把一次输出分配给多个通道。例如“把这个移到这里”：语言给出动作，指点给出对象和目标位置。识别各路信号正确，仍可能发生对象绑错、抢先提交、重复执行或反馈相互矛盾。因此，设计对象是从表达、组合、提交到反馈与恢复的完整过程。

本规范由六条原则、34 条规则组成。每条规则说明适用条件、行为要求、设计应用、用户侧与实现侧验证，以及“做不到／做过头”两侧反例。评审时回答三个问题：设计师决定什么，工程提供什么事实，用户怎样知道并改变结果。

多通道是用户按任务选择的表达方式，不是必须采用的入口。先指后说、边说边指和中途换成触摸都需要明确处理；一次输入不以各路信号同时到达为前提。历史研究中的使用比例和时间间隔仅适用于其样本，不作为其他设备、人群或任务的默认值（R03、R04）。

适用范围：两个及以上通道共同构成输入、共同触发操作，或参与同一次输出。只有多种独立入口、但不存在组合、冲突、重复接收或组合输出的产品，可记录不适用。本文不指定识别算法、融合层级、传感器或通用时间阈值；无障碍、隐私与安全关键领域仍需针对实际产品专项验证。

阅读顺序：第 1 章原则；第 2 章规则读法与速查；第 3 章完整要求；第 4 章术语与运行事实。附录 A 提供验收场景，附录 B 说明论据边界，附录 C 提供时间参数测定方法。配置查 Design Token，来源查 reference.md。

---

1. 六条原则¶

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

同一个场景可以触及多条原则——用户看着一张卡片说"把这个删掉"，系统同时面对指代绑到哪张卡（MM1-1）、语音比注视晚到该等多久（MM2-2）、注视落在 A 而语音里说了 B 的名字时谁赢（MM3-1）、语音识别和手势识别各产生一次删除意图会不会删两次（MM4-1）、以及删除结果该用哪个通道回执（MM6-1）——这不是分类错误：五条规则约束的是五个不同规范对象上的义务，一个是绑定关系，一个是时间组合，一个是内容冲突，一个是执行次数，一个是输出分配。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证。检验不过，修改的是原则的切分。

本切分中最需要持续检验的两处边界，在此明示：MM2 与 MM4——MM2 管"等不等第二个通道、等多久"，MM4 管"两个通道都到齐之后执行几次"。融合窗口内的第二个信号既是 MM2 的等待对象，也是 MM4 的去重输入，看起来是同一个机制；归属依据是义务的直接规范对象——"窗口关闭前不得抢先执行"约束的是时间组合，归 MM2；"关闭后不得把已融合的意图再执行一次"约束的是执行次数，归 MM4。MM3 与 MM5——通道给出不同内容是 MM3，通道给不出内容是 MM5。实践中两者会连在一起（某通道置信极低，既像冲突又像不可用），归属依据是系统实际做了什么：在两个内容之间选一个是裁决，把一个通道从组合中拿掉是降级。这两处若在实践中反复出现归属争议，应当调整原则而不是增设中间层。

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

规则归属唯一，不等于机制不能复用。一份带时间戳的信号缓冲既是融合窗口的实现基础（MM2-1）、冲突检出的比对来源（MM3-1），也是去重判据的输入（MM4-2）；一套通道健康状态既决定降级路径（MM5-2），也决定输出通道的选择（MM6-1）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

2. 规则的读法¶

2.1 每条规则的结构¶

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

规则写行为性质、不写实现方式：融合窗口关闭前不执行看起来完整的单通道指令，这是产品行为；用缓冲队列、状态机还是延迟提交实现，是工程方案——两者必须对得上，但不是同一份交付物。本规范同样不规定融合发生在哪一层：信号级、特征级与语义级融合都可能满足这些要求，选哪一层是工程决定（三层的差别见 R07）。

2.2 约束词¶

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

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

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束（MM1-6、MM2-5、MM2-6、MM4-5、MM5-5、MM6-2、MM6-5、MM6-6 含此类子句），规则标题与速查表的强度标注不替代子句约束力。正文中的「不能」仅用于能力或事实陈述，不表达义务。

强度表示约束力，不表示重要性。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而把每次融合都变成一轮确认对话。多模态融合被做坏的方式在两端都很密集：一端是绑错了对象还照做、两个通道各执行一次；另一端是因为怕绑错而在每句"把这个移到这里"之后都弹出"您指的是哪一个？"的候选列表——那样用户不如自己点两下，多通道带来的表达效率被确认成本吃光。已有记录显示多通道在视觉—空间任务上带来的任务完成时间收益是有限量级的（R04），把它整个抵消掉并不需要多少额外确认。谨慎不等于把判断全部推给用户。

2.4 规则速查：34 条¶

下表是全部规则的一句话记忆版，点击规则名可跳到第 3 章的完整正文。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句（MM1-6、MM2-5、MM2-6、MM4-5、MM5-5、MM6-2、MM6-5、MM6-6），判定以正文为准（见 2.2）。

MM1 指代解析到对象

MM2 融合窗口有边界

MM3 冲突可裁决可撤销

MM4 一个意图执行一次

MM5 少一个通道仍能完成

MM6 输出按通道分工

3. 规则详解¶

本章按六条原则展开全部 34 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一组件，也不要求新增独立交付文档。

3.1 MM1 指代解析到对象¶

跨通道指代是这个领域的起点问题："这个""这里""那个蓝色的"本身不携带足够信息，它的所指要由另一个通道补上。这条原则管的是这个补全过程：什么时候算补全成功、补不成功怎么办、补上之后到执行之间发生变化怎么办、以及补全的结果要不要给人看。指代解析的失败与语音识别的失败是两件事：语音可以一字不差，指代仍然绑错——本原则约束的是对象对应关系，识别准确率不能替代绑定正确率。

MM1-1指代解析到具体对象才执行必须¶

一句话："这个"没指出是哪个之前，不要动手。

适用接受跨通道指代表达（指示代词、方位词或省略了宾语的指令）并据此执行操作的系统。

规则含跨通道指代的指令，必须在指代解析到明确的对象或位置之后才进入执行。解析结果必须是一个可被系统指名的具体对象或坐标，不得以"当前上下文中最可能的一项"这类未收敛的描述进入执行。解析失败、候选多于一个且无法区分、或候选集合为空时，禁止执行，按 MM1-2 处置。指代所需的补全信息来自哪个通道由产品定义，但任何单一通道都不必然拥有解析权——注视落点、指向射线、触点与上文提及都可能是候选来源，选用哪些须显式声明（见 mm.binding.sources）。

组合输入的片段必须关联到已声明的交互主体或参与范围。共享场景中跨主体的组合须有明确的角色规则（谁可以为谁补全、哪些角色的表达可以合并），禁止仅因时间接近就把不同主体的片段拼成一条指令——甲说"移动这个"、乙指了另一个对象，即使时间与语义都相容，也不是甲的完整指令。主体归属无法确定时，不执行依赖该组合的动作，保留各路已有效表达的部分，并给出重新指定的路径。

候选与操作意图分开：看向、经过、系统播放的声音或被读取的画面文字可以是候选依据，不自动成为激活、确认或授权。产品必须声明何种明确动作开始输入、何种动作提交；仅增加一个被动通道不得提高执行权限。系统自身输出再次进入麦克风或摄像头时，须按来源排除自触发；无法区分来源时停止受影响提交并提供直接输入路径。

边界条件本条不要求系统支持所有类型的指代表达，也不要求解析必须成功；它要求的是"未解析到具体对象时不执行"。本条不要求识别或建档在场的其他人——归属可由会话、设备绑定、显式角色或结构隔离取得；通过识别所有旁观者来满足归属要求不是合格实现。单用户且结构上保证隔离的产品可记录依据后简化。不含指代的完整单通道指令不受本条约束。系统对候选对象的排序机制不在本条要求范围内，排序的可解释性见 MM1-6。

设计应用把"解析成功"设计成执行的前置状态而非执行过程中的一步，这样失败会停在解析而不是停在半个操作里。把"候选唯一"和"候选置信最高"分开表达——后者不是前者。

验证示例

• 用户侧：在两个相邻且外观相似的对象之间说"把这个删掉"，观察系统是执行还是要求区分。
• 实现侧：检查执行入口是否接受未解析的指代占位符；构造空候选集合，确认不落到默认对象。

反例做不到——注视落在两个卡片的交界处，系统按 Z 序挑了上面那张就删了；做过头——所有含"这个"的指令一律要求用户先点选对象，多通道表达退化为"先点后说"，指代能力实际上没有被用上。

依据与参考跨通道指代解析是本领域最早被提出的问题形态（R01）；在三维环境中把指代候选做成带时间戳的对象命中统计并据此排序，是已有实现路径（R08）。

MM1-2解析不成立时回退显式选择必须¶

一句话：猜不出来就让人自己选，不要挑一个最像的。

适用跨通道指代解析可能失败的系统。

规则指代解析不成立时，系统必须回退到显式选择路径——列出候选、请求重新指定，或提示改用不含指代的表述——并禁止以下三种处理：按内部排序静默选取一项执行；把指令整体丢弃且不给出任何反馈；把未解析的指代当作"上一次操作的对象"沿用。回退路径必须能在当前通道条件下走完：若解析失败的原因正是某通道不可用，回退不得要求使用同一通道（见 MM5-1）。候选列表的呈现须保留用户已经表达的部分，不要求用户重述整条指令。

边界条件本条不禁止系统给出带排序的候选建议；它禁止的是把建议直接当成结论执行。未解析到具体对象时不得进入执行，不设"可撤销即可先执行"的例外——MM1-1 的固定底线在此没有分支。产品可以呈现显著标记的暂定预览：它不写入业务状态、不外发、可被丢弃，且不得显示为已完成；用户选定候选后才进入执行。候选集合为空时连预览也不成立——不存在可被预览的对象。

设计应用候选列表用用户能认出的属性排序与标注（位置、名称、最近一次改动），不要用内部 ID 或置信度分值；把"重新指一次"和"从列表里选"做成两条并行入口，前者留给还能用指点通道的人。

验证示例

• 用户侧：在候选歧义场景下，观察系统是否给出可操作的下一步而不是沉默或直接执行。
• 实现侧：注入空候选集与多候选等分场景，确认不落到默认项；检查回退路径是否依赖已失效的通道。

反例做不到——识别不出指哪个，就按最近一次操作过的对象执行；做过头——候选有两个，系统弹出包含全部 40 个可见对象的完整列表让用户翻找。

依据与参考本条属于附录 B 的"从承诺反推"类：系统既然承诺理解"这个"，就必须在理解不了时把控制权交回，而不是用一个未经确认的猜测替代理解。

MM1-3多个指代项按语义角色对位必须¶

一句话："把这个放到那儿"是两个位置，不能串。

适用单条指令中含两个及以上跨通道指代项的系统。

规则一条指令含多个指代项时，每个指代槽位必须绑定到具有明确角色的对象、对象集合或位置（源、目标、参数等）。配对依据是已声明的语义角色、事件时间与有效上下文三者；禁止仅按信号到达顺序配对，也禁止仅以表述顺序作为唯一依据——语言中的槽位顺序标识的是槽位，不能独自决定逆序到达的两个指点分别填哪一个槽。

原始的采样事件、手势片段与语义候选不是同一计数单位：系统必须先按已声明的规则把原始事件归并为语义候选（一次持续指点的多帧是一个候选，同一对象被重复指仍是同一候选，一次圈选可以是一个对象集合候选），再比较候选与槽位。禁止把原始事件数与槽位数直接相比并据此整体拒绝。无法唯一确定某个槽位的角色、或该槽位缺项时，只就受影响的槽位发起澄清，其余已确定的绑定保留。系统必须能表达"第一个指代已绑定、第二个尚未绑定"的中间状态，并允许用户只补全缺失的那一项。产品支持的单数与复数指代范围须在能力披露中说明。

边界条件本条不要求用户按任何特定顺序提供指点事件——事件到达顺序可以与表述顺序不同。本条也不承诺在完全没有角色线索时自动配对成功：两个无任何角色证据的指点，正确处置是澄清而不是猜测。语言本身允许的语序变化（例如把方位词前置）由产品的语言解析处理，不在本条范围内。

设计应用把指代项建模为带序号的槽位，把指点事件建模为带时间戳的候选池，配对是一次显式匹配而不是逐个弹栈。槽位数与事件数不等时，缺口要指得出来是哪个槽位。

验证示例

• 用户侧：说"把这个移到这里"，先指目标位置再指源对象，在存在角色证据（对象类型、可放置性、上下文）时应正确绑定而不互换；再构造两个完全无角色线索的指点，检查系统是否发起澄清而不是猜测。
• 实现侧：构造两个指代项、三个原始指点事件（其中两帧属于同一次持续指点）的输入，确认系统先归并为语义候选再配对，不因原始事件数不等而整体拒绝，也不自行丢弃事件凑数。

反例做不到——用户先指了要放的位置再指了对象，系统把对象移到了它自己原来的位置上；做过头——要求用户严格"说一个词、指一下"地交替输入，任何提前的指点都被丢弃；或因为一次持续指点产生了多帧事件、事件数与槽位数不等，就把整条合理指令判为失败。

MM1-4绑定在执行时点重新校验必须¶

一句话：从指到做之间东西变了，绑定就不算数了。

适用指代绑定的产生时点与操作执行时点之间可能存在间隔，且对象状态可能在此期间变化的系统。

规则绑定产生之后、操作执行之前，系统必须重新校验被绑定对象仍然存在、仍然可操作，且其身份未被替换；校验同时覆盖主体、目标身份、内容快照与本次交互。到达顺序可以影响等待策略，但不替代事件发生时点与主体归属；迟到片段只在声明的窗口与版本仍然有效时参与本次绑定。校验不通过时禁止在替代对象上执行，须按 MM1-2 回退。对象内容发生变化但身份未变时，是否仍然执行由产品定义并向用户表达，不得默认按旧内容执行。列表、地图或时间线等位置随时刷新的容器中，绑定必须锚定到对象身份而非屏幕坐标或列表序号。

边界条件本条不要求系统冻结界面或阻止后台更新；它要求的是执行前的校验与校验失败后的处置。绑定与执行在同一帧内完成、期间不可能发生变化的场景，记录"结构上不可能"即满足本条。增加被动通道不自动扩大执行资格。

设计应用绑定记录里存对象标识与观测时间，不存屏幕位置；把"对象已不在"与"对象变了"设计成两种可分别处置的结果，前者必须停，后者可以问。

验证示例

• 用户侧：说出指令的同时让列表刷新一位，观察操作落在哪个对象上。
• 实现侧：在绑定与执行之间注入删除、移动与内容变更三类变化，分别检查处置。

反例做不到——用户注视第三行说"删掉"，语音处理完成时列表插入了新项，系统删了新的第三行；做过头——只要界面有任何刷新就作废绑定，在实时数据界面上多通道指令永远无法完成。

MM1-5高代价操作的绑定结果执行前可见必须¶

一句话：删之前先说清楚删的是哪一个。

适用跨通道指代绑定的结果将用于不可逆、涉及他人或代价显著的操作的系统。

规则当被绑定对象将承受不可逆操作、外发操作或按产品风险分级属于高代价的操作时，系统必须在执行前把解析结果本身呈现给用户——即"这个＝哪一个""这里＝哪儿"——而不只是呈现操作名称。呈现必须使用用户可辨认的标识，且必须与实际将被操作的对象一致。确认必须同时绑定具体对象、动作、关键参数与后果；这些内容变化后，原确认不再覆盖新的请求。未作确认不视为同意。禁止以"已理解您的指令"这类不含所指的表述替代呈现。

边界条件本条不为所有多通道操作引入确认步骤，只针对高代价一档；风险分级必须考虑可逆性、外部影响、对象数量与纠错成本；后果未知按高代价处理。可完全撤销且撤销入口在结果处直接可达的操作，可按产品定义归入低代价一档。

设计应用把"操作确认"与"指代确认"合成同一次呈现，不做成两跳；在确认里给出对象的可见特征而不是内部标识。

验证示例

• 用户侧：对一个高代价操作发出含指代的指令，检查确认信息里能否看出对象是哪一个。
• 实现侧：核对确认时呈现的对象与执行时实际操作的对象是同一个标识，中间不允许再解析一次。

反例做不到——"确定要删除吗？"点了确定才发现删的是相邻那一个；做过头——每次移动一个图标都要先确认"您指的是图标 A 吗"，连续布局操作变成逐项审批。

MM1-6绑定的依据与失败侧可被说明应当¶

一句话：是没听清还是没看清，要分得出来。

适用指代解析可能因不同通道的不同原因失败的系统。

规则系统应当能说明一次绑定用了哪些通道的什么信息，以及绑定失败时失败发生在哪一侧——语言侧没有产生可解析的指代项、指点侧没有产生可用的候选、还是两侧都有但无法配对。面向用户的说明应当用可行动的语言给出下一步（"再指一次"与"换个说法"是不同的下一步）；面向实现的记录应当保留必要的时间锚点、候选摘要与选中依据，以便复核；原始音视频、眼动轨迹不因可解释性要求而默认留存。禁止用一句统一的失败文案掩盖不同的失败原因，也禁止把内部置信度分值直接作为对用户的解释。

边界条件本条不要求向用户展示完整的候选排序过程，也不要求实时解释每一次成功的绑定；成功时的说明按需提供即可。

设计应用把失败原因分成"语言侧""指点侧""配对侧"三类并各自对应一句可操作提示；内部记录与用户提示分开设计，前者详尽，后者简短。

验证示例

• 用户侧：分别在麦克风被遮挡与手离开跟踪范围两种情况下发出同一条指令，观察提示是否不同。
• 实现侧：抽查失败样本，确认记录中能还原出各通道的输入与选中依据。

反例做不到——任何绑定失败都提示"没有理解您的指令"，用户不知道该重指还是重说；做过头——失败时向用户展示候选对象的置信度排行榜和时间戳表格。

3.2 MM2 融合窗口有边界¶

融合需要等待：一个通道的信号到了，另一个可能还在路上。这条原则管的是这段等待——窗口什么时候开、开多久、关的时候做什么、以及等待本身对用户意味着什么。已有实证记录表明不能假定信号在时间上重叠：语音与笔输入在约一半的情况下是顺序整合，笔输入先于语音，中间有一到两秒的间隔；而按用户区分，存在同时整合与顺序整合两类稳定的个体模式，后者的先后间隔可达数秒（R04）。本原则不给出任何通用的窗长数值——那是产品按附录 C 测定并记录的结果。

MM2-1融合窗口显式定义并可核验必须¶

一句话：窗口开多久是产品做过的决定，不是代码里的一个常数。

适用把来自两个及以上通道的信号组合为一次输入的系统。

规则融合窗口必须解析到一份窗口合同，其中至少包含：事件时间锚点（以信号的发生时间而非系统接收时间测量间隔，并声明取信号的起点还是终点）、接收时间的用途（只用于超时与调度，不用于测量人的表达间隔）、可接受的到达延迟与时钟不确定的处置、完成所需的通道集合、开启条件、可提前关闭的条件、最长截止、关闭后的处理，以及关窗后迟到事件的处置。"可早关的条件""最长收集期限""开始给出等待提示的时刻"是三个分别决定的量，不得合并为一个数值（后者见 MM2-3）。

三路及以上的融合另须声明全局完成判据：两两通道相容不蕴含整体解释相容，缺少全局判据时不得按"已配对的两路"提交。窗口合同必须可查询并可复核（见 mm.fusion.window.contract）。窗长必须有依据：由产品按目标人群与任务实测并记录，或引用已声明适用范围的公开结果；禁止使用没有来源的通用数值，也禁止把窗长写成不可查的实现细节。窗口定义必须说明它适用于哪些通道组合——每种组合都须有测定依据；经验证相同的取值可以复用，不能未经测量直接通用。已知的人群差异（语言、年龄、运动能力）与交互差异（首次使用与熟练使用）若在测定中出现，须在定义中声明适用范围。

连续跟踪流必须定义采样片段的归并、候选有效期和空间参照：坐标绑定到哪个界面、视口或空间锚点。坐标变换不可用、时钟误差超出已声明容差或候选过期时，不强行融合。后续帧不得无限续开同一窗口；迟到片段不得重新打开已经提交或取消的交互，也不得仅因迟到便自动成为新的操作。

边界条件本条不规定窗长的具体数值、时钟容差或延迟上限，也不要求窗长固定不变；按情境或按用户自适应的窗口同样满足本条，只要自适应规则本身被定义并可核验。窗口关闭意味着融合终止，不意味着任务终止——关窗后用户仍可澄清或补全，那是一条新的输入而不是原窗口的延续。一次交互所用的窗口配置快照随该次运行事实记录；一般策略变更从下一个窗口起生效，撤权与关闭立即阻止受影响的未提交行为。

设计应用把窗口参数放在可查的配置里而不是散落在各处的超时常量；对每个通道组合分别记录一组参数与其测定依据。窗口过短会漏掉顺序整合的用户，过长会把两条独立指令粘成一条——两侧都要在测定中被检查。

验证示例

• 实现侧：调取窗口参数及其测定记录，确认覆盖了产品实际支持的每个通道组合。
• 用户侧：在实测样本中检查窗口两端的错误率，确认取值不是只优化了一侧。

反例做不到——融合窗口是某次调试时随手定的一个毫秒常量，无人知道依据；做过头——为每个用户每个会话动态调参，窗口行为不可复现，故障无法归因。

依据与参考已有系统按经验数据设定时间约束来许可融合，其记录的模式是语音倾向于跟随手势、反向很少见（R03、R02）；个体整合模式在首次交互时确立并在会话中保持稳定（R04）。附录 C 给出测定方法。

MM2-2窗口关闭前不抢先执行必须¶

一句话：看起来完整的半句话，等等第二个通道再说。

适用存在输入融合、流式识别或由组合输入触发执行的系统。

规则当一个通道产生了在语义上完整、可独立执行的指令，而该指令同时可能是一次多通道输入的组成部分时，系统在融合窗口关闭之前禁止执行它，也禁止产生该执行的任何外部可见副作用。窗口关闭后，若另一通道未提供可融合的信号，则按单通道解释处理（见 MM2-3）。本条约束的是执行与副作用，不约束预处理、候选生成与界面预览——这些可以在窗口内进行，但必须是可无痕撤回的。

流式输入：中间转写、尚未结束的手势和预测落点只能更新候选或预览。产品必须定义“输入已完成”的依据；收齐通道不等于解释已稳定。用户说“不是 A，是 B”或识别器修正同一段输入时，只替换受影响槽位并重新校验，旧候选不得再提交，修正不得被当作新的重复操作（见 mm.fusion.revision.policy）。

停止与取消：必须存在无需补齐普通融合输入即可到达的控制路径，优先拦截尚未提交的动作。控制回执分别说明“已收到”与“已生效”；已提交部分核对真实结果，不能只因识别到“取消”就显示“已撤销”。暂停播报、取消本次输入、停止任务和撤销已执行结果须有不同语义；恢复必须由明确的继续动作触发，迟到识别或通道重新上线不自动恢复（见 mm.fusion.control.policy）。

边界条件当产品已声明某通道组合下不会出现跨通道补全（例如该界面上没有任何可指代对象），可不开窗直接执行，此判断须可核验而不是由实现顺手决定。停止与取消按本条的控制要求优先处理，不等待普通融合窗口。

设计应用把"可执行"和"已提交"分开：窗口内到达可执行状态，窗口关闭才提交。给窗口内的等待一个轻量、非阻塞的可见表现，让用户知道系统在等而不是卡住（与 MM2-5 配合）。

验证示例

• 用户侧：先说出一条完整指令，随即在窗口内补一个指点动作，观察是执行了两次还是一次融合结果。
• 实现侧：检查执行入口是否在窗口关闭事件之后被调用；确认窗口内不产生网络写入或状态变更。

反例做不到——用户说"删除"然后指向对象，系统在听完"删除"时就删了当前选中项；做过头——所有单通道指令都被无条件延迟等待第二通道，纯语音操作整体变慢，且这个延迟不可关闭。

依据与参考已有系统明确记录了这一处理：融合器在收到看起来完整的单通道指令时不立即执行，以防随后到达的另一通道信号构成多通道解释；若窗口内没有等到，则送出最佳的单通道解释（R03）。本条是该实现模式的行为化表述，不指定实现。

MM2-3等待有上限且结果明确必须¶

一句话：等不到就按单通道解释办或明确失败，不悬着。

适用存在融合等待的系统。

规则融合等待必须有上限。窗口关闭时，系统必须结束本次收集并产生明确的融合结果：完整解释进入提交前校验，缺项或冲突进入待澄清，或明确拒绝／取消。只有完整、无冲突且满足提交条件的单通道解释才可执行；禁止停留在既未执行也未反馈的静默状态。等待期间超过产品定义的可感知时长时，必须给出正在等待的可见或可感表现。最长等待上限、可提前关闭的条件与开始给出等待提示的时刻是三个分别决定的量——等待提示的时刻约束的是用户感知，窗口的最长截止约束的是融合逻辑，早关条件决定它可能更早结束；产品若令其中任意两者相等须是显式决定。

边界条件本条不要求等待上限对所有通道组合相同，也不禁止在用户显式表示"还没说完"时延长等待；延长须由用户行为触发并可被观察，不得由系统自行续期。

设计应用把"窗口关闭"做成一个必然发生的事件而不是一个可能不发生的条件；对每条路径都写出收集结论与后续任务状态，包括"两个通道都没给出可用结果"这一条。

验证示例

• 用户侧：只提供半条多通道指令然后停止动作，观察系统是否在声明期限内说明缺项、保留已有内容并给出补全或取消入口。
• 实现侧：注入第二通道信号永不到达的情况，确认窗口按时关闭且产生融合结果与下一步，无悬挂请求。

反例做不到——用户说"把这个"然后没有指点，系统既不提示也不放弃，界面停在原样；做过头——等待上限压到远短于实测的顺序整合间隔，先指后说的用户几乎无法完成任何多通道指令。

MM2-4顺序整合与同时整合都要支持必须¶

一句话：有人先指后说，有人边说边指，两种都是正常用法。

适用支持跨通道指代或跨通道补全的系统。

规则融合逻辑必须同时接受时间上重叠与时间上先后两种通道到达模式，禁止把"信号重叠"作为构成一次多通道输入的必要条件。通道之间的先后顺序不得被固定为唯一合法顺序——产品可以声明它支持哪些顺序，但不得以"用户应当同时进行"为由拒绝处理常见的顺序输入。本条不要求支持任意长的间隔：可接受的间隔上限由 MM2-1 的窗口定义给出，本条要求的是间隔本身不是错误。

边界条件本条不要求支持所有通道对的所有顺序；若某一顺序在实测中不出现或产品明确不支持，须在能力披露中说明，而不是在运行时静默丢弃。

设计应用融合器不要以"当前正在接收语音"为前提去等指点，也不要反过来；把两侧都建模为可先可后的事件流。窗口的起点应当能由任一通道的信号触发。

验证示例

• 用户侧：分别以"先指后说""边说边指""先说后指"三种方式发出同一条指令，比较结果是否一致。
• 实现侧：检查融合条件中是否含有时间区间必须相交的硬性判断。

反例做不到——只有在语音时间区间与指点时间区间相交时才融合，先指两秒再开口的用户永远得不到融合结果；做过头——为容纳所有顺序把窗口开到很长，两条不相关的指令被粘成一条。

依据与参考已有实证记录显示多通道输入约有一半是顺序整合，且笔输入先于语音的比例极高，间隔在一到两秒量级；同一记录还区分出同时整合与顺序整合两类用户，个体模式稳定（R04）。另有记录指出，包含与指点重叠的口语指示词的指令只占少数（R04），"重叠即融合"的假设会漏掉大部分情况。

MM2-5窗口内外的同一动作语义不同且可感知应当¶

一句话：这一指是补上一句还是新的一句，人要看得出来。

适用同一动作在融合窗口内与窗口外具有不同语义的系统。

规则当同一个通道动作在窗口内被解释为"补全上一条指令"、在窗口外被解释为"发起新指令"时，系统应当让当前处于哪种状态是可感知的，且状态表现要在动作发生之前就可获得，而不是事后才由结果揭示。窗口开启与关闭这两个时刻应当有可感表现（视觉、听觉或触觉均可，选择见 MM6-5）。禁止让用户只能通过观察执行结果来推断刚才是否还在窗口内。窗口状态的表现应当轻量，不遮挡内容也不要求用户为它分配注意力。

边界条件本条不要求把窗口剩余时间量化展示；只要求"在窗口内"这一事实可被感知。当窗口内外语义完全相同（补全与新指令导致同一结果）时，本条不适用，记录"不适用"即可。

设计应用用一处持续的轻量状态而不是一次瞬时提示表达"正在等待补全"；窗口关闭时给一个明确的结束表现，避免用户在关闭之后继续做补全动作。

验证示例

• 用户侧：在窗口即将关闭时做出指点动作，询问用户预期该动作属于上一条还是新一条，比较与系统实际处理是否一致。
• 实现侧：确认窗口开闭事件都有对应的输出，且交互状态与呈现同步更新；呈现未准备好时不开放依赖新语义的入口。

反例做不到——用户以为还在补上一句，系统已经关窗并把这一指当成了新指令；做过头——窗口状态用一个占据屏幕中央的倒计时环表达，每次多通道输入都伴随一次显著动画。

MM2-6不为提高融合率延长窗口应当¶

一句话：延长窗口时，漏融合与误绑定都要测。

适用以融合成功率作为优化目标之一的系统。

规则融合窗口的取值应当由 MM2-1 所述的测定依据决定，禁止仅以提高融合率、降低"未融合"计数或改善某项聚合指标为由延长窗口。窗口变更应当同时记录其对误绑率的影响——延长窗口在提高融合率的同时会把更多无关信号纳入候选，两者必须一并评估。融合率本身不应当作为该能力做对了的验收指标；验收应当采用与任务结果相关的指标（见 mm.evidence.success.metrics）。

边界条件本条不禁止调整窗口，也不禁止在实测支持下延长；它禁止的是把融合率单独作为调整理由。

设计应用把融合率与误绑率作为一对必须同时报告的量，任何一次窗口调整的记录里两者都要出现。

验证示例

• 用户侧：在相同任务上比较候选窗长，确认先指后说的成功率改善没有以误绑、等待或多余确认为代价。
• 实现侧：调取窗口的参数调整依据，检查每次调整是否附有两侧影响的评估。

反例做不到——为了让"多通道使用率"这项指标好看，把窗口从实测值翻倍；做过头——窗口一经确定就再不允许调整，实测已显示取值不适用于新增的通道组合也不改。

3.3 MM3 冲突可裁决可撤销¶

两个通道给出不相容的内容，这是融合的常态而不是异常：注视落在 A 而语音提到 B，手势指向左而语音说"往右"。这条原则管的是这种不一致被怎么处理——先要被发现，再按事先定好的规则裁，裁完要说出来，而且要能改回去。本原则管内容不一致，不管通道缺失：通道给不出内容时按 MM5 处理。已有实现把跨通道的相互印证当作纠错手段（一个通道的语义信息可以帮助另一个通道从识别错误中恢复），这条原则的另一面正是：相互印证成立的前提是不一致会被发现（R04、R08）。

MM3-1冲突必须被检出必须¶

一句话：两个通道说的不一样，这件事本身要被发现。

适用同一次输入中多个通道可能给出彼此不相容内容的系统。

规则系统必须具备检出跨通道内容冲突的机制，禁止用"后到覆盖先到""某通道恒定优先"或"取置信度最高者"的隐式规则让冲突在无人察觉的情况下消失。检出的粒度至少要能区分三种情况：两通道内容相容（可融合）、两通道内容不相容（冲突）、其中一方无可用内容（缺失，转 MM5）。冲突事件必须可被记录与统计——冲突率是这类系统的基础运行指标，不得因为它一直被自动处理而不予观测。

无法判明相容性时必须保留“未知”，不得把未知等同相容。两路分数未经同任务、同人群条件下的校准，不得直接相加、相乘或取高者作为正确性的证明；同一原始信号的两种推断不得计作两份独立证据。采用自动裁决时须记录输入来源关系和共同失效条件；不能证明满足裁决条件时转显式选择。

边界条件本条不要求系统解决所有冲突，只要求识别出冲突存在；解决方式由 MM3-2 至 MM3-5 规定。通道之间在语义上互补而非重复的输入（一个提供动作、一个提供对象）本就不构成冲突，不在本条范围内。

设计应用把“相容”“冲突”“缺失”“未知”分别表达，让下游显式处理未能判明的情况。冲突计数与融合计数一起上报。

验证示例

• 用户侧：注视一个对象的同时用语音说出另一个对象的名称，观察系统是否表现出察觉。
• 实现侧：检查融合逻辑中是否存在无条件覆盖。用已知冲突样本注入，检出率须达到产品声明的门槛；用已知相容样本注入，不得被判为冲突。统计须同时报出分母、漏检数、误报数与归入「未知」的数量。恒为零本身既不能证明机制有效，也不能证明机制缺失——低冲突场景下真实值可以是零；只有在注入样本未被检出时才判为机制未生效。

反例做不到——语音说"打开设置"，指点落在"删除"上，系统按指点执行且全程无任何冲突记录；做过头——把所有语义不完全等价的通道输入都判为冲突，互补型输入（"移到" + 指点位置）被反复要求澄清。

MM3-2裁决规则预先定义且稳定必须¶

一句话：谁赢是事先定好的，不是谁先到谁赢。

适用会对跨通道冲突作出自动裁决的系统。

规则自动裁决必须依据预先定义、可核验且在相同条件下产生相同结果的规则（见 mm.arbitration.policy）。禁止以信号到达顺序、处理线程调度或识别器返回快慢作为裁决依据——这些是实现细节而非设计决定。裁决规则可以引用通道的可靠性差异、任务情境或用户显式设置，但所引用的每一项都必须是可解析的声明值而非运行时的偶然状态。通道优先级不等于内容正确：某通道在优先级上靠前，只决定冲突时采纳谁，不构成"它说的是对的"这一判断，也不减免 MM3-3 的告知义务与 MM3-4 的撤销义务。

边界条件本条不要求裁决规则固定不变，允许按情境解析出不同规则；变化必须由声明的情境维度驱动并可复现。本条不适用于 MM3-5 所述必须交由用户裁决的高代价冲突。

设计应用把裁决规则写成一张可查的表：情境 × 通道对 → 采纳方，而不是散布在各处的 if 分支。设置项里让用户能表达"我说话时以语音为准"这类偏好，并让它进入同一张表。

验证示例

• 用户侧：在同一情境下重复制造同一种冲突，确认裁决结果一致。
• 实现侧：改变信号到达顺序而保持内容不变，确认裁决结果不随之改变。

反例做不到——哪个识别器先返回就用哪个，同一操作在网络好和网络差时表现不同；做过头——裁决规则细化到每个控件每种组合都单列一条，无人能预测系统行为，规则表本身成了不可维护的黑盒。

依据与参考已有平台文档给出过成文的输入优先级与回退次序，并把"设备输入优先于身体输入"解释为对用户意图的推断（R16、R17）——那是一个可核验的预先声明，而不是运行时的偶然结果；本条要求的是这种可声明性，不采纳其具体次序。

MM3-3裁决结果可见必须¶

一句话：采纳了哪一边、放弃了哪一边，要说出来。

适用对跨通道冲突作出自动裁决并据此改变行为的系统。

规则自动裁决改变了系统行为时，必须让用户能知道采纳了哪个通道的内容，并且在被放弃的一侧存在明确用户表达时，必须让用户知道它被放弃了。告知须与结果同处一处、同一时机，不得只存在于日志或事后可查的记录中。告知的详略按后果分级，但"发生过一次裁决"这一事实本身不得被省略。回执必须来自实际裁决与提交事实，不由动画播放或生成文案推断。

边界条件本条不要求逐次展示裁决依据的完整推理；依据的可说明性见 MM1-6 的同类要求。当被放弃的一侧并非用户的明确表达（例如一次低置信的被动信号）时，可将采纳来源合并进结果回执，不必呈现被放弃项；仍须让用户知道采用了哪一路。

设计应用把裁决告知合并进操作结果的呈现里，不做成额外的提示层；用"按您说的执行"这类指向通道的措辞，而不是"已处理"。

验证示例

• 用户侧：制造一次两侧都有明确表达的冲突，检查用户能否从界面上看出哪一侧生效。
• 实现侧：确认裁决事件在用户可见层有对应输出，而不是只写入日志。

反例做不到——语音和手势指向不同对象，系统选了一个执行，界面上完全看不出另一侧存在过；做过头——每次轻微的通道不一致都弹出"检测到输入冲突，已采用语音输入"的模态提示。

MM3-4裁决可撤销并可切到另一解释必须¶

一句话：选错了要能一步换回来，不是重做一遍。

适用存在自动裁决且裁决可能与用户意图不符的系统。

规则自动裁决产生的结果必须可撤销，并且系统必须提供直接切换到被放弃的那一个解释的路径——不要求用户重新完成整条多通道输入。切换路径应当与裁决告知处于同一位置，且在结果发生后的一段可用时间内保持可达（时长见 mm.arbitration.revert.window）。切换前必须核对已产生的结果：先撤销原结果，再提交另一解释；原结果无法撤销时不得叠加执行替代操作。撤销只作用于本次操作，保留用户此后无关的修改。若被放弃的解释因对象状态变化已不可用（见 MM1-4），必须说明原因而不是静默移除入口。

边界条件本条不要求无限期保留候选解释；保留时长由产品定义。对于按 MM3-5 已交由用户裁决的情况，本条不再额外要求撤销入口。

设计应用把候选解释与结果一起保留一小段时间，让"不是这个，是那个"成为一次点击而不是一次重新输入。撤销与切换是两件事：前者回到操作前，后者跳到另一个结果。

验证示例

• 用户侧：在裁决结果出现后尝试切换到另一解释，记录所需步数与是否需要重述指令。
• 实现侧：确认被放弃的解释在保留期内可被检索并执行；构造对象已变化的情况，确认给出原因。

反例做不到——裁决错了只能撤销后把整条"看着它说把这个移到那儿"重做一遍；做过头——每个结果旁边长期挂着一列"其他可能的理解"，界面被候选项占满。

MM3-5后果越大越不自动裁决必须¶

一句话：代价高的冲突交给人，不要替人挑。

适用跨通道冲突可能发生在不可逆、外发或高代价操作上的系统。

规则当冲突涉及的操作属于不可逆、影响他人或按产品风险分级属于高代价一档时，禁止自动裁决后直接执行；系统必须把冲突呈现给用户并由用户选择。呈现必须包含两侧各自对应的具体结果（不是通道名称），使用户能在结果之间而不是在通道之间作选择。用户未作选择时不得默认执行任一侧。确认须包含对象、动作、关键参数和后果；风险未知时按高代价处理。

边界条件安全关键的即时停止类指令不受本条约束——此类指令走 MM2-2 的控制路径，在声明的安全策略内优先处理。当两侧解释导致的结果完全相同时不构成需要用户裁决的冲突。

设计应用把选项写成"删除 A"与"删除 B"，不要写成"采用语音"与"采用手势"——用户不需要知道通道，需要知道后果。

验证示例

• 用户侧：在高代价操作上制造冲突，确认系统停下来询问且选项描述的是结果。
• 实现侧：核对风险分级表与自动裁决开关的对应关系，确认高代价一档不可被配置为自动。

反例做不到——语音说"发给张三"、注视落在李四的头像上，系统自动选一个发了出去；做过头——把所有多通道操作都归入高代价一档，每次交互都以一次二选一对话结束。

3.4 MM4 一个意图执行一次¶

同一个用户意图可能在两个通道上各被识别一次。融合分组只解决输入归并，实际提交还要抵抗并发、重传与结果回执丢失。设计要同时证明“形成一个意图”和“业务只生效一次”；只合并界面提示不能证明后者。

MM4-1同一意图只产生一次副作用必须¶

一句话：两个通道识别到同一件事，只做一遍。

适用多通道输入可产生业务副作用，且同一操作可能被多路、重传或重连重复提交的系统。

规则当多个通道在同一次交互中各自产生了对应同一用户意图的指令时，系统必须只产生一次副作用。禁止把"两个通道都识别到了"当作两次表达，也禁止把它当作置信度提升的理由而执行得更彻底（例如从提示升级为直接执行）。去重必须发生在产生外部可见副作用之前；已经外发、已经写入或已经通知的结果，事后合并不满足本条。

输入归并后，提交入口必须在实际副作用发生前保证同一动作不会因并发、重传或重连重复生效。已提交但回执丢失时，结果为“未知”，先核对业务状态；不得生成新动作标识盲目重试，也不得显示已失败。无法提供安全提交机制时，停用受影响的自动执行路径，保留意图并提供核对／人工处理入口。

边界条件本条不适用于用户明确表达的重复（见 MM4-4），也不适用于语义上互补的多通道输入——那是一次输入的两个部分，本就只有一次意图。

设计应用在意图产生处而不是在执行处去重；把"融合产出一个意图"作为唯一的下游入口，不给各通道保留旁路提交路径。

验证示例

• 用户侧：同时说出确认词并做出确认手势，检查是否只发生一次操作。
• 实现侧：检查是否存在绕过融合层直接提交的通道；构造两通道同时产出的场景，确认下游只收到一个意图。

反例做不到——用户说"发送"的同时点了发送手势，消息发出两条；做过头——把用户在两秒内的两次真实发送都判为重复，第二条消息静默丢弃且不告知。

MM4-2去重按意图标识而非表面相同必须¶

一句话：字面一样不等于同一次，字面不同也可能是同一次。

适用进行跨通道去重的系统。

规则去重判据必须建立在意图的标识上——即所指对象、动作与参数构成的可比较标识——而禁止仅以文本相同、事件类型相同或时间接近作为唯一判据。两个通道对同一意图的表述通常不相同（一个说"删掉"、一个做删除手势），仅比文本会漏判；两次不同的意图也可能表述相同（连续两次"下一个"），仅比文本会误判。标识的构成须显式定义（见 mm.idempotence.key），并须包含足以区分相邻两次真实操作的成分。

"语义签名"与"交互实例标识"必须分开：前者比较动作、目标域与参数，用于判断两路表达是否在说同一件事；后者由融合分组与明确的新操作证据（用户的再次发起、状态已变化、显式的重复入口）决定，用于判断这是不是新的一次。仅凭语义签名相同不得判为重复——连续两次"加一"在动作、对象与参数上完全相同，却是两次意图。缺少绑定对象的指令不得为满足标识而伪造指代对象：此类指令以其目标域（当前焦点上下文、当前任务）作为标识成分。实际提交的动作标识与输入语义签名分别定义，并保持可追溯关联；同一动作重试复用其标识，有意重复生成新动作标识。

边界条件本条不要求标识在全系统唯一，只要求在去重窗口与作用范围内可区分。当产品的意图空间中不存在可重复的相邻同类操作时，可简化标识，但简化须是显式决定。本条不承诺任何单一时间阈值能把"跨通道重复"与"真实的第二次"分开：去重窗口须同时参照跨通道重复的到达延迟分布与真实重复的间隔分布，两者重叠的区间以显式的重复入口、状态证据或"不确定"处置解决，不得宣称一个阈值必然分开。

设计应用把标识定义成结构而不是字符串：动作 + 绑定对象 + 关键参数。让不同通道产出的意图落在同一个标识空间里，否则去重无从比较。

验证示例

• 用户侧：连续发出两次真实的相同操作，确认两次都生效；同时用两个通道发出一次操作，确认只生效一次。
• 实现侧：检查去重判据的组成，确认不是仅比较识别文本或事件名。

反例做不到——按识别文本去重，用户连说两次"下一页"只翻了一页；做过头——把绑定对象的内部内容标记也放进标识，同一意图因两通道读到的内容标记不同而去重失败，仍然执行两次。

MM4-3去重窗口与作用范围显式必须¶

一句话：管多久、管到哪儿，要写下来。

适用进行跨通道去重的系统。

规则去重的时间窗口与作用范围必须显式定义并可核验（见 mm.idempotence.window 与 mm.idempotence.scope）。作用范围须说明去重在哪些通道之间生效、是否跨会话、是否跨入口。去重窗口与融合窗口是两个分别定义的量，禁止默认相等而不作说明——融合窗口决定"还等不等"，去重窗口决定"这次算不算重复"。窗口取值须有依据，不得使用无来源的通用数值。输入去重窗口结束，不代表已提交动作可以再次执行；提交记录的保留期须覆盖重试与回执核对范围。

边界条件本条不要求所有意图类型使用同一窗口；按意图代价分档设置不同窗口是允许的，分档规则须可核验。

设计应用把两个窗口分别命名、分别记录依据，避免工程实现顺手共用一个常量；作用范围写清参与者、任务、通道与入口，明确哪些事件共享一次交互。

验证示例

• 实现侧：调取两个窗口的定义与依据，确认它们是分别决定的。
• 用户侧：在窗口边界前后各制造一次重复，确认行为符合定义。

反例做不到——去重直接复用融合窗口的常量，融合窗口一调整，去重行为跟着变且无人知道；做过头——去重窗口设为整个会话，用户一整天内只能执行一次同类操作。

MM4-4有意重复必须可表达必须¶

一句话：用户真想做第二遍时，去重不能拦着。

适用进行跨通道去重且其意图空间中存在合理重复操作的系统。

规则用户有意重复执行同一操作的意图必须能够被表达并被执行。系统必须提供至少一条不受去重抑制的路径：可以是显式的重复入口，可以是用户确认"再来一次"，也可以是携带新操作证据的自然重复。禁止把去重做成用户无法绕过的限制，也禁止在抑制了一次重复之后不告知——对用户可能理解为新操作的输入，抑制时必须说明没有再次执行；已明确归并为同一交互的多路输入可共用一次回执，无需逐路提示。

边界条件本条不要求在高代价操作上提供快捷的重复路径；此类操作的重复可以要求显式确认。产品若能论证某类操作在其语义下不可能被合理重复，记录该论证即满足本条。

设计应用把"抑制了一次重复"做成一次轻量反馈而不是无反馈；重复入口放在结果附近，用户不必回到起点。

验证示例

• 用户侧：在去重窗口内故意重复一次真实操作，确认能完成或至少被告知未发生。
• 实现侧：检查是否存在不受去重影响的执行路径，且该路径不需要用户切换通道。

反例做不到——用户想连续加两次数量，第二次被去重静默吃掉，界面无任何变化；做过头——为保证重复可达，任何被判为重复的操作都弹窗询问"是否再执行一次"，去重的意义被抵消。

MM4-5判不准时不静默执行第二次应当¶

一句话：说不清是不是重复，就别偷偷再做一次。

适用去重判据在部分输入上必然无法确定的系统。

规则当系统无法确定两次意图是同一次表达还是两次表达时，应当优先按不重复执行处理，并把不确定性表达出来：给出已执行一次的结果与一个可用的重复入口，让用户决定是否再来一次。禁止在不确定的情况下静默执行第二次并只在事后提供撤销。对于可完全撤销且撤销成本低的操作，产品可按 mm.idempotence.uncertain 选择"执行并显著提示"一档，但该档不适用于不可逆与外发操作。

边界条件本条不要求消除不确定性，也不禁止产品通过增加判据来降低不确定比例；它规定的是不确定情况下的默认方向。

设计应用把"不确定"设计成去重结果的一档合法取值而不是异常分支——否则实现会倾向于二选一，通常选成执行。

验证示例

• 实现侧：注入时间戳缺失、通道时钟偏移与标识部分缺失三类情况，确认产生"不确定"档而非默认执行。
• 用户侧：在不确定场景下确认用户能看出只执行了一次，并且知道怎样再执行一次。

反例做不到——两个通道的时间戳对不上，系统无法判断，于是两次都执行，转账发生两笔；做过头——一旦出现不确定就中止操作并要求用户重新完整输入，正常操作被高频打断。

3.5 MM5 少一个通道仍能完成¶

通道会消失：权限被撤销、设备被占用、跟踪短暂丢失、环境不适宜或用户主动关闭。需要明确减少通道后怎样继续、哪些输入仍然有效、何时允许恢复。多通道的价值包含在表达条件变化时仍能完成任务，而不只是正常条件下少点几次（R04）。

MM5-1任务不只有多通道一条路径必须¶

一句话：每项任务都有不依赖原组合的完成路径。

适用提供多通道组合输入的系统。

规则通过多通道组合可完成的每一项任务，必须存在不依赖该组合的替代完成路径。替代路径可以更慢、步数更多、表达更啰嗦，但必须能达到同一结果，且必须在产品内可被发现。禁止存在只有多通道组合才能触发的功能，除非该功能在物理上不可能由更少通道完成（此类例外须显式声明并说明理由）。替代路径的可达性不因用户关闭了某通道而降低（见 MM5-4）。

替代路径须验证选择对象、填写参数、确认、纠错与取消的全过程。不得仅按首次检测到的设备锁定输入方式。对 Web 的拖拽功能，同时检查无需拖拽的单指针路径；提供键盘入口本身不证明触摸用户能够完成。状态变化须能被辅助技术感知，常规反馈不抢焦点，流式候选不逐帧播报。相应公开依据与适用边界见 R13、R19、R20。

边界条件本条不要求替代路径在效率上等同，也不要求每个剩余的单通道都能单独完成全部任务——要求的是存在至少一条不依赖多通道组合的路径。产品须声明它承诺覆盖的可用通道子集清单、每个子集下各任务的可达入口，以及完全没有可操作通道时的保留与恢复路径（保留已表达的部分，恢复后可继续）。"存在替代路径"不得被读成"任一单通道均全能"。

设计应用设计功能时先写出它的单通道路径，再考虑多通道能省掉哪几步；反过来做容易产生只有组合才能触发的功能。已有设计记录建议让可选的输入模式提供重复的功能覆盖，以便用户用任一模式达成目标（R04）。

验证示例

• 用户侧：遍历产品声明支持的通道子集，检查各任务能否走完；完全无可操作通道时检查状态保留和恢复入口。
• 实现侧：核对功能清单与其单通道路径的对应表，确认无空缺或空缺已有声明理由。

反例做不到——"把这个移到那里"是布局功能的唯一入口，不能说话的用户无法调整布局；做过头——为保证等价，把多通道路径也拆成与单通道相同的分步确认，组合输入的表达效率被抹平。

MM5-2通道不可用是明确状态必须¶

一句话：用不了就说用不了，不要装作在工作。

适用任一参与融合的通道可能不可用的系统。

规则通道不可用必须是一个明确的、可被系统内部识别并对外表达的状态，而不是表现为持续无响应或持续低质量结果。不可用状态必须区分至少三种成因：设备或权限层面不可用、用户主动关闭、当前环境条件下不适用。禁止把不可用的通道继续计入融合候选并因此拖长等待（见 MM2-3），也禁止在不可用状态下继续向用户呈现该通道可用的表现（例如仍显示"正在聆听"）。

跟踪短暂丢失与恢复须有稳定判据，避免在两种交互方式间反复跳转；稳定等待不得拖延权限撤销和用户关闭。恢复只允许新鲜且归属明确的信号参与，不重放断开期间的旧动作，不自动提交先前未完成的意图（见 mm.channel.recovery.policy）。

边界条件本条不要求系统区分不可用的全部技术原因；三类成因的区分是下限，因为它们对应不同的用户下一步。短暂丢失也必须阻止使用已过期的候选；是否改变提示与默认通道，按声明的稳定条件决定。

设计应用把通道状态做成融合器的一等输入，让融合逻辑读取状态而不是靠超时推断；对外表达用"当前不可用"而不是"没有听到"。

验证示例

• 用户侧：撤销麦克风权限后发起多通道指令，观察系统是否明确说明而不是无响应。
• 实现侧：分别注入权限拒绝、用户关闭与环境不适用三种情况，确认状态可区分且融合逻辑读取到。

反例做不到——摄像头被系统占用，手势通道永远收不到数据，界面上手势图标依然亮着；做过头——通道每一次短暂抖动都升级为"通道不可用"横幅，正常使用中提示不断。

MM5-3降级须被告知并说明变了什么必须¶

一句话：悄悄换了一套行为，比不能用更糟。

适用通道减少时会改变交互方式或改变同一动作语义的系统。

规则因通道减少而进入降级路径时，系统必须告知用户已经降级以及哪些行为随之改变。禁止静默降级——尤其禁止在保持界面外观不变的情况下改变同一动作的语义。告知须说明用户当下可以怎么做，而不只是说明发生了什么。降级期间被禁用或被改变的入口须可被识别，不得保持原样但不再生效。

边界条件本条不要求为每一次通道状态波动都发出告知；只要求在交互方式实际改变时告知。若降级后行为完全不变（仅冗余通道消失），可不告知，但该判断须可核验。

设计应用把"降级告知"和"如何继续"写在同一处；对改变了语义的控件给出明确的新语义提示，而不是让用户从失败中发现。

验证示例

• 用户侧：在多通道使用中途关闭一个通道，观察是否得到告知以及能否知道接下来怎么做。
• 实现侧：列出所有降级路径，逐条确认有对应的告知与行为差异说明。

反例做不到——手势通道失效后，原本"看着并捏合"的操作变成了"注视两秒即触发"，界面毫无变化，用户开始误触；做过头——每次降级都以模态对话框中断当前任务，并要求用户阅读完整的能力差异说明。

MM5-4可分通道关闭且关闭有效必须¶

一句话：关掉摄像头就是不再看，也不用别的信号绕回来。

适用采集两个及以上通道信号的系统。

规则用户必须能分通道关闭参与融合的采集，而不是只能整体开关。某通道被关闭后，系统必须停止该开关已声明控制范围内的采集、读取或推断，禁止继续将其历史原始信号或未接受的候选用于当前融合。已被接受的对象与参数按 MM5-6 保留为任务状态；用户另行要求删除时按声明的删除范围执行。禁止在未经用户明确选择的情况下，借其他信号恢复已被关闭的采集、读取或推断用途（例如关闭眼动后自动以头部朝向推断"等价注视落点"，或关闭麦克风后以唇动重建语音内容）。

用户可以明确启用经过说明的替代输入：例如在关闭眼动之后主动选择头部指针——它表达的是用户直接控制的指向，不得被呈现为对真实注视的推断，也不恢复已关闭的数据流。关闭控制必须披露它实际控制的层级（原始采集／本应用读取／某项推断用途／整个定位能力），以及在共享传感器上哪些系统必要用途不在本应用的控制范围内。关闭不得导致与该通道无关的核心功能降级，也不得改变 MM5-1 所要求的替代路径可达性。关闭前已采集数据的保留与删除必须一并说明并可分别执行。

关闭或撤权必须使待处理缓冲中的相应片段退出当前融合，并阻止未提交动作继续使用它们。融合用途、原始采集、处理位置、保留范围与期限须有明确说明；撤回一种用途不等于删除全部历史。运行诊断优先保留事件摘要与必要依据，原始敏感信号的留存须有独立目的和可执行的删除路径，不得以“调试需要”为由无限保留（见 mm.evidence.data.policy）。

边界条件本条要求参与融合的各通道用途分别可控；产品不能承诺关闭自己无法控制的系统级采集。产品可将同一物理传感器上的多项推断合并为一个开关，但该合并须有技术依据并说明该开关实际关闭了哪些采集与哪些用途；物理上共用传感器不自动取消对本应用各项用途的分别控制。

设计应用把"停止采集"与"删除既有数据"做成两个可分别执行的操作，各自说明后果；关闭状态要在所有入口生效，包括被动通道与后台采集。

验证示例

• 用户侧：关闭其中一个通道后，观察系统行为是否不再随该通道的信号变化。
• 实现侧：检查是否存在以其他通道信号重建等价能力的路径；确认关闭状态被融合层实际读取而非仅记录在设置里。

反例做不到——用户关闭了眼动采集，系统改用头部朝向估计注视落点，融合行为几乎不变；做过头——关闭任一通道即停用全部多通道能力，且不提供 MM5-1 要求的替代路径，开关变成劝退。

MM5-5环境与社会条件纳入可用性判断应当¶

一句话：能出声不代表此刻方便出声。

适用在移动、公共或共享环境中使用的多通道系统。

规则通道可用性的判断应当包含环境条件与社会条件，而不只是设备与权限层面的技术可用性：噪声、手被占用、公共场合不便出声、旁边有人不便使用大幅手势，都会使一个技术上可用的通道在实际上不可用。系统应当在这些条件可被观察时据此调整默认的通道组合，并禁止把用户不使用某通道解释为该通道不被需要而永久降低其权重。判断依据须可解析且可被用户覆盖——用户显式选择的通道组合优先于系统的情境判断。旁观者的说话与动作不得默认作为当前用户的指令。

边界条件本条不要求系统具备环境感知能力；不具备时按用户显式设置处理即可，记录该限制。本条不要求推断用户所处的社会情境细节，只要求把可直接观察的条件纳入默认值选择。

设计应用把情境判断的结果做成"默认组合建议"而不是"强制组合"；让用户的一次显式选择能覆盖它并在同类情境下保持。

验证示例

• 用户侧：在嘈杂环境与安静环境下分别发起同一任务，观察默认建议的通道组合是否合理且可被覆盖。
• 实现侧：确认用户显式设置在情境判断之上生效，且不被使用频率反向修改。

反例做不到——在会议室里系统仍把语音作为唯一便捷路径，用户只能小声重复三遍；做过头——系统根据环境噪声频繁自动切换主通道，用户每次抬手都不知道这次该说还是该指。

MM5-6切换通道不重置已完成的部分必须¶

一句话：换个方式接着说，不是从头再说一遍。

适用允许用户在一次任务中切换输入通道的系统。

规则用户在一次任务过程中切换通道时，已经表达并被系统接受的部分必须保留，禁止因通道切换而重置输入状态、清空已绑定的对象或要求用户重述前序内容。切换后系统必须能说明当前还缺什么。通道切换是错误恢复的常见手段——用户在一个通道识别失败后倾向于换一个通道再试（R04）——因此切换路径在识别失败之后必须仍然可达，且不得因失败而清空上下文。

边界条件确已失效的槽位单独标记并说明原因，其余有效部分保留。在新通道不能直接展示的已接受内容须提供可回取形式，不得因无法展示而删除。本条不要求无限期或跨会话保留。

设计应用把任务状态存在任务上而不是存在通道会话上；把"还缺什么"做成随时可查的当前状态，而不是只在失败时才出现的提示。

验证示例

• 用户侧：说到一半改用手势完成，检查前半部分是否仍然有效。
• 实现侧：在通道切换点检查任务状态对象是否被重建；构造识别失败后切换的场景，确认上下文保留。

反例做不到——语音说完"把这个移到"之后识别失败，改用触摸时发现绑定的对象也没了，只能从头开始；做过头——保留了已完成部分却不告诉用户保留了什么，用户重复表达一遍，系统按两次意图处理（同时违反 MM4-1）。

3.6 MM6 输出按通道分工¶

输出侧的融合问题与输入侧对称：一次系统输出可以分配到视觉、听觉、触觉等多个通道上。这条原则管的是这个分配——谁承载什么、什么时候一起出现、少一个通道会怎样。常见错误是把多通道输出理解为多份保险：同一句话在屏幕上写一遍、念一遍、再震一下，结果是三个通道互相争抢注意力，用户一个也没接住。已有关于人的多通道表达的记录指出，自然的组织方式是互补而非冗余——不同通道承载不同的语义成分，完全重复的比例极低（R04）。

MM6-1不可错过的信息落在收得到的通道必须¶

一句话：屏幕不在视野里的时候，别把要紧的话只写在屏幕上。

适用输出可分配到多个通道，且存在用户不得错过的信息的系统。

规则对于用户不得错过的信息——操作已执行的回执、不可逆结果、错误与需要用户介入的状态——系统必须将其投放到按当前可观察条件判断可接收的通道上，且必须为这类信息显式指定承载通道而不是让它随默认布局分散。承载通道的选择须依据可观察的接收条件（屏幕是否在视野内、是否外放、是否佩戴设备）与用户的输出通道设置。已发出、平台已接受、已呈现、用户已处理是四件事，禁止互相冒充；通道路由是产品的决定，不构成用户已获知的保证。

接收条件未知，或候选中没有任何已知可用通道时，系统必须把该信息保留为"未确认接收"，提供可回查或待处理的路径，并按预先定义的规则有限升级（改走其他通道、提高显著度、延后重试）；禁止把此类信息只放在一个当前不可接收的通道上，禁止仅以"已发出"作为送达的判定，也禁止为满足本条自行恢复用户已关闭的通道。只有当后续处理必须依赖用户的决定时才要求显式确认，不得对每一次提醒都询问用户是否看见。安全关键信息必须同时提供可回查详情。

边界条件本条不要求所有信息都多通道投放；只针对"不得错过"一档。该档的划分由产品定义并记录，划分本身须可核验。

设计应用先给每类输出标注"可错过／不可错过"，再决定通道分配；把承载通道写进输出定义（见 mm.output.critical.carrier），不要交给渲染层的默认规则。

验证示例

• 用户侧：在用户视线离开屏幕时触发一次不可逆操作的回执，检查用户能否得知。
• 实现侧：核对不可错过信息清单与其承载通道声明的对应关系，确认无遗漏。

反例做不到——头显中的确认回执只以一行小字出现在用户当前不在看的面板上，用户以为没执行又做了一次；做过头——把所有系统消息都升格为不可错过并同时以声音与触觉推送，重要信息淹没在提醒里。

MM6-2分工是默认，冗余要有理由应当¶

一句话：三个通道说同一句话，不是三倍稳妥。

适用一次输出可以分配到多个通道的系统。

规则同一次输出在多个通道上应当分工承载不同成分——例如视觉承载细节与可复核内容、听觉承载结论、触觉承载事件发生本身——而不是在每个通道上重复同一内容。采用冗余（同一内容多通道重复）应当有明确理由并被记录，典型的正当理由是接收条件不确定或信息属于不可错过一档（见 MM6-1）。禁止把冗余作为不做分工决定时的默认做法。分工方案须说明缺少任一通道时信息如何仍然完整（见 MM6-4）。

边界条件本条不禁止冗余，也不要求分工必须细到每个语义成分；它要求的是分工与冗余都是被决定过的。无障碍所要求的等价替代不属于本条所指的冗余——那是 MM6-4 的要求。

设计应用为每类输出写一张小表：这条信息的哪一部分给眼睛、哪一部分给耳朵、哪一部分给皮肤，以及为什么。中性触觉提示可以提醒事件发生，具体对象、数量和结果应有可取得的明确说明。

验证示例

• 用户侧：观察一次典型输出，记录三个通道各自说了什么，检查是否为同一句话的三份拷贝。
• 实现侧：抽查输出定义，确认冗余项附有理由。

反例做不到——每条通知都同时弹窗、朗读全文并震动，用户关掉了其中两个，然后错过了真正重要的那条；做过头——为了避免重复，把结论只放在听觉通道，静音的用户完全得不到结论（同时违反 MM6-4）。

依据与参考人的自然多通道表达以互补为主，不同通道承载不同语义成分，完全重复的比例极低（R04）。该记录来自输入侧的观察；把它用于输出侧的分工是本规范的设计推导，不构成「分工普遍优于冗余」的证明——在输出侧，冗余在何种条件下更可取仍未有本规范可援引的结论，产品须自行验证。

MM6-3跨通道输出的时序有定义必须¶

一句话：差得太远，人会当成两件事。

适用同一次输出跨两个及以上通道呈现的系统。

规则属于同一次输出的多通道呈现，其相对时序必须被定义：哪个先出、允许的间隔范围是多少、超出范围时如何处理（见 mm.output.sync）。间隔取值须由产品按目标情境测定并记录依据，禁止使用无来源的通用数值。超出定义范围时，系统必须避免让用户把它们理解为两次独立事件——可以合并、可以丢弃迟到的一路并保持已呈现的一路完整，但不得原样先后呈现而不作处理。

各路输出必须关联同一业务事件和当前结果。结果被纠正或取消时，须移除尚未播放的过期输出，已呈现的错误结论须更正；不得让“发送失败”的画面与排队中的“发送成功”语音先后出现。取消播报只停止呈现，不自动撤销已执行业务动作（见 mm.output.update.policy）。

边界条件本条不要求各通道严格同时；不同通道的呈现时长本就不同，本条约束的是起始时序与可接受区间。刻意设计的先后序（先提示后详述）不属于同步失败，但其序与间隔同样须被定义。

设计应用把跨通道输出建模为一个带时序约束的组合而不是几个独立发送；为迟到的一路预先写好处置，不要留给运行时偶然决定。

验证示例

• 用户侧：在人为增加一路延迟的条件下观察用户是否把一次输出理解成两件事。
• 实现侧：注入单通道渲染延迟，确认按定义的处置执行而不是原样呈现。

反例做不到——触觉反馈立刻发生，对应的视觉说明在数秒后才出现，用户以为是两次不同的事件；做过头——为保证时序把所有通道都对齐到最慢的一路，即时反馈整体变迟钝。

依据与参考本条要求「同步窗口由产品自行定义并测定」是本规范的设计主张，不依赖外部研究即成立——没有测定就没有可核验的承诺。常被援引的「人对跨通道信号是否属于同一事件的判断存在时间窗、且窗宽因人因条件而异」这一定性陈述登记为 R09，已有访问记录未取得正文，保持待核验；在原文核实之前，本条不以「已有研究证明」的语气引用它，也不据此设定任何毫秒数。

MM6-4任一通道单独可理解必须¶

一句话：少一个通道，信息可以变少，不能变错。

适用跨通道分工呈现输出的系统。

规则跨通道分工的输出必须做到：用户在只能接收其中任一通道时，所获得的信息仍然是正确的，可以更少、更粗，但不得产生与完整信息相反或有歧义的理解。会改变语义方向的关键成分（否定、数量、对象归属）必须出现在表达该结论的那一路中，禁止把结论放在一路而把改变其方向的成分放在另一路。中性的事件提醒可以不携带这些成分——一次不表达结论的触觉提示不因未编码否定与数量而不合格；但此时必需的详情必须能在当前可用的路径上取得，不得只剩一个无法追查详情的提醒。信息为不可错过一档时，还须同时满足 MM6-1 的承载要求。本条与 MM6-2 的关系：MM6-2 说分工是默认，本条给分工划下限——分工不得分到任何一路单独看是错的。

边界条件本条不要求每个通道都传达完整信息；它禁止的是单通道视角下的错误理解，不是信息缺失。三项检查须分别进行：各路是否与真实状态一致（本条）、必要信息是否在当前可用路径上可达（MM6-1）、无障碍等价替代是否具备（另按无障碍要求）。"视觉显示未发送的原因 + 一次中性触觉提醒"符合本条；"只有中性提醒且无法取得错误详情"违反的是 MM6-1 而不是本条。纯粹的氛围性或装饰性输出不承载语义，不在本条范围内。

设计应用检查每一路输出能否独立成句：只听声音、只看画面、只感觉震动，各自都不能得出相反结论。特别检查否定词与数量词落在哪一路。

验证示例

• 用户侧：分别屏蔽每一路输出，请用户复述得到的信息，检查是否出现与实际相反的理解。
• 实现侧：抽查含否定或含数量的输出，确认关键成分未被拆到单一通道。

反例做不到——屏幕显示"未发送"，语音只念了"发送"，静音用户与不看屏幕的用户得到相反结论；做过头——为保证每路独立可理解，每一路都完整重复全部内容，退化为 MM6-2 所禁止的默认冗余。

MM6-5输出通道分工随情境解析且用户可改应当¶

一句话：谁承载什么，按当下情境定，也让人能改。

适用输出通道的可用性或适宜性随情境变化的系统。

规则输出的通道分工应当按当前情境解析——设备形态、是否外放、是否佩戴、是否共享屏幕、是否处于免打扰——而不是固定绑定在某个通道上。用户应当能改变分工偏好（例如"结论也给我显示出来"），且该偏好应当在同类情境下保持。禁止把用户关闭某一输出通道理解为可以把原本由它承载的信息一并丢弃——被关闭通道所承载的信息须改由其他通道承载或明确告知不再提供。路由必须遵守系统静音、免打扰与用户关闭设置；敏感详情不得因原通道不可用而自动转到外放或共享屏幕。

边界条件本条不要求提供逐条信息的通道选择；类别级的偏好即可。不具备情境感知能力的产品按用户设置处理并记录该限制。

设计应用把分工写成"信息类别 × 情境 → 通道"的可解析规则，让用户偏好作为一层覆盖进入同一规则，而不是散在各功能里的独立开关。

验证示例

• 用户侧：在外放与佩戴耳机两种情境下触发同类输出，观察分工是否变化且合理。
• 实现侧：关闭一个输出通道，确认其原本承载的信息改由其他通道承载或有明确告知。

反例做不到——用户关掉了语音播报，原本只由语音承载的结论从此再也不出现，界面上也没有；做过头——分工规则随情境频繁变化，同一类消息每次出现的位置都不同，用户无法形成预期。

MM6-6多通道输出不叠加为过载应当¶

一句话：同时来三下，等于一下都没收到。

适用可能在短时间内产生多路输出的系统。

规则系统应当对同一时间窗内的多通道输出总量设上限，超限时按语义重要性合并、延后或丢弃，而不是全部呈现。上限本身是必须存在的：可以按产品记录的理由改用等效的总量控制手段（例如按语义类别分别限流），但不得不作任何总量控制；所采用的手段与其等效性论证须记录，并接受与设上限同样的验证。禁止因为通道不同就认为它们互不干扰——视觉、听觉与触觉同时到达仍然共同占用注意力。合并规则应当保留不可错过一档的信息（见 MM6-1），优先丢弃可错过的部分。

边界条件本条不规定具体的总量数值；上限由产品按情境定义并记录依据。安全关键告警按专门告警策略处理，不因普通预算被丢弃；该策略也必须定义优先级与告警风暴处置，不允许无限叠加。

设计应用把输出总量做成一个跨通道共享的预算而不是各通道各自计数；先按重要性排序再分配预算，不要先分配再排序。

验证示例

• 用户侧：构造密集事件场景，检查用户能否指出其中最重要的那一条。
• 实现侧：确认存在跨通道共享的输出预算，且不可错过一档在合并中被保留。

反例做不到——同时到达五条通知，界面弹五个卡片、朗读五段话、震动五次；做过头——上限设得过严，把用户主动操作的即时反馈也一并合并掉，操作变得没有回应。

4. 术语和定义¶

本章区分配置、一次交互中的事实和用户可见反馈；状态与真实输入不属于 Token。

4.1 一次交互的事实契约¶

下表用于实现与评审 MM1–MM6，不要求采用特定协议，也不新增 Token。实际的事件、对象、坐标、时间与回执属于运行数据。

收集状态（收集中／已关闭）、解释状态（完整／缺项／冲突／未知）和执行状态分别保存。例如“收集已关闭、缺目标位置、未提交”是合法状态，界面应显示“已选中卡片 A，请选目标列”，而非“任务失败”。

运行记录按 mm.evidence.data.policy 最小化保留；可复核不要求保存所有原始信号。

附录 A：故障注入验证清单与分类检验¶

本清单用于检验条款是否真的生效，不新增义务。逐项注入，记录系统的实际行为；“不适用”须附场景依据；“没测”记待验证，不得记通过。

A.1 指代与绑定

A.2 时间与融合窗口

A.3 冲突与裁决

A.4 重复与幂等

A.5 通道可用性与降级

A.6 输出分工

A.7 组合链路与正常使用成本

每个用例分别记录设计定义、机制证据、用户理解；文档检查通过不等于产品实测通过。

A.8 分类检验

用于检验第 1 章的切分是否成立：取 10 至 15 条具体要求（可来自本规范条款，也可来自真实评审意见），让至少三名未参与撰写的评审者独立判断其归属原则。归属分歧集中在某两条原则之间，说明这两条原则的规范对象没有切开——此时应当调整原则，而不是增设中间层或映射说明。已知需要重点检验的两处见第 1 章的明示（MM2 与 MM4、MM3 与 MM5）。此处的评审人数与分歧判据是本规范建议的内部检查法，不是经文献验证的标准方法。

附录 B：论据边界与来源类型¶

B.1 约束词的判据

标「必须」的唯一依据是：缺了它，某条对用户的承诺会在可预见的情境下失效。下列三类论据提供不同支持，不是三种独立的强制性来源；实现参考本身不足以决定标「必须」——

标「应当」的八条是 MM1-6、MM2-5、MM2-6、MM4-5、MM5-5、MM6-2、MM6-5、MM6-6，它们各自都含有禁止级子句（判定见 2.2）。其中的“应当”子句允许有依据的偏离；“必须／禁止”子句仍是底线，不能用偏离记录豁免。

B.2 本规范证据最薄的三处

明确列出，不用条款语气掩盖：

1. MM2 组的窗口取值没有可直接采用的通用基准。 所列来源的时间关系记录来自特定的通道组合（语音与笔、语音与手势）与特定任务（地图类空间任务），其量级不能直接移植到注视与捏合、语音与触摸等组合上。本规范因此只要求"窗口被显式定义、有依据、可核验"，不给数值——这也是本规范中最可能被形式化应付的一组条款。
2. MM6 组的分工原则来自输入侧观察。 "互补而非冗余"的记录描述的是人在表达时如何组织多通道信息（R04），把它用于系统输出侧的分工是本规范的设计推导，不是对来源结论的直接移植。输出侧分工的效果尚待各产品自行验证。
3. MM3 的裁决规则缺少跨产品的效果比较。 所列平台文档记录了成文的输入优先级声明（R16、R17），但未发现可比较不同裁决策略在用户理解与纠错成本上的公开结果。本规范因此只要求裁决规则可声明、可复现、可撤销，不推荐任何具体的优先级次序。

B.3 本规范未做的事

不给融合架构（信号级、特征级、语义级均不作规定），不给识别阈值与置信度设定，不给时间窗数值，不给通道优先级次序，不给指代解析算法。这些是产品与领域的决定；本规范只规定这些决定必须被作出、必须可被检验，以及哪些取值不被允许。识别准确率、设备可感知性与任务安全性仍需独立测量，不能由组合行为合格推定。

B.4 来源

完整的来源对照与核验范围见 reference.md。规范中的条款不因为某个产品这样做过就成立；产品做法是"这类机制在真实产品中可行"的证据，不是"应当这样要求"的依据。

附录 C：融合窗口与去重窗口的取值测定¶

本附录是 MM2-1、MM2-3、MM4-3 与 MM6-3 的应用参考，不新增义务，也不给出任何推荐数值。

先写清楚要保护的是哪一侧的用户，再选取值。测定记录应当包含样本的人群构成、任务类型与设备条件；换了人群、任务或设备，取值须重新确认。

---

实施验收场景¶

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

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