跨设备交互设计规范

面向设计师与工程师：让用户在多台设备之间认得出同一件事、接得上同一个任务、信得过看到的状态，并且只被打断一次。

用户的一件事很少只发生在一台设备上。手机上开始、电脑上完成，手表上确认、车机上收听，家里的电视和会议室的屏幕上还坐着别人。设计对象因此不只是每台设备上的界面，还包括设备之间的关系：任务怎么移动、状态以谁为准、能力不足时任务变成什么、提醒该在哪台响，以及这台设备前面的人是不是本人。

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

本规范约束的是产品在多设备场景下对用户作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不绑定任何一家的分布式方案、连接协议或生态能力。它不是组件库，也不是同步引擎的实现方案。采用本规范不能替代无障碍、安全、隐私、数据跨境与领域合规的专项评估；多设备场景显著放大隐私与旁观者风险，这些专项评估比单设备产品更必要，而不是更次要。

全文四章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；验证清单、论据说明与完整场景见附录 A、B、C，完整来源见 reference.md。

---

1. 六条原则¶

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

同一个场景可以触及多条原则——把一份文档从手机流转到客厅电视，同时涉及目标设备的私密级别（D1-3）、迁移时的内容裁决（D2-6）和提醒内容的呈现级别（D5-6）——这不是分类错误：三条规则约束的是三个不同规范对象上的义务，一个是设备的属性，一个是迁移这个动作，一个是打断这个动作。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证。检验不过，修改的是原则的切分。

本切分中最需要持续检验的两处边界，在此明示：D2 与 D3——迁移是"任务、内容、交互入口或控制关系的转移"，同步是"数据的收敛"，两者可以互不发生（可以不迁移而需要同步，也可以迁移时数据早已收敛）；D4 与 D6——降级管"这台设备上这件事还做不做得成"，一致性管"同一件事在这台设备上怎么表达"。这两处若在实践中反复出现归属争议，应当调整原则而不是增设中间层。

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

规则归属唯一，不等于机制不能复用。设备私密级别既是信任判定的输入（D1-3）、迁移内容的裁决依据（D2-6），也是提醒呈现级别的解析输入（D5-6）；一次"设备类解析"既服务于可读性（D6-2）也服务于降级判定（D4-1）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

2. 规则的读法¶

2.1 每条规则的结构¶

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

规则写行为性质、不写实现方式：断开重连后不重复已完成的迁移是产品行为，用什么协议和幂等键实现是工程方案——两者必须对得上，但不是同一份交付物。

2.2 约束词¶

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

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

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

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

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而堆确认、提示、开关和设备列表。两侧都算没做对。常见的过度设计包括：每台设备都弹一次、每次靠近都问一次"要不要流转"、为了"一致"把手表做成缩小的手机。

2.4 规则速查：37 条¶

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

D1 设备可识别可信任

D2 任务可迁移可协同

D3 状态有真相源

D4 能力差异可降级

D5 注意力跨端唯一

D6 一致性有边界

2.5 先选择跨设备方式，再配置能力¶

先写用户成果，例如“到电脑后继续修改刚才的段落”，不要以“支持手机、平板、电视”代替目标。比较以下路径，只有收益足以覆盖发现、授权、等待和恢复成本时才引入换端：

最小设计记录包含：用户成果与单设备基线、参与者与设备角色、对象及成功证据、正常与失败路径、预设及取值理由、待验证的体验指标。不适用项记录原因，不要求把全部 Token 暴露为设置。

2.6 状态与界面事实契约¶

以下是 D2-5、D3-1、D3-2、D4-3、D5-1 的落地读法，不新增强度。传输阶段、结果、控制归属与内容状态分别记录，不压成一个“成功”标记。

支撑状态承诺的记录建议包含对象、主体、请求身份、来源、确认范围与时间；内容相关事实还需能识别所依据的数据修订。只保留支撑核验和恢复的必要信息，不把密码、验证码或完整私密内容复制进遥测。

3. 规则详解¶

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

3.1 D1 设备可识别可信任¶

设备是这套体系里最容易被含糊处理的对象：一台设备"在不在""是谁的""私不私密""前面坐着谁"，是四个互相独立的事实，产品经常用其中一个替代另外三个——连上了就当可用，登录了就当是本人，是自己的账号就当没有旁人。本原则管辖这四个事实各自的成立方式。

D1-1设备身份与归属可见必须¶

一句话：让用户看得到哪些设备算"我的"，并且能把它请出去。

适用任何在两台及以上设备之间共享账号、状态、内容或控制权的产品。

规则产品必须让用户能够查看当前被纳入跨设备能力范围的设备清单，每台设备可由用户识别（名称、类型、最近使用时间或位置线索之一以上）；用户必须能够移除任一设备，移除后该设备失去继续获取新内容与新授权的资格。设备清单必须反映实际生效的范围，不得只展示部分设备或把已失效的设备长期留在清单中。移除后的残留数据处置见 D1-5。

边界条件本条不要求为一次性、就近、无账号的临时协同（如一次投屏、一次文件传送）建立持久设备清单；这类协同的范围由该次会话的存续期界定，结束即失效。

设计应用把设备清单放在用户找得到的位置（账号或隐私设置），而不是埋在某个功能的二级设置里；用用户能认出的名字，而不是内部标识符。

验证示例

• 用户侧：让用户指认清单中每一项分别是自己的哪台设备；再让其移除一台不再使用的设备，观察能否完成并理解后果。
• 实现侧：移除后验证该设备无法继续拉取新内容、无法承接新的迁移、既有令牌失效。

反例做不到——设备清单里躺着七个"iPhone"，用户分不清哪个是旧手机，也没有移除入口；做过头——每次在新设备上打开应用都要走一遍确认与命名流程。

D1-2在场状态真实必须¶

一句话：设备列表里的可用状态来自真实探测，不把上次在线当现在可用。

适用向用户呈现其他设备可用性，或提供选择目标设备入口的场景。

规则呈现给用户的设备可用状态必须来自当前有效的在场判定（连接、近场信号、近期交互或用户显式选择之一以上），并明确该判定的有效期；判定过期后必须呈现为状态未知或不可用，不得沿用历史状态。不具备承接条件的设备禁止呈现为可流转、可投送或可控制的目标；用户选择后才发现目标不可用的，必须给出可执行的下一步而不是静默失败（失败处置见 D2-5）。

设计应用区分"不在线"与"状态未知"；把探测成本高的判定做成用户触发的刷新，而不是常驻轮询。

验证示例

• 用户侧：把目标设备关机或断网，观察源设备上该设备的呈现在多长时间内变化，用户是否会误选。
• 实现侧：检查在场判定的信号来源与有效期；验证过期状态不被缓存复用。

反例做不到——设备列表长期显示三天前用过的平板"可用"，点了转圈三十秒后失败；做过头——为了状态实时，持续高频广播探测，明显影响电量与网络。

D1-3设备私密级别分级必须¶

一句话：电视、车机、会议室屏幕默认是共享的，不按私人设备对待。

适用内容或提醒可能出现在非用户独占设备上的产品。

规则产品必须为纳入范围的设备维护私密级别（至少区分私人设备与共享设备），并以该级别作为内容呈现、提醒内容与迁移裁决的输入。设备私密级别未知时必须按共享设备处理，禁止默认按私人设备处理。私密级别必须可由用户查看与更正；产品可以给出推断的默认值，但推断不得覆盖用户的明确设置。本条只规定级别的成立与默认方向，级别在各动作中的具体后果分别见 D2-6（迁移）、D5-6（提醒）、D4-4（关键操作）。

设计应用把私密级别做成设备的属性而不是每个功能各自的开关；在用户首次向一台新设备投送内容时，是询问级别的自然时机。

验证示例

• 用户侧：把内容投送到客厅电视，观察默认呈现是否按共享处理；用户把该电视标记为私人后，行为是否随之变化。
• 实现侧：验证未知设备的默认级别为共享；验证用户设置优先于推断。

反例做不到——同账号登录的车机被当作私人设备，锁屏摘要在副驾面前完整展开；做过头——每台设备每次连接都要求用户重新回答一遍私密性问题。

D1-4账号在场不等于本人在场必须¶

一句话：登录着不代表坐在前面的是本人，敏感操作前检查验证是否仍有效。

适用共享设备，以及长期保持登录状态的设备上的敏感操作。

规则产品必须区分“账号处于登录状态”与“当前操作者已被验证”两个事实。在共享设备或长期保持登录的设备上执行敏感操作（涉及支付、权限变更、对外发送、删除、查看敏感个人信息）前，必须核验当前操作者的身份验证仍有效；缺少有效验证时重新确认本人。验证必须绑定用户、设备或会话、适用范围与有效期，账号切换、撤权及风险变化可提前使其失效。验证方式必须与设备能力相称，不具备可靠验证能力时禁止直接完成该类操作（D4-3、D4-4）。凭据与支付凭据必须在可信认证界面中由用户控制使用，禁止由普通业务界面、模型或跨端代理收集后转录到另一设备；用户主动使用的密码管理器、系统自动填充和粘贴不在此禁令之内。不得把记忆密码、手工抄码或扫描二维码作为没有等效替代的唯一认证路径。

边界条件本条不要求为浏览、播放、查询等低影响操作增加重验；也不要求有效验证范围内每次点击都重新做生物识别。身份验证不等于对具体业务操作的授权或确认，后者仍须独立成立（D4-3）。

设计应用把重验绑定到操作的影响而不是绑定到时间；闲置时长可以作为重验的触发条件之一，但不是唯一条件。

