L5.04.1catastrophic trust collapse设计研究
单次严重错误可摧毁长期信任
别名: 信任崩塌 · 一次重创 · one severe miss
概念解释
报税助手用了一年，每季都算对。某一季它把主体类型报错，罚款落到用户头上。一年的顺利在那一天下了线。一次足够严重的错误可以摧毁长期攒下来的信任（catastrophic trust collapse）。崩的不是慢慢校准回来的偏差，是信任作为交托意愿被一次性抽空。
严重，指后果不可逆或难以逆转，且被归在系统身上。普通小错堆出的过度信任，不是这条的对象。
机制
长期信任像对「它不会在要紧处害我」的概括。概括靠许多低后果成功撑着，但概括的内容是关于要紧处的。一次要紧处的伤害直接证伪这个概括，先前的成功因为不在同一后果档，无法对冲。人不会用「它填对过四十次税额」去抵「它填错了主体」——单位不同。
崩塌之后的行为是撤离：关掉自动申报、改回手工、向同事传播「别用」。撤离的速度远快于当年把申报交出去的速度。Lee 与 See 讨论过信任可被单一负面事件急剧改写；这里要标的是严重性门槛——过了这道门槛，谈的就不是调一调估计，而是关系断了。
怎么研究
在一段成功历史之后注入一次高后果失败（真实或高仿真的外发、罚款、不可撤回发送），对比同等次数的低后果失败。自变量：后果严重性、失败是否可归到系统、成功历史的长度。因变量：交托意愿的掉崖幅度、撤离行为、把系统从工作流里拿掉的决定。
实验室很难造出真罚款。要用参与者在乎的货币、声誉或不可撤回，否则测到的只是评分波动，不是崩塌。
边界
用户若从未把任务交到要紧处——一直当草稿用——「严重」可能够不到崩塌，只会变成一次差评。可靠度本就声明极低的工具，用户没有长期信任可崩。一次失败之后信任仍在、只是下降，那是不对称更新，不是这条的抽空。连续小成功把信任顶过可靠度，也不是崩塌。
怎么落地
- 把功能按后果分档。能造成罚款、外发、不可撤回写入的档，不要用「一年都很准」当免检许可；要紧处保持独立核对。
- 高后果路径上预置紧急撤回、人工接管和事故说明，假设崩塌可能在任何一次发生。
- 不要用低后果场景的好评去为高后果自动操作背书。
- 验证：走一遍「错误真的发出去了」的演练，看工作流里还有没有第二道闸。没有闸，你们就是在赌不会碰到那一次；碰到就会把长期信任一起赔掉。