泛在计算与智能环境设计规范

面向设计师与工程师：当设备嵌进了人所在的房间、被不止一个人共用、并且会自己动起来之后，让墙上的开关始终有效、让人知道现在是谁让这件事发生的、并且随时能就地把它停下来。

泛在计算与智能环境产品做的事，是把计算能力嵌进物理环境本身：灯、锁、空调、窗帘、摄像头、传感器、语音终端、工位与会议室。它们的共同点不是"联网"，而是计算、传感或控制发生在真实的物理空间里——这是本规范的适用基础。另外两件事是关键的风险情境，按其是否成立触发相应规则，而不是三者必须同时成立才适用本规范：被不止一个人共用（触发 U2-6、U4、U5-3 等条款），以及会在没有人下达当次指令的时候动起来（触发 U2 全组）。独居者的住宅、尚未启用任何自动化的智能空间，同样落在本规范的断网降级、采集告知与换手清除等要求之内。这些条件一旦成立，屏幕时代不需要回答的问题就全部出现了：灯是被谁开的、开关还管不管用、断网之后这个房间还能不能住人、客人知不知道这里有麦克风、房子卖掉之后前主人还能不能开门。

这个领域最常见的设计错误，是把智能环境写成一份智能家居 App 的功能清单：以为设计对象是那个应用的界面，于是把"在 App 里能看到状态""在 App 里能远程控制""在 App 里能编辑自动化"当成完整交付。但用户真正生活在里面的是房间，不是应用。房间里的人可能没装这个应用、没有账号、正在睡觉、只是来送个快递。本规范的规范对象是嵌在物理环境中的设备与空间本身，不是操作它们的那个应用。

本规范由六条原则和 40 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（U3-2 就是第三条原则下的第二条规则）。六条原则按规范对象切分：环境的物理状态与实体控件、在这个空间里运行的自动化规则、系统对外部服务的依赖、空间中的控制权关系、持续进行的传感采集、设备与空间之间的归属关系。

范围声明本规范约束产品把设备嵌入物理环境之后对身处其中的人作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不指定通信协议、设备形态或云端方案。它不是组件库，不是互操作性认证，更不是安装手册。采用本规范不能替代下列专项评估与合规判定：网络协议与互操作实现（配网方式、传输栈、厂商间互通与认证测试不在本规范范围内，本规范只要求相关承诺可被核验）、能耗与设备安全认证（电气安全、电磁兼容、燃气与消防相关认证由适用标准与主管机构判定）、建筑规范与消防疏散要求（门锁、疏散通道、应急照明的强制性规定优先于本规范任何条款）、信息安全的技术控制（密钥管理、固件签名、漏洞处置属于安全工程），以及无障碍、隐私与个人数据保护、劳动法与工作场所监控、未成年人保护、租赁与不动产相关法律。本规范同时要求采集用途、数据去向、保存与删除边界可被理解和核验，具体法律依据与主体权利的适用由项目另行评估。上述任一项与本规范条款冲突时，以适用的法规与安全标准为准。

全文五章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语，第 5 章运行事实与交付；验证清单与论据说明见附录 A、B，完整来源见 reference.md，可配置项见《泛在计算与智能环境 Design Token》。

---

1. 六条原则¶

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

同一个场景可以触及多条原则——凌晨两点客厅的灯自己亮了，屋里的人同时面对：这盏灯的墙壁开关此刻还管不管用（U1-1）、这件事是哪条规则触发的且能不能就地停掉（U2-2、U2-3）、这条规则是同住的另一个人定的而自己从没被告知（U2-6）、以及自己作为住在这里但不是账号所有者的人有没有权限把它关掉（U4-2）。这不是分类错误：四条规则约束的是四个不同规范对象上的义务，一个是实体控件的有效性，一个是自动化规则本身，一个是规则的作者与受众关系，一个是空间中的控制权划分。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证。检验不过，修改的是原则的切分。

本切分中最需要持续检验的两处边界，在此明示：U1 与 U3——U1 管"物理状态与系统状态谁是基准、实体控件还管不管用"，U3 管"外部依赖断掉之后还剩下哪些能力"。断网时按墙壁开关灯要亮，其直接规范对象是实体控件的有效性，归 U1-1；断网时应用里的调光、场景与定时还能不能用，其直接规范对象是对云服务的依赖，归 U3-1、U3-3。U2 与 U4——U2 管自动化规则本身（它是谁定的、为什么现在触发、能不能被停下来），U4 管这个空间里谁有权控制什么。"室友设的规则半夜开灯，我能不能当场把它关掉"归 U2-3；"室友有没有资格给客厅设这条规则、我能不能看到他能控制什么"归 U4-6。这两处若在实践中反复出现归属争议，应当调整原则而不是增设中间层。

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

规则归属唯一，不等于机制不能复用。一套"就地控制通道"既是实体控件有效性的实现方式（U1-1）、自动化就地否决的路径（U2-3），也是云服务终止后的手动路径（U3-1、U3-4）；一套"在场检测"既是提醒路由的输入（U5-5），也是控制权与在场分离时的判定依据（U4-1）。同一机制一物多用是常态，写在哪条取决于义务的直接规范对象。

2. 规则的读法¶

2.1 每条规则的结构¶

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

规则写行为性质、不写实现方式：屋里的人不打开手机就能停下一次正在执行的自动动作，这是产品行为；用本地网关、设备端按钮、语音短语还是墙面面板实现，是工程方案——两者必须对得上，但不是同一份交付物。本规范因此不指定通信协议、网关形态或配网流程。

2.2 约束词¶

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

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

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

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

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而把环境做成一台需要逐次审批的机器。泛在计算被做坏的方式在两端都很密集：一端是让房子在断网之后变成一个人住不进去的壳子、让客人在不知情的情况下被录了三天音；另一端是因为怕出错而把每一次自动调光都做成一条通知、每一次开灯都要求先解锁手机确认、把访客权限做成需要八步才能给出去的表单——环境计算的价值本来就在于人不必逐次操作，把它做成一台索取确认的机器，同样是没做对。可预期不等于事事询问，可控不等于把控制成本全部推给人。

2.4 规则速查：40 条¶

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

U1 物理世界是基准

U2 自动化可被理解、可被当场停止

U3 断开之后还剩什么

U4 空间里的控制权

U5 采集发生在人身上

U6 设备的归属与去留

2.5 从空间承诺开始使用¶

先列出实际空间、在场人群、物理输出与传感能力，再判断条款是否适用。无账号、短住、断网与停服都是部署条件，不是可以通过商品命名排除的情况。

每项决定再映射到 Design Token，记录有效值、依据、执行位置和验证证据。

3. 规则详解¶

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

3.1 U1 物理世界是基准¶

智能环境与屏幕产品最根本的差别在于：这里有一个不受软件管辖的物理世界。灯泡是亮是灭、门是开是关、房间是冷是热，这些事实由物理决定，不由数据库里那条记录决定。系统对它们的表示可能滞后、可能错、可能因为掉线而完全停在过去某一刻。这条原则管的就是这层对应关系——谁是基准、实体控件在系统失效时还管不管用、以及当人的手和系统的意图指向相反方向时怎么收敛。

U1-1实体控件始终有效必须¶

一句话：墙上的开关不能因为软件、网络或账号的状态而失灵。

适用具备实体控件（墙壁开关、旋钮、按键、拉绳、把手、机械阀）的设备与空间，以及会改变这些控件所控对象状态的产品。

规则产品必须保证空间中既有的实体控件在网络中断、云服务不可用、账号失效、订阅到期、应用未安装与设备未配网的任一情形下，仍然产生其外观所承诺的物理效果。禁止把实体控件的有效性作为软件功能的下游——不得出现"开关能不能用取决于服务器是否在线"这类结构。若产品在设计上改变了某个实体控件的原有效果（例如把墙壁开关改造成只发送场景指令），必须在安装说明与设备本体上说明改变后的效果，并保证改变后的效果同样满足前一句的独立性要求。

边界条件本条不要求每台设备都配备实体控件，也不禁止实体控件在联网时具备更丰富的行为；它要求的是已经存在于空间中的实体控件不因软件状态而丧失效力。因电力中断而失效不在本条范围内，由 U1-5 处理。消防、疏散与电气强制性规定优先于本条。

设计应用把"这个控件在最坏情况下还剩什么效果"作为设备选型与安装设计的输入，而不是事后的容错分支。常见的一处结构性冲突是：智能灯泡装在普通墙壁开关下，用户关掉墙壁开关后灯泡断电、随后一切软件控制失效——这不是缺陷，是一个必须被显式选择并向用户说明的取舍，选择它就要同时给出面向使用者的说明与替代路径（例如改用智能开关而非智能灯泡、或在开关处加装保留供电的面板）。

验证示例

• 用户侧：拔掉网关或断开互联网，逐一按下空间中的每一个实体控件，检查其效果是否与外观承诺一致。
• 实现侧：核对实体控件的控制链路上是否存在必须经过远端服务的环节；核对账号退出、订阅到期与固件回滚三种状态下的控件行为。

反例做不到——断网后墙壁开关只能点亮一个提示灯，灯具本身不受控；做过头——为了保证独立性而取消所有联网能力，把可远程控制、可编组、可定时的价值一并去掉。

U1-2物理状态优先于系统意图必须¶

一句话："指令发出去了"不等于"灯亮了"，界面上显示的应该是后者。

适用向用户呈现环境或设备状态的产品。

规则系统呈现的设备状态必须以可核验的物理状态或设备回报为依据，而不是以系统已下发的指令为依据。物理状态与系统记录不一致时，必须以物理状态为准更新系统记录，并让不一致这件事对用户可见；禁止以系统记录覆盖物理状态的呈现，也禁止在无法确认物理状态时显示为确定状态。每个被当作当前事实消费的观察必须有来源、观测时间、接收时间和时效判断；超期、失联、单位错误或来源冲突时，必须保留最后已知值的时间并把当前状态标为未知或冲突，不得因界面刷新延长观察有效期。状态来源与其时效由 amb.state.truth.source 与 amb.state.staleness.ttl 表达。

边界条件本条不要求所有设备都具备状态回报能力。不具备回报能力、也没有独立物理测量的设备，必须被呈现为"状态未知"或"最后一次下发的指令是……"，而不是被呈现为确定状态；这类设备的清单应当可查。命令链路没有回执，不等于没有独立的观察能力：存在独立测量时按该测量呈现，并注明其观测时刻。设备自身的回报与物理目标是否达成也是两件事，产品对二者的区分能力须如实声明。

设计应用把"上次下发的指令"与"上次收到的回报"作为两个独立字段贯穿到界面层，不在中间层合并成一个布尔值。用户在墙上手动关灯之后，界面上那盏灯应当变成关闭，而不是保持开启直到下一次轮询。

验证示例

• 用户侧：在墙上手动改变设备状态，观察界面多久、以什么方式跟上。
• 实现侧：断开设备回报但保留指令通道；无独立观察时检查是否显示未知，有独立观察时检查来源和观测时间是否真实。

反例做不到——App 里显示"客厅灯：开"，实际灯泡早已被墙壁开关断电；做过头——因为要求可核验而在每个设备卡片上常驻一段"状态可能不准确"的免责文案，使真正的异常无法被区分出来。

U1-3已下发与已确认分开呈现必须¶

一句话：命令走到哪一步、动作结果如何、现场实际怎样，要分别回答。

适用允许用户或自动化向物理设备下发指令的产品。

规则命令的阶段与结果必须分别表达，不合并为一列"三态"。阶段至少区分：已下发未确认、已被受理、已结束；结果至少区分：已成功、已失败、未知。"已失败"必须有可靠的失败证据（设备明确拒绝、执行侧报错）；超时与回执丢失只进入"未知"，不得被判为失败，也不得被呈现为成功。禁止把"已下发"或"已被受理"呈现为"已完成"——受理确认只证明命令被接收，不证明动作执行；设备内部报告成功也不证明物理目标已达成（继电器闭合不证明灯泡发光，锁舌动作不证明门扇已闭合）。

