• 菜雞行為：只設計正常路徑，把例外留給現實
• STAR 階段：T (Task)
• 本篇定位：定義錯誤分類、狀態、可執行操作與完成條件。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 10｜我只畫了 Happy Path，然後讓現實負責例外，停在畫面顯示成功、工單卡在半路、沒人答得出系統怎麼了。本篇只定義任務；修補與測試留給 Day 12。

「把錯誤處理補一補」聽起來像任務，其實是方案

虛構的粉鳥工單服務還沒完。我的第一反應是開一張「補錯誤處理」的待辦：多包 try、多加訊息、失敗就重試。但這些是方案，不是任務。回到會碰到失敗的人——送單的使用者、追查紀錄的人、救火的維運——他們要的是判斷發生什麼、決定下一步、讓系統回到可繼續的狀態。真正的任務是把每種失敗接進這三件事，不是藏進同一句「系統忙碌中」。

回應成功只代表已接受，完成要另外定義

還有一件我當時沒想清楚的事：建立工單是非同步操作，HTTP 回應成功只代表請求被收下，不代表業務完成。任務因此多一層：把生命週期說清楚——已接受、執行中、完成、失敗、已取消，每個狀態有進入條件與允許操作，且畫面、API 與事後查詢看到同一個狀態。完成不再是「回傳成功」，而是拿得出證據。

邊界：不是每種失敗都值得自動重試

任務也包含非目標。這次不做永不失敗的系統，也不用無限重試蓋掉錯誤：重試只留給逾時這類暫時性失敗，且要先確認同一命令重送不會建立第二張工單——這是開工前必須確認的未知；補償要做到多自動、文案要多長，可先用人工與預設值頂著。驗收只有一句：任何失敗發生時，值班的人不用翻 log，就能回答狀態是什麼、誰該做什麼。

先定義狀態，再談重試

補 try 是方案，讓失敗可判斷、可處理、可恢復才是任務；狀態與完成條件對外只有一套；重試是設計後的選項，不是錯誤設計的替代品。

今天可以帶走的練習

挑一個手上的非同步操作，用二十分鐘，以《非同步操作生命週期表》寫出各狀態的進入條件、允許操作與完成證據。產出一頁表格，讀者能據此回答「失敗時使用者能做什麼」即通過。同步單步驟操作不必填表。

對應工具：《非同步操作生命週期表》。

# 非同步操作生命週期表

用途：定義接受、執行、完成、失敗與取消狀態。
使用時機：回應先於完成、失敗需要重試或補償的操作。
不必使用：同步完成、失敗重做一次即可的操作。

| 狀態 | 進入條件 | 可執行操作 | 完成證據 |
| --- | --- | --- | --- |
| 已接受 | 請求通過驗證 | 查詢、取消 | 工單編號 |
| 失敗 | 背景工作出錯 | 查詢、重試、取消 | 錯誤分類與紀錄 |

提醒：狀態對外只有一套；不放機密、個資與可辨識人物。

下一篇

任務定義完，剩下是讓它看得見。Day 12｜我補上失敗情境後，測試才開始像真的，會交代我怎麼把它接成測試與證據。