“计划预览”比一句 Done 更重要

过去我们设计 AI 产品时，习惯把注意力放在结果上。用户提出问题，模型给出回答；如果回答不准确，可以继续追问、重新生成，或者直接舍弃。整个过程中，AI 提供的是信息，真正采取行动的人仍然是用户。因此，一个清楚的结果反馈通常已经足够。

当 AI 开始替用户创建会议、发送邮件、修改工单，甚至操作共享系统时，它输出的不再只是一个可供参考的答案，而是在现实环境中产生后果的行动。此时，如果界面仍然沿用“提出需求—等待执行—显示 Done”这套逻辑，用户真正获得信息的时候，往往已经太晚了。

UXperiment 最近围绕这一问题做了一组小规模原型测试。他们设计了一个会议 Agent，让它为三名参与者寻找两个合适的时间，并在确认后发送日历邀请。测试首先采用最常见的聊天模式：用户提出要求，Agent 完成任务，最后显示“邀请已发送”。这种流程很短，也足够流畅，但当实验模拟 Agent 把邮件发给错误的通讯组时，问题立刻显现出来——用户此前没有任何机会检查它究竟理解了什么，也无法在错误真正发生之前介入。

随后，研究者在执行之前增加了一层 Plan Preview。在真正发送邀请之前，界面先列出参与者、候选时间、将要使用的日历账户以及邮件主题，再由用户确认或修改。五名参与者都至少检查了参与者名单，其中三人主动调整了时间。整个任务因此增加了大约 20 到 30 秒，但参与者对过程的信任反而有所提高。有人甚至把这张预览卡片视为“真正的界面”，而聊天更像是在描述任务。

样本只有五个人，也只是一个可点击原型，这当然不足以证明 Plan Preview 应该成为所有 Agent 产品的标准模式。但它揭示出的设计矛盾，过去我们常常通过减少确认步骤来提高效率；当软件开始替用户行动以后，某些确认恰恰成为效率能够被信任的前提。

传统确认框通常发生在用户已经明确选择某项操作之后，例如删除文件之前再次询问是否确认。Agent 的情况不同：用户往往只表达了目标，至于系统会采用什么路径、调用哪个账户、影响哪些对象，中间还有大量由 Agent 自己完成的判断。

因此，Plan Preview 所承担的并不是简单的二次确认，而是把原本隐藏在 Agent 内部的行动计划，在产生后果之前重新变成用户可以检查的界面。这也是为什么一句 完成 会逐渐显得不够。

“已完成”只能证明系统认为任务结束了，却无法说明它是否正确理解了对象、条件和权限。对于一个只负责整理文本的 AI，这种反馈可能已经足够；但如果 Agent 准备向十个人发送邮件，或者修改一个共享日历，那么真正需要被看见的就不只是结果，而是承诺发生之前的关键条件。

同一组测试还观察到了另一个相关问题。研究者尝试显示类似“80% 置信度”的数值，但参与者并没有因此获得多少有效信息。相比抽象的百分比，明确指出具体的不确定性——例如“旅行时间来自估算”“某位参与者的时区尚未确认”——更能帮助用户判断是否应该继续。

这里反映出的仍然是同一个变化：Agentic UX 不能只告诉用户系统“有多确定”，还需要让用户知道它究竟对什么不确定，以及这种不确定会影响什么。

当 Agent 真正开始行动以后，界面也随之出现了一些过去并不突出的状态：计划尚未确认、执行进行中、用户主动暂停、部分步骤失败、从某个已验证节点恢复，或者撤销已经产生的影响。研究中，当参与者看到“从上一个检查点继续”这一选项时，多数人会先查看哪些步骤已经被验证，而不是直接选择恢复。一个被保存下来的状态，并不天然意味着它就是安全的恢复点，这些变化会重新调整设计师对“流畅”的理解。

传统产品设计常常把少一步、少一次打断视为体验优化。但 Agent 的价值越大，它能够产生的外部影响通常也越大。此时，真正成熟的体验未必始终追求无感，而是能够根据风险决定什么时候应该安静地自动完成，什么时候必须让用户重新获得清晰的判断权。因此，Plan Preview 的意义不只是增加一道保险。

它更多代表的是 Agent 产品中一条新的交互边界，在“用户表达意图”和“系统真正采取行动”之间，需要有一个让人重新理解、检查和授权的时刻。