按结果给出不同的后续路径：失败可按其原因提示或重试；未知必须有已定义的处理方式（转为状态未知、引导现场核对、或在确属安全可重复时按声明的上限与退避重试），不得默认无限重试，也不得静默丢弃。对不能安全重复的动作（开锁、投料、阀门与模式切换），未知之后必须先核对再决定，不得以"有限重试"充当安全依据。指令的回执模式由 amb.state.report.mode 表达。

边界条件本条不规定超时时长与重试次数；这些由产品按设备类别与链路条件测定并记录依据。对于纯广播式、结构上无法获得回执的控制方式，产品必须声明该链路不提供确认；此时若存在独立的物理测量，状态按该测量呈现，不因命令链路无回执而一律呈现为未知（见 U1-2）。

设计应用把"超时未知"设计成一档下游可消费的正常取值，而不是异常分支——否则实现会倾向于乐观地显示成功，让流程走下去。对有物理后果的动作（见 U1-6），超时未知应当引导用户到现场核对，而不是提示"请稍后重试"。

验证示例

• 用户侧：在设备离线时下发一次开关指令，观察界面是否停留在可分辨的中间态并给出下一步。
• 实现侧：分别注入可靠拒绝、成功回执、回执丢失和乱序，检查失败、成功、未知的证据是否正确，晚到信息是否覆盖较新的事实。

反例做不到——点了"开锁"立刻变成"已开锁"，实际指令根本没送到；做过头——每次开灯都要求用户等待并确认回执，把一个瞬时动作做成一次事务提交。

U1-4就地操作优先，收敛规则显式必须¶

一句话：人刚刚动手关掉的东西，自动化不该在三秒后又打开。

适用同一设备既可被人手动操作、又可被自动化或远程控制的产品。

规则人在现场作出的手动操作与自动化、远程或计划任务的意图冲突时，产品必须有显式定义且对用户可预期的收敛规则，至少规定：手动操作是否以及在多长时间内优先于自动化、这段优先期如何结束（到期、显式恢复、离开该空间或下一个自然边界）、以及优先期内自动化被抑制的范围。抑制范围包括已经排队但尚未执行的受影响自动化；网络恢复、定时器重启与规则重新加载不自动取消该优先期，恢复条件按原定义核对。默认必须是就地手动操作优先；相反的默认（自动化立即覆盖人的手动操作）只在有安全或合规依据时成立，且必须向用户说明。收敛规则由 amb.state.conflict.resolution 表达，抑制时长由 amb.automation.suspend.default_ttl 表达。

边界条件本条不要求手动操作永久优先，也不禁止在优先期结束后恢复自动化；它要求的是"优先多久、怎么结束"这件事被事先定义并可被用户知道。安全联锁（燃气泄漏关阀、火警解锁疏散门）不受本条约束；该例外须有明确范围与依据，不是所有远端命令的豁免。

设计应用把"最近一次人的操作"作为设备状态的一部分持久化，让自动化在执行前读取它。不要用固定的一刀切时长解决所有设备：临时关掉一盏灯与临时关掉恒温器，合理的优先期长度不同，各自由产品按使用场景测定并记录依据。

验证示例

• 用户侧：在自动化的触发窗口内手动关闭设备，观察它是否被重新打开，以及在多久之后。
• 实现侧：核对自动化执行前是否读取了手动操作状态；检查优先期的结束条件是否为显式定义而非隐含的定时器。

反例做不到——用户手动关掉运动感应灯，三十秒后传感器再次触发把灯打开，循环一整晚；做过头——任何一次手动操作永久停用该设备上的全部自动化，用户必须逐条重新启用才能恢复。

U1-5断电与重启后的状态预先定义必须¶

一句话：来电那一刻整屋灯全亮，是设计没做，不是意外。

适用会因供电中断、设备重启或固件更新而丢失运行状态的设备与空间。

规则产品必须为每一类设备分别定义三种恢复事件下的初始状态：供电中断后恢复、普通重启、以及更新引起的重启——三者可以取不同值，不得用一条规则代表全部。每种至少覆盖：恢复到中断前状态、恢复到指定的固定状态（须解析到能力、目标值、单位与合法范围）、以及保持关闭三种取值中的一种，并使该选择对用户可见。该选择应当可由有权者在允许范围内修改；出于安全或合规须固定的项，必须说明其固定的理由与可行的退出路径，不得实现为无人可查、无人可改。

恢复过程必须避免产生未经评估的危险或不可预期的批量恢复后果——判据是危害与可预期性，不是同时动作的数量：多路加热或多个安全输出同时恢复可能不可接受，多盏低风险照明同时恢复则未必有问题。禁止把恢复状态默认为"由远端在设备重新联网后决定"——这会使恢复行为依赖于网络恢复时序，用户无法预期。恢复状态取值由 amb.state.power_restore.behavior 表达。

边界条件本条不规定哪一种恢复状态是正确的，也不要求所有设备使用同一取值；照明、加热、安防与医疗辅助设备的合理默认各不相同。本条不覆盖电力系统本身的可靠性设计。

设计应用把恢复状态做成设备级而非账号级的设定，并在设备本体或安装配置中生效，使其在完全没有网络的情况下仍然成立。夜间恢复供电的场景值得单独检验，但不同设备的合理答案不同：夜间照明通常宜"保持关闭"；冷藏与冷冻应当自动恢复运行；温控与防冻保护有其自身的安全下限；安防与紧急呼叫按其安全要求恢复。把这些分别写下来，而不是给整屋一个默认。

验证示例

• 实现侧：核对每类设备在三种恢复事件下是否各有显式取值与目标值；检查恢复行为是否在无网络条件下同样成立；核对固定项的理由与责任人可查。
• 用户侧：在受控试验环境或等效仿真中重放夜间供电恢复，记录恢复瞬间的实际表现与其后果评估；在真实住居空间执行断总电源测试前，须先评估该空间是否存在医疗辅助、安防或冷藏依赖并取得住户同意，不得为验证本规范制造真实风险。

反例做不到——凌晨恢复供电，全屋灯与音箱同时启动；做过头——为避免突发效果而要求用户在每次恢复供电后逐台手动开启，包括冰箱与安防设备这类本应自动恢复的对象。

依据与参考表达通电启动行为的枚举（恢复前一状态／固定状态／反转）及其在固件升级重启时的例外，见 R24。

U1-6有物理后果的动作按后果分级必须¶

一句话：开灯和开锁不是一类操作，不能共用一套确认。

适用可被远程或自动触发、且会产生物理后果的动作。

规则产品必须按后果的可逆性、对人身安全的影响、以及在场者能否当场制止对物理动作分级，并使确认强度、授权要求与自动化准入随级别变化。分级必须按动作能力与参数边界判断，不能给整台设备固定一个等级；场景须展开全部子动作并评估组合后果，不得因“回家”“节能”等名称降低要求。门锁与出入口、燃气与明火、加热与制冷、可夹伤人的机械运动（卷帘、闸门、升降）、以及会在无人时长时间运行的高功率设备，禁止与照明、场景切换等低后果动作共用同一档确认与同一档自动化准入。高级别动作在自动触发前必须核验触发条件仍然成立，且必须有在场可用的就地制止方式（见 U2-3）。动作分级由 amb.control.actuation.class 表达。

边界条件本条不规定具体分级数量，也不要求高级别动作一律禁止自动化——门在预定时间自动落锁是合理的，问题在于它是否与"自动开锁"共用同一套条件。安全联锁与法定的消防疏散要求优先于本条。

设计应用把级别写在设备能力声明里，让自动化编辑器在用户选择高级别动作时改变可用的触发条件与确认要求，而不是在文案里提醒用户注意。远程开锁与远程落锁应当是两个分别授权的能力。

验证示例

• 用户侧：尝试为高级别动作创建一条只由单一传感器触发的自动化，观察产品是否附加条件或拒绝。
• 实现侧：核对分级是否被自动化引擎、语音入口与第三方接入方共同读取，还是只在主界面生效。

反例做不到——语音助手在未核验说话人的情况下执行"开门"，与执行"开灯"走同一条路径；做过头——把恒温器调高两度也要求二次生物识别确认，用户改用手动旋钮绕开整套系统。

U1-7传感输入的有效性先于自动行动必须¶

一句话：没有新动静，不等于没有人；有读数，也不等于读数可用。

适用以传感器、设备回报或推断结果触发物理动作的产品。

规则输入在参与裁决前必须核对来源、观测时间、单位、合法范围、覆盖区域与已知的失准条件。遮挡、低电量、漂移、安装位置变化、多源矛盾或校准失效会影响承诺时，必须能标识受影响能力并进入已定义的降级路径。无法判断的事实保持未知，不得把旧的正常读数沿用为当前安全证据。用于“无人”判断的证据必须说明其覆盖和有效性，未检测到运动、手机离开或身份匹配失败均不能单独证明无人。

产品必须为连续控制定义防抖或滞回条件，区分进入与退出条件，并声明传感失效时是维持已评估的状态、限制输出还是转交手动控制。不得把“全部关闭”作为所有设备的通用安全回落。观察校验由 amb.state.observation.validation 表达，时效由 amb.state.staleness.ttl 表达。

边界条件本条不要求为每种故障增加独立传感器，也不把算法置信度当作物理安全证明。校验不足时缩小自动化适用范围即可，核心手动路径仍须成立。

设计应用会议室久坐人员可能不触发运动传感器；先检查覆盖与证据，而不是不断延长熄灯计时。设备迁移位置后先重新验证覆盖，再启用原规则。

验证示例

• 用户侧：让人员静坐、躺卧或使用轮椅，确认不会仅因无运动而失去基本照明或温控。
• 实现侧：注入过期数据、错误单位、遮挡、来源冲突和阈值附近抖动，核对降级与恢复条件，以及输出是否反复切换。

反例做不到——运动传感器十分钟无事件便认定房间无人并关闭全部设备；做过头——任一读数不确定便要求住户逐次确认开灯。

3.2 U2 自动化可被理解、可被当场停止¶

自动化是这个领域的核心价值，也是它最大的风险面。一件事在没有人下达当次指令的情况下发生了，屋里的人要回答三个问题：发生了什么、为什么是现在、怎么让它停下来。每条自动化规则都有创建者、适用条件、作用范围与停止方式。设计时必须考虑：在场的人未必是委托人，未必带着手机，也未必知道这条规则存在。

U2-1自动执行在发生处可感知必须¶

一句话：事情在客厅发生，就要在客厅能察觉，而不是只在手机里有条记录。

适用执行会改变环境状态、且用户未在当次下达指令的自动动作。

规则自动动作正在执行或已经执行这件事，必须在动作发生的物理位置可被在场的人感知，而不只在应用、日志或通知中可查。可感知的方式随后果级别变化：低后果动作可以由动作本身的可观察性承担（灯亮了就是可感知的），有物理后果的高级别动作（见 U1-6）必须在动作发生前或发生时于现场给出可被感知的提示，且该提示不依赖在场者持有终端。禁止仅以推送通知作为高级别动作的唯一可感知方式。可感知方式由 amb.automation.execution.perceptible 表达。

边界条件本条不要求为每一次自动调光都发出提示——那会把环境计算的价值反过来抵消（见 2.3）。它要求的是可感知性与后果级别相称，且高级别动作不得静默发生。夜间与免打扰情境下，应优先采用不惊扰旁人的现场表达。可延迟的动作可以连同提示一起延迟；必须先提示的动作不得先执行再补提示。高后果动作的提示不得降为零，安全联锁按其专门要求执行。

设计应用让设备本体承担提示：动作前的短促声音、状态指示灯的变化、机械动作前的预告蜂鸣。这类提示的作用对象是在场的所有人，不是账号所有者——因此它不应当出现在只有一个人能看到的地方。

验证示例

• 用户侧：让一位没有安装该应用的人待在空间中，触发一次高级别自动动作，检查他能否察觉。
• 实现侧：核对高级别动作的提示是否由设备端产生；关闭全部推送通道后重新检验。

反例做不到——门在预定时间自动落锁，唯一提示是账号所有者手机上的一条通知，屋里的人毫不知情；做过头——每一次运动感应开灯都伴随一声提示音和一条语音播报。

