• 菜雞行為：只設計正常路徑，把例外留給現實
• STAR 階段：S (Situation)
• 本篇定位：呈現功能在理想路徑上很順，遇到真實失敗後卻無法回答系統現在怎麼了。

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

這篇在三日故事中的位置

上一組故事收在 Day 09｜我用差距表把展示品推到可驗收成果。這一組的學生味是只設計正常路徑，把例外留給現實。本篇停在情境，任務留給 Day 11。

回應成功那一刻，工作才做到一半

這段經驗的技術細節放進虛構的「粉鳥工單服務」，不對應真實公司或人物。建立工單的 API 我寫得很順：驗證輸入、寫入資料庫、回傳成功；通知與同步較慢，丟給背景工作。背景工作稍後失敗，事情才露出另一面：畫面仍顯示成功，工單卡在半路，沒有重試、取消，也沒有地方追蹤。最先發現的是回頭來問工單去哪了的使用者；我只能翻 log。

[收到請求] --> [回應成功] --> [背景工作]
                                  |
                       +----------+----------+
                       v                     v
                    [完成]          [失敗: 畫面仍顯示成功]

主路徑每步都有去處，唯獨背景失敗停在沒有出口的地方。

測試全綠，讓我以為例外只是小機率

當時這樣寫並不心虛。正常路徑有測試、有畫面、有進度；錯誤處理被我濃縮成 catch-all：包一層 try，跳一句「系統忙碌中，請稍後再試」。例外很少發生，發生再修，聽起來務實。但這句話什麼都沒回答：使用者不知道該重試還是等待，我不知道失敗停在哪一步。

會失敗的地方，其實排得出一整排

事後攤開，我漏掉的是一整類情境。網路會逾時、會斷在回應途中；外部系統會慢、會掛、會回怪內容；資料會髒、會重複送出。失敗長得都不一樣，卻被我用同一句話打發。最難的不是完全失敗——那至少乾脆——而是部分成功：工單建立了、通知沒發出去。它不能整筆重來，也不能假裝沒事，我的設計裡沒有它的位置。

成功回應只是收件，不是完成

任務留給下一篇，這裡先記下三個自問：回應成功後還有哪些工作在背景跑；每種失敗，使用者看到什麼、能做什麼；哪種狀態只能靠翻 log 回答。

今天可以帶走的練習

挑一項手上的功能，花半小時左右，用《失敗情境矩陣》列出錯誤輸入、外部失敗、逾時、重複請求、取消與部分成功，寫下觸發條件與使用者所見。產出一頁矩陣，讀者能指出最危險的一格即通過。小功能口頭確認即可。

對應工具：《失敗情境矩陣》。

# 失敗情境矩陣

用途：把可能失敗的地方攤成可以逐格檢查的清單。
使用時機：功能含背景工作、外部系統或多步驟資料更新時。
不必使用：單步驟小功能，失敗重做一次即可時。

| 情境 | 觸發條件 | 使用者看到什麼 | 補償方式 |
| --- | --- | --- | --- |
| 背景工作失敗 | 通知服務逾時 | 仍顯示成功 | 目前沒有 |
| 部分成功 | 同步中斷 | 資料不一致 | 目前沒有 |

提醒：先誠實記錄現況；不放機密、個資與可辨識人物。

下一篇

情境攤開後，問題顯然不是多補幾個 try。Day 11｜功能真正的任務，是失敗時仍能被理解和處理，會把它們整理成該完成的任務。