取消之后，界面应该停在哪里

一个取消按钮很容易画出来，难的是确定按下之后整个系统处于什么状态。文字停止增长了，网络请求是否仍然存在？面板关闭了，后台是否仍在工作？如果用户重新打开，应该看到原来的任务，还是一张空白界面？

这些问题不只是实现细节。用户按下取消，是在表达一项明确意图；界面需要把这个意图能影响到的范围说清楚，并给出可以理解的结果。

先区分关闭与取消

关闭一个面板，通常表示暂时不想看它，不一定表示放弃正在进行的工作。一个全站播放器可以在面板收起后继续播放，助手也可以把当前会话留在全局状态中。这种行为本身没有问题，但不能把关闭按钮标成取消任务。

取消则应该指向一项具体工作：停止当前请求，撤回等待中的操作，或者不再继续生成。若某个动作已经产生外部结果，系统还需要说明取消是否能够影响那部分结果，而不是让一个按钮看起来可以回到所有事情发生之前。

离开页面又是第三种边界。站内切换和真正关闭浏览器，在组件生命周期与状态保存上可能不同。明确这些区别，可以减少用户用同一个“关闭”动作表达不同预期时的误解。

取消正在发生，不等于已经取消

对于需要请求外部服务的任务，按下按钮和确认停止之间可能存在一段过程。界面可以立即停止接受新的用户操作，同时显示正在取消；等请求真正结束后，再进入明确的已取消状态。

如果取消之后只剩一个不动的加载图标，用户无法判断是否需要再按一次。如果直接恢复到未开始状态，又可能隐藏已经发生过的工作。一个短暂但明确的状态，比让用户猜测更有价值。

取消过程中也可能失败。重要的不是保证每次都能撤回全部影响，而是呈现当前能确认的事实。哪些部分停止了，哪些结果已经完成，哪些状态还没有得到回应，应当分别处理。

已经输入的问题值得保留

取消可能只是因为等待太久，也可能因为发现问题需要修改。保留原始输入，让用户可以调整和重试，通常比清空整个面板更符合这两种意图。

已完成的历史也不应跟着当前任务一起消失。历史、输入和生成中的临时结果，是不同的信息。当前任务结束，只需要改变它所拥有的状态；清空会话可以是另一个明确操作。

至于半段结果，可以保留并标记未完成，也可以移除并给出提示。选择取决于任务类型与后续用途。如果半段结果不能参与下一次决策，就不应该默默把它放进正式历史。

重新打开之后仍然能理解

面板再次打开时，用户不应该依靠记忆才能知道上一件事停在哪里。一个已取消标识、一条保留的输入、或者一个可重新发起的入口，都可以成为恢复路径。

这里不一定需要复杂的任务轨迹。对于只读问答，清楚地保留问题并说明回答没有完成，可能已经足够。对于有外部写入的任务，则还需要更明确的结果与影响记录。

好的取消交互，最终不是一个动画或按钮样式，而是一组可以兑现的边界：什么停止了，什么仍然存在，接下来可以做什么。把这三件事说清楚，用户才真正拿回了控制权。