U2-2触发原因可在现场追溯必须¶

一句话："为什么现在开了"必须有答案：哪条规则、谁建的、什么条件。

适用具备自动化、场景、例程或情境自适应能力的产品。

规则对于任一次已发生的自动动作，产品必须能在事后向被影响的人给出可解析的触发说明，至少包含：触发它的规则或机制的名称、该规则的创建者或来源、当次满足的触发条件、以及执行时间。说明必须指向可操作的入口——看到原因之后能到达修改或停用该规则的地方，而不是只给出一句无法追查的"由智能助手执行"。当触发来自模型推断或学习结果而非显式规则时，必须如实说明其性质，并给出关闭该类推断的入口（见 U2-7）；禁止把推断性触发表述为用户设定的规则。可追溯的字段集合由 amb.automation.rule.explanation 表达。

边界条件本条不要求向用户展示模型内部依据或完整决策路径，也不要求实时解释；它要求的是事后可追溯，且追溯结果足以让人找到并改变那条规则。对不具备本产品账号的在场者，追溯义务的范围见 U4-6。

设计应用把"这次为什么发生"设计成设备与空间的历史视图，而不是规则编辑器的附属功能——用户是从"刚才那件事"出发去找规则的，不是从规则出发去找那件事。当多条规则共同促成一次动作时，一并列出而不是只显示最后执行的那条（见 U2-5）。

验证示例

• 用户侧：在一次意料之外的自动动作发生后，让用户在不询问他人的情况下找出原因并停用该规则，记录步数与成功率。
• 实现侧：核对执行日志是否保留了规则标识、作者与当次条件；检查经语音、第三方平台与厂商云触发的动作是否同样可追溯。

反例做不到——历史记录里只有"18:42 客厅灯 开"，没有任何触发来源；做过头——把完整的条件求值树摊在用户面前，一次开灯产生二十行技术日志。

依据与参考触发—动作规则的用户理解偏差见 R04、R06。

U2-3就地否决不依赖账号与网络必须¶

一句话：想让它停下来，不该先去找手机、找账号、找信号。

适用会自动执行、且执行过程可被中断或其效果可被立即撤销的动作。

规则正在执行或刚刚执行的自动动作，必须能被在场且具备该空间基本控制权的人（见 U4-2）当场停止或撤销，且该路径不得要求持有终端、登录账号、可用网络或云服务在线。对于有物理后果的高级别动作（见 U1-6），就地停止路径必须存在于动作发生的位置或其可达范围内。禁止把就地否决的可用性建立在识别否决者身份的前提上——识别失败不得成为拒绝停止的理由。产品必须分别反馈“停止请求已接收”和“输出已停止或进入规定的安全状态”，并说明已经发生且无法撤回的效果。各类动作必须声明停止生效的最长时间、物理验证方法与超时后的可行处置；设备无法安全急停时应进入已评估的受控停止过程，不得仅删除队列便显示“已停止”。就地否决入口与响应合同由 amb.control.override.surface、amb.control.override.response 表达。

边界条件本条不要求所有动作都可撤销——已经播报出去的语音、已经送出的消息不可收回；对不可撤销的动作，本条的要求转为"停止其继续执行并停止后续同类触发"。安全联锁与法定强制动作不受本条约束。本条不要求就地否决者拥有修改规则的权限，修改规则的权限归 U4。

设计应用把实体控件本身作为最可靠的就地否决入口（见 U1-1）：按一下墙壁开关就等于"这次不要"。否决与关机是两回事——用户想停的是这一次自动动作，不是让设备从此不工作，因此否决之后的状态应当由 U2-4 决定，而不是默认转为停用。

验证示例

• 用户侧：断开网络后触发一次自动动作，让一位没有账号的在场者尝试停止它，记录是否成功及所需步数。
• 实现侧：核对停止路径上是否存在鉴权、联网或云端调用环节；检查语音、第三方与厂商侧触发的动作是否共用同一停止路径。

反例做不到——自动窗帘正在下降，唯一的停止方式是打开应用登录后点"取消"；做过头——把就地否决做成任何人碰一下就永久停用该场景，家庭成员反复互相关掉对方的自动化。

U2-4否决的作用范围由人选择必须¶

一句话："这次别这样"和"以后都别这样"是两件事，得让人分开说。

适用允许用户中止、跳过或撤销自动动作的产品。

规则用户否决一次自动动作后，产品必须使本次否决、在一段时间内抑制、以及永久停用该规则成为可分别表达的选择，并让当前生效的是哪一档对用户可见。三档的可用范围按权限区分：在场且具备基本控制权的人可用"本次"与"限时抑制"（这两档不得要求账号权限）；"永久停用该规则"属于规则管理权，由具备该权限的人执行；无管理权者必须能查到该规则将继续生效的范围，并有联系有权者的路径，不得以"看不见也管不了"了事。禁止把一次否决默认解释为永久停用，也禁止在用户表达了否决之后，在下一个触发窗口以相同条件无声复现同一动作——若产品选择了"仅本次"，则至少要让用户能看出这条规则仍将再次触发，并给出一步可达的升级路径（改为长期抑制或停用）。否决范围的可选档由 amb.control.override.scope.options 表达。

边界条件本条不要求为每一次否决都弹出选择项；默认档可以由产品设定（多数场景下"本次跳过"是合适的默认），要求的是其余档位可达且当前档位可见。

设计应用在就地否决与应用内否决之间保持同一套语义：墙上按一下是"本次跳过"，长按或在应用里操作可升级为"今天不要"或"停用"。把"这条规则今晚还会再触发四次"写出来，比事后解释为什么又发生了更有用。

验证示例

• 用户侧：否决一次后不作其他操作，观察同一规则在下一个窗口是否再次触发，以及用户是否事先知情。
• 实现侧：核对否决状态的持久化范围与到期方式；检查是否存在"否决只作用于当前会话、换个入口即失效"的路径。

反例做不到——用户手动关掉一次自动开启的加湿器，规则每二十分钟重新触发一次，直到用户找到并删除它；做过头——每次否决都弹出一个含五个选项的对话框，用户为了关掉一盏灯要先做一次配置决策。

U2-5规则冲突有裁决且对人可见必须¶

一句话：两条规则打架的时候，产品要有说法，而不是看谁最后执行。

适用允许存在多条自动化规则、且多条规则可能作用于同一设备或同一环境变量的产品。

规则产品必须定义多条规则同时作用于同一对象时的裁决方式，至少覆盖：同时触发的执行顺序、相互矛盾的动作（一条开、一条关）的取舍依据、以及一条规则的动作构成另一条规则的触发条件时的处理（连锁与循环）。裁决结果必须可被追溯（见 U2-2）。在规则被创建或修改时，产品必须能识别出与既有规则的明显冲突并提示，而不是等到运行时由执行顺序决定；无法在创建时判定的冲突，必须在实际发生后可被查出。裁决策略由 amb.automation.conflict.policy 表达。

边界条件本条不要求产品自动消解所有冲突，也不要求实现完整的形式化检查；它要求的是裁决方式被显式定义、明显冲突被提示、实际冲突可被追溯。跨厂商、跨平台的规则之间无法互相感知时，产品必须说明该限制而不是假装不存在。

设计应用把"这个设备当前受哪些规则管辖"做成设备视图的一部分。多人共用的空间是冲突的高发地：两个人各自建了一条相反的规则，产品若只按执行顺序收敛，用户看到的就是设备在两个状态之间反复跳动，且双方都认为对方在捣乱（见 U2-6、U4-6）。

验证示例

• 用户侧：由两名用户分别为同一设备创建相反的规则，观察创建时是否被提示，运行时的结果是否可解释。
• 实现侧：构造 A 触发 B、B 触发 A 的规则对，检查是否存在循环抑制；核对同时触发时的顺序是否稳定且已定义。

反例做不到——"日落开灯"与"无人关灯"互相打架，灯每分钟开关一次，历史里只有一长串开关记录；做过头——为避免冲突而禁止任意两条规则触及同一设备，用户被迫把所有逻辑塞进一条巨大的规则里。

依据与参考触发—动作规则的长尾与重复见 R05；缺陷类别（含无限循环）与用户预测能力下降见 R06；通电行为与占用传感器互相拉扯的机制示例见 R24。

U2-6规则的作者与被影响者不同时须告知必须¶

一句话：一条规则作用在别人身上，那个人有权知道它存在。

适用多人共用的空间，或规则的效果会作用于规则作者之外的人的产品。

规则当一条自动化规则会改变其作者之外的人所处的环境状态时，产品必须使该规则对被影响的人可知：至少能查到它的存在、它的作用对象与触发条件（见 U2-2、U4-6）。规则涉及采集、记录或通报被影响者的行为时（到家通知、离开通知、活动记录、门锁使用记录），必须对被影响者主动告知，而不是仅作为可查项；禁止提供以"对被影响者隐藏"为目的的规则配置。被影响者对影响自身的规则享有 U2-3 的就地否决权，其能否修改或停用该规则由 U4 的权限划分决定。告知对象由 amb.automation.notice.audience 表达。

边界条件本条不要求把每条规则推送给空间中的每个人——那会制造无法承受的通知负担。它区分两档：改变环境状态的规则可查即可，采集或通报个人行为的规则必须主动告知。受法律授权的场景（如受监护的未成年人、经明确告知的工作场所记录）按适用法规执行，其判定不在本规范范围内。

设计应用把"这条规则会让谁知道我的什么"作为规则创建时的一项显式声明，并据此决定告知义务。家庭与合租场景中的权力不对等是这条规则的核心动机：一条"某人到家时通知我"的规则，从配置界面看只是一条普通自动化，从被影响者的处境看是一次持续的行踪通报。

验证示例

• 用户侧：以成员 A 的身份创建一条通报成员 B 行踪的规则，检查 B 是否被告知、能否查到、能否否决。
• 实现侧：核对是否存在可将规则对特定成员隐藏的配置项或参数；检查告知是否在规则生效时而非事后触发。

反例做不到——一条"B 的手机连上家里 Wi-Fi 时通知 A"的规则存在了半年，B 从未被告知；做过头——把全部规则的每一次触发都通报给空间中的所有人，正常的照明自动化淹没了真正需要被知道的那几条。

依据与参考多人智能家居中安装者与被动使用者的能力落差见 R07；智能家居设备被用于监控伴侣的具名案件见 R15。

U2-7学习得到的自动化不静默生效应当¶

一句话：从行为里猜出来的习惯，默认是建议，不是已经开始执行的规则。

适用从用户行为、传感数据或使用模式中自动生成自动化规则或习惯性动作的产品。

规则由系统学习或推断得到的自动化，应当默认以建议形式呈现，转为自动执行须经用户显式接受。已生效的学习型自动化应当与用户显式创建的规则同样可查、可停用、可否决，并在追溯时如实标明其来源为推断（见 U2-2）。禁止把学习型自动化呈现为用户设定的规则，也禁止对有物理后果的高级别动作（见 U1-6）采用未经显式接受的学习型自动化。用户拒绝某条建议后，必须按已声明的抑制窗口或实质情境变化条件限制再次提出，不能仅改写文案绕过拒绝；重复提出策略由 amb.automation.learned.reproposal 表达；学习型自动化的生效方式由 amb.automation.learned.mode 表达。

边界条件本条不禁止无需确认的连续性自适应——按环境光调节屏幕亮度、按人数调节新风量这类效果连续、随时可被手动覆盖且无残留后果的适配不在本条范围内。判据是：这次适配是否产生了一个会在未来自行重复的离散动作。

设计应用把"建议"与"已生效"做成两个可见的状态，并让用户能看到某条建议是基于多少次观察提出的。"你最近每晚十一点关灯，要不要自动化"是建议；直接开始每晚十一点关灯是替用户作了决定——后者在用户当晚有客人时会以一种难以理解的方式失败。

验证示例

• 用户侧：制造一段规律行为，观察产品是提出建议还是直接开始执行；拒绝一次建议后观察它是否短期内再次出现。
• 实现侧：核对学习型自动化在追溯视图中的来源标注；检查高级别动作是否被排除在自动生效之外。

