你让 AI 整理会议笔记，它分错一组，改回来就好。可如果你让它发邀请、改客户记录或支付账单，同一套“自动完成”逻辑就危险了。反过来，每动一步都弹窗确认，也会让人习惯性地点“继续”。真正的问题不是 AI 要不要获得行动权，而是哪类行动可以直接做，哪类必须先让人看清后果。
设计师 Dmytro Hanin 在 Muzli 的文章 中提出一套四级框架：自动执行（Act）、执行后可撤销（Act + Undo）、执行前预览（Preview + Approve）和明确确认（Explicit Confirmation）。它不是经过实验验证的行业标准，而是一套 UX——也就是用户如何与产品交互——的设计方法。它的价值在于，把抽象的“信任 AI”拆成几个可以逐项检查的产品决定。
别先问“要不要确认”
文章建议先判断三件事。
第一，出错的代价有多大。笔记分类错误只是麻烦；付款、发布内容或更改权限，可能留下长期后果。
第二，谁会受影响。私人工作区里的草稿只影响自己；邮件一旦发出，就会对收件人形成期待；订单状态变化还可能启动另一个团队或一套自动流程。
第三，能否完整恢复原状。这就是“可逆性”：操作完成后，系统能不能以较低成本退回原来的状态。移动文件可以恢复，但前提是系统记得旧位置。邮件可能只有很短的撤回窗口；公开内容即使删除，也无法收回别人已经保存的副本。
这三个问题分别对应代价、影响范围和可逆性。它们比“这个功能看起来重不重要”更具体，也决定了控制应该放在哪一步。
四级控制，不是一排弹窗
最低一级是 Act。适合本地、低风险、容易检查的任务，例如整理结果、给笔记分组、准备草稿或生成多个备选方案。AI 做完后展示结果即可。这里增加确认，只会增加操作，不会明显降低风险。
第二级是 Act + Undo。它适合风险中等、但旧状态确实能够恢复的更改，例如移动文件、重命名记录或调整任务分类。AI 先执行，再清楚说明改了什么，并提供撤销。
不过，Undo——撤销——不能只是一行按钮文字。产品必须事先回答：原始状态保存在哪里，多久内可以恢复，依赖它发生的后续变化是否一起回滚，部分恢复失败怎么办，以及系统如何验证恢复成功。如果后台做不到真正复原，就应提供它确实能做到的补救，例如停止剩余步骤、恢复旧版本或发送更正。
第三级是 Preview + Approve，也就是先预览，再批准。它适合批量操作以及会影响他人的行动。比如 AI 准备邀请五个人参加会议，预览页应一次展示收件人、日期、时间、最终文案和发送渠道，并允许删掉个别收件人。用户需要看的不是模型调用了哪些内部工具，也不是一份技术执行日志，而是“哪些对象将被改变，还有哪些后果可以阻止”。
最高一级是 Explicit Confirmation，即明确确认。付款、正式发布、删除、权限变更以及难以彻底撤回的操作，都应设置最严格的检查点。确认页要摆出真正影响决定的信息：付款时显示收款人、金额、币种、手续费和支付方式；删除时显示具体对象、受影响数据及恢复条件。按钮也不该只写含糊的“继续”，而应直接写明“支付 €480”或“永久删除工作区”。
停止，不等于什么都没发生
智能体常常连续执行多个步骤。假设五封邀请已经发出两封，此时按下 Stop——停止——只能拦住剩下三封。界面应分别说明哪些已经发送、哪些已停止、哪些还能补救、哪些无法撤回。若只显示“任务已取消”，反而掩盖了真实状态。
这也是渐进式授权的意义：系统按任务、权限与风险逐步取得许可，而不是一开始就拿走全部控制权。确认应留给真正关键或异常的动作。否则弹窗太多会造成“确认疲劳”——用户逐渐机械点击，确认机制反而失去作用。
熟练用户不是不要控制
Hanin 的文章转述了一组据称由 Anthropic 在 2026 年 2 月发布的 Claude Code 使用数据：新用户约有 20% 的会话启用 full auto-approve——让系统自动批准操作；在“750 个会话”这一用户分组中，该比例超过 40%。新用户约在 5% 的 turns——智能体与用户的一轮交互——中主动中断，而有经验用户约为 9%。
作者据此解释，用户熟悉智能体后，监督方式可能从逐步事前审批，转向允许它先工作，并在结果偏离时介入。这个变化不能简单理解为“越熟练越放任”。更可能的产品启示是：新用户需要更多检查点，熟练用户则更需要清晰的活动轨迹和随时可用的停止按钮。
但这些数字只有该文这一条信源，且文章没有给出原始报告、样本量、观察期和统计口径。“750 个会话”究竟指恰好 750 次、至少 750 次，还是某个分组，也不明确。因此，它们适合用来提示一种可能的监督变化，不能证明使用经验导致了自动批准或更多中断。
真正的边界写在系统里
这套框架值得关注，因为它把设计与工程绑在了一起。设计师可以决定控制级别、预览内容、确认时机和失败状态；开发者则必须让这些界面承诺成真：保存撤销所需的旧状态，停止尚未开始的步骤，逐项报告执行结果，避免重试造成重复操作，并处理部分失败。
说白了，一枚画在设计稿里的 Undo 按钮，不会自动让操作变得可逆。智能体产品的信任也不来自更多弹窗，而来自一套与风险匹配、状态真实、补救有效的控制机制。
局限与未知
- 四级框架和三项判断问题来自作者的方法建议，不是实验结论或已形成共识的规范。
- Claude Code 的比例由二手 UX 文章转述，缺少原始数据与统计口径，不能据此推出因果关系。
- 供稿正文末尾在发布前检查清单处截断，因此文章最终如何落实或补充该清单，现有材料无法确认。