可撤销优于确认
与其在操作前问「你确定吗」，不如让操作先发生，再给一个能反悔的窗口。
你会遇到的现象
- 用户对所有确认弹窗都直接点确定，从来不读
- 批量操作时要一个个确认，烦到不想用
- 真的删错了，除了找你恢复没有别的办法
确认弹窗的问题在于它的成本分摊反了：一百次操作里可能只有一次是误操作，但一百次都被打断。而且弹得多了，用户会形成肌肉记忆，看到弹窗直接点确定——那一次真正的误操作照样拦不住。
撤销把成本挪到了出错的那一次：正常操作完全不被打断，出错的那次花一秒钟点一下撤销。
什么时候还是要确认
| 情况 | 用哪种 | 为什么 |
|---|---|---|
| 删一条笔记、归档一封邮件 | 撤销 | 可逆，影响只在自己 |
| 批量删除、批量修改状态 | 撤销 | 逐个确认会让人放弃使用 |
| 发送消息、提交表单 | 撤销 | 给几秒钟的撤回窗口就够 |
| 付款、转账 | 确认 | 钱出去了收不回来 |
| 作废合同、公开发布 | 确认 | 影响到别人，且对外可见 |
| 物理删除、清空数据 | 确认 | 真的没了。这时候还要提高确认成本 |
确实需要确认的时候，要提高确认的成本，让人无法条件反射地点过去：要求输入合同编号、把主按钮改成危险色、把「确定」换成具体的动词（「作废合同」而不是「确定」）。
撤销怎么做
- 底层用软删除。加一个删除标记而不是真的删掉。有了它，撤销就是把标记改回来，成本极低。
- 撤销入口跟结果反馈放在一起。删除后的提示条上直接带「撤销」，用户不用去别处找。
- 窗口期给足。五到十秒是常见值。批量操作可以更长，或者干脆做成回收站。
- 撤销之后要能看到东西回来了。只弹一句「已撤销」不够，列表里那一条要真的出现。
- 回收站是撤销的长期版本。短窗口来不及的时候，用户还有第二条路。
这套做法对 vibecoding 有个额外好处：软删除加撤销，本质上是让数据不会真的消失。AI 生成的代码在删除逻辑上出错的概率不低，有这一层兜底，出错的代价小很多。