反例做不到——设备观察两周后开始每晚自动落锁，用户在门外才发现；做过头——把每一次亮度微调都做成一条需要确认的建议，用户被建议卡片淹没后一律关闭该能力。

U2-8触发、执行与组合场景有明确边界必须¶

一句话：条件还成立，不代表要再做一遍；场景做了一半，也不算全部完成。

适用具备定时、事件触发、持续条件控制、连锁规则或多设备场景的产品。

规则每类触发必须明确它响应一次事件、进入某个状态，还是在条件持续时循环执行；循环执行必须有间隔、次数或持续时长上限以及退出条件。时间规则必须定义时区、时钟不可信、时间前后跳变、重复时段和错过时段的处理。相同触发的重送、网络重连与设备重启不得造成非预期重复动作。

组合场景必须列出子动作、依赖顺序和成功标准，逐项区分未提交、执行中及结果，并汇总成功、部分完成、失败或待核验。必须预先说明某一步失败或未知时，哪些后续步骤被阻止、哪些可以继续、哪些需补救；不得假设跨设备动作天然同时成功。补救必须重新核对当前状态、权限及人在此期间作出的操作，不得为了恢复场景而撤回人的新决定。全场景停止须覆盖尚未提交的步骤，并说明已提交且无法停止的部分。

触发策略由 amb.automation.trigger.policy 表达，场景处置由 amb.automation.scene.failure_policy 表达。

边界条件本条不要求所有设备支持回滚或严格同时执行，也不要求给单设备开关增加场景管理界面；真实能力不足时应缩小场景承诺。

设计应用“离家”场景中，灯已关闭而门锁结果未知，显示“灯已关，门锁待核对”，保留照明控制，不自动再开锁以模拟回滚。

验证示例

• 用户侧：场景中途停止，检查能否分辨已完成、未执行和待核验部分，是否知道下一步。
• 实现侧：重复投递同一事件、令时钟回拨、断开一个子设备并注入晚到回执，确认不会重做已完成动作或绕过手动抑制。

反例做不到——一项失败便重新执行整套“回家”场景，重复解锁与投料；做过头——为了追求全有或全无，取消所有本可独立完成的低后果动作。

依据与参考动作幂等性与同步性是不同属性，见 R31；属性声明本身不证明物理动作可以安全重试。

3.3 U3 断开之后还剩什么¶

智能环境与手机应用有一处根本差别：应用打不开，用户放下手机就是了；房子的灯打不开，人今晚就得摸黑。把一间屋子的可住性挂在一家公司的服务器与一份订阅上，是这个领域独有的一种风险，而它通常不是在设计时被决定的，是在架构选型时被默认的——先做云端控制，本地路径留作以后再说，然后就没有以后了。本原则管的是系统对网络、云服务、账号、订阅与厂商持续经营的依赖：哪些能力在这些依赖断掉之后还剩下、这件事在什么时候被告诉用户、以及厂商决定不再提供服务时设备变成什么。

U3-1核心功能有本地路径必须¶

一句话：没网、没账号、没订阅的时候，灯还得能开，门还得能开。

适用把物理环境中的基础功能（照明、出入、温控、通风、给排水、烹饪与安防）纳入系统控制的产品。

规则产品必须为其所控制的基础功能定义一条不依赖互联网、厂商云服务、用户账号与订阅状态的可用路径，并使该路径在设备正常供电时始终可达。该路径至少覆盖：开启与关闭、以及使设备回到不妨碍人正常使用空间的状态。禁止把基础功能的可用性设计为登录状态或订阅状态的函数。本地路径可以由实体控件承担（见 U1-1），也可以由本地网络内的控制方式承担；采用后者时，必须在互联网中断而本地网络仍在、以及本地网络也不可用两种情形下分别声明其可用性。本地路径的覆盖范围由 amb.offline.local_path.scope 表达。

边界条件本条不要求全部功能都有本地路径——远程查看、异地控制、跨家庭共享、语音理解与模型推断依赖远端是正常的。它要求的是被本条列举的基础功能有本地路径。本条不规定本地路径的实现形态，也不要求产品自建本地网关。

设计应用把"这台设备断网之后还能做什么"写进设备能力声明，并让它在采购、安装与故障排查三个环节都可见。在受控空间中重放一天的基本使用任务，再按附录 A 的环境要求安排现场走查。做不到这件事的产品，需要的往往不是更好的错误提示，而是改变控制链路的结构。

验证示例

• 用户侧：断开互联网但保留本地网络，完成开灯、开门、调温三项操作；随后断开本地网络重复一次。
• 实现侧：核对基础功能的控制链路是否必然经过远端；核对账号退出、订阅到期与令牌过期三种状态下这些功能的可用性。

反例做不到——家庭网络断开后，屋内的灯只能靠手机应用控制，而应用需要登录，登录需要联网；做过头——为了保证本地可用而放弃全部远程能力，用户出门后无法确认门是否锁好，被迫再装第二套系统。

依据与参考云服务终止使已售中枢不可用的公开记录与监管机构的关切见 R16；已售设备的本地控制被订阅条件限制的公开记录见 R17。

U3-2依赖在购买与安装前可获得必须¶

一句话：哪些功能离了云就没有，要在买之前说，不是坏了之后说。

适用功能可用性依赖厂商云服务、账号、订阅或持续联网的产品。

规则产品必须在用户作出实质投入之前（购买、安装、施工改造、签订服务合同）以可获得的方式说明：哪些功能需要互联网、哪些需要厂商云服务、哪些需要账号、哪些需要付费订阅，以及这些依赖分别断开时该功能变成什么状态。说明必须指名到功能而不是笼统的"部分功能需要联网"。禁止把关键依赖只写在安装完成后才能看到的位置——包装、商品页与安装说明中的表述须与实际一致。还必须分别声明云功能与安全维护的最低支持期限或已知结束日期、期限起算依据和未知部分，区分保修期、支持期与停服提前通知期。依赖声明由 amb.offline.dependency.disclosure 表达。

边界条件本条不要求产品披露技术架构或服务商信息；它要求的是从用户角度可判断的功能—依赖对应关系。本条不规定披露的载体形式。

设计应用把依赖声明做成一张功能对照表，而不是一段免责声明——用户需要回答的是"我家这面墙上要不要开槽布线"这类不可逆的问题。智能环境的投入常常包含施工：拆掉的机械门锁装不回去，这使购买前的披露比一般软件产品更重要。

验证示例

• 用户侧：在不安装产品的情况下，仅凭公开可得的材料判断"断网后这台设备还能不能开关"，记录判断是否与实测一致。
• 实现侧：逐项核对商品页、包装与安装说明中的功能表述，检查是否有依赖未被提及的功能。

反例做不到——门锁商品页强调"手机开门"，断网后不能远程开门这件事只在应用内的帮助中心提到；做过头——用一份逐条列出全部依赖的技术清单替代可读的说明，用户看完仍答不出"停电了我进不进得去"。

U3-3降级是已定义状态，不是故障必须¶

一句话：断网不是错误弹窗，是产品早就想好的一种运行状态。

适用会因网络、云服务或设备离线而失去部分能力的产品。

规则产品必须把降级运行定义为一种已命名、可进入、可退出的正常状态，而不是一系列错误分支。降级状态必须规定：哪些能力保留、哪些能力暂停、暂停期间用户的操作被如何处理（拒绝、排队、还是本地生效待同步）、以及退出降级时如何与远端收敛。禁止在降级状态下把不可用的能力呈现为可用，也禁止把降级期间的用户操作静默丢弃。重连时必须先核对当前设备状态、有效授权、手动抑制和触发条件，再决定继续、取消或请求处理。排队命令必须有失效条件与可见取消入口；过期命令、已撤销授权和已否决动作不得补执行，结果未知的非安全可重复动作不得重发。多个设备的恢复须控制并发，避免冲击与连锁触发。降级与重连策略由 amb.offline.degraded.profile、amb.offline.reconnect.policy 表达。

边界条件本条不规定降级应保留哪些具体能力——那由 U3-1 与产品定位决定。本条不要求为每一种依赖组合定义独立的降级档，但降级状态必须能被用户区分于"设备坏了"。

设计应用把降级做成设备与空间的一种可见状态，并让它说明白当前还能做什么，而不是罗列做不到什么。用户在断网时最需要的信息是"我现在还能开灯"，不是"连接失败，请检查网络"。排队待同步的操作要有可见的取消入口，避免网络恢复时一次性执行一串过期指令。

验证示例

• 用户侧：断网后使用产品十分钟，记录用户能否说出当前哪些功能可用；恢复网络后检查此前的操作如何被处理。
• 实现侧：核对降级状态是否有显式表示并被界面层读取；注入"网络在但云服务不可用"与"云服务在但设备离线"两种情况，检查是否被区分。

反例做不到——断网后每次操作弹出"网络错误"，用户无法判断哪些还能用；做过头——为了标示降级而在断网期间禁用全部界面元素，包括本可正常工作的本地控制。

U3-4服务终止有提前量与终态说明必须¶

一句话：服务要停了，得提前说，还得说清楚设备之后变成什么。

适用设备功能依赖厂商持续提供服务的产品，包括云服务停止、产品线终止、账号体系合并与固件停止维护。

规则厂商终止支撑设备运行的服务时，必须在生效前给予提前告知，并同时说明设备在服务终止后的终态：哪些功能保留、哪些功能消失、是否可迁移至其他控制方式、以及用户已有数据的导出方式、开放时点与截止时间（含终止后是否仍可导出）；导出窗口必须在服务终止前实际可用。禁止在终止生效后才告知，也禁止只告知"服务将停止"而不说明设备变成什么。提前量应当与用户的投入程度相称——涉及施工安装或不可逆改造的设备适用更长的提前量。若终态是设备失去全部智能功能，必须明确说明其是否仍保留基础的非联网功能。提前量与终态说明由 amb.offline.discontinuation.notice 与 amb.lifecycle.end_of_support.terminal_state 表达。

边界条件本条不禁止厂商终止服务，也不规定具体提前量的时长；它要求的是提前量存在、由产品按投入程度设定并记录依据，以及终态被说明。因安全漏洞、法律要求或不可抗力导致的紧急停服不受提前量要求约束，但终态说明与数据导出义务仍然成立。

设计应用把终态设计成一个产品决定而不是一个后果：设备在服务终止后回落为本地可用、开放给第三方控制、还是彻底失效，是可以在设计阶段选择的。一台在服务终止后仍能被墙壁开关控制的灯，与一台变成塑料壳的灯，差别在 U3-1 的架构选择上，不在停服公告的措辞上。

验证示例

• 用户侧：检索该产品线过往的停服记录，核对当时的提前量与终态说明是否与本条一致。
• 实现侧：核对是否存在可在不发布固件更新的情况下远程使设备失效的服务端开关；检查数据导出路径在服务终止后是否仍可用。

反例做不到——中枢设备在公告后数周停止工作，用户在设备失灵当天才知道；做过头——为避免终止承诺而永不下线任何服务，把停止维护的旧固件长期留在运行中，安全风险由用户承担。

依据与参考停服使设备不可用的公开记录见 R16、R18、R19；设备生命周期相关的官方指导文件见 R25、R26（后者正文本次未取得）。

U3-5已具备的本地能力不被追溯回收应当¶

一句话：已经装在墙上的东西，不该在某天更新后需要续费才能开灯。

适用已售出并已安装的设备，其功能可被固件更新或服务端策略改变的产品。

规则设备售出时已具备的本地可用功能，应当在其后续的固件更新与服务端策略变更中保持可用，不因新增订阅、账号策略调整或商业模式变更而被回收。禁止通过固件更新把此前无需订阅即可使用的基础功能（见 U3-1 列举范围）转为订阅项；确需调整的，应当对已售设备保留原有功能，或在变更前提供可执行的替代路径与退出选择。变更涉及功能移除时按 U6-5 告知。本地能力的变更策略由 amb.offline.local_path.regression_policy 表达。

边界条件本条不禁止对新增功能收费，也不禁止因安全原因移除存在漏洞的能力——后者应当说明原因并给出替代路径。云侧能力（远程访问、异地共享、模型推断）的商业条件调整不在本条范围内。

