• 菜雞行為：在未知還很多時就急著選方案
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何用假設清單、小型探查與最小決策降低返工。

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

這篇在三日故事中的位置

Day 05｜我該管理的不是框架，而是那些還沒確認的假設，留下能開工的工作定義。本篇交代我實際做了什麼，以及重做少在哪裡。

高風險的未知，我用小型探查換成事實

粉鳥工單服務的故事接著走。拿著分好類的假設清單，我沒有先選匯入框架，而是先處理兩個難回頭的未知：向提出者確認資料怎麼來，答案是另一個系統的排程 API，不是人工上傳；再取幾筆真實資料試解析，發現欄位比文件寫的亂。探查刻意做小，只求把「我以為」換成「已確認」。

[假設清單] --> [小型探查] --> [最小決策] --> [實作]
 高風險優先     取樣試解析     只定介面      其餘延後

探查不是原型，問題答完就丟。

最小決策不是最少程式碼

探查之後，我只決定收檔介面與資料契約的第一版；完整匯入框架、批次報表與稽核畫面全部延後。最小決策不等於最少程式碼——為了讓框架晚點選，我反而多寫了一層薄轉接，把解析實作關在介面後面。採用與延後都寫進紀錄，只留當時知道的事。

對應工具：《工程決策回顧表》。

# 工程決策回顧表

用途：記下決策當時的資訊與假設，讓選擇之後可回顧、可修正。
使用時機：決策難回頭、影響資料契約或對外介面時。
不必使用：容易復原的小決策，口頭確認就足夠。

| 決策 | 當時資訊 | 假設 | 下次調整 |
| --- | --- | --- | --- |
| 收檔介面第一版：採用 | 來源與重送已確認 | 契約短期不再變動 | 來源系統改版時重新檢查 |
| 選定匯入框架：延後 | 欄位仍在變動 | 晚點選不會更貴 | 資料契約穩定後重新評估 |

提醒：只寫當時知道的事；不放機密、個資與可辨識人物。

重做還是發生了，只是變小了

結果不是一次到位。欄位與重送細節後來仍變動過，但要改的只剩介面後面的解析模組，資料契約與整條資料流都沒動。這裡我不打算誇大：我沒有平行做一次「照原本方式硬幹」的版本來比較，說不出省下多少工時，只能說重做被關進了比較小的房間。決策紀錄留下另一種證據：要不要上框架，檢查延後條件成立了沒有就行，不必憑記憶重比一次。

粉鳥工程筆記：決策愈小，重做愈小

高風險的未知先換成事實，只決定現在非決定不可的事，其餘留一道薄介面等它。限制也得說清楚：探查只消除被挑中的未知，其餘照樣會咬人；延後要付轉接層的維護成本，不是免費等待。

今天可以帶走的練習

挑一項還沒定案的技術選擇，用《工程決策回顧表》寫下打算採用什麼、延後什麼，以及各自的重新評估條件。重點是趁答案還沒揭曉時寫，事後補的理由通常比當時漂亮。寫得夠清楚的話，另一位讀者能看懂當時為何這樣選。容易復原的小決策口頭確認即可。

下一篇

決策縮小了，程式也在本機跑了起來；下一種學生味從這裡冒出來。Day 07｜本機能跑，我就以為事情差不多了。