L5.10.5more successes than failures to recover设计研究
恢复信任所需的成功次数远多于造成损害的失败次数
别名: 次数不对称 · 多次成功补一次 · count to recover
概念解释
报错一次主体类型，交托掉下去。要回到掉之前的交托，后面需要的「报对」不是一次，而是一串——十五次干净申报也不稀奇。恢复所需的成功次数远多于造成损害的失败次数（more successes than failures to recover）。
这是计数。崩塌条说的是恢复比建立更慢，那是时钟。一次对一次的更新不对称，是步长。这里把步长累加成「要多少次才能回到原位」。
机制
下降步长大、上升步长小，回到原点需要多次上升。失败还可能关掉取样：人不再交托，成功次数攒不起来，计数更拉长。所以「远多于」有两层：算术上的步长比，加上取样变慢。产品若在失败后没有一条仍可观察的低后果成功路径，计数可以停在永远不够。
这与「信任由经验形成」一致：声明「我们已修复」不计一次成功。成功必须是用户自己看见的、同任务上的完成。Muir 的更新不吃新闻稿。
怎么研究
在一次中等失败后，按次给予可观察成功，找出交托回到失败前水平所需的 n。自变量：失败档、成功是否同任务同档、失败后是否仍开放低后果路径。因变量：n、中途退出使 n 不可达的比例。
n 对高后果失败会更大。必须分档报，不能给一个万能倍数。
边界
失败被立刻撤回、用户几乎未受后果时，n 可以接近 1。崩塌之后人已撤离，计数尚未开始，先要解决的是重新打开取样，那是时间过程。展示典型失败来压过信，是在主动增加负样本，不是在谈恢复计数。早期失败的 n 通常更大，因为要同时推翻第一笔画像。
怎么落地
- 失败后规划的不是一封「已修复」，而是一条用户能连续看见成功的同任务路径。按你们测到的 n 来运营，而不是按公关日历。
- 保留低后果通道，让成功次数有地方攒。关掉自动又没有任何手工可见的对，n 无法开始。
- 不要在第 2、第 3 次成功时催人把高后果开关打开。计数还没到。
- 验证：事故后跟踪「第几次同任务成功时交托回到原位」。若声明发出当天评分回了、行为要到第十几次才回，产品在用礼貌冒充计数完成。