设计应用把"售出时的功能基线"作为设备固件的一项可核对记录，让后续变更能与之比对。这条规则的实际约束对象是商业决策，不是工程实现——因此它需要在功能规划阶段就有人负责回答"这项能力属于已售基线吗"。

验证示例

• 用户侧：在一台已使用一年以上的设备上，核对其当前可用的本地功能与购买时的说明是否一致。
• 实现侧：核对固件发布流程中是否有针对已售基线的比对环节；检查服务端是否可在不更新固件的情况下禁用本地功能。

反例做不到——一次固件更新后，此前免费的本地录像回看需要订阅才能使用；做过头——为不动已售基线而拒绝所有涉及该功能的安全修复，把已知漏洞留在设备上。

依据与参考已售中枢被追加订阅条件、并以失去固件安全更新为代价的公开记录见 R17。

U3-6安全相关功能不依赖单一远端必须¶

一句话：烟感、门锁与报警的基本功能不押在一个云服务上。

适用承担火灾探测、燃气泄漏探测、入侵报警、紧急呼叫、出入口控制或医疗辅助提醒的设备与系统。

规则安全相关功能的本地探测与本地告警必须在互联网、厂商云服务与账号体系全部不可用时仍然成立，不得以远端可用为前提。需要外发的环节（推送通知、接警、呼叫）不可用时，必须以本地方式表明该环节失效，禁止在外发失败时静默处理。安全相关功能的可用性与其依赖必须在 U3-2 的依赖声明中单独列出。安全相关功能的独立性要求由 amb.offline.safety.independence 表达。

边界条件本条不替代消防、燃气、电气与安防领域的强制性标准与认证，这些标准优先适用；本条也不要求产品自行承担接警服务。本条不禁止安全功能具备云侧增强能力，要求的是基础探测与本地告警不因云侧失效而失效。

设计应用把"本地告警"与"外发通知"设计成两条独立链路，各自有独立的失效表示。用户对安全设备的心智是"它一直在守着"，因此一个已经离线三天却仍显示正常的传感器，比一个明确显示离线的传感器更危险。离线本身应当被主动告知，而不是等用户去查。

验证示例

• 用户侧：断开互联网后触发一次探测（测试按钮或标准测试方法），检查本地告警是否响起；检查用户是否被告知通知无法送出。
• 实现侧：核对探测判定是否在设备端完成；注入云服务不可达、推送通道失败与账号失效三种情况，检查各自的本地表现。

反例做不到——燃气报警器把判定放在云端，断网后传感器仍在工作但不再鸣响；做过头——把所有非安全设备也按安全等级设计，每台智能插座离线都触发一次高优先级告警。

3.4 U4 空间里的控制权¶

一个物理空间里的人不对等，这是本领域与个人设备产品最大的差别。有人付了账单，有人只是住在这里，有人来做保洁，有人来住三天，有人是这家的孩子。他们对同一盏灯、同一把锁、同一个摄像头的正当诉求不同，而多数产品把这套关系压缩成了"账号所有者与被共享者"两档。这条原则管的是谁能控制这个空间中的设备，以及在场者之间的控制关系：权限如何按身份与期限划分、在场的人保有什么不可被远程剥夺的最低控制、以及这套关系对身处其中的人是否可见。

U4-1控制权与在场分别定义必须¶

一句话：人在房间里不等于有权限，有权限也不等于必须在房间里。

适用允许多人控制、或允许远程控制的空间与设备。

规则产品必须把在场（人此刻处于该空间中）与控制权（人被授予对某设备或某空间的操作资格）定义为两个独立的量，并显式规定二者如何共同决定一次操作是否被允许。至少必须回答：远程操作在空间中有人时是否受限、在场但无账号的人拥有哪些操作、以及在场判定失败时按哪一档处理。在场判定的失败必须回落到不损害在场者的一档——禁止把"检测不到人"直接等同于"空间中无人"并据此执行有物理后果的动作。角色与在场的组合方式由 amb.access.role.model 与 amb.access.presence.binding 表达。

边界条件本条不要求产品实现人体在场检测，也不要求所有操作都核验在场。不具备在场检测能力的产品按"在场未知"处理并据此设定回落，同样满足本条。本条不规定角色的数量与命名。

设计应用把在场当作一个三值而不是布尔值：有人、无人、未知。多数事故来自把"未知"当成"无人"——传感器视角被遮挡、人坐着不动超过超时时长、宠物与人无法区分。"离家模式"由手机位置触发而屋里还有人，是这个领域最常见的一类失败，它的根因是把一台设备的位置当成了全部住户的在场状态。

验证示例

• 用户侧：让一人静坐在传感器覆盖区内超过其超时时长，触发依赖"无人"的自动化，观察结果。
• 实现侧：核对在场是否具备"未知"取值并被下游读取；核对远程操作是否读取在场状态。

反例做不到——最后一台手机离开地理围栏即执行"离家"场景，屋里的老人被关掉了空调与照明；做过头——所有操作都要求先确认在场，用户在外地无法为家人打开空调。

U4-2在场者对影响自己的设备保有基本控制必须¶

一句话：住在这里的人必须能关掉正在照着自己、吹着自己、响在自己耳边的东西。

适用会对在场者产生直接物理作用的设备，以及部署在个人私密生活区域的非安全用途采集设备。

规则合法使用该空间且正在受影响的人，包括住户、短住者、访客和工作人员，无论其在产品中的账号角色如何，必须能就地停止正在直接作用于自己的设备输出，至少包括：使其停止、使其静音、以及使其在一段时间内不再自动重复（见 U2-4）。

在私密生活区域（卧室、卫浴、更衣与个人房间）内，合法使用该区域的人对该区域内的非安全用途采集（影像、录音、持续人体识别）同样保有停止能力，其边界与验证按 U5-4 的"停止路径"执行。该能力不得要求账号权限、不得被远程操作者覆盖、也不得被管理员配置关闭；共用的安全设施（烟感、燃气、紧急呼叫、门禁）与运营方保留控制的空间级设施不在此列，其例外须说明设施性质、保留控制的理由与可行的求助路径；涉及安全功能时按 U3-6 声明。长期身份或管理员角色不得被配置成撤销他人既有基本控制的手段。本条的基本控制不包含修改规则、增删设备与查看历史，那些由角色权限决定。基本控制的范围由 amb.access.occupant.baseline 表达。

边界条件本条不赋予在场者对整个空间的控制权，也不适用于安全联锁、法定强制动作与消防设备。在酒店、办公、租赁与共享空间中，运营方可对空间级设施（中央空调、公共照明、门禁）保留控制，但对直接作用于个人的设备仍适用本条。成员角色可以决定规则管理权与历史访问权，但不得以入住时长、未注册或访客标签取消对直接作用于自身设备的基本控制。

设计应用把这项控制绑定在设备本体或房间内，而不是绑定在账号上——因为需要它的人恰恰是账号体系里没有位置的那个人。孩子、老人、伴侣、合租者与被照护者，都可能是这个空间里没有管理员权限的人；一个只有付费账号持有者才能关掉的卧室摄像头，在设计上就是一件施加于他人的设备。

验证示例

• 用户侧：以无账号的家庭成员身份，尝试关掉正对着自己的摄像头、正在播放的音箱与正在吹的风口，记录是否成功。
• 实现侧：核对是否存在可让管理员关闭在场者基本控制的配置项；检查远程指令是否能覆盖就地停止的结果。

反例做不到——卧室摄像头只有账号所有者能关闭，同住的人只能拿东西挡住镜头；做过头——任何在场者都能永久停用空间中的全部安防设备，独居老人的紧急呼叫被来访者关掉。

依据与参考多人智能家居中的角色落差与故障时被动使用者的处境见 R07；旁观者对设备控制权的诉求见 R09（仅核验摘要）。

U4-3临时与受限身份有范围与期限必须¶

一句话：客人的权限要有边界，也要有到期这件事。

适用允许把控制权授予非长期成员（访客、租客、保洁、维修、临时看护、短租住客）的产品。

规则产品必须支持带范围与期限的授权：授权时必须能限定可控制的设备或空间范围，并能设定整体到期时点；重复时间窗口与使用次数是有效期内的附加限制，不能替代整体到期。禁止默认授予全部管理权或提供无法终止的临时授权。设备须按可信时间执行到期；时钟不可信时，只有能证明仍在有效期内才可继续授予的控制，否则拒绝该临时凭证并给出可行替代路径，不得无限延长。此限制不得妨碍法定疏散与独立的基本控制。授权到期或被撤销后，被授权者对相应设备的控制、历史查看与通知接收必须同时终止（见 U4-4）。授权的范围与期限由 amb.access.grant.scope 与 amb.access.grant.ttl 表达。

边界条件本条不规定角色的分档方式，也不要求所有产品都提供细粒度授权；能力有限的产品可以只提供"全部设备 + 固定期限"一档，但期限必须存在且可执行。本条不覆盖法定的租赁与雇佣关系中的权利义务。

设计应用让创建授权时就必须回答期限，而不是把它做成一个可选的高级设置。授权的默认期限应当取有限的一档，而不是永久——因为忘记撤销是常态，而记得撤销需要一个人在几个月后主动想起某件事。授权的证据（临时密码、二维码、钥匙卡、语音短语）本身也应当随授权一并失效。

验证示例

• 用户侧：创建一次两小时的保洁授权，到期后用被授权者的身份尝试开门、查看历史与接收通知。
• 实现侧：核对到期是否由服务端与设备端共同执行；检查离线状态下已发放的临时凭证是否仍然到期失效。

反例做不到——给短租住客的门锁密码在退房后仍然有效，需要房东手动删除；做过头——把每一位家庭成员都做成需要每月续期的临时授权，一位成员出差回来发现自己进不了家门。

U4-4权限回收的生效范围可核验必须¶

一句话：搬走、离职、分手之后，能不能进这个门要当场有答案。

适用允许撤销他人控制权的产品。

规则撤销一个人的控制权时，产品必须让操作者当场知道撤销是否已经生效，并区分三种状态：已在全部相关设备上生效、部分设备待生效（离线设备、本地凭证未同步）、以及无法确认。待生效的部分必须列出具体设备与生效条件，并在生效后可被核实。禁止把"从成员列表中移除"呈现为已完成的权限回收。撤销必须及于该人此前获得的独立凭证（临时密码、钥匙卡、绑定的语音档案、已授权的第三方平台连接）与其接收通知的资格。回收的核验方式由 amb.access.revocation.mode 表达。

边界条件本条不要求所有设备都能即时回收——机械钥匙、已复制的实体凭证与已导出的数据无法通过软件回收；这类限制必须被明确说明，而不是被回避。本条不规定回收的时限，但待生效状态必须可见且有已定义的处理方式。

设计应用把权限回收设计成一次有回执的操作而不是一次列表编辑。这条规则的使用场景往往带有紧迫性与安全含义：分手、离职、纠纷、房屋交割。在这些时刻，用户需要的答案是"他现在还能不能开这扇门"，而"已从家庭中移除"回答不了这个问题。无法回收的部分（如已被记住的机械钥匙位置、已知的门锁密码）应当被主动提示需要另行处理。

验证示例

• 用户侧：在一台设备离线的情况下移除一名成员，检查界面是否指出该设备待生效；设备恢复联网后核实其是否真的失效。
• 实现侧：逐项核对被撤销者的凭证、第三方连接、通知订阅与历史访问是否同步失效；检查是否存在绕过成员体系的直连控制路径。

反例做不到——前住户被移出家庭一个月后仍能通过此前配对的音箱开门；做过头——一次误操作的权限回收导致全屋设备重新配网，房主自己也被锁在门外。

依据与参考智能锁在离线时无法更新访问控制列表、被撤销者仍可开锁的机制见 R13；亲密关系监控的手段分类见 R14（仅核验摘要）；厂商自述的移除后残留权限见 R21。

U4-5空间不止一个控制入口应当¶

一句话：一个人的账号丢了，整座房子不该跟着锁死。

适用把空间的管理权集中于单一账号或单一设备的产品。