验证示例

• 用户侧：在共享设备上让另一个人尝试执行一次支付或一次对外发送，观察是否被拦下。
• 实现侧：检查敏感操作前的验证检查、范围及有效期；切换账号、超时或撤权后旧验证不能复用，身份已验证也不能替代具体操作批准。

反例做不到——家庭共享的平板长期登录，任何人可直接下单；做过头——用户在自己手机上每看一条消息都要验一次生物识别。

D1-5配对与解绑对称必须¶

一句话：连得上就要断得开，解绑后残留的数据和授权有明确去向。

适用建立持久跨设备关系（配对、绑定、加入设备组）的产品。

规则任何可建立的跨设备关系必须可由用户解除，解除入口的可发现性应当与建立入口相当。解绑必须撤回该设备上继续获取新内容与新授权的资格，并明确本地缓存内容、未完成迁移与已授予权限的处置；处置结果必须告知用户，不得让用户以为已清除而实际保留。解绑不影响已同步到其他设备的合法内容，也不追溯撤销该设备在解绑前已产生的合法结果；需要撤销既有影响时，必须另行核对操作是否可撤、用户权限及实际结果。

授权撤回与远端数据清除必须分别记录结果。设备离线、仅支持离线验证的凭据尚未到期、或平台无法清除缓存时，必须说明生效边界与残留风险；禁止把“已提交清除请求”呈现为“已清除”。撤回决定必须在相应授权检查点生效；重连后必须先核对撤权与清除要求，再恢复内容交换。退出账号或切换工作空间时，旧身份的缓存、待提交操作与接续入口必须隔离，不得提交到新身份下。

依据与参考Apple Find My 的离线擦除说明区分待擦除与实际擦除。此处据此补充回执边界，不要求普通应用具备系统级远程擦除能力。

设计应用解绑时区分"从这台设备移除"与"删除内容"，两者用户心智不同，不要用一个按钮同时做两件事。

验证示例

• 用户侧：让用户在丢失一台设备的假设下完成解绑，观察其能否找到入口并理解哪些内容仍留在那台设备上。
• 实现侧：验证授权检查点拒绝后续访问；离线设备清除显示待执行，只有取得清除回执才显示已完成，重连不复活撤回的权限。

反例做不到——配对一步完成，解绑要联系客服；做过头——每次短暂断连都提示用户是否要解除绑定。

D1-6发现不等于授权必须¶

一句话：同一个网络、离得很近，都只是发现条件，不是授权依据。

适用使用近场、同网段、同账号或其他环境信号发现设备的产品。

规则环境信号（物理邻近、同一局域网、蓝牙或超宽带可见、同一账号在场）只能作为发现与候选排序的依据，禁止作为授予控制权、读取内容或执行操作的授权依据。跨设备的控制与内容访问必须有独立于环境信号的授权依据（用户显式选择、既有配对关系或有效凭据）。被发现的设备发送的名称、描述与提示文本属于外部内容，不得因被读取而获得指令权威。

发现阶段必须限制广播与采集的信息，不得为尚未授权的候选发现暴露任务正文、访问凭据或不必要的稳定个人标识；发现范围与持续时间应当与当前用途匹配。设备名称只作识别线索，不能单独证明设备身份。使用扫码或短码建立关系时，授权界面必须使用户能够核对实际设备、账号或工作空间、请求范围及有效期；扫描或输入代码本身不得替代对授权对象的核对。

使用扫码、短码或推送授权时，必须呈现发起来源、用途、实际授权对象及后果，并提供清楚的拒绝或取消入口；对非本人发起或不符合预期的请求，不得默认接受。配对码须绑定请求并受有效期与使用次数约束，重复到达不得建立额外授权。名称相同、访问了真实登录域名或完成了多因素验证，都不独立证明请求来自用户预期的设备。

外部依据：RFC 10027 §6.1.14强调保留请求上下文及明确拒绝入口，并指出界面说明需与其他缓解机制结合；邻近可辅助核对，不替代授权。

依据与参考这是跨设备场景中与单设备产品差别最大的一条，也是最容易被便利性侵蚀的一条：为了"走近就能用"，把邻近判定接到了授权路径上。物理邻近是可被制造的条件——同一间办公室、同一节车厢、同一个咖啡馆都满足。本条要求便利性只作用于发现与排序，不作用于授权。

设计应用靠近提示可以把目标设备排到第一位，但确认动作仍由用户在源设备上完成；不要用"检测到附近有设备"直接触发内容投送。

验证示例

• 用户侧：在同一网络下用另一个账号的设备尝试发起控制，观察是否被要求独立授权。
• 实现侧：验证仅有环境信号时不会获准；情境可以收紧既有授权，但不能自行扩大授权。在设备名称中植入指令性文本，验证只作为显示字符串处理。

反例做不到——同一 Wi-Fi 下任意设备可直接向本机投送内容并自动播放；做过头——每次在自己家里从手机投到自己的电视都要走一次完整配对。

3.2 D2 任务可迁移可协同¶

迁移是有语义、有承接点、有终态的动作；协同则允许多台设备持续承担不同角色。本原则管任务的位置、分工与控制权：这次移动是什么性质、接到哪一点、谁继续执行、谁可以控制，以及成员变化后怎么办。数据在两端如何收敛见 D3。

D2-1迁移语义显式必须¶

一句话：说清这次是移动、复制、接管还是镜像，四件事后果不同。

适用提供任务、内容或控制权跨设备转移能力的产品。

规则产品必须为每类跨设备转移定义并向用户表达其语义，至少区分：移动（主要交互入口转到目标设备，源设备不再作为同一任务的独立主动交互入口；实际执行位置另由执行角色定义，可以保留在源端或服务端，本项不要求重启执行）、复制（两端各自持有，此后可独立演进）、接管（目标设备取得控制权，源设备转为受控或旁观）、镜像（两端呈现同一内容，控制权不变）。同一入口禁止在不同情境下产生不同语义而不加区分。语义必须在用户确认迁移前可知，不得只在结果中体现。

边界条件四种语义只在产品实际提供对应能力时区分，不要求提供四种入口，也不穷尽持续协同形态。"迁移"是本规范对任务、内容、交互主场或控制关系跨设备转移的统称——复制与镜像不移动任务主场，产品按本条声明每一类的实际变化即可；若产品提供的是独占控制的移交，另须满足 D2-7 的接管义务。手机显示讲稿、电视显示幻灯片属于分工协同，按 D2-7 处理；远端独立播放不必是镜像。“投屏”“在此继续”等名称不能代替对实际后果的定义。只打开同一任务的另一个视图，不得隐式复制任务或重启执行。

设计应用用动词而不是图标传达语义——"在电脑上继续"（移动）、"也发到平板"（复制）、"用手机遥控"（接管）、"投到电视"（镜像）；同一产品内保持动词与语义的固定对应。

验证示例

• 用户侧：让用户在流转前预测原设备之后会怎样，比对其预测与实际行为是否一致。
• 实现侧：枚举产品全部转移入口，检查每个入口的语义唯一且已声明。

反例做不到——一个"发送到设备"按钮，有时是复制有时是移动，用户回到原设备才发现任务没了；做过头——每次流转都要求用户从四种语义里先选一种。

D2-2源设备终态明确必须¶

一句话：任务走了以后，原来那台处于什么状态，用户看得见。

适用任何会改变源设备上任务状态的跨设备转移。

规则迁移完成后源设备的状态必须被定义（继续、暂停、只读、退出之一）并对用户可见；源设备上的呈现必须与该状态一致，不得停留在迁移前的画面让用户以为仍可继续操作。若源设备转为只读或退出，正在进行中的未提交编辑必须被保留或明确告知其去向。源设备上的后台执行是否继续，必须与实际执行情况一致，不得声称在后台继续而实际已停止。

设计应用在源设备上留一个明确的落点——"已在客厅电视上继续播放"并附带取回入口，而不是直接把界面关掉。

验证示例

• 用户侧：迁移后回到源设备，观察用户能否说出这台设备现在还能做什么。
• 实现侧：验证源设备呈现状态与实际执行状态一致；验证未提交内容未被丢弃。

反例做不到——手机上流转到电脑后界面照旧，用户继续在手机上编辑，改动全部作废；做过头——迁移后在源设备上弹出全屏说明页，挡住用户想做的其他事。

D2-3迁移粒度与承接点必须¶

一句话：承接的是整个任务还是当前视图，接到哪一点，事先定义。

适用提供跨设备接续能力的产品。

规则产品必须定义每类迁移的粒度（任务、视图、播放或阅读位置、当前选区之一以上）与承接点的精度，并使目标设备的起始状态与该定义一致。承接点必须落在用户可识别的位置上；无法达到声明精度时必须告知实际承接位置，禁止静默退回到起点或跳到不相关位置。跨设备接续必须可靠保存目标、进度、已确认决定、待处理输入及恢复位置，不得依赖模型或界面重新推测用户此前进行到哪里。

接续状态必须绑定同一任务或对象标识、所属账号或工作空间与内容修订标识，并明确必要草稿、附件、本机资源的可用范围。目标端必须校验这些依赖；依赖不齐或数据格式不兼容时按 D4-2 降级，不得打开空白任务冒充接续成功。承接点应当保存为可映射的段落、字段或媒体位置，而非只保存源设备的像素坐标；目标布局变化后的焦点与辅助技术接续见 D6-3。

设计应用视频与音频接续到播放位置，文档接续到滚动位置与光标，表单接续到已填字段与当前焦点；写清哪些内容不随迁移过去（如未保存的本地草稿、依赖本机的资源）。

