Z5.02.2Priority and arbitration设计研究
需要显式的优先级与仲裁
别名: 仲裁机制 · 优先级仲裁 · conflict resolution
概念解释
冲突发生时，系统必须有一个决定「谁赢」的机制——仲裁（arbitration）。关键不在于有没有：任何实现都在某种裁决下运行，「后到的指令覆盖先到的」（last-write-wins）也是仲裁，只是没人知道它的存在。关键在于仲裁是否显式：优先序被声明、被用户知道、被稳定执行。
隐式仲裁的代价是把结构问题伪装成随机故障：同一冲突今天 A 赢明天 B 赢（取决于毫秒级的到达顺序），用户面对的就是一个「时灵时不灵」的设备——不可预测且无从问责。
机制
没有仲裁策略时，结果由竞态时序决定：同一时刻成立的两条规则各自发出指令，赢家取决于网络延迟、评价周期的错相位、云端排队的顺序——每一次都合法，每一次都可能不同。竞态把决定权从「设计」转移到了「物理」，而物理没有语义。
显式仲裁需要三层东西：
- 优先序本体：一个可比的排序依据。常见的是类型序（手动指令 > 显式场景 > 自动规则 > 例行日程）与来源序（安全 > 舒适 > 节能）。类型序比数值优先级可靠——用户理解「手动压过自动」，不理解「这条是 7 那条是 5」。
- 仲裁点：指令汇聚处（设备或中枢）执行裁决的地方，必须唯一且在因果链上先于执行。
- 裁决的可陈述性：仲裁依据能被翻译成一句话（「手动操作优先于自动规则」），这是它区别于竞态的本质——竞态的结果无法陈述，只能接受。
为什么显式性如此重要：仲裁规则本身会变成用户心智模型的一部分。用户知道了「手动永远压过自动」，就能据此设计自己的策略（出门前手动关一下， Override 一小时的自动浇灌）；仲裁不可知时，这种上层策略无从建立。
怎么研究
- 仲裁策略的系统研究：智能家居与多代理系统文献对冲突消解（conflict resolution）策略有成型讨论——优先级、时间序、来源加权、用户裁决的适用条件比较；表述宜保守，家用场景的直接对照评估证据有限。
- 并发控制传统：last-write-wins、时间戳排序来自分布式系统的成熟机制分析，可作为仲裁语义的机制背景——它们在数据库语境的失效条件（丢失更新、写偏斜）在智能家居语境有直接对应物。
- 可预期性实验：给用户一个会冲突的规则集，比较显式声明优先序与隐式 last-write-wins 两个版本下，用户对系统行为的预测准确率与信任量表。仲裁显式性的收益可以直接度量。
方法论注意点：实验必须包含规则例外场景（用户想暂时打破默认优先序的时刻），否则只能测到「可预测」测不到「可商榷」——而后者才是家庭使用的常态。
边界
- 优先级体系自身有复杂度成本。 分级超过三到四层、或要求用户为每条规则手工设数值，用户会放弃理解退回盲试——显式性死于自己的复杂度。默认序要少而稳，例外按需覆盖。
- 有些冲突不该被仲裁，该被拒绝。 两条安全规则相悖（「断电时开门」与「火灾时闭门」同时成立）时，随机挑一个赢家是错误处理——正确的动作是显式报错并请求人工裁决。仲裁适用于舒适与便利类指令，不适用于安全类。
- 仲裁解决指令冲突，不解决需求冲突。 「你开的暖气我嫌热」是人对人的控制权问题，规则裁决再优雅也不解决谁的偏好算数——那是共享空间里控制权协商的范畴。
怎么落地
- 定义并公示默认优先序，建议从「手动 > 显式场景 > 自动规则 > 例行日程」起步；序要少（三到四档）、要写成人话、要在冲突提示里引用。
- 冲突发生处显示裁决依据：「按手动优先，此指令已覆盖『日落开灯』」——每次仲裁都是一次免费的教学。
- 允许按规则的例外覆盖：单条规则可声明「此规则压过场景」，但例外本身要显式列出，不提供全局数值优先级编辑器。
- 安全类规则冲突走拒绝并报错路径，不参与自动裁决。
- 验证办法：对注入的同刻冲突逐条核对结果是否符合声明序；再测用户复述优先序的准确率——复述不出来说明序的表述不够人话。