L5.10.4handling offsets first-failure damage设计研究
失败后的处理方式能部分抵消损害，承认错误优于淡化
别名: 承认优于淡化 · 部分抵消 · admit versus downplay
概念解释
邮件助手把信发给了错误的人。一种回应是「我们不认为这是缺陷」；另一种是「是我们发错了，这是撤回」。失败已经发生，第二种不能把它抹掉，但交托掉幅会小一截。处理能部分抵消损害；承认优于淡化（handling offsets first-failure damage）。
抵消是加减法上的一截，不是「处理比错误本身更决定断不断」。后一句是崩塌场景里的主导因素。这里的失败可以并不严重到抽空，处理仍能改步长。
机制
不对称更新的下降步长，有一部分来自「它会不会再隐瞒、会不会把错推给我」。承认把事件留在能力问题，下降主要走能力那一项；淡化加上第二项：不可预测的对待。两项叠在一起，步长更大。所以同样一次失败，淡化组掉得更多——多出来的不是更错，是关系信号。
承认要配得上。口头承认、撤回点不了，等于又一次失败，抵消变成负的。Lee 与 See 的态度包含对自动化是否还站在同一边的判断；处理是这个判断的输入，不是错误率的输入。
怎么研究
同一次中等失败（可撤回的误发、可改正的错时区），随机承认并给补救 / 淡化 / 推给用户。测交托掉幅相对于「无说明」基线能收回多少。自变量：处理类型、补救是否真能执行。因变量：掉幅、收回比例、对「下次还会这样待我」的判断。
收回比例是「部分」。不要把承认组做成零损害，那会与崩塌条混淆。
边界
失败已跨过严重门槛（不可逆伤害），承认仍应该，但不要承诺能把信任买回来——那是恢复时间与成功计数的事。处理在崩塌里可以是断不断的主导因素；中等失败里它只改步长。用户没发现失败时，处理无从发生。第一人称的「我很抱歉」另有内部状态问题，不等于这里的承认。
怎么落地
- 中等失败的默认脚本：标明是系统这次错了、范围是什么、现在能点的补救。禁止「也许是你的输入」。
- 补救先于解释。撤回、重发、导出记录，比模型原理更能收回那一截。
- 把「承认 / 淡化」做成事故复盘的对照项，看哪一类掉幅更大，用来改默认文案。
- 验证：同一次误发，两套脚本的次日交托差。承认组若明显少掉一截，抵消存在；若两组一样差，承认没有配上能执行的补救。