验证示例

• 用户侧：在长文档中途流转，观察用户是否需要重新寻找刚才读到的位置。
• 实现侧：验证承接点来自持久工作状态；验证声明的精度在弱网与冷启动下仍成立。

反例做不到——播客流转到车机后从第一集开头开始播；做过头——为了精确承接，迁移前强制等待全量同步完成，用户在设备前干等。

D2-4迁移可拒绝可撤回必须¶

一句话：自动流转可拒绝；已完成的迁移在可行窗口内提供退回。

适用由系统自动发起、或由邻近与情境触发的迁移。

规则非用户显式发起的迁移必须提供拒绝路径，且拒绝不得被计为同意；迁移提示未获响应不视为同意，提示有有效期，过期即失效。迁移完成后应当在合理时间窗内提供退回源设备的入口。禁止把自动迁移设为无法关闭的默认行为；产品可以提供自动迁移，但用户必须能够将其收敛为需要确认或完全关闭。

近场与情境提示应当有重复提示的冷却规则；同一机会被拒绝或忽略后，不应当因信号抖动反复出现。有效预先授权可以覆盖自动流转，其设备范围、内容范围与触发条件必须明确；不能以“自动”为由将一次未响应的邀请转为授权。

边界条件本条不要求为用户在源设备上主动点击发起的迁移额外增加一次确认；也不要求对已在目标设备上产生了不可逆外部影响的迁移提供退回；此时必须说明哪些影响已发生，提供仍可执行的停止或补救路径，禁止把返回源端表述为撤销既有影响。

设计应用把"要不要流转"的提示做成低打扰的可忽略形态而不是模态弹窗；退回入口放在目标设备完成迁移后的原位。

验证示例

• 用户侧：走近电视时观察是否被自动接管播放；用户忽略提示后行为是否保持不变。
• 实现侧：验证未响应的提示到期失效且不产生迁移；验证关闭自动迁移后不再触发。

反例做不到——走进客厅手机上的音乐自动转到电视，正在通话的用户手忙脚乱；做过头——每次流转前后各弹一次确认，来回四次点击。

D2-5迁移失败不吞任务必须¶

一句话：中断时保住恢复状态，结果未知先核对，不因重试重复执行。

适用所有跨设备迁移。

规则迁移过程中断（连接失败、目标设备不可用、超时、用户取消）时，必须保留可恢复的工作状态与恢复入口，禁止因过早清理源状态造成两端都无法恢复。发出请求、目标已接收、目标可接续必须可区分；仅收到传输回执不得宣告迁移成功。目标实际承接前，源状态不得被销毁。迁移结果必须区分成功、失败与未知三态；结果未知时必须先核对目标设备的实际状态，不得因超时假定目标未执行，也不得在两端重复执行具有外部影响的动作。失败或待核对状态必须告知用户，并给出可执行的下一步。

取消与承接同时发生时，必须以可核验的生效顺序裁决；已承接后的取消应表达为新的返回或停止动作，不得宣称原迁移从未发生。结果未知期间必须保留请求身份和恢复点，核对仍无结果时提供等待、查询或人工处理路径，不得用无限重试掩盖未知。

边界条件两端离线或执行归属不明时，不承诺立即继续全部操作；可以暂缓外部写入并保留浏览、草稿或等待恢复的路径。“保住任务”不等于在无法确认安全性时允许两端同时执行。

设计应用把源设备的退出安排在目标设备确认承接之后，而不是发起迁移的同时；对涉及外部影响的操作使用可去重的标识。

验证示例

• 用户侧：在迁移过程中断开目标设备网络，观察能否找到保留的任务、理解待核对状态并继续可安全进行的工作。
• 实现侧：注入超时与部分成功故障，验证不出现双端丢失、不出现重复外部影响。

反例做不到——点了流转后源设备立即退出，目标设备没接上，任务消失；做过头——每次迁移失败都要求用户手动核对两端状态并选择保留哪一份。

D2-6迁移不扩大可见与权限必须¶

一句话：任务换了设备，权限和内容可见范围按新设备重新裁决。

适用所有跨设备迁移，尤其是目标的私密级别、受众或权限环境不同的场景。

规则迁移到目标设备后，内容可见范围与操作权限必须按目标设备的私密级别（D1-3）、当前用户及任务所属账号或工作空间重新裁决，禁止直接沿用源设备的可见范围与权限。向共享设备迁移可能使私密内容对旁观者可见时，必须在内容呈现前由用户确认或按降级级别呈现。目标端只承担呈现或控制、实际执行仍在源端或服务端时，必须分别校验目标端的查看或控制权限与执行端的行动授权，禁止借代理绕过任一边界；权限不足按 D4-2 降级。

输出受众变化时必须重新裁决可见范围，包括新外接屏接入、镜像开始、录制开始与私密耳机切换外放。无法可靠感知变化的平台必须说明能力边界，并采用预先选定的共享输出或敏感内容不呈现策略；不得先输出私密内容再要求用户补确认。

依据与参考本条与 D1-3、D5-6 共用"设备私密级别"这一机制，但规范对象不同：D1-3 规定级别本身如何成立，本条规定迁移这个动作如何使用它，D5-6 规定打断这个动作如何使用它。三处要求不可互相替代。

设计应用投屏时把"完整呈现"与"仅呈现共享内容"作为迁移前的选项，而不是投出去之后再让用户去关；通知与消息内容按目标设备级别单独裁决。

验证示例

• 用户侧：把包含私密信息的文档投到会议室屏幕，观察默认呈现内容与用户预期是否一致。
• 实现侧：验证目标设备上的权限判定不引用源设备的授权结果；验证降级呈现在内容首帧即生效，而不是渲染后再遮挡。

反例做不到——手机投屏到会议室大屏，私人消息横幅照常弹出；做过头——向任何设备迁移都要求逐项勾选哪些内容可以带过去。

D2-7协同角色与控制权可交接必须¶

一句话：多台设备一起用时，说清谁控制、谁呈现，离开一台之后谁接着做。

适用多台设备同时参与同一任务，包括第二屏、分布式界面、远程控制与多人设备组。

规则产品必须定义并使参与者可知各设备的输入、输出、执行与控制角色，以及当前有权控制的主体和作用对象。设备组成员资格不等于任务的全部权限；多人参与时必须区分参与者身份及各自可见、可操作范围。共享控制必须定义冲突命令的裁决与回执，不得用内容合并策略替代暂停、跳转、提交等命令的执行裁决。独占控制发生交接时，必须在实际执行入口核对生效点：新控制范围已生效、旧控制范围已失效、残余动作已按预定方式处置，三项分别有据；交接后的旧主控不得继续以原控制权发出有效命令，各端界面同时显示“已接管”不构成交接完成的证据。采用独占还是共享控制，须分别声明其冲突裁决与失联后援。

主控断开、成员退出、组到期时，必须按预定规则转交、暂停或结束相应协同能力，并告知任务留在哪里；禁止静默产生两个独占主控。退出某台设备、断开控制连接、停止远端呈现、结束设备组与取消任务必须区分。离组后依赖本组取得的临时访问与控制资格必须失效，不撤销独立于本组的既有授权；重连的旧设备不得凭缓存身份恢复已经转移或已过期的控制权。

边界条件主控丢失后不要求自动选举新主控；暂停并提供有权用户接管的入口也是有效策略。单人双设备不要求展示成员管理页，当前控制端与退出后果可在现有控制界面内表达。

设计应用手机上保留演讲者备注与控制，电视只显示幻灯片；“断开我的手机”与“结束大屏演示”采用不同动作。电脑执行后台任务、手机监督时，停止请求返回已接收与已生效的真实状态，不因手机离线重建执行实例。

验证示例

• 用户侧：两人各用一台设备加入演示，再让主控退出；观察双方能否理解谁现在可以翻页、大屏是否继续以及如何结束。
• 实现侧：注入同时接管、主控断网、旧命令延迟到达与离组后重连，验证独占控制不分裂、临时权限失效、退出不误取消任务。

反例做不到——两部手机都声称是主控，反复把大屏切到不同页面；做过头——每次翻页都让所有参与者确认一次。

依据与参考W3C Presentation API分别定义控制端、呈现端及连接关闭与呈现终止；Android Sessions API区分 transfer 与 share。两者是模型参照；本条的控制权与离组行为是本规范的设计要求，不是这些 API 的通用保证。

3.3 D3 状态有真相源¶

多端产品最伤用户的失败不是慢，是撒谎：界面显示已保存而服务端没有，两台设备各自显示一份不同的内容而都声称是最新，用户在飞机上写的两千字回到地面被静默覆盖。本原则管辖状态在多端之间的收敛及其呈现——哪一份是真的、现在收敛了没有、冲突怎么裁决、用户的输入受不受保护。任务在哪台设备上进行不在本原则之内，见 D2。

D3-1真相源与乐观呈现分离必须¶

一句话：分清本机保存、跨端同步与业务完成，每种确认都有依据。

适用任何在多台设备之间共享可变状态的产品。

规则产品必须为每类跨设备共享状态定义权威来源或确定的合并规则，并使各端呈现可以解析到该定义。可以采用服务端、指定主设备或本地优先的多副本模型；多副本模型必须明确内容修订、冲突与收敛判定，禁止将某台设备上最后看到的值任意当作全局事实。内容状态与控制命令可以采用不同的权威模型（D2-7）。

