L5.04.2slow trust recovery设计研究
信任恢复远慢于建立
别名: 信任恢复 · 建立与修复 · recovery slower than building
概念解释
私人邮件被助手误发给错误的人。关掉自动发送之后，即便随后三周封封都对，用户仍不把开关打开。攒到肯用，也许只要几天顺手；攒到肯再用，要长得多。信任的恢复远慢于建立（slow trust recovery）：两条时间曲线不对称，修比建贵。
慢的是时间过程，不是「需要多少次成功才能抵一次失败」的计数题。计数是另一层。
机制
建立信任时，人在收集「它可以」的证据，默认还是自己盯着，风险小。崩塌之后，人在收集「它不会再害我」的证据，默认已经撤离，每一次重新交托都是主动承担已知伤害。取样变慢：不用了就看不到成功，看不到成功就更难恢复，回路是负的。
记忆也偏。伤害事件的情节、责任、传播（告诉过同事）会反复被提取，日常的正确反而沉底。Muir 描述过信任随经验增减；崩塌把经验的权重改写成「先证明安全」，证明所需的观察窗比当初试探所需的更长。
怎么研究
在崩塌事件后，按日或按周测量交托意愿和实际开关状态，对比从未崩过、从零建立的曲线。自变量：崩塌后是否强制给一小段低后果成功、观察窗长度、是否仍看得到系统在别人那里正常工作。因变量：恢复到崩前交托水平所需天数、中途退出率。
必须把「评分回升」和「开关重新打开」分开。评分可以几天就礼貌地回，行为往往不回。
边界
低后果、可一键撤回的失败，恢复可以很快，这条的时间差会收窄。用户若没有替代路径，会在不信任的状态下继续用，看起来像恢复，其实是被锁住。新用户没有崩过，不存在恢复曲线。不要把「承认错误能抵消一部分损害」算进这条的时间——那是处理方式，不是时钟。
怎么落地
- 崩塌后不要用「我们已经修复」的一次性声明催人重新打开高后果开关。先提供一段可观察、低后果的成功窗，让取样重新开始。
- 保留人工路径，避免把不信任的人锁在系统里假装恢复。
- 把恢复当作以周计的过程来运营：回顾开关状态，而不是回顾道歉是否发过。
- 验证：事故后连续记录「仍关闭自动」的人数和天数。若声明发出三天评分回了、开关没动，恢复并没有发生，只是礼貌。