可撤销优于确认

危险操作给一次后悔的机会，好过弹窗问三遍。

与其在操作前问「你确定吗」，不如让操作先发生，再给一个能反悔的窗口。

你会遇到的现象：

• 用户对所有确认弹窗都直接点确定，从来不读
• 批量操作时要一个个确认，烦到不想用
• 真的删错了，除了找你恢复没有别的办法

确认弹窗的问题在于它的成本分摊反了：一百次操作里可能只有一次是误操作，但一百次都被打断。而且弹得多了，用户会形成肌肉记忆，看到弹窗直接点确定——那一次真正的误操作照样拦不住。撤销把成本挪到了出错的那一次：正常操作完全不被打断，出错的那次花一秒钟点一下撤销。撤销是计算机界面里最老也最稳的交互技术之一，从最早的编辑器开始就在用。undo

删除、发送、提交这类高频操作，用户每天做几十次，每一次被弹窗打断，累积起来就是一层怨气；而真正的误操作次数远比想象中少。撤销只在出错时出现，平时对用户完全隐形——这是它比确认更友好的根本原因。

什么时候还是要确认

判断依据只有两条：这个动作可不可逆，以及后果影响几个人。两条都答「可逆、只影响自己」，就用撤销。

确实需要确认的时候，要提高确认的成本，让人无法条件反射地点过去：要求输入合同编号、把主按钮改成危险色、把「确定」换成具体的动词（「作废合同」而不是「确定」）。判断时还要看用户所在的上下文：正在专注批量操作时弹出的确认框，杀伤力最大。

撤销怎么做

• **底层用软删除。**加一个删除标记而不是真的删掉。有了它，撤销就是把标记改回来，成本极低。
• **撤销入口跟结果反馈放在一起。**删除后的提示条上直接带「撤销」，用户不用去别处找。
• **窗口期给足。**五到十秒是常见值。批量操作可以更长，或者干脆做成回收站。
• **撤销之后要能看到东西回来了。**只弹一句「已撤销」不够，列表里那一条要真的出现。
• **回收站是撤销的长期版本。**短窗口来不及的时候，用户还有第二条路。

这套做法对 vibecoding 有个额外好处：软删除加撤销，本质上是让数据不会真的消失。AI 生成的代码在删除逻辑上出错的概率不低，有这一层兜底，出错的代价小很多。撤销入口就长在结果反馈上，配合操作必有反馈一起做，交互才算闭环。还有个细节：撤销要能撤销到底。删除恢复了但附件没回来，用户会以为整个都回来了。设计时把「撤销之后用户看到什么」写进验收标准。