Z2.09.3Stale-context automation errors设计

陈旧情境驱动的自动化会做出过时的决策

别名: 过时决策 · 陈旧情境 · outdated automation decisions

概念解释

自动化拿情境判断当输入,判断一过期,自动化就成了在执行过时指令的代理:人已经离开,系统还在执行「在家模式」的整套动作——灯全开、门禁解除、安静策略生效。错误不在自动化逻辑(规则本身没问题),也不在执行(动作准确执行了),而在输入——它对的是「过去的现实」。

这类错误的隐蔽性在于每个环节单独看都正常:传感器没坏(当时确实在家)、规则没写错(在家就该这样)、执行没失败(动作都做了)——串起来却是一个对着空房间服务的系统。用户看到的「智障行为」,拆开全是无辜组件。

机制

过时决策的放大效应来自自动化的三个特性:

  • 自动化无时不在执行。 手动操作只在人在场时发生,人不在自然不会有人按错;自动化没有这个天然闸门——判断过期的那几个小时里,它持续地、勤勉地执行错误前提下的动作,错误按时间积分。
  • 情境输入的权重不可协商。 规则一旦以「在家」为条件,这个条件就支配整套动作组合(不止一盏灯,而是照明、门锁、音箱、告警的联动);单点过时被联动结构扇出成一串过时后果——情境是打包消费的,过期也是打包的。
  • 错误在物理世界结算。 界面 bug 刷新就好;过时决策的后果落在门外(门没锁一夜)、电表上(空调对着空屋跑了八小时)、安全上(布防从未生效)。结算的不可逆性抬高了同一逻辑错误的真实代价。

还有一个方向性规律:过时决策几乎总是保守方向的错误被原谅、相反方向被严惩——把在家人当成离开(误布防、误关灯)通常只是烦;把离开的人当成在家(门不锁、安防不设)是安全事故。过期判断默认倒向哪一边,决定了错误的代价结构。

边界

  • 不是所有过时决策都可见。 对着空屋开灯这类无差别动作,用户可能永远不知道发生过——代价是电费与能耗,不上账面。评估过时决策的规模时,能耗数据与用户报告是两个独立来源,后者严重低估前者。
  • 低后果自动化可以容忍陈旧。 加湿器跟着「在家」判断走,过期十分钟无非多转十分钟——给所有自动化一律上严格的时效门禁,是用安全关键的标准惩罚日常便利;时效要求应按自动化的后果分级。
  • 「行为正常」不等于「前提正常」。 验收测试通常只验证「触发后动作对不对」,从不验证「触发时前提还新鲜吗」——一套测试全绿的自动化完全可以长期在过期前提上运行。这个盲区是测试设计要主动补的。

怎么落地

  • 高后果自动化的规则里显式声明时效前提:触发条件不只是「在家」,而是「在家(判断年龄 ≤ 上限)」;年龄超限走不触发分支,而不是硬着头皮执行。
  • 过时决策事件留痕并聚合:每次「执行时判断已超龄」记一条(当时判断、年龄、执行的动作);按自动化分组统计超龄执行率,排名前列的规则优先修时效链路。
  • 给过期前提一个保守默认:判断过期时自动化退到的状态要按错误代价不对称性选——宁可在场时误执行「离开模式」(灯关了,人再开),不可离开时误执行「在家模式」(门没锁)。
  • 验证办法:两类审计一起跑——日志侧统计超龄执行率与最长超龄时长;演练侧人为制造「判断过期 + 高后果自动化待触发」场景,验证系统拒绝执行并落进保守默认。两条都达标,过时决策才算被关进笼子。

延伸

  • 同组Z2.09.1 情境判断有有效期,超期后不应继续被采信 · Z2.09.2 环境快速变化时情境失效速度快于判断更新速度 · Z2.09.4 系统需要主动标记情境为过期而非无限沿用
  • 相邻Z3.02 自动执行的边界 · Z4.09 故障、失联与降级
  • 站内检索stale context · automation failure · fail-safe defaults · condition freshness

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/Z2.09.3