界面必须区分本机持久保存、声明范围内的同步与业务动作完成。本机持久化已确认时可以显示“已保存到本机，尚未同步”；禁止将仅在内存中回显的输入说成已保存，将本机保存或服务端接收说成目标设备已可用。对外发送、支付及其他不可逆影响可以立即显示“待发送”“处理中”，但禁止乐观宣告成功，完成必须以真实业务回执为准。

依据与参考Local-first software讨论离线工作与多副本协作，提示本规范需要容纳本地优先模型；这不意味着所有操作都能离线完成，也不证明用户一定理解同步状态。

设计应用编辑后先反馈“已保存到本机”，上传确认后反馈“已同步到账号”；只有核实目标端已取得对应内容修订与必要资源，才表达“可在平板继续”。发送中的气泡可以先出现，但保留待发送状态与失败后的内容。

验证示例

• 用户侧：断网状态下完成一次编辑，观察用户是否会认为内容已经保存到云端。
• 实现侧：分别检查本机持久化、同步确认与外部动作回执；验证未收到业务回执时不显示成功，且失败后保留用户输入。

反例做不到——离线时点击发送，界面显示"已发送"，对方三小时后才收到或根本没收到；做过头——每一次输入都等待服务端确认才回显字符。

D3-2同步状态可见必须¶

一句话：已同步、同步中、未同步、冲突，四态可分，不是只有一个对勾。

适用内容可在多设备间同步且用户可能在同步未完成时切换设备的产品。

规则用户必须能够就当前工作对象获知其同步状态，至少区分已同步、同步中、未同步（含离线与失败）与存在冲突四种情况；处于非"已同步"状态时，必须能获知这意味着什么以及可以做什么。同步失败禁止仅以静默重试处理而不告知用户；重试可以自动进行，但持续失败必须可被用户发现。状态呈现的详略可按设备类调整（D6-4），但四态的可分性不因设备而取消。

“已同步”必须说明其确认范围：到服务端、到指定设备、或到当前参与同步的设备集合，不得暗示所有离线设备都已更新。确认范围或内容修订未知时必须标明未知；目标端只取得较早的内容或缺少附件时，必须说明当前可用内容与缺失项。四态是最低语义区分，可以叠加保存位置、最近确认的内容修订与等待原因，不要求压成一个互斥枚举。

边界条件本条不要求为每一次微小改动都呈现同步指示；对用户不可见、不影响其决策的内部状态同步不在适用范围内。

设计应用把状态挂在对象上而不是全局角落里——用户关心的是"我这份文档"同步了没有；离线时给出"回到网络后会怎样"的说明，而不只是一个感叹号。

验证示例

• 用户侧：制造一次同步失败，观察用户多久发现、是否会在另一台设备上误以为拿到的是最新内容。
• 实现侧：验证四态在界面上确有区分；验证持续失败在合理时间内升级为用户可见的提示。

反例做不到——同步失败后图标不变，用户在另一台设备打开的是三天前的内容；做过头——每保存一次弹一条同步成功的提示。

D3-3并发写入有裁决规则必须¶

一句话：两台同时改，规则事先定好，任何一方的输入不静默消失。

适用同一对象可能在两台及以上设备上被同时修改的产品。

规则产品必须预先定义并发写入的裁决策略（阻止并发编辑、自动合并、保留双方副本交由用户裁决、后写入生效之一以上），并使策略与实际行为一致。任何策略下都禁止静默丢弃任一端已被用户认可的输入：采用后写入生效时，被覆盖的内容必须可被用户发现并取回；采用自动合并时，合并结果必须可被用户识别与更正。存在冲突且无法自动裁决时，必须保留双方内容并交由用户处理，不得以任一方为准直接覆盖。

设计应用把“保留双方副本”设计成可比对形态。按数据语义决定自动合并范围：不同段落的新增可以自动合并；同一收款方、数量或删除与编辑的冲突需要专门裁决。短文本不天然比长文本安全。

验证示例

• 用户侧：在两台设备上同时编辑同一段落后恢复连接，观察用户能否理解发生了什么、能否取回自己那一版。
• 实现侧：注入并发写入与时钟偏差，验证不出现静默丢失；验证被覆盖的内容可取回。

反例做不到——平板上写的段落被手机端较早的内容覆盖，没有任何提示也无法恢复；做过头——任何两端先后修改都判为冲突，用户每天要处理十几次合并。

D3-4离线写入有承诺边界必须¶

一句话：说清离线能改什么、回来怎么合并、什么情况会被拒绝。

适用允许在无连接或弱连接状态下继续操作的产品。

规则产品必须定义离线状态下允许的写入范围，并在用户进入该状态时使其可知；超出范围的操作必须在用户投入之前被拦下并说明，禁止让用户完成大量输入后再告知无法提交。恢复连接后的处理方式（提交、合并、进入冲突裁决、被拒绝）必须与声明一致；可能被拒绝的操作必须事先告知这种可能，并在被拒绝时保留用户输入的内容。离线期间产生的、依赖外部状态的操作按 D3-1 不得呈现为已完成。

离线草稿与排队待执行的命令必须分开。依赖时效或外部状态的命令必须定义有效期；重连提交前必须重新校验当前账号、授权、对象修订标识及删除状态。过期、撤权、对象已删除或关键条件改变时，不得按旧条件自动执行；保留仍有权保留的输入并说明可选路径。恢复草稿不等于重新授权发送，也不得让离线旧副本静默复活已删除的共享对象。

设计应用区分"离线可写并保证提交"与"离线可写但可能失败"两类，并在入口处就体现差异；把不能离线做的事灰掉并说明原因，而不是允许操作后失败。

验证示例

• 用户侧：在飞行模式下完成一段较长的编辑并恢复连接，观察内容是否完整、用户是否需要重做。
• 实现侧：验证离线写入范围与声明一致；验证被拒绝时用户输入仍可取回。

反例做不到——地铁上写完长评论，出站后提示"网络错误"，内容清空；做过头——检测到网络不稳定就整体切换为只读，用户什么都做不了。

D3-5修改保护优先于同步覆盖必须¶

一句话：后到的同步不得覆盖用户正在编辑或已认可的内容。

适用同步可能在用户正在操作时到达的产品。

规则来自其他设备的同步结果禁止以丢弃输入、破坏已确认内容或改变业务含义的方式覆盖用户工作。符合 D3-3 裁决策略且能保护贡献的变更可以自动合并，不要求用户逐次采纳；无法安全合并的重叠修改必须保留双方内容并提供裁决入口。同步到达时必须保留用户输入与组合输入状态，将光标、选区与焦点映射到更新后的对应位置，不得无故跳转、重置或丢失。影响用户判断的远端变更必须可识别，并提供内容取回或修复路径；本地撤销不得无差别抹掉其他人的独立贡献。

设计应用非冲突修改自动进入协作文档；重叠改写提供行内比较，用户仍可继续编辑其他区域。输入法候选词尚未提交时保护组合输入，不能用远端整段刷新打断选字。

验证示例

• 用户侧：在一台设备上输入的同时从另一台推送更新，观察输入是否被打断、光标是否跳走。
• 实现侧：验证非冲突合并、冲突隔离、组合输入与选区映射；验证取回内容及本地撤销不删除他人的独立修改。

反例做不到——正在写的一段被另一台设备的内容整段替换，光标跳到文首；做过头——任何远端更新都要求用户先处理才能继续输入。

D3-6收敛延迟有承诺应当¶

一句话：给出可预期的同步时间，超了要说，不让用户盯着转圈猜。

适用用户可能在同步完成前切换设备的产品。

规则产品应当为主要内容类型给出可预期的收敛时间范围，并在超出该范围时告知用户当前情况与可行的下一步；超时后禁止继续呈现为同步中而不加区别，长时间未收敛应当归入未同步或失败并按 D3-2 呈现。收敛承诺应当以用户可感知的对象为单位表达，而不是以内部批次或队列为单位。

承诺应当声明计时起点、确认范围、适用网络与资源条件；超时只表明未在承诺内确认，不证明操作没有生效。产品必须禁止把目标设备时钟较快、重连或重新打开界面当作新的授权期限或重试机会；跨端有效期由可核验的时间依据裁决。

边界条件本条不要求承诺一个精确数值，也不要求在网络条件不可控时保证达成；要求的是有可预期的范围、超出时有告知。

设计应用在用户即将切换设备的时机（如发起迁移前）主动检查收敛状态，而不是等到另一台设备上打开才发现内容是旧的。

验证示例

• 用户侧：在弱网下保存后立即切换设备，观察用户是否被告知内容可能尚未同步。
• 实现侧：验证超时后状态发生变化而非无限停留在同步中。

反例做不到——同步指示转了十分钟，用户在另一台设备上打开发现是空的；做过头——每次同步都显示预计剩余秒数，数字反复跳动。

3.4 D4 能力差异可降级¶

手表没有键盘，车机在行驶中不能读长文，电视没有精确指点，头显里打字很慢，音箱没有屏幕。这些不是"不支持"，是能力落差。本原则管辖落差本身：能力怎么判定、任务在能力不足时变成什么形态、什么操作根本不该在这台设备上完成、裁剪到什么程度就不该再让用户拍板。表达上的差异不在本原则之内，见 D6。

D4-1能力按声明解析必须¶

一句话：按设备声明的能力决定行为，不按型号和屏幕尺寸猜。

适用在不同设备上呈现不同功能或形态的产品。

