H3.05.1confirmation habituation in recovery flows设计研究
频繁确认会被自动点过
别名: 确认疲劳 · 自动点过 · click-through
概念解释
把确认当成默认的防错手段，同一条恢复路径里就会反复出现同一张问句。人很快把「确定」编进动作链，问句不再被读。频繁确认会被自动点过说的是：滥用确认会让确认在真正危险的那一次也失效。这条管频率如何毁掉策略，不管确认本该留给哪些动作，也不管手滑和判断错误的差别。
机制
注意把稳定重复的刺激降级为背景。恢复流程若在归档、取消、删除、离开未保存时都弹出同一骨架的对话框，视觉系统登记的是「又是那张卡」，决策在读到对象名之前完成。瞄准右下角变成技能。更糟的是危险动作若复用这张脸，习惯化会跨过后果边界：点穿草稿确认的那条肌肉，同样点穿生产库确认。用更多确认去补已经被点穿的确认，只会提高登记速度。所以确认的稀缺性是它还能工作的条件，不是礼貌。
怎么研究
在一段连续主任务里插入结构相同的确认，次数递增，再在不预告的情况下把其中一次换成高后果对象。
自变量：单次任务中确认次数、卡片视觉是否与日常确认相同、高后果试次插在第几次。 因变量：高后果试次是否仍被点穿、该次阅读时间、能否复述对象名。
不要书面要求「请每次仔细阅读」。那测的是服从，不是产品里的点穿。主任务要有时间压力，确认才像真实阻碍。
边界
偶尔出现、视觉上与日常卡片明显不同的确认，习惯化慢得多。跨天、跨会话的重复比单次实验更强，实验室里「第三次才点穿」在产品第三周可能已经完成。脚本、宏和自动化测试也会点穿，它们没有阅读器。把确认做成输入名称或强制等待，能打断瞄准，但那是另一层摩擦，不能靠把所有确认都变成惩罚来治点穿。
怎么落地
- 统计每个确认在真实会话里的出现次数；一轮任务超过一次的，默认视为正在被点穿，删掉或改成事后撤销。
- 高后果确认不得复用日常确认的版式与按钮位置，让那套瞄准打不中。
- 不要在已经被点穿的路径上再叠一张确认来「加强安全」。
- 验证：看录屏里对话框出现到按下的时间。短到读不完对象名，这条路径上的确认已经是空转。