• 菜雞行為：在未知還很多時就急著選方案
• STAR 階段：T (Task)
• 本篇定位：定義在實作前真正需要完成的任務：辨識不可逆決策、未知與最低資訊門檻。

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

這篇在三日故事中的位置

Day 04｜需求才一句話，我已經開始選框架，停在一排被寫進程式碼、卻沒人確認過的假設。本篇只處理任務定義：把這些假設整理成實作前真正該完成的事；行動與結果留給下一篇。

匯入功能的任務，不是挑一個 CSV 套件

回到虛構的粉鳥工單服務。當時我把任務理解成「選一個好用的匯入方案」。但「支援匯入」是要求，CSV 套件與上傳表單是候選方案，真正的任務是第三件事：把不確定性降到可以安全開工。而我連使用者是誰都還沒確認：是坐在上傳畫面前的人，還是某個定時送資料的系統？該確認的是來源、頻率、資料契約、重送、稽核、權限與失敗處理。

先分決策：哪些錯了能回頭，哪些會跟著資料定型

我把前篇的假設攤開，依影響與可逆性分類：

畫面怎麼排是可延後決策，錯了下週改回來；資料契約與重送語意一旦上線，會跟著別人的系統與歷史資料一起定型。第三列是另一種未知：問誰都只會得到「應該還好」，文件也未必寫得準，這種未知不值得開會等結論，該用比開會便宜的方式自己換成事實——換法留給下一篇。

開工前的最低資訊門檻

這個任務的驗收不是「選好框架」，而是一份能開工的工作定義：不可逆決策需要的資訊已確認或已排定確認方式；可延後決策標明預設值；非目標寫清楚，本次不做自動修復、不重做整套工單；責任講明，來源格式由來源系統負責，解析與稽核由我負責。我仍沒有選出最佳框架，也不需要：工具比較，要等條件列完才有意義。

對應工具：《工具選擇比較表》。

# 工具選擇比較表

用途：從決策條件比較方案，而不是替熟悉工具找使用理由。
使用時機：選型難回頭、影響資料契約或對外介面時。
不必使用：決策容易復原、口頭確認就足夠時。

先列決策條件：來源與頻率、資料契約、重送與稽核、失敗處理。

| 方案 | 符合需求 | 退出成本 | 風險 | 不採用理由 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

提醒：條件先寫完才填方案；資訊補齊前，不宣稱已找到最佳方案。

條件先於方案

先分可逆與不可逆，再決定哪些未知值得等；先列決策條件，再比較工具；先寫非目標與驗收，再動手實作。

今天可以帶走的練習

拿 Day 04 記下的五個假設，用半小時左右分成可延後、需立即確認、必須自己動手換成事實三類，各附一句下一步。產出是一頁分類清單，另一位讀者能指出最該先確認的一條即通過。小變更口頭確認即可，不必填表。

下一篇

Day 06｜我把決策縮小後，重做的程式碼也跟著變少，會交代我如何依這份定義縮小決策，以及少寫掉哪些重做。