规则跨设备的功能与形态差异必须依据可解析的能力维度（主输入模态、屏幕类别、是否可私密显示、可持续注意程度、是否可后台执行、是否可离线写入等）判定，禁止仅以屏幕尺寸、设备型号或操作系统作为唯一判定依据。能力维度必须可解析到明确的来源（设备自述、平台查询或产品预设映射）与有效性依据；来源不可用时按最低能力假定，并使降级结果符合 D4-2。用户可覆盖的能力设定（如"在这台设备上按大屏处理"）优先于推断。

能力必须在承接时及相关条件变化后重新判定，包括应用与数据格式兼容性、必要资源可用性、后台限制与当前输入能力。网络连接成功不等于这些条件成立；缺少应用、格式不兼容或后台执行被限制时，必须在相应承诺前说明。用户的布局偏好不能覆盖平台实际限制、授权或安全门槛。

依据与参考OpenHarmony 跨设备迁移文档提供目标应用兼容性检查及不兼容反馈的实现示例；不兼容的后果取决于产品，不能仅因已连接就宣告可接续。

Android 自适应布局指南提供按窗口适配布局的实践。本条另外区分设备能力与情境：同样宽度下，键盘桌面、遥控电视与行驶中的车机具有不同交互条件。窗口尺寸可以决定布局，但不足以单独决定行动能否成立。

设计应用把能力维度定义成产品级的少量枚举而不是每个功能各自判断；折叠、外接屏幕、外接键盘等运行中变化的能力必须能被重新解析。

验证示例

• 用户侧：给平板接上键盘，观察产品行为是否随之变化；在车机静止与行驶状态下比较可用功能。
• 实现侧：验证功能开关的判定输入是能力维度而非型号；验证能力变化被重新解析而不是仅在启动时读取一次。

反例做不到——按屏幕宽度判定为"手机"，于是接了键盘的折叠屏展开后仍然没有快捷键；做过头——为每一种设备型号维护一套独立的能力表与界面分支。

D4-2降级有定义，不是不可用必须¶

一句话：能力不够时任务变成什么形态要事先定义，不是弹一句不支持。

适用主要任务可能在能力不足的设备上被发起或承接的产品。

规则对每类主要任务，产品必须定义能力不足时的行为（功能降级为受限形态、代理到具备能力的设备、明确不可用并说明原因之一以上），并使实际行为与定义一致。禁止静默失败：不可用必须被告知，且告知中包含用户可执行的下一步。降级形态必须仍能达成该任务的核心价值或明确地把用户导向能达成的路径，不得只保留一个空壳入口。

设计应用常见降级方向是只读、摘要、确认、排队待办——手表上不编辑但可以确认，车机上不阅读但可以收听，音箱上不选择但可以记下待办。

验证示例

• 用户侧：在能力最弱的目标设备上尝试发起主要任务，观察用户是否知道现在能做什么、接下来去哪里做。
• 实现侧：枚举主要任务与设备类的组合，检查每个组合有定义好的行为，不存在未定义的静默失败。

反例做不到——手表上点开文档提示"该设备不支持"，没有下一步；做过头——在手表上勉强塞进完整编辑器，字小到无法操作还必须用它完成。

D4-3代理到其他设备可知可控必须¶

一句话：把输入或输出转到另一台时，说清转去哪、谁在等。

适用把某一步骤的输入或输出转交给其他设备完成的场景。

规则将输入或输出代理到其他设备时，产品必须明示目标设备、正在等待什么、以及该等待的有效期；用户必须能够取消代理并在当前设备上选择其他路径（若存在）。目标设备必须处于真实可用状态（D1-2），不得把请求发往不可达设备后无限等待。代理不改变授权范围：目标设备上完成的操作仍按其自身权限与私密级别裁决（D2-6、D1-4）。凭据与支付凭据类输入的代理受固定底线约束，必须由人在具备该能力的设备上直接完成。

跨设备确认必须绑定请求标识、发起设备、账号或工作空间、对象修订标识与实际操作后果；确认前关键内容变化必须使旧确认失效。同一请求在多端确认只生效一次；取消、过期后的迟到确认不得重新触发执行。验证身份、批准设备登录与批准某项业务操作是不同决定，不得互相冒充。人在手机的可信认证界面完成登录、仅向电视返回限定授权结果，是认证接续；不得把密码转录或转发到电视输入框。

依据与参考RFC 8628提供受限设备在另一设备上完成授权的协议，并讨论设备核对与远程钓鱼；此处借鉴其绑定与过期边界，不把登录授权等同于业务操作批准。

设计应用在发起端明确显示"已发送到你的手机，等待确认"并附带取消入口；在目标端使请求的来源与内容可辨认，避免用户不知道自己在批准什么。

验证示例

• 用户侧：在电视上触发需要输入密码的步骤，观察用户是否清楚要去手机上完成、以及等多久会失效。
• 实现侧：验证等待超时、取消与批准竞争、内容变更及迟到回执；两端显示实际状态，未生效不冒充已取消，重复确认不重复执行。

反例做不到——电视上停在"请在手机上确认"，手机上什么也没收到，也没有超时；做过头——每一次跨设备输入都要求两端各确认一次。

D4-4关键操作有设备门槛必须¶

一句话：承载不了后果的设备上，不直接完成不可逆操作。

适用具有不可逆外部影响或高影响后果的操作（删除、对外发送、支付、权限变更、发布）。

规则产品必须为该类操作定义最低设备能力门槛，门槛至少覆盖能否充分呈现操作对象与后果、能否可靠确认本人在场（D1-4）、当前情境是否允许用户投入必要注意力。不满足门槛的设备上禁止直接完成该类操作，应当代理到满足门槛的设备（D4-3）或延后至满足条件时。行驶中、运动中、锁屏及其他受限情境按同一门槛判定，不因设备本身能力充足而豁免。

边界条件本条不禁止在受限设备上发起或排队该类操作；禁止的是在无法呈现后果、无法可靠确认的条件下完成它。紧急场景（如求助、停止执行）的必要操作不适用本条门槛。"停止类控制通道始终可用"指其入口与受理不被普通的完成门槛关闭；远端是否真正送达与生效，按真实状态如实反馈——离线时呈现为"待送达／待核对"而不是"已停止"。本句不新增无授权的停止权。

设计应用把"发起—确认—完成"三步在设备之间拆开，而不是把三步都塞进能力最弱的那一端；受限情境下把操作转为待办而不是直接拒绝。

验证示例

• 用户侧：在行驶中的车机上尝试完成一次转账或删除，观察是否被拦下并给出可行路径。
• 实现侧：验证门槛判定覆盖全部该类操作；验证停止类控制不受门槛限制。

反例做不到——手表上一次误触即完成付款，屏幕上根本没显示金额与收款方；做过头——在用户自己的电脑上执行常规删除也要求切换到手机确认。

D4-5裁剪保留判断所需信息必须¶

一句话：小屏可以少显示，但不能少到用户没法作判断还让他确认。

适用在小屏、无屏或注意力受限设备上呈现需要用户判断的内容。

规则为适配设备而裁剪内容时，必须保留用户作出当前判断所必需的信息：操作对象的身份、关键数量与金额、不可逆性、以及与用户预期可能不符之处。无法在该设备上完整呈现判断所需信息时，禁止在该设备上索取用户的确认，应当按 D4-2 降级或按 D4-3 代理。摘要与截断必须可被识别为摘要，并提供获取完整内容的路径（可以在其他设备上）。

设计应用先确定"这一步用户凭什么作判断"，再决定裁剪什么；金额、收件人、影响范围属于永不裁剪的项。

验证示例

• 用户侧：在手表上呈现一次需要确认的操作，让用户复述自己正在批准什么，比对其复述与实际内容。
• 实现侧：枚举各设备上索取确认的场景，检查判断所需信息是否完整呈现。

反例做不到——手表上只显示"确认这笔支付？"，金额与收款方都在下一屏或根本没有；做过头——把完整合同全文塞进手表，用户滚动两百屏才看到确认按钮。

D4-6降级不减告知义务必须¶

一句话：降级减的是功能，不是必要的说明、确认和回执。

适用所有采用降级形态的设备与情境。

规则降级只减少功能与呈现细节，不减少必要的告知：操作的实际结果、失败与阻塞、不可逆性、以及控制动作的回执必须保留并可在获授权的入口查询；有可用交互通道时及时反馈，没有通道时保留待告知状态。表达可以采用语音、简短文本或可理解的触觉信号，但不得以单次震动替代无法辨认的结果含义。禁止以"这台设备屏幕太小"或"驾驶中不便打扰"为由省略必要回执或不告知失败。本条按三件事分别裁决：

• 事实保留：必要结果、失败与不可逆性在获授权的入口持续可查，这一项在任何情况下不得省略。
• 当前端的在线反馈：存在在线交互且通道可用时，在当前端及时给出可被理解的最短反馈。
• 主动补达：只使用用户允许、符合私密与情境约束的通道，并受 D5 的路由与去重约束——不得为满足本条而绕过用户已关闭的通道或另选设备推送。当前没有任何可用通道时，记录为"待告知／未确认送达"，在后续取得授权通道时呈现；"已排队"不得表述为"已送达"。

安全关键告警另按其适用的专项规则处理，不由本条自行取得穿透资格。

设计应用为无屏与小屏设备预先定义必要告知的最短表达；把"稍后在手机上查看详情"作为补达而不是替代。

验证示例

• 用户侧：在音箱上发起一次会失败的操作，观察用户是否知道失败了、以及去哪里了解详情。
• 实现侧：枚举必要告知项，验证在线反馈、可查询事实、获准补达与无通道时的待告知状态；投递未确认不得标为已送达。

反例做不到——车机上语音下单失败，全程没有任何反馈，用户到家才发现没下成；做过头——每一次微小状态变化都用语音朗读一遍，驾驶中被持续打断。