规则一个空间的管理控制应当不止依赖一个人的账号、一台设备或一个凭证：产品应当提供至少一条在主管理者不可用（账号丢失、设备损坏、本人失能或去世、关系破裂）时仍能恢复空间控制的路径，并在设置阶段说明该路径。禁止把恢复路径设计为必须由主管理者本人发起——那在主管理者不可用时不成立。恢复路径可以是第二管理员、可离线执行的物理重置、或有身份核验的人工流程；采用物理重置时必须说明其后果（见 U6-4）。恢复路径不得被实现为可绕过 U4-4 权限回收的后门：已被撤销控制权的人不因恢复路径而重新获得控制。管理入口的冗余方式由 amb.access.admin.redundancy 表达。

边界条件本条不要求所有产品提供人工客服恢复；一条可由在场者执行的物理重置路径即可满足，只要其后果被说明。本条不规定恢复路径的身份核验强度，该强度应当与被恢复的控制范围相称。

设计应用在空间创建阶段就提示设置第二管理者，而不是等到出问题时才提供找回流程。这条规则的现实场景包括继承与照护：一位老人的智能门锁绑定在其子女的账号上，另一位子女在紧急情况下无法进入；一位独居者去世后，其家人无法关掉仍在运行的自动化。

验证示例

• 用户侧：模拟主管理者账号完全不可用，尝试由空间中的另一人恢复对设备的控制，记录路径与所需材料。
• 实现侧：核对恢复路径是否需要主管理者参与；核对恢复后被撤销者是否仍然处于撤销状态。

反例做不到——房主账号被盗后，家中门锁与摄像头全部由攻击者控制，本人无法通过任何路径夺回；做过头——把恢复路径做成任何在场者长按设备十秒即可接管，入室者可以直接接管全屋。

U4-6谁能控制与谁能看见，对在场者可查必须¶

一句话：屋里的人有权知道这个空间里谁在控制、谁在看。

适用多人共用的空间，或允许非在场者远程控制、远程查看的产品。

规则合法使用该空间的人必须能查到与自身区域相关的信息：当前有哪些人对这个空间或其中的设备拥有控制权、各自的范围、以及哪些设备的数据可被谁访问。接收方必须能解析到具体服务、组织或受限可查清单；不要求公开私人联系方式。禁止提供以对空间内特定成员隐藏其权限或隐藏其访问记录为目的的配置。远程访问正在发生（有人正在查看摄像头、正在收听、正在对讲）时，该事实应当在设备本体上可被在场者感知（见 U5-1）。可查范围由 amb.access.roster.visibility 表达。

边界条件本条不要求向在场者公开他人的账号身份信息、联系方式或位置；可查的对象是权限与访问的存在与范围，不是他人的个人资料。本条不适用于依法进行且不得告知的执法访问，其判定不在本规范范围内。共享办公与公共空间中，运营方的运维访问可以按角色汇总呈现，但不得表述为"无人可访问"。

设计应用把这份可查清单做成空间的属性而不是账号的设置项，并让它在设备本体可达的位置有入口——需要它的人可能正是那个没有管理员权限的人。"这个房间里有谁能看到我"是一个在场者的问题，不是一个账号所有者的问题。

验证示例

• 用户侧：以无管理权限的家庭成员身份，尝试查出谁能控制卧室设备、谁能查看客厅摄像头，记录路径与结果完整性。
• 实现侧：核对是否存在可隐藏某成员权限或访问记录的配置；检查第三方平台接入与厂商运维访问是否被计入清单。

反例做不到——一名家庭成员在两年后才发现另一人一直能远程查看客厅摄像头；做过头——把每一次远程查看都以全屋语音播报的方式通报，正常的家人问候变成一次广播事件。

依据与参考安装者掌握他人不掌握的设备信息见 R07；旁观者与所有者之间的隐私预期张力见 R09（仅核验摘要）；厂商侧的角色与可见范围划分见 R21、R22。

3.5 U5 采集发生在人身上¶

传感器不问对方有没有装这个应用。这个领域里被采集的人和购买产品的人不是同一群人——客人、保洁、租客、孩子、快递员、邻居、路过的人都可能落在传感范围内，他们没有账号、没同意过任何条款、也没有入口去看自己被记录了什么。这条原则管的是环境中持续进行的传感采集本身：正在采集这件事能否从设备被察觉、采集范围能否被静默扩大、以及停止采集意味着什么。本原则同时约束采集的可知性、用途边界、最小化、可停止性，以及本地和远端数据的保存与清除。

U5-1采集状态可从设备本身感知必须¶

一句话：摄像头有没有在拍，要能从摄像头上看出来，不是从应用里查出来。

适用具备摄像、录音、持续测距、雷达或其他人体感知能力的设备。

规则设备正在采集这件事必须能从设备本体被在场的人感知，方式包括但不限于指示灯、屏幕提示、机械遮蔽件的位置或可闻的提示音。该指示必须与实际采集状态可靠联动，不能仅表示电源或网络在线，不能由上层软件把正在采集改画为未采集；禁止提供关闭采集指示而保留采集的配置。指示必须能区分至少两档：未在采集、正在采集；具备本地处理与外发两种模式的设备应当能进一步区分。远程访问正在发生时按同样方式指示（见 U4-6）。指示须在实际安装位置、照明和噪声条件下可理解；关键状态不得仅靠颜色区分，现场基本控制不得只有语音或精细触控一种方式。指示方式由 amb.sensing.indicator.mode 表达。

边界条件本条不要求指示在任何光照与噪声条件下都被察觉，也不要求指示不可被物理遮挡——用户自己贴上胶带不构成违规。它要求的是产品自身不提供隐藏采集的能力。夜视场景下的指示强度可调整，但不得降为零。本条不覆盖依法进行的隐蔽取证设备，其适用规则不在本规范范围内。

设计应用把指示做成采集链路的一部分：镜头通电即亮、麦克风阵列取音即亮。"应用里显示摄像头已关闭"与"摄像头真的没在拍"之间的差距，正是这条规则要消除的东西——它对在场者的价值完全取决于该指示是否可被信任。带物理遮蔽件的设计在这一点上有结构性优势：遮蔽状态本身就是可核验的。

验证示例

• 用户侧：让一位不熟悉该产品的人站在设备前，判断它此刻是否在采集，记录判断正确率。
• 实现侧：核对指示是否由采集部件驱动；尝试通过接口单独关闭指示而保留采集，检查是否可行。

反例做不到——摄像头的指示灯由应用层控制，第三方固件可以关掉灯继续录像；做过头——为强调采集状态而让指示灯常亮刺眼，用户第一件事就是拿胶带贴上，指示反而永久失效。

依据与参考访客与居住者在采集理解上的角色差异见 R08；旁观者的界定与设计诉求见 R09（仅核验摘要）。

U5-2采集范围与推断粒度不得静默扩大必须¶

一句话：一次更新不能把测温的传感器变成认人的传感器。

适用具备传感能力、且其能力可被固件更新或服务端策略改变的设备。

规则设备的采集范围（采集哪些信号、覆盖哪些物理区域、采样频率）与推断粒度（从信号中得出何种结论：有无人、人数、位置、姿态、身份、活动类型、生理状态）必须被显式声明，且任一项的扩大必须在生效前告知并取得用户的显式接受。禁止以固件更新、服务端策略或新增功能的方式静默扩大二者。已具备的传感硬件不构成使用其全部能力的授权——设备装有麦克风阵列不等于可以开始做声学事件识别。采集范围与推断粒度由 amb.sensing.scope 与 amb.sensing.inference.granularity 表达。

边界条件本条不禁止扩大能力，要求的是扩大经过告知与接受。修复缺陷、提高既有推断的准确度、以及在既有粒度内的实现改动不属于扩大。用户拒绝扩大时，产品应当保留其原有功能而不是使设备不可用（见 U3-5）。

设计应用把粒度做成一个分级枚举而不是开关：有人/无人是一档，人数是一档，位置是一档，身份是一档，活动与生理状态各是一档。级别之间不是渐进增强，是性质变化——从"这个房间有人"到"这个房间里的人是谁"，跨越的是可识别性的边界，需要单独的理由（见 U5-5）。

验证示例

• 用户侧：在一次固件更新前后，对照设备的采集与推断声明，检查是否有未告知的变化。
• 实现侧：核对推断粒度是否有显式声明并被下游读取；检查新增功能上线流程中是否有粒度变更的评审环节。

反例做不到——存在感应器在一次更新后开始区分个体并生成个人活动记录，用户从未被告知；或以"从身份识别降级为匿名生理监测"为名新增了此前不存在的生理采集能力；做过头——把每次算法优化都作为粒度扩大重新征求同意，用户在反复的同意请求后关闭全部传感功能。

U5-3非用户第三方的采集有告知与最小化应当¶

一句话：客人、清洁工和快递员没有账号，但同样被拍到了。

适用采集范围会覆盖非本产品用户的设备与空间，包括入户门铃、室内摄像头、语音终端与人体传感器。

规则对没有本产品账号、也未作出任何选择的在场者，产品应当：使采集在设备本体可被察觉（见 U5-1）；为空间管理者提供可执行的告知手段（门口标识、进入时的语音提示、访客模式）；并在这类人群可能在场的情形下默认采用较小的采集范围与较粗的推断粒度。禁止把非用户在场者的信号用于建立跨次识别的个体档案，除非该人已被告知并作出选择。产品必须分别评估每一类部署空间中的被影响者、用途、私密程度与控制关系，并据此确定最小必要的默认档；评估结论相同时，不同空间类型可以采用同一档——本条要求的是逐类评估与记录，不是形式上的取值必须不同，更不得为制造差异而在某一处扩大采集。混合空间（居家办公、住宅内的短租房间）按各项实际约束分别裁决，不以"住宅"标签覆盖工作场所或访客保护。旁观者相关的默认与告知手段由 amb.sensing.bystander.notice 与 amb.sensing.bystander.default_profile 表达。

边界条件本条不要求产品替空间管理者履行法定告知义务，也不判定其法律效力——工作场所监控、公共场所影像采集与录音的合法性由适用法规判定，本规范不替代该判定。本条不禁止安防用途的影像采集；它约束的是默认档、可察觉性与跨次识别。

设计应用把"这台设备装在哪种空间"作为安装时的一项必答配置，并让它真的进入默认值的评估——评估之后取值相同是合法结论，未作评估才是缺陷。面向住宅的默认档不适合直接用在共享办公与出租房：后者的在场者与设备所有者的关系完全不同。访客模式（临时降低采集粒度或暂停采集）是一项可以提供给空间管理者的具体能力，它把"要不要告诉客人"变成"客人在的时候少采一点"。

验证示例

• 用户侧：让一位从未使用该产品的人进入空间，记录他能否察觉采集、能否得知采集内容、以及是否被建立了可跨次识别的记录。
• 实现侧：核对不同空间类型是否分别评估，默认档是否与评估结论一致；检查未注册人员的特征是否被持久化用于跨次匹配。

反例做不到——门铃摄像头默认为所有出现过的面孔建立档案并命名，被拍到的邻居毫不知情；做过头——每次有人经过就播放一段冗长的采集告知，居民把设备的提示音永久关掉。

依据与参考访客的心智模型缺口见 R08；短租住客与房东在数据类型上的分歧见 R10；商业楼宇中在场者的知情缺口与告知偏好见 R11；住宅与办公场景不可互换的论证见 R03。

U5-4停止采集有边界明确的路径应当¶

一句话："已关闭"到底关掉了什么，要说得出来，也要能验证。

适用提供关闭、暂停或静音传感能力的产品，以及按 U4-2 必须提供私密区域停止能力的设备。

规则产品提供的每一种"停止采集"路径，应当明确其实际边界：停止的是采集、是上传、是留存、还是仅仅是界面展示；停止是持续到手动恢复、到期恢复、还是随重启恢复；以及停止期间哪些功能随之不可用。禁止把仅停止展示或仅停止上传的操作表述为已停止采集。至少应当提供一条可被在场者验证的停止方式——其效果能从设备本体看出来（见 U5-1）。U4-2 要求的私密区域停止能力属于必须项，不能按本条的应当级别省略。其停止必须实际阻止所声明的采集，并保持到在场使用者显式恢复；断网、重启、更新与远程命令不得绕过。其他可定时恢复的暂停须在操作时说明恢复条件，恢复时仍有 U5-1 的现场指示。停止路径的边界由 amb.sensing.stop.scope 表达。

