在产品里，Undo/Redo 就像魔法棒，用户一抖就能回到刚刚的状态，听起来很爽，但如果用户的心理预期跟实现不符，往往变成了头疼事。今天我把这件事拆成三个层面：系统层、功能层、用户层，看看怎么用心智模型把它们拉直。

【系统层】从技术上讲，Undo/Redo 是一种“命令模式”。每一次可逆操作都被包装成一个对象，按时间顺序入栈；Redo 则是从栈弹出。简单的堆栈结构在 Photoshop、Figma、Google Docs 里屡见不鲜，堆栈深度常被设为 20 步——这是 Nielsen Norman Group 在 2015 年做的实验得出的“安全阈值”。如果超过 20 步，用户往往会觉得越挠越痛，因为他们需要先记住想回到哪一步，然后才能逐步回退。

【功能层】要让功能跟用户心智对齐，关键是“可见性”和“可恢复性”。例如 Notion 在撤销时会给出“已撤销上条操作，点击此处恢复”的提示，让用户意识到他们已经离开原点，但仍有路径回到原点。相反，某些早期版本的 Microsoft Word 在一次删除后，撤销按钮会消失，让用户误以为已无法恢复，导致“为什么撤销不起作用”的抱怨。

【用户层】用户的心智模型往往是“时间轴”。他们会想：我想回到 3 分钟前的状态。于是，产品设计者可以给用户一个时间滑块或者历史版本列表，像 Google Drive 的版本历史那样，让用户直接跳到某一时间点，而不是一步步往前。Apple 在 iOS 13 推出的“撤销/重做”手势就非常好，手势一滑就能回到之前的状态，符合“瞬时回退”的心理预期。

但现实里常有“Undo 没起作用”的痛点。比如某款协作白板软件在多人同时编辑时，只保存本地操作的 5 步 Undo，超过 5 步就直接丢失。用户在看到“撤销失败”的弹窗后，往往会误解为“系统故障”，甚至放弃使用。解决办法是：①使用更大容量的本地缓存；②给用户“完整历史”选项；③在协作时同步每个操作到服务器，保证跨设备一致性。

总结一句：Undo/Redo 不只是技术实现，更是心理契约。要让产品的撤销行为与用户的时间轴心智模型匹配，需要在堆栈深度、可视反馈、历史路径三方面做足功课。你在设计新的可逆功能时，问自己：用户到底想回到哪一步？系统给出的路径能否让他们安心？如果答案是“可以”，那这条魔法棒就会真正“起作用”。