3.5 D5 注意力跨端唯一¶

用户只有一份注意力，设备却有五台。同一条消息在手机、手表、电脑、平板和电视上各响一次，会让用户逐台消除重复提醒。本原则管辖打断在设备之间的分配：一件事有效打断几次、送到哪台、处理过了别处怎么消解、勿扰和驾驶状态跨不跨得过去、共享屏幕上显示到什么程度。

D5-1同一事件跨端去重必须¶

一句话：一件事只有效提醒一次，去重范围和时间窗明确。

适用同一账号或同一用户在多台设备上可能接收同一事件提醒的产品。

规则在产品可协调的设备范围内，同一事件的同一次提醒机会必须只分配一个有效打断目标；事件标识、提醒轮次、去重时间窗与协调范围必须可解析，其他设备只作静默呈现。任何配置不得取消该范围内的跨端去重，不得因经过不同设备或重复投递而把同一事件算成新事件。再次提醒或换端升级必须依据明确的次数、间隔及停止条件；穿透去重或勿扰另受 D5-5 约束。

产品必须定义提醒的业务有效期，过期事件禁止在设备重连后按新事件打断。投递服务已接受、设备已收到、实际已呈现与用户已处理必须区分，未知回执不得当成已送达或未送达。平台限制或网络分区使跨端协调不可用时，必须采用预定的单端保守路由或有限升级策略，并记录可能漏达或重复的边界；禁止退化为无差别全端广播，也不得声称能保证用户恰好感知一次。

边界条件本条约束产品可控制的提醒分配，不保证人的实际感知，也不承诺离线与跨生态条件下既绝不漏达又绝不重复。不同用户各自计算提醒；不同事件不应误合并。用户明确启用的有限升级不等于取消去重，每轮仍需去重并在已处理或过期后停止。

依据与参考FCM 消息生命周期明确接受投递不等于到达，且折叠针对同一注册令牌的待投递消息；传输层折叠不能代替产品跨端去重。Wear OS 桥接指南展示了平台内去重与消解能力，也明确其跨平台限制。

设计应用把去重放在服务端或统一的路由层，而不是让每台设备各自判断；定义清楚什么算"同一事件"——同一条消息的多次投递是同一事件，同一会话的多条消息通常不是。

验证示例

• 用户侧：让用户同时携带手机与手表、面前放着电脑，触发一条消息，数一数用户被打断了几次。
• 实现侧：验证去重的判定键与时间窗；在设备时钟偏差与离线补投条件下验证去重仍成立。

反例做不到——一条消息在四台设备上响四次，用户在会议中逐台静音；做过头——为了去重把提醒压到只在一台早已放在抽屉里的设备上响，用户始终收不到。

D5-2提醒路由基于真实在场应当¶

一句话：送到用户此刻可能在用的设备，不是全都响一遍。

适用具备多设备在场判定能力，且提醒具有时效性的产品。

规则提醒应当路由到用户此刻最可能接收的设备，路由依据应当是真实的在场与近期交互信号（D1-2），而不是设备的默认优先级或注册顺序。在场判定不可用时应当回退到用户显式指定的默认设备，禁止以在场判定不可用为由退化为全设备广播。路由结果应当可被用户覆盖：用户能指定某类提醒固定送往某台设备。

设计应用把"最近交互"作为主要信号，把"设备类型优先级"作为回退；对时效性弱的提醒不必路由，进入列表即可。

验证示例

• 用户侧：用户在电脑前工作时触发提醒，观察是否出现在电脑上而不是只在口袋里的手机上震动。
• 实现侧：验证路由输入为真实交互信号；验证信号缺失时回退到指定设备而非广播。

反例做不到——用户正在电脑前，提醒只送到手表，需要抬手才能看到；做过头——为了判断用户在哪台设备前，持续采集摄像头或麦克风信号。

D5-3已读与已处理跨端消解必须¶

一句话：一台处理完，其他设备的红点、横幅和待办跟着消。

适用在多台设备上呈现待处理项、未读标记或未完成提醒的产品。

规则用户在任一设备上读取或处理某一事项后，其他设备上对应的未读标记、角标、待办项与未消解的提醒必须相应更新；更新的延迟必须在用户可接受的范围内并有明确承诺（D3-6）。处理动作的跨端消解不得依赖用户在每台设备上重复操作。尚未消解的原因（离线、同步中）必须可被用户理解，不得让用户以为事项未被处理而重复处理一次；同一业务请求必须复用其身份并核对处理结果，禁止重复提交造成重复外部影响。

关闭横幅只消解对应提醒，已读只更新阅读状态，已处理必须依据业务结果；禁止因通知被划掉就把任务标为完成。提醒过期也不自动完成或取消业务任务。重连设备在补投前必须核对已读、已关闭、已处理与过期状态；离线缓存中的可执行按钮必须重新校验当前对象状态，避免处理已结束的请求。

设计应用把"已读"与"已处理"分开——看过不等于办完；对会产生外部影响的事项，消解必须以真实处理结果为准而不是以本地点击为准。

验证示例

• 用户侧：在手机上回复一条消息，观察手表与电脑上的未读提示多久消失。
• 实现侧：验证消解状态的同步路径与延迟；验证离线设备恢复连接后正确消解而非重新提醒。

反例做不到——手机上已回复的消息，手表上的红点留了一整天；做过头——每次消解都在其他设备上弹一条"已在别处处理"的提示。

D5-4情境状态跨端继承必须¶

一句话：勿扰、驾驶、会议、睡眠在一处设定，别处不得绕过。

适用提供勿扰或情境模式，且用户可能同时携带多台设备的产品。

规则用户设定的免打扰与情境状态必须在其名下参与该情境的设备之间生效，禁止以未在该设备上单独设置为由绕过。产品自身的提醒必须遵守当前生效的情境状态；确需穿透的事项按 D5-5 处理。情境状态的生效范围必须可被用户理解与调整（对所有设备生效，还是仅本设备），产品可以提供默认，但默认方向应当是保护用户不被打扰。

设计应用把情境状态当作用户级属性而不是设备级设置；对于产品无法读取系统级情境的平台，至少保证自身的跨设备提醒受产品内设定统一约束。

验证示例

• 用户侧：在手机上开启勿扰后触发提醒，观察手表、平板与电脑是否仍然发声。
• 实现侧：验证情境状态的同步与生效范围；验证穿透事项确在例外清单内。

反例做不到——手机开了勿扰，会议中手表照样震动；做过头——一台设备进入睡眠模式，导致用户在另一个时区的工作电脑上也收不到任何提醒。

D5-5例外路径显式有限应当¶

一句话：能穿透去重和勿扰的事项，范围写死、次数有限、可审计。

适用存在需要穿透去重或免打扰的紧急或时效性事项的产品。

规则可穿透去重（D5-1）与情境状态（D5-4）的事项应当以显式清单定义，清单应当尽量小、有频次上限、且穿透行为可被审计与复盘。禁止将营销、推荐、增长类提醒纳入例外清单。例外清单应当可被用户查看与调整；产品认为不宜由用户关闭的事项（如安全告警），应当说明理由并仍然接受频次上限。

设计应用把例外的判定标准写成产品级规则（后果的时效性与不可挽回性），而不是交给各业务方各自申请；定期复核清单，把用不上的移出去。

验证示例

• 用户侧：查看例外清单，让用户判断其中每一项是否值得在会议中打断自己。
• 实现侧：验证例外清单外的事项确实无法穿透；验证穿透次数受上限约束并被记录。

反例做不到——"重要通知"作为例外项，实际包含运营活动推送；做过头——把安全告警也一并纳入勿扰，账号异常登录时用户毫不知情。

D5-6共享设备不呈现私密提醒内容必须¶

一句话：客厅电视上弹的是有新消息，不是消息内容。

适用提醒可能出现在共享设备或旁观者可见位置的场景。

规则本条规范的是"通知预览"这一呈现动作的默认值与配置上限，与用户主动查看原文是两件事。在私密级别为共享或未知的设备上（D1-3），提醒内容必须按降低的可见级别呈现，至少不直接展开消息正文、验证码、金额、健康与其他敏感个人信息；用户可以主动提升该设备的呈现级别，但产品的默认方向必须是保护。

共享设备、未知私密级别的设备，以及正在投屏或录制的画面上，通知预览不得包含验证码原值——普通用户偏好不得放宽这一上限。用户在具备相应权限的可信私密界面上主动查看原始内容，是一次独立的查看动作，按其自身的权限与重验规则裁决，不受本条对预览的限制。**其他敏感类别的主动展开须定义可展开的对象、范围与有效期（另见 D2-6）。

锁定状态、投屏状态与录制状态属于同一类判定输入，其中任一成立时按更保守的级别呈现；"更保守"按各输入所允许的内容取交集裁决，不是在一条强度轴上取最小值——不能提供满足所有限制的筛选摘要时，退至"仅存在性"或"不呈现"，不得给出一个可能保留被遮蔽字段的摘要。

依据与参考本条与 D1-3、D2-6 共用设备私密级别这一机制而规范对象不同：D1-3 规定级别如何成立，D2-6 规定迁移动作如何使用它，本条规定打断动作如何使用它。投屏与录屏是最容易被漏掉的输入——设备本身是私人手机，但此刻它的画面正在会议室大屏上。

设计应用把"有新消息"与"消息内容"设计成两个呈现级别而不是一个开关的开与关；投屏与录屏期间自动切到保守级别，并让用户可见这一变化。

验证示例

