营运与维护 · 实作指南
按了取消，AI 工作流真的停了吗？
沿三条虚构时间线，区分停止浏览器输出、请求后台取消和动作已经完成。
AAHouse 原创解说视频，采用 AI 辅助概念画面、合成旁白及原创音乐。
英文逐字稿 · 简体中文普通话逐字稿 · 台湾华语逐字稿 · 香港粤语逐字稿 · 澳门粤语逐字稿
按下取消之后，故事还没有结束
设想一家美国活动服务公司的 AI 助手正在整理客户资料，并准备发送已获批准的确认邮件。员工发现日期有误，按下“取消”。这是虚构演练，不是客户事故。按钮可以表达停止意图，却不能单凭页面停止转圈，证明后台没有继续执行。我们沿三条时间线检查它的真实含义。
依已核准文章重绘的解说示意图。
时间线甲：只停止了浏览器等待
MDN 说明，AbortController 可以中止 fetch 请求、响应正文读取和流。[1] 这描述的是相关异步操作，不是业务回滚承诺。我们的设计建议是把“停止接收输出”与“请求取消后台任务”分开：如果产品只实现前者，按钮文字就不应暗示邮件已被阻止。
依已核准文章重绘的解说示意图。
时间线乙：后台收到请求，尚未确认停止
Microsoft 的 .NET 文档把取消定义为协作过程：监听者负责发现请求并作出响应，而非被强制终止。[2] 因此，建议保留“取消请求已提交”的中间状态，让执行端在安全检查点报告结果。请求发出和任务已停止不能共享同一个完成标记。
依已核准文章重绘的解说示意图。
时间线丙：确认邮件已经发出
若发送先于取消完成，界面应诚实显示已确认的发送结果。Microsoft 的异步请求模式建议由后台处理取消后更新状态，并评估部分回滚或补偿操作。[3] 我们的建议是先核对实际回执，再决定是否需要更正邮件；更正属于新动作，不能因用户按了取消就自动获得发送权限。
依已核准文章重绘的解说示意图。
给取消按钮写一份简短说明
团队应明确取消作用于哪一项任务、何时还能停止、已完成步骤如何显示，以及结果不明时由谁处理。这是产品约定，不是所有平台的共同保证。遇到网络断开，不要把“没收到回执”改写成“取消成功”，也不要立即重新提交一份相同任务。
依已核准文章重绘的解说示意图。
用三次演练验收，而不是看按钮变灰
建议用虚构数据分别测试启动前取消、执行中取消和完成后取消。核对后台最终状态、外部回执和用户看到的文字是否一致，再测试取消请求与完成通知几乎同时到达的情况。本文没有执行客户系统测试；验收目标是让每个结果都可解释，而不是承诺任何动作都能撤销。
依已核准文章重绘的解说示意图。