設想一家美國活動服務公司的人工智慧助手，正在整理客戶資料，並準備寄出已獲核准的確認郵件。員工發現日期有誤，按下取消。這是虛構演練，不是客戶事故。按鈕可以表達停止的意圖，但不能只憑頁面停止轉圈，就證明後端系統沒有繼續執行。我們沿著三條時間線，檢查它真正的意思。

開發者文件說明，中止控制器可以中止網路擷取請求、回應正文的讀取，以及串流。這描述的是相關的非同步操作，不是業務回滾的承諾。我們的設計建議，是把停止接收輸出，和請求取消背景工作分開。如果產品只實作前者，按鈕文字就不應暗示郵件已經被阻止。

微軟的 Dot Net 文件，將取消定義為協作過程：監聽者負責發現請求，並作出回應，而不是被強制終止。因此，建議保留取消請求已提交這個中間狀態，讓執行端在安全檢查點回報結果。請求已經發出，和工作已經停止，不能共用同一個完成標記。

如果郵件先寄出，取消才完成，介面應該如實顯示已確認的寄送結果。微軟的非同步請求模式，建議由後端處理取消之後更新狀態，並評估部分回滾或補償操作。我們建議先核對實際回條，再決定是否需要更正郵件。更正是新的動作，不能因為使用者按了取消，就自動取得寄送權限。

團隊應該說清楚，取消針對哪一項工作、什麼時候還能停止、已完成的步驟如何顯示，以及結果不明時由誰處理。這是產品約定，不是所有平台的共同保證。遇到網路斷線，不要把沒有收到回條，改寫成取消成功，也不要立刻重新提交一份相同的工作。

建議使用虛構資料，分別測試啟動前取消、執行中取消，以及完成後取消。核對後端的最終狀態、外部回條，和使用者看到的文字是否一致，再測試取消請求和完成通知幾乎同時到達的情況。本文沒有執行客戶系統測試。驗收目標，是讓每個結果都能解釋，而不是承諾任何動作都能撤銷。