• 用户侧：投屏演示时收到一条私人消息与一条验证码，观察大屏上呈现了什么。
• 实现侧：验证投屏、录屏、外接显示等状态触发保守级别；验证通知预览中的验证码原值不受用户配置放宽；另验证私人设备上的主动查看仍可按其自身权限进行。用"私人／共享／未知 × 锁定／投屏／录制／普通 × 正文／金额／验证码"逐格记录默认内容、可否主动展开与最终结果；摘要中出现应被遮蔽的字段即为失败；撤销展开或新增共享输出后须立即重新裁决。

反例做不到——会议投屏中，私人消息全文弹在大屏正中；做过头——用户自己的私人手机在锁屏时也一律只显示"你有一条通知"，无法配置。

3.6 D6 一致性有边界¶

跨设备设计里常见的误解是把一致性理解成“长得一样”，于是把手表做成缩小的手机、把电视做成放大的网页。需要一致的是用户的心智模型——同一个对象叫同一个名字、同一个操作产生同一种后果；靶区、字号、层级深度与信息密度则应按实际使用条件适配。本原则管表达的边界，功能能否成立见 D4。

D6-1一致的是语义不是像素必须¶

一句话：定义哪些语义固定、哪些按设备适配，不强求处处相同或不同。

适用在两种及以上设备类别上提供界面的产品。

规则产品必须明确划定跨设备锁定项与按设备解析项两个集合，并使实现可解析到该划分。锁定项至少包含：对象与操作的术语、状态与语义的表达（成功、失败、进行中、不可逆）、操作后果的表述、以及品牌识别要素；锁定项禁止按设备类别改变含义。解析项至少包含：字号、行高、间距、触控靶区、层级深度、信息密度与动效时长；必须结合当前设备与情境验证，不得未经验证直接套用另一端的固定值。不同设备解析后可以得到相同值，不得为了体现差异而强行改变。划分本身必须有单一来源，不由各端各自决定。

依据与参考DTCG 的相关模块属于社区组报告，不是 W3C Recommendation；Format Module定义交换格式与类型，Resolver Module提供多情境解析机制。本规范补充的是跨设备行为及约束词汇，不宣称既有标准不能表达时长或情境差异。具体表达见配套 Design Token.md。

设计应用把划分写在一处并被各端引用；新增设备类别时先回答"它落在哪些解析项的哪一档"，而不是新开一套界面规范。

验证示例

• 用户侧：让用户在手机与电视上完成同一操作，观察其对操作后果的预期是否一致。
• 实现侧：检查锁定项来自同一来源，解析项具有各端验证依据；相同值可以通过，未经验证的跨端硬套不能通过。

反例做不到——同一个动作在手机上叫"归档"、在桌面上叫"移出收件箱"，用户以为是两件事；做过头——为了一致把电视端的触控靶区尺寸也设成手机的值，遥控焦点几乎选不中。

D6-2靶区与可读性按设备类解析必须¶

一句话：字号、靶区、对比度按观看距离和输入方式解析，不跨设备沿用。

适用所有提供可视界面的设备类别。

规则可读性与可操作性的关键值（字号、行高、最小触达区域、对比度、焦点可见性）必须按设备类别及当前情境解析，输入至少包含典型观看距离与主输入模态；未经验证不得把某一类别的值直接沿用到另一类别。解析结果必须满足各目标平台适用的无障碍要求，按设备解析不得成为低于无障碍下限的理由；用户的系统级字号、对比度与动效偏好在各设备上分别生效，不得因跨设备统一而被忽略。

边界条件本条不规定具体数值，也不替代各平台的无障碍规范与人因标准；它要求的是解析机制的存在与下限的守住。

设计应用把设备类别做成少量枚举（手表、手机、平板、桌面、电视、车机、头显、无屏）并为每一类给出解析结果；遥控与旋钮操作的可达性由焦点顺序而不是靶区尺寸解决。

验证示例

• 用户侧：在典型使用距离上（电视三米、车机臂展、手表抬腕）让目标用户读取关键信息与完成选择。
• 实现侧：检查关键值确由设备类解析而来；检查系统级无障碍偏好在每一端都生效。

反例做不到——把网页端的正文字号原样搬到电视，三米外无法阅读；做过头——为了保证可读性把手表上的每屏内容压到只剩一行，用户要翻十屏才看完一条消息。

D6-3输入模态改变路径不改变可达应当¶

一句话：语音、遥控、旋钮下路径可以不同，但能做的事不应当凭空消失。

适用同一产品在不同主输入模态的设备上提供的功能。

规则不同输入模态下的操作路径应当各自适配该模态（语音用意图表达、遥控用焦点导航、旋钮用有限层级、触控用直接操作），路径可以不同、步数可以不同。在设备能力允许的前提下，同一能力不得仅因输入模态不同而无法到达；确因能力不足而不可达的，按 D4-2 定义降级形态并告知，不得静默地在某一模态下隐藏功能。多模态并存的设备上，各模态应当可以互相接续，用户中途切换模态不必从头开始。

迁移或切换模态后，应当恢复到目标设备上与任务进度相符的焦点及阅读位置，保留目标端的辅助技术偏好；不得仅以动画或屏幕坐标提示承接成功。状态变化与控制入口必须能被目标平台支持的辅助技术识别。扫码、拖拽、靠近、语音等入口应当有适用的替代路径；目标设备不在手边或用户无法使用该模态时，按 D4-2 保留继续或恢复路径，不反复要求同一种失败动作。

依据与参考WCAG 2.2的焦点顺序（2.4.3）与状态消息（4.1.3）是 Web 内容的验证依据；跨端焦点接续是本规范据此提出的设计应用，并非 WCAG 直接规定的跨设备协议。

认证接续还应提供可使用的替代路径：二维码不可读时可从可信入口输入关联码；需输入密码或验证码时支持用户控制的粘贴、系统填充或等效辅助方式。相关依据为 WCAG 可访问认证说明；它不要求将凭据透露给另一设备。

设计应用为每种模态设计其原生路径而不是移植——语音不做"读菜单让用户选第几项"，遥控不做需要精确指点的拖拽。

验证示例

• 用户侧：用语音、遥控和触控分别完成同一任务，比较能否完成以及各自的步数。
• 实现侧：枚举功能与模态的组合，检查不可达的组合是否都有明确的降级定义。

反例做不到——车机语音只能导航和放歌，其他功能必须触屏，行驶中无法使用；做过头——为了模态齐备给语音也做了一套逐级朗读的树形菜单，用户听完三层还没选中。

D6-4层级与密度适配注意力预算应当¶

一句话：车机和手表上给几层、放多少，按用户能分出的注意力定。

适用用户注意力不完整或使用时长受限的设备（车机、手表、头显、大屏远距离操作）。

规则信息层级深度与单屏信息密度应当按该设备上用户可分配的注意力与典型单次使用时长解析，而不是按屏幕能容纳多少内容解析。注意力受限设备上的主要任务应当在有限的层级与交互步数内完成；驾驶等安全相关情境下的界面设计不得仅以本规范为依据，必须同时满足适用的行业人因标准与法规要求（本规范不替代此类评估）。

边界条件本条不规定具体的层数或步数上限；此类上限在安全相关领域由专门标准规定，本条要求的是把注意力预算作为解析输入而不是事后检查。

设计应用为注意力受限设备定义主任务清单并只保留它们；把"能放下"和"该放下"分开评估。

验证示例

• 用户侧：在模拟受限情境下（双手占用、间歇注视）让用户完成主要任务，记录中断次数与完成率。
• 实现侧：检查注意力受限设备的界面是否由专门解析产生，而非从大屏界面裁剪而来。

反例做不到——车机把手机端五层菜单原样搬来，用户在行驶中逐层点选；做过头——手表上每屏只放一个字，简单查询要滑动二十次。

D6-5同一对象跨设备可识别应当¶

一句话：同一个任务在两台设备上叫同一个名字，用户认得出是同一件事。

适用同一对象（任务、文件、会话、订单）在多台设备上被呈现的产品。

规则同一对象在不同设备上应当具备一致的名称、标识与关键状态表述，使用户能够确认这是同一件事；排序、分组与呈现形态可以按设备不同，但对象的身份表达不应当改变。跨设备接续时目标设备上呈现的对象应当可被用户与源设备上的对象对应起来（承接 D2-3 的承接点要求）。

设计应用对象命名以用户可见的名称为准而不是内部标识；避免同一对象在一端显示为文件名、在另一端显示为标题的第一行。

验证示例

• 用户侧：在两台设备上并排展示对象列表，让用户指出哪些是同一个。
• 实现侧：检查跨端呈现的名称与标识来自同一字段。

反例做不到——手机上的"周会纪要"在电脑上显示为"未命名文档 (3)"；做过头——为了标识统一，在所有设备上都显示完整的内部编号。

D6-6平台惯例优先于内部统一应当¶

一句话：和宿主平台的返回、通知、分享惯例冲突时，让给平台。

适用在多个宿主平台上分发的产品。

规则产品内部的一致性与宿主平台的系统级交互惯例（返回与导航手势、通知呈现与管理、分享与文本选择入口、系统级设置的归属）冲突时，应当遵从平台惯例；不得为了跨平台统一而拦截或改写平台的系统级控制通道，包括返回、停止、关闭与系统通知设置。让位于平台惯例的项应当被显式记录，属于 D6-1 中的解析项而不是锁定项。

边界条件本条不要求在每个平台上重做界面，也不要求放弃品牌识别；它约束的是系统级交互惯例这一有限集合。

