營運與維護 · 實作指南
按了取消，AI 工作流真的停了嗎？
沿三條虛構時間線，區分停止瀏覽器輸出、請求後台取消和動作已經完成。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 香港粵語逐字稿 · 澳門粵語逐字稿
按下取消之後，故事還沒有結束
設想一家美國活動服務公司的 AI 助手正在整理客戶資料，並準備發送已獲批准的確認郵件。員工發現日期有誤，按下“取消”。這是虛構演練，不是客戶事故。按鈕可以表達停止意圖，卻不能單憑頁面停止轉圈，證明後台沒有繼續執行。我們沿三條時間線檢查它的真實含義。
依已核准文章重繪的解說示意圖。
時間線甲：只停止了瀏覽器等待
MDN 說明，AbortController 可以中止 fetch 請求、響應正文讀取和流。[1] 這描述的是相關異步操作，不是業務回滾承諾。我們的設計建議是把“停止接收輸出”與“請求取消後台任務”分開：如果產品只實現前者，按鈕文字就不應暗示郵件已被阻止。
依已核准文章重繪的解說示意圖。
時間線乙：後台收到請求，尚未確認停止
Microsoft 的 .NET 文檔把取消定義為協作過程：監聽者負責發現請求並作出響應，而非被強制終止。[2] 因此，建議保留“取消請求已提交”的中間狀態，讓執行端在安全檢查點報告結果。請求發出和任務已停止不能共享同一個完成標記。
依已核准文章重繪的解說示意圖。
時間線丙：確認郵件已經發出
若發送先於取消完成，界面應誠實顯示已確認的發送結果。Microsoft 的異步請求模式建議由後台處理取消後更新狀態，並評估部分回滾或補償操作。[3] 我們的建議是先核對實際回執，再決定是否需要更正郵件；更正屬於新動作，不能因用户按了取消就自動獲得發送權限。
依已核准文章重繪的解說示意圖。
給取消按鈕寫一份簡短說明
團隊應明確取消作用於哪一項任務、何時還能停止、已完成步驟如何顯示，以及結果不明時由誰處理。這是產品約定，不是所有平台的共同保證。遇到網絡斷開，不要把“沒收到回執”改寫成“取消成功”，也不要立即重新提交一份相同任務。
依已核准文章重繪的解說示意圖。
用三次演練驗收，而不是看按鈕變灰
建議用虛構數據分別測試啓動前取消、執行中取消和完成後取消。核對後台最終狀態、外部回執和用户看到的文字是否一致，再測試取消請求與完成通知幾乎同時到達的情況。本文沒有執行客戶系統測試；驗收目標是讓每個結果都可解釋，而不是承諾任何動作都能撤銷。
依已核准文章重繪的解說示意圖。