• 菜雞行為：把「昨天測過會動」當成完成證據
• STAR 階段：T (Task)
• 本篇定位：定義同步回應、非同步狀態與業務完成之間的證據。

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

這篇在三日故事中的位置

Day 19｜我說昨天測過會動，隔天卻連自己都重現不了，留下的問題是：我把單次成功的記憶當成完成證據。本篇定義「完成」要證明什麼、對誰證明；怎麼補證據留給 Day 21。

回傳成功的那一刻，事情多半還沒發生

開始認真留紀錄後，我發現抄下的「實際結果」常常只有一行：API 回傳成功。虛構的粉鳥工單服務又派上用場：批次匯入的 API 回覆成功，意思只是請求送到了、已排進背景佇列，匯入本身稍後才發生。我拿傳輸層的成功當成業務完成，證據記在錯的那一層。

從收到請求到事情完成，中間隔著四層

這張表仍是虛構案例的整理。每一層都該有自己的證據，而我當時做的事，是拿第一層的證據冒充最後一層。

任務是讓完成可以被查到，而且各處說法一致

任務不是「讓 API 回成功」，而是替這條非同步流程定義可觀察的完成條件：送出匯入的人拿到編號後能查到狀態；成功要看得到匯入幾筆；失敗要知道敗在哪、能否重試；取消也要留下證據。還有一條容易漏掉：狀態、Log、通知與查詢介面必須說同一個故事——查詢說完成、Log 卻停在一半，證據就互相拆台。必須先確認的未知：狀態由誰更新、失敗如何定義、部分成功算什麼。非目標先寫明：這一輪不承諾自動重試，也不回補歷史資料。

先問使用者憑什麼採取下一步

• 成功碼只證明請求進了系統，不證明事情完成。
• 每個狀態都要指得出對應證據；指不出來就是任務缺口。
• 狀態與 Log、通知、查詢一致，證據才可信。

今天可以帶走的練習

挑一個「API 先回成功、事情稍後才完成」的操作，用二十分鐘，寫出接受、進行中、完成與失敗四種狀態的進入條件與證據，產出一頁生命週期表，驗收方式是另一位讀者只看表就能回答使用者何時可採取下一步。同步且立即回結果的小操作不必填。

用的還是 Day 11 那張《非同步操作生命週期表》，這次多開一欄「對外回應」，因為本篇重點正是各處說法要一致。

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

# 非同步操作生命週期表

用途：定義非同步命令從接受到完成、失敗與取消的狀態與證據。
使用時機：API 先回覆、工作稍後才完成，完成與否必須能被查到時。

| 狀態 | 進入條件 | 可執行操作 | 對外回應 | 完成證據 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

提醒：狀態要與 Log、通知、查詢一致；不放機密與個資。

下一篇

完成條件釘在紙上了，還得釘進系統才算數。實作過程留給 Day 21｜我用 Log、狀態和測試證據把完成條件釘住。