设计应用把"让位清单"写进产品级规范并逐平台维护；产品自有的返回逻辑与平台返回手势保持行为一致而不是各行其是。

验证示例

• 用户侧：在各平台上用系统惯例操作（侧滑返回、系统返回键、通知长按管理），观察是否得到该平台用户预期的结果。
• 实现侧：检查让位清单的实现覆盖各平台；检查未拦截系统级控制通道。

反例做不到——为了跨端统一自绘返回栈，安卓上的系统返回键直接退出应用；做过头——为迎合每个平台的惯例把核心信息架构也改成三套，用户换设备后完全找不到功能。

4. 术语和定义¶

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

按原则给出可执行的故障注入项。每项验证的是规则在失败条件下是否仍然成立——通过不代表符合全部要求，不通过即存在明确缺口。

D1 设备与信任

1. 目标设备断电或断网后，源设备上的可用状态在多长时间内变化；期间用户是否会误选。
2. 移除一台设备后，该设备是否仍能拉取新内容、承接迁移或使用既有令牌。
3. 向未知私密级别的新设备投送内容，默认呈现级别是否为共享。
4. 在共享设备上由非本人尝试支付、对外发送与权限变更，是否被重新确认拦下。
5. 在设备广播名称中植入指令性文本，验证其只作为显示字符串处理。
6. 在同一网络下用未授权设备发起控制，验证被独立授权要求拦下。

D2 迁移

1. 迁移过程中断开目标设备，验证工作状态与恢复入口仍保留，结果未知时不重复产生外部影响。
2. 迁移结果未知时，验证系统先核对目标状态而非单方面终止源任务。
3. 忽略自动迁移提示，验证提示到期失效且不产生迁移。
4. 向共享设备迁移含私密内容的任务，验证可见范围按目标设备重新裁决且在首帧即生效。
5. 源设备存在未提交编辑时发起迁移，验证内容被保留或明确告知去向。

D3 状态

1. 断网编辑后切换设备，验证“已存本机”“已同步到账号”“目标端可用”各自有证据，不相互冒充。
2. 在两台设备上并发修改同一对象后恢复连接，验证任一方已认可的输入未被静默丢弃、被覆盖的内容可取回。
3. 制造持续同步失败，验证在合理时间内升级为用户可见提示而非无限静默重试。
4. 用户正在输入时推送远端更新，验证输入位置与焦点未被破坏、变更可回退。
5. 离线完成超出允许范围的操作，验证在用户投入之前被拦下且输入可取回。

D4 能力与降级

1. 为平板接入键盘、展开折叠屏，验证能力被重新解析而非仅在启动时读取。
2. 在能力最弱的设备上发起每一项主要任务，验证不存在未定义的静默失败。
3. 在行驶中的车机、运动中的手表上尝试不可逆操作，验证被门槛拦下并给出可行路径。
4. 在小屏设备上索取确认，让用户复述正在批准的内容，验证判断所需信息完整。
5. 在无屏设备上触发失败，验证在线最短反馈、详情可查及获准补达；无可用通道时保留待告知，不绕过通知关闭。

D5 注意力

1. 用户同时持有三台以上设备时触发同一事件，统计有效打断次数。
2. 在一台设备上处理事项，验证其他设备的未读与待办在承诺时间内消解。
3. 一台设备开启勿扰后触发提醒，验证其他设备不发声。
4. 遍历例外清单，验证清单外事项无法穿透去重与勿扰、清单内穿透受频次上限约束。
5. 在投屏与录屏状态下接收私人消息与验证码，验证呈现级别自动收敛。

D6 表达

1. 检查锁定项来自单一来源，解析项经过各设备与情境验证；相同数值可以成立，未经验证的照搬不成立。
2. 在典型使用距离上进行可读性与可选中性测试；验证系统级无障碍偏好在每一端生效。
3. 用各输入模态分别完成同一任务，记录不可达的组合是否都有明确降级定义。
4. 在各宿主平台上使用系统级手势与通知管理，验证未被产品拦截或改写。

组合边界回归

1. 离线设备被解绑后继续使用旧凭据，再恢复联网；验证撤权检查点、待清除状态与实际清除回执分别成立（D1-5）。
2. 同一终端退出个人账号并进入工作账号，验证旧草稿、缓存与排队命令没有提交到新账号（D1-5、D2-6）。
3. 广播同名设备、展示过期配对码，验证名称不能冒充可信身份、过期请求不能获准；发现广播不泄露任务正文（D1-6）。
4. 目标仅接收数据但尚未恢复页面或缺少附件，验证未宣告接续成功；不兼容的应用有明确恢复路径（D2-3、D2-5、D4-1）。
5. 已忽略的近场提示因信号抖动再次触发，验证冷却与既有自动授权范围，未响应不成为授权（D2-4）。
6. 两台设备同时申请独占控制，主控随后断网，旧命令延迟到达；验证不会产生两个独占主控，用户知道如何接管（D2-7）。
7. 分别退出控制设备、结束远端呈现、解散组与取消任务，验证后果不混淆，离组临时权限失效（D2-7）。
8. 采用多副本离线编辑，服务端已经收到但目标端仍离线，验证“已同步”的范围没有暗示目标已更新（D3-1、D3-2）。
9. 一端删除对象，另一端离线编辑后重连，验证不静默复活原对象；可保留的草稿有取回路径（D3-4）。
10. 排队命令过期、授权撤回或对象关键字段改变后重连，验证不按旧条件自动执行（D3-4）。
11. 输入法组合输入尚未结束时到达非冲突与冲突更新，验证安全合并不逐次询问、冲突不丢内容，焦点和选区正确映射（D3-5）。
12. 手机确认前，电脑修改请求对象，或取消与批准交错到达；验证旧批准不生效，重复批准不重复执行（D4-3）。
13. 同一事件经系统桥接和应用推送到达，回执丢失后尝试改投；验证每轮去重、升级有界、过期不补响（D5-1）。
14. 只划掉通知而未处理任务，再从离线设备打开旧操作按钮，验证通知关闭不等于任务完成，操作先核对当前状态（D5-3）。
15. 使用读屏、键盘或开关控制完成发现、接续与返回；布局改变或扫码不可用时，验证任务位置与替代路径仍可达（D6-2、D6-3）。
16. 用转发的配对码和同名设备发起非预期授权，验证来源、用途与授权后果可辨认，拒绝与取消可达，已使用代码不会重复授予资格（D1-6、D4-3）。
17. 承接成功回执丢失后源端取消，验证显示待核对或返回操作，不假称原迁移从未发生，不恢复两个独占控制端（D2-5、D2-7）。
18. 私密耳机切为外放，或任务中途新增共享显示器，验证敏感输出在下一次输出前被拦截或降级（D2-6、D5-6）。
19. 禁用摄像头并启用读屏，通过可信入口与辅助输入完成认证；不要求记忆、手抄或由他人代输秘密（D1-4、D6-3）。
20. 在期限 T 前、到达 T、超过 T 及设备时钟偏移时接收回执，验证到期按失效处理、读取与重连不续期，未知不冒充失败（D1-2、D2-4、D3-4、D4-3）。

上述项目应组合覆盖单人顺序接续、多人同时协同、共享屏幕、源端执行与异端确认四类真实任务；记录用户是否认得出对象、能否继续、能否纠错，以及系统据何回执判定。故障清单不替代完整用户旅程验证。

分类检验：可随机抽取产品中的 10 条具体要求，由三名以上未参与撰写的评审者独立判断原则归属；分歧超过三成时，重新检查原则切分或规则粒度。人数与阈值是本规范建议的内部诊断办法，未经外部实证校准，不作为行业标准或单独的上线硬门槛。

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

本规范使用以下来源类型，来源、阅读范围与适用边界见 reference.md。文件自身的规范地位不等于对本规范全部体验主张的证明力，不将不同类型简单按强弱排序：

本规范尚未收敛的部分，在此显式声明，不以条款语气掩盖：

• D5-1 的去重范围与时间窗、D3-6 的收敛延迟、D6-4 的层级与密度上限：本规范只要求"有明确定义"，不给出数值。这些数值在不同产品类别下差异很大，且缺少可直接引用的跨领域标准。
• D4-4 的设备能力门槛：门槛的具体构成（哪些能力、达到什么程度）目前只有各产品的分散实践，未见收敛的行业共识。
• D1-3 的私密级别枚举：本规范采用私人／共享二分并要求未知按共享处理；是否需要第三档（如家庭共享）随产品形态而定，留待真实项目验证。
• D2 与 D3 的边界、D4 与 D6 的边界：见第 1 章的明示。这两处若在实践中反复出现归属争议，应当调整原则的切分。
• D3 的用户理解证据：本地优先研究补足架构与失败模式依据，但未验证本规范的状态命名能被目标用户正确理解。
• 空间计算与特殊领域：尚未系统检视空间锚定、坐标重定位与领域专项安全要求；设备类别列入头显不等于完成该领域覆盖。

配套的 Token 词汇表见 Design Token.md；本规范不通过 Token 字典产生新的义务，字典也不替代本规范。

附录 C：完整场景与验收记录¶

下表把规则连成用户旅程，示例不是指定实现。每个项目仍需填写真实设备、参与者、允许保留的数据范围和验收阈值。

每项验收记录什么¶

错误主体获权、敏感内容出现在禁止的受众中、用户工作丢失、重复外部影响、未知冒充完成，均不可用平均完成率抵消。体验阈值由项目预先声明；本附录提供验证方法，不宣称已经完成用户研究或设备实测。

---

实施验收场景¶

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

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