边界条件本条不要求所有设备都能完全断开传感器供电，也不要求停止采集不影响功能——关掉麦克风后语音唤醒失效是合理的，需要被说明而不是被隐藏。安全相关设备（烟感、燃气、紧急呼叫）的探测可以不提供停止路径，但这一事实必须被声明（见 U3-6）。

设计应用用动词而不是形容词命名这些开关："暂停录像"与"隐藏画面"是两件事，"麦克风静音"与"不再上传语音"也是两件事。当用户想要的是"这段时间别记录我"时，一个只停止了展示的开关比没有开关更糟——它制造了一种被验证过的错误信心。

验证示例

• 用户侧：执行每一种停止路径，事后核对该时段是否仍有数据被采集、上传或留存。
• 实现侧：逐项核对停止路径在链路上的作用点；检查重启、更新与重连后是否按声明保持或恢复；私密区域的保护性停止保持至使用者显式恢复。

反例做不到——"关闭摄像头"只是在应用中隐藏了实时画面，录像与上传照常进行；做过头——把静音做成必须物理断电，用户每次接电话都要去拔插头，最终不再使用该功能。

U5-5在场检测与身份识别分开必须¶

一句话：知道"有人"就够用的场合，不要去认"是谁"。

适用使用人体感知能力驱动自动化、路由提醒或调整环境的产品。

规则产品必须把在场检测（判断空间中有没有人、有几个人）与身份识别（判断这个人是谁）作为两项分别启用、分别授权的能力，禁止以在场检测的名义启用身份识别，也禁止把身份识别作为在场检测的必要实现手段。仅需在场信息的功能不得读取身份识别结果。身份识别启用后，必须能被单独关闭且关闭后在场检测仍然可用。未被识别的人不得因此被拒绝 U4-2 的基本控制（见 U2-3）。两项能力的分离由 amb.sensing.presence.identification 表达。

边界条件本条不禁止身份识别——出入口控制、个性化响应与多人场景下的提醒路由都有正当用途。它要求的是二者不被捆绑启用，且弱能力的功能不搭乘强能力的实现。本条不规定身份识别的技术方式，声纹、面容、随身设备与手动选择在本条下同样适用。

设计应用在功能设计阶段就问一句"这个功能需要知道是谁吗"。大多数环境自动化只需要在场：开灯、调温、通风、节能都不依赖身份。需要身份的是提醒路由与个性化，而那些功能应当各自承担启用身份识别的理由。

验证示例

• 用户侧：关闭身份识别后检查照明、温控与通风类自动化是否仍然工作。
• 实现侧：逐项核对读取身份识别结果的功能清单；检查是否存在以在场为名采集并保留可识别特征的路径。

反例做不到——走廊灯的感应功能要求先为每位家庭成员录入面容；做过头——为避免识别而关闭全部多用户能力，家庭成员的提醒全部发到同一个共用音箱上播报。

U5-6环境采集不用于对在场者的评价与差别待遇必须¶

一句话：工位传感器不是考勤机，客厅传感器不是家长监控台。

适用在工作场所、教育场所、住宅或照护场景中部署环境传感能力的产品。

规则为空间管理、能耗优化、设施调度或环境自适应而采集的数据，禁止用于对个人的评价、考核、纪律处理、定价、保险核定、信用判定与准入决定，也禁止以派生指标（在座时长、活动频次、离开次数、作息规律）间接实现同等效果。产品必须使这些用途在机制上不可达，而不是仅写入使用条款；用途扩展至评价类场景时，不得以原采集的同意作为依据（见 U5-2）。禁止用途清单由 amb.sensing.purpose.blocklist 表达。

边界条件本条不禁止在明确告知并具备法律依据的前提下开展的考勤、门禁记录与合规监控——那类系统应当以其自身的名义部署并接受相应约束，而不是由环境传感系统顺带实现。本条不判定任何具体法域下工作场所监控的合法性。照护场景中经被照护者或其法定代理人明确同意的健康监测不属于本条禁止范围，但仍适用 U5-2 的粒度约束。

设计应用把禁止用途做成数据接口层的约束：环境传感数据不向人事、绩效、教务与保险类消费方开放，聚合与去标识不作为放行的理由——在一个只有少数人的房间里，聚合数据仍可指向个人。这条规则最常被绕过的方式，是把它变成一份"管理者可导出的活动报表"，报表本身不作评价，但它的存在使评价成为默认用法。

验证示例

• 用户侧：以空间管理者身份尝试导出某一在场者的活动记录，观察产品是否提供该能力。
• 实现侧：核对环境传感数据的下游消费方清单；检查是否存在按人聚合的活动统计输出。

反例做不到——工位占用传感器的数据被用于生成员工在座率排名；做过头——为规避风险而关闭全部空间使用统计，设施团队无法判断会议室是否需要扩建。

依据与参考商业楼宇中在场者的知情缺口与告知方式偏好见 R11；工位传感器引发的争议及其节能定位见 R20（原始报道本次未取得）。

U5-7数据的用途、保存与清除可核验必须¶

一句话：停止传感、删除本机数据和删除云端副本，分别说明、分别确认。

适用保存或向外传送环境采集数据、活动历史、身份特征或推断结果的产品。

规则每类数据必须明确用途、接收方、存放位置、本地及远端的保存上限和删除路径；只做即时处理且不持久保存时也必须明确。空间管理者同意安装不代表所有在场者已同意所有用途。用途或接收方扩大须在生效前重新判断授权与告知，不能以既有硬件能力或既有账号同意直接放行。

清除须分别说明原始数据、派生特征、日志、备份与第三方副本的处理，给出已清除、待清除或无法确认的回执及未完成原因。仅解除设备绑定不得表述为数据已删除；停止上传不得隐含无限期本地缓存。离线缓存必须受保存期限和容量限制，重连后仅处理仍在有效范围内的数据。多人共用设备应当允许按主体或使用期间清除个人数据，而不必重置整间房。确需保留的数据须说明类别、理由、期限和访问限制。

数据处理策略由 amb.sensing.data.lifecycle 表达；实际记录与删除回执是运行事实。

边界条件本条不承诺召回他人已经合法导出的副本，不把假名化或聚合自动等同于匿名或已删除。具体法定保存与主体权利由项目按适用法域判断。

设计应用短住者退房时可以清除其语音记录与个人偏好，保留房间照明配置；设备脱网时，将云端删除单列为待确认。

验证示例

• 用户侧：关闭采集并执行个人数据删除，检查是否能理解两种操作的差异和未清除部分。
• 实现侧：检索本地缓存、派生特征与外部副本的处置记录；测试删除失败、备份保留与断网后重连，不得把待处理变成已完成。

反例做不到——退房后只移除账号，语音和行为特征仍被下个住客使用；做过头——删除一个人的记录必须恢复整屋出厂设置，导致其他住户失去控制。

依据与参考设备与关联服务数据删除、清除确认及共享使用情境见 R29；本条的用途与缓存要求是从空间承诺推导的设计要求。

3.6 U6 设备的归属与去留¶

一台装在墙上的设备会比一段使用关系活得更久：房子会卖、租约会到期、公司会搬家、设备会被转手、固件会被更新成另一副样子。这条原则管的是一台设备与一个空间、一个控制主体之间的归属关系及其变更：它此刻属于谁、加入时给出了什么、被移除之后还剩什么、换手时怎么才算真的交割干净、以及它的行为被远程改变时谁该被告知。

U6-1归属可解析必须¶

一句话：这台设备属于哪个空间、归谁管、数据进了谁的账号。

适用可被加入某个空间、家庭或组织的设备。

规则对空间中的每一台设备，产品必须以可核对的物理标识或定位确认建立绑定，不能仅依靠可重名的昵称或近邻信号推测所在房间，并能解析出：它归属的空间或房间、它的管理主体（哪个账号或组织持有其管理权）、它的数据接收方（其采集或产生的数据进入谁的账号与哪个服务），以及它是否同时被其他控制主体管理（多平台接入、厂商侧保留的访问、第三方集成）。这些信息必须对合法使用相应区域的人可查（见 U4-6），禁止把设备在多个控制主体下的并存状态呈现为只归属于当前查看者。归属记录的必需字段与解析来源由 amb.lifecycle.ownership.record_contract 表达；具体的账号与设备列表是运行数据。

边界条件本条不要求披露服务商的内部架构与数据处理细节，那由隐私专项管辖；它要求的是从用户角度可判断的归属关系。本条不禁止一台设备被多个平台同时管理，要求的是这一事实可被解析。

设计应用把归属做成设备详情里一段可读的答案，而不是散落在配对记录、共享列表与第三方授权页三处。"这台摄像头拍到的画面进了谁的账号"是一个在合租、租赁与照护场景中反复被问到的问题，而它常常没有一处能给出完整答案的地方。

验证示例

• 用户侧：随机选取空间中的三台设备，尝试查出各自的管理主体与数据接收方，记录能否完成。
• 实现侧：核对同时接入多个平台的设备是否在各平台侧都披露了其他控制主体的存在。

反例做不到——一台通过第三方平台接入的传感器，其数据同时上报给两家厂商，用户在任一侧都看不到另一侧；做过头——把设备详情做成一页密集的技术标识与服务地址清单，用户仍答不出"谁能看到"。

U6-2加入时的授权对象可核对必须¶

一句话：加一台设备等于给出一份权限，那份权限给了谁要看得见。

适用具备设备加入、配网、绑定或第三方集成授权流程的产品。

规则设备加入空间或授权第三方接入时，产品必须在用户确认前指名被授权的主体（厂商、平台、集成方）与被授予的能力范围（可控制哪些设备、可读取哪些数据、能否代替用户执行动作），并使二者可被核对。禁止把设备名称或界面呈现作为身份证据——名称可被任意设置，不独立证明设备或集成方的身份。授权范围应当默认取满足当前功能所需的最小一档，扩大范围须另行确认。授权披露方式由 amb.lifecycle.onboarding.grant_disclosure 表达。

边界条件本条不规定身份核验的技术手段，也不要求产品验证第三方的资质。它要求的是授权对象与范围在确认前可被用户看到。批量部署场景（办公楼、酒店、长租公寓）中，逐台确认可以由一次针对该批次的授权替代，但授权对象与范围的披露义务不变。

设计应用把授权确认页写成"你正在允许 X 做 Y"，而不是"是否添加设备"。配网过程是这个领域里少数几个用户会认真看一眼的时刻，把权限说明放在这里，比放在事后的设置页有效得多。发现附近设备不等于可以加入它，也不等于它就是它自称的那台。

验证示例

• 用户侧：完整走一遍设备加入与一次第三方集成授权，记录用户在确认前能看到的主体与范围信息。
• 实现侧：核对授权范围是否在服务端强制，还是仅在界面提示；检查是否存在加入后自动扩大范围的路径。

反例做不到——添加一个语音助手集成后，它获得了对全屋门锁的控制权，授权页只写"允许访问你的家庭"；做过头——为每一项能力单独弹出一次授权确认，用户在第七次确认后一律点允许。

U6-3移除效果与残留可查必须¶

一句话：从"我的家"里删掉，不等于它真的不再听话、不再上报。

适用允许把设备从空间、家庭或组织中移除的产品。

规则从空间中移除一台设备时，产品必须说明该操作的实际效果与残留：设备是否仍保有此前的配网信息与凭证、是否仍在上报数据、是否仍对此前的自动化作出响应、以及本地存储的数据是否仍在设备上。禁止把界面上的移除呈现为设备已恢复出厂状态。移除必须同时处理该设备参与的自动化规则、共享授权与第三方集成，并在存在待处理残留时列出。设备离线时的移除按 U4-4 的三态处理。残留声明由 amb.lifecycle.removal.residue 表达。

