C4.25.4Unspecified fallback as random failure设计研究
缺少预定义降级路径会让边缘案例表现为系统随机失灵
别名: 随机失灵 · 边缘案例 · 无降级路径
概念解释
阳光角度、路过的人、深色手套、镜头上的指纹，都是部署后一定会碰到的边缘案例。没有预定义降级时，这些案例在用户那边的形态是：有时灵、有时不灵、找不出规律的随机失灵。实现里可能每一种都有日志，用户只看见同一张脸——设备脾气不好。随机性是缺失剧本的外在症状，不是识别器的固有性格。
机制
边缘条件把分数和跟踪推到训练分布外面，快乐路径没有出口，每次失败的近因不同（这一次是逆光，下一次是手套），但产品行为都是「命令没出来」。人在无规律的强化里学不会策略：既不会稳定地换站位，也不会稳定地去找按钮，只会降低对整台设备的信任。运维被报修单淹没，因为「随机」无法被用户复现给维修人员。预定义降级把不同近因收敛成少数几种用户能学会的状态（换大动作、改用按键、去调灯光），随机感才会下降——即使底层错误类型仍然很多。
怎么研究
在现场或高保真模拟里收集一周的失败事件，按近因编码，再按用户可见行为编码。没有降级的系统里，近因很多、可见行为几乎只有「无响应」一种。引入降级后再测可见行为的种类是否变少、用户策略是否可被描述。访谈里问「你下次会怎么做」：答「再碰运气」就是随机失灵还在；答「光线不好就改按键」说明剧本已经被学会。
边界
实验室里只测标准站姿、标准光照，边缘案例根本不出现，会得出「不需要降级」的假象。真正随机的硬件故障（接触不良、过热重启）降级剧本也收不住，应走报修，不要假装成识别降级。游戏里故意保留的「高难度识别」若被做成降级，会破坏挑战；那类产品要把失败设计成玩法而不是应急。一次性演示环境可以靠人在旁补位，随机感被人工压住，不能代表无人值守的部署。
怎么落地
- 上线前用目标场地的一周录像列出高频近因，为每类指定用户可见的状态，而不是为每类写一条只有工程师能读的日志。
- 把「用户说它有时候不好使」当成缺少降级的信号，去对可见状态做走查，而不是先重训模型。
- 验收问现场使用者「识别不行时你做什么」：说不出下一步，就还是随机失灵。