AI 时代的撤销不能只是回到上一步

传统软件的撤销机制，依赖用户操作与系统变化之间清晰、连续的对应关系。删除一段文字、移动一个图层或调整一项参数，通常都会形成一条独立记录。用户按下撤销键，系统便取消最近完成的动作。只要操作对象和执行顺序没有歧义，这套机制就足以帮助用户修正错误。

Agent 改变了这种对应关系。用户提出的一个要求，可能被系统拆解为多项彼此关联的修改。设计师要求 Agent“让这个页面更符合品牌气质”，系统可能同时调整字体、色彩、间距、文案和信息层级。用户认同其中一部分，却认为另一部分破坏了原有逻辑，此时传统撤销只能取消整轮生成，无法保留已经成立的判断。

10 月 12 日，UX 研究者 Jakob Nielsen 在个人通讯中讨论了这一问题。他援引卡内基梅隆大学研究者 Libby Divers 等人的早期观察，指出用户面对 AI 生成结果时，经常无法通过现有撤销机制恢复到真正需要的状态。一些人只能手工修正，也有人连续按下撤销键，直到界面回到一个大致可以接受的位置。撤销原本用于取消误操作，如今还要承担比较方案、拆分结果和重新取得控制权的任务。

1. 非单一操作

问题首先出在撤销的粒度。传统软件把一次命令视为一次操作，Agent 却可能把多个修改封装在一次回应中。如果系统只能整体接受或整体撤销，用户就必须在保留错误结果与放弃有效结果之间选择。更合适的设计，是让每轮生成保留内部结构，使用户能够分别查看并处理文案、样式、布局与数据等不同变化。

这要求 AI 产品把生成结果从一个完成状态改造成一组可以检查的修改。界面不仅要展示“Agent 已完成任务”，还应说明它改动了哪些对象，以及这些改动之间是否存在依赖。用户取消标题样式时，正文排版是否会随之恢复；撤销组件替换后，相关交互状态是否仍然成立；恢复旧版布局会不会覆盖随后新增的内容。这些关系如果不可见，所谓选择性撤销仍然只是一次新的不透明操作。

当用户与 Agent 同时编辑同一对象，撤销还涉及操作归属。用户刚刚移动了一个组件，Agent 随后在后台重组页面结构，“撤销上一步”可能首先取消 Agent 的修改，也可能破坏用户刚刚完成的调整。Nielsen 提到，协同软件早已采用按参与者区分操作记录的思路。Agent 进入创作与生产工具后，也需要拥有独立的修改轨迹，让用户能够选择撤销自己的操作、Agent 的操作，或某一项任务引发的全部变化。

2. 重构操作历史

历史记录的表达方式也需要改变。“更改属性”“更新节点”一类系统术语只能说明软件执行过什么，无法对应用户对任务的记忆。面对持续数十分钟、跨越多个对象的生成过程，用户更容易记住“重新组织导航之前”或“调整品牌语气之后”。历史面板需要以任务、对象和意图组织状态，使用户能够理解自己将返回哪个阶段，而不是依靠一串底层操作猜测结果。

长时间运行的 Agent 还需要在关键节点主动建立检查点。Agent 可以读取文件、批量修改页面、调用外部服务，并在用户没有逐步参与的情况下继续执行。此类任务如果只在末尾提供一个撤销按钮，用户必须承担整条操作链的验证成本。更稳妥的方式是在权限扩大、批量覆盖、对外发送或产生费用之前保存状态，同时呈现影响范围，让用户决定继续、暂停或保留分支。

3. 撤销边界

并非所有后果都能通过恢复界面状态而消除。已经发送的邮件可能被阅读，完成的付款可能进入结算流程，公开发布的内容也可能已经被传播。系统即使恢复了本地记录，也不能把外部世界一并还原。此时，界面必须区分哪些变化已经恢复，哪些结果仍然存在，以及用户还能采取哪些补救措施。笼统显示“已撤销”，反而会掩盖真实风险。

Nielsen 引用的观察仍属于早期研究，样本和应用场景不足以证明传统撤销在所有 AI 产品中都已失效。但 Agent 对操作结构造成的改变已经可以确认。一次意图不再对应一次动作，用户也不再是唯一的执行者。

撤销因此不能继续停留在“回到上一步”，而要帮助用户拆分生成结果、辨认修改来源、理解恢复后果，并在不可逆行为发生之前保留选择。设计师需要重新处理的不是一个按钮，而是人在复杂自动化过程中如何持续拥有决定权。