边界条件本条不要求移除必须清空设备——保留配网信息以便重新加入是合理设计。它要求的是保留了什么被说出来。本条不覆盖设备物理损坏或丢失后的处理，那属于 U6-4 的换手场景与安全专项。

设计应用把移除设计成一个有清单的流程：这台设备参与了三条自动化、被共享给两个人、连接着一个第三方平台，这些在移除时一并呈现并给出处理选项。留下一条引用已移除设备的自动化，会在几个月后表现为一条永远不触发的规则，而用户无从得知原因（见 U2-5）。

验证示例

• 用户侧：移除一台参与了多条自动化的设备，检查这些规则的后续状态是否可见；在移除后检查设备是否仍能被此前的控制方式操作。
• 实现侧：核对移除操作在设备端的实际作用；检查第三方集成侧的授权是否同步失效。

反例做不到——从应用中删除摄像头后，它仍连着 Wi-Fi 并持续上传画面，直到被物理断电；做过头——移除任一设备都强制清空其本地数据与配网信息，用户把设备换到另一个房间时要重新配置一遍全部设置。

U6-4换手有可执行的清除路径必须¶

一句话：房子卖了、设备转手了，前一个管理员必须真的失去控制。

适用可能随房屋、办公场地或二手交易转移给新使用者的设备。

规则产品必须提供一条可由有权接收设备的当前持有者独立执行的换手路径，执行后：前一个管理主体对该设备的控制、远程访问与数据接收终止；设备上的本地数据与凭证按声明处理；设备可被新的管理主体重新加入。禁止把换手路径设计为必须由前一个管理者配合才能完成——房屋交割与二手交易中前手常已不可联系。该路径必须能在物理接触设备的条件下执行，且不依赖前手的账号或云服务在线。物理接触本身不证明接管资格；清除流程必须防止访客或维护人员仅因短暂接触便取得管理权。设备端清除、远端删除与外部平台解除连接必须分别给回执；离线时不能验证的远端删除保持待确认。远端历史数据无法当场清除不应阻止旧凭证在设备端失效，但旧控制仍能生效时不得宣称交割完成。换手清除的效果由 amb.lifecycle.transfer.reset 表达。

边界条件本条不要求设备可被任意在场者重置——重置路径应当要求物理接触，可以要求额外的持有证明。本条不判定二手设备交易中的法律责任归属。已被前手导出的数据无法通过本条回收，这一限制应当被说明而不是被回避。

设计应用把换手做成双向的两件事：新持有者需要一条"把它变成我的"的路径，前持有者需要一条"把它从我这里清干净"的路径，二者都要能在对方不参与时完成。买下一套带智能门锁的房子却发现前房主仍能开门，是这条规则最直接的失败形态；它同样出现在办公室转租、设备二手转让与租客更替中。

验证示例

• 用户侧：在前一个账号完全不参与的情况下，把一台已绑定设备转为新账号管理，记录路径是否可完成。
• 实现侧：核对换手后前手账号侧是否仍保有该设备的访问入口与历史数据；检查设备端凭证是否被清除。

反例做不到——门锁的管理权绑定在前房主账号上，新住户只能联系厂商客服并提供购房证明；做过头——任何人长按设备按键即可完成换手，入室者可以直接把安防设备转到自己名下。

依据与参考恢复出厂设置后凭证仍留存于闪存、且本地重置未必解除云端绑定的实验见 R12；离线时撤销不生效的机制见 R13；厂商自述的移除后残留权限见 R21。

U6-5更新改变行为须提前告知必须¶

一句话：装在墙上的东西被远程改了脾气，不该等用户自己发现。

适用可通过固件更新或服务端策略改变行为的设备与空间系统。

规则当更新会改变设备既有的行为——移除或改变某项功能、改变默认值、改变自动化的触发或执行方式、改变采集范围或推断粒度（见 U5-2）、改变本地可用性（见 U3-5）——产品必须在生效前告知受影响的用户，说明变化内容与影响范围。禁止把改变行为的更新与安全修复捆绑为不可分辨的单次推送并以安全为由免除告知。安全紧急修复可以先执行后告知，但仍须告知。涉及有物理后果动作（见 U1-6）的行为变更，必须在受影响空间的使用者层面告知，而不仅告知账号所有者（见 U2-6）。变更告知方式由 amb.lifecycle.update.behavior_change_notice 表达。

边界条件本条不要求为每次更新都发布详细说明，也不要求用户可以拒绝安全修复。它要求的是行为变更被识别出来并被告知。不改变外部可观察行为的内部优化不属于本条范围。

设计应用在发布流程中设一道判断："这次更新会不会让用户在同样的操作下得到不同的结果"。答案为是就进入告知路径。智能环境的更新有一个屏幕产品没有的特点：用户不会主动打开它——一台墙面温控器可能几个月不被人查看，更新在其间悄悄改变了它的排程逻辑，用户只会体验为"最近家里怪怪的"。

验证示例

• 用户侧：在一次包含行为变更的更新后，检查用户是否在生效前收到说明，以及说明是否指出了具体变化。
• 实现侧：核对发布流程中是否有行为变更的识别环节；检查告知是否触达了非账号所有者的空间使用者。

反例做不到——一次更新把运动感应灯的默认延时从五分钟改为三十秒，用户在浴室里反复挥手；做过头——每次更新都要求全部家庭成员逐一确认后才生效，安全修复被拖延数周。

依据与参考固件升级引起的重启不应重新套用通电默认值，见 R24 的相关条款；配置变更仅由授权主体执行的能力基线见 R25。

U6-6安装、变动与维修后验证空间承诺必须¶

一句话：配对成功只证明连上了，不证明这个房间已经能放心使用。

适用安装、移动、更换、维修设备，或改变传感覆盖、房间用途与控制拓扑的产品。

规则交付自动化前必须核对物理设备与房间绑定、执行方向与范围、传感覆盖、实体控制、现场停止、采集指示和断网路径。涉及电池、校准、清洁或消耗件的能力，必须说明维护条件、负责人可达路径，以及维护逾期或部件异常时哪些承诺不再成立。移动设备、改变房间用途或维修更换后，必须重验受影响的能力；通过联网或自检不能自动代替现场验证。

维护模式必须明确影响范围、进入权限、结束条件和退出检查，不得静默停用必要告警或扩大维护人员的数据访问。退出后须复核手动抑制、撤销权限与采集边界，不能通过恢复默认设置重新启用已关闭的能力。安装与维护核对项由 amb.lifecycle.commissioning.checks 表达。

边界条件本条不规定布线、传感器选型或安全认证步骤；无对应能力的核对项可记不适用并说明原因，不强求额外传感硬件。

设计应用把客厅传感器移到卧室后，先核对实际覆盖、私密区域设置和停止入口，再允许它沿用自动化；更换窗帘电机后重新核对上下行方向。

验证示例

• 用户侧：由未参与安装的人完成开关、停止、识别采集与断网操作，核对安装交付是否足够。
• 实现侧：模拟房间绑定错误、执行方向反转、低电量与维护中断，检查相关自动化是否受限，退出后是否恢复到实际授权的状态。

反例做不到——传感器配对成功即显示“已就绪”，实际监测的是隔壁房间；做过头——更改设备昵称也要求整屋重新安装和验收。

4. 术语和定义¶

本章定义物理空间、动作、观察与控制关系中容易混淆的概念。运行事实的最小字段见第 5 章。

5. 运行事实与交付¶

本章给出落实 U1-2、U1-3、U2-2、U2-3、U2-8、U4-4、U5-7 与 U6-1 的最小记录形状，不要求采用特定数据库或协议。只收集兑现相关承诺所必需的事实，不以追溯为由扩大个人数据采集。

5.1 设计参数、实例与状态分别记录¶

“默认不补执行”是参数；“本次因已过期取消”是事实。Token 配置不能充当设备已经执行或权限已经撤回的证明。

5.2 状态按维度组合¶

5.3 最小事实记录¶

记录按动作与对象关联，不用最后一条收到的消息覆盖整个房间的状态；来源失联时保留事实时间和未知范围。给在场者的说明只展示足以理解与操作的内容，诊断细节按权限展开。

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

本清单用于检验条款是否真的生效，不新增义务：每一项的期望行为随其对应条款的适用范围、强度与例外一并解析；每个用例须写明前置条件、适用的例外分支、期望结果与证据形式；涉及【应当】级条款的，检查其偏离理由与替代验证是否被记录。记录"不适用"是合格结果，记录"没测"不是。

环境选择按后果分层：高后果注入（断总电源、切断安全设备、诱发误触发高级别动作）在受控试验环境、测试模式或等效仿真中验证；只有经风险评估的低后果部分才在真实使用空间中与住户一同执行，且须先确认该空间是否存在医疗辅助、安防、冷藏或照护依赖，并保留随时终止的手段。可感知性与理解类的用例本来就需要真实空间，按其自身风险评估安排。

另须包含一次无故障的日常走查：记录不必要的提示与确认、常用控制的步骤数、以及误停带来的代价——"做过头"一侧同样是不合格。

A.1 物理世界与实体控件

A.2 自动化的可理解与可停止

A.3 断开与降级

A.4 控制权与在场

A.5 采集与在场者

A.6 归属与去留

A.7 输入、组合场景与交付检查

A.8 正常使用与评审记录

日常走查应包含住户、短住者、无账号访客及有不同感知或操作能力的人。记录完成基本控制的成功率、步骤与耗时、对未知状态的误判、无必要提示与确认，以及错误恢复的成本。项目先定义测量方法和验收目标，不把示例数值当行业阈值，也不以平均分抵消一项必须要求的失败。

每条适用要求记录：规则编号、适用条件、实现机制、用例、预期、实际观察、证据位置、结论和责任人。结论使用“通过／不通过／不适用／待验证”；不适用须说明实际能力原因。设计文档检查、实现验证、使用者理解验证分别记录，不能以文档完整替代现场证据。

必须项未通过或关键项待验证时，不宣称相关能力满足本规范；可限制未验证自动化的范围，但保留已经有人依赖的基础控制与安全功能。发生误触发、错误停止或残留访问后，先控制影响，再将该轨迹纳入对应检查。

A.9 分类检验

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

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

B.1 约束词的判据

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

标「应当」的五条（U2-7、U3-5、U4-5、U5-3、U5-4）包含可按情境取舍的要求：偏离要留痕并接受替代验证；其中显式的必须与禁止子句仍是硬约束，不能随整条一起豁免。其中 U3-5 与 U4-5 的偏离通常源于商业模式或架构约束，理由应当写明该约束而不是写"暂不支持"。

B.2 仍需项目实证的三处

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

1. U1-4 与 U1-5 缺少可迁移的默认值。手动优先应当持续多久、断电恢复后哪一档是正确默认，都随设备类别、居住习惯与气候条件变化，所列来源未提供可跨产品引用的实测基准。本规范因此只要求这些值被显式定义并记录依据，不给数值——这也是本规范中最容易被形式化应付的两条。
2. U5-3 的旁观者告知效果未经验证。"门口贴标识""进入时语音提示""访客模式"这三种手段在真实使用中各自有多少人真的因此知情，所列来源未提供可比较的效果证据。本规范给出的是义务与判据，不是已验证有效的手段清单。
3. 多人偏好冲突没有通用最优解。合法在场者共享温控、光照或声音时，舒适度、健康需求与管理责任可能不同。本规范要求裁决可知、基本控制不被取消，但具体范围与替代路径仍需在实际空间验证。

B.3 本规范未做的事

不给通信协议与互操作方案，不给设备形态与安装规程，不给传感器选型，不给具体时长与阈值，不给权限模型的字段设计，不判定任何法域下工作场所监控、影像采集与录音的合法性。这些是产品、工程与法务的决定；本规范只规定这些决定必须被作出、必须可被检验，以及哪些取值不被允许。

B.4 来源

完整的来源对照、阅读范围与证据限制见 reference.md。规范中的条款不因为某个产品这样做过就成立；产品做法是"这类机制在真实产品中可行"的证据，不是"应当这样要求"的依据。平台文档是厂商对自身产品的说明，不是独立研究结论。

---

实施验收场景¶

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

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