冲突结果需可追溯到具体规则
别名: 冲突归因 · 仲裁记录 · arbitration log
概念解释
仲裁执行之后，用户要能查到这次冲突是谁和谁、谁赢了、为什么赢——冲突结果的归因记录。它记录的是一次裁决：参与竞争的指令集、各自的规则来源、仲裁依据、赢家与被压制者。
没有这份记录，冲突在用户眼里只是「灯不听话」——现象存在，结构不可知。用户无法区分「设备坏了」「网络卡了」「规则打架了」三种情况，只能按最坏的猜测处理；而被压制的那条规则处于静默失败状态：它以为自己触发了，动作却从未执行，规则作者对此一无所知。归因记录是把静默失败变回可观察事件的唯一通道。
要注意这里的范围：冲突归因回答的是「这次裁决谁赢了」；至于一般性的「某个动作由什么触发」——不涉及竞争的那类——属于触发追溯，是另一张卡的事。冲突归因只在裁决发生的地方存在。
机制
冲突归因的困难在于它是瞬时事件，事后无法重建。裁决依赖三样只存在于那一刻的信息：同时成立的规则集（各自的触发条件与命中值）、指令到达仲裁点的实际顺序、仲裁器的决策路径。任何一样没有被当场记下，事后只能靠推测——而推测最容易错的就是「哪条规则当时也成立」，这正是用户最想知道的部分。
这也解释了为什么简单的「动作日志」不够用。普通日志记的是执行了什么；冲突归因还需要记没有执行什么——被压制的指令、被丢弃的候选。否定事实不会自己留下痕迹，系统必须显式地为「失败方」写记录，这在工程上是反直觉的投入：为没有发生的事消耗存储。
第三层：被压制的规则需要持续记账而不是单次记录。一次被压制可能正常（仲裁正确执行），连续一周每次都被同一条规则压制说明优先序设错了或条件重叠了——模式比单例更有诊断价值。
怎么研究
直接针对家庭场景冲突归因的研究稀少，可用的经验基础：
- 审计日志与可观测性传统（observability）：运维领域对「裁决类事件必须记录决策输入」是成熟共识，分布式追踪（tracing）的 span 记录就是「谁调用谁、谁被取消」的结构化先例，可作为设计参照。
- 智能助手误触发归因的用户研究（泛写）：语音助手产品中「为什么我的指令没被执行」类工单的分析，提供了用户归因需求的第一手形态。
- 归因可用性实验：制造一次已知冲突，给用户不同粒度的冲突记录（仅赢家 / 赢家+候选 / 赢家+候选+依据），测量定位「哪条规则被压制」的时间与错误率。粒度收益曲线是设计决策的直接依据。
方法论注意点：评估要把「归因成功」定义在规则对级别而不是设备级别——用户查明「灯不听话是因为两条规则打架」只是半程，查明「是哪两条」才算完成。
边界
- 显式冲突才需要冲突归因。 同刻裁决的记录成本只在冲突确实发生时发生；错峰拉锯类（设备反复开关）没有单一裁决时刻，归因靠的是触发时间线的对照分析，那是自动化历史的范畴。
- 记录有隐私成本。 冲突记录包含家庭行为的时间结构（谁在家、何时活动），存储与保留策略要按家庭数据对待——这里只记一笔，展开属于共享空间隐私的讨论。
- 归因记录不修复冲突。 它把冲突变成可见的，让用户有能力改规则或改优先序；冲突本身的消除靠预检与仲裁设计。把日志当成修复手段会收集一堆无人阅读的冲突史。
怎么落地
- 冲突事件单独成类记录，字段至少含：候选指令集、各指令的规则来源、仲裁依据、裁决结果、时间戳。与普通动作日志分开，有独立的筛选视图。
- 被压制的规则在下次查看时提示「上次触发被『日落开灯』压制」——把静默失败在规则自己的页面上显形，而不是埋在全局日志里。
- 冲突记录的保留期与普通日志解耦：冲突稀有且信息密度高，可以留得比状态日志更长。
- 验证办法：人为制造一次两规则冲突，测用户从「发现现象」到「查明是哪两条规则、谁赢了」的步数与时间；三步内查明的算合格，需要翻全局日志的算不合格。