• 菜雞行為：在未知還很多時就急著選方案
• STAR 階段：S (Situation)
• 本篇定位：呈現我如何用熟悉工具替尚未定義的問題搶答。

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

這篇在三日故事中的位置

前一組故事在 Day 03｜我先不寫程式，反而比較快找到該做的事收尾。這一組換一種更細微的學生味：未知還很多時，我就急著選方案。本篇只停在情境，任務的定義留給 Day 05。

「支援匯入」四個字，我直接聽成 CSV 上傳

這段經驗來自我自己的工作方式，細節放進虛構的「粉鳥工單服務」，不對應真實公司、人物或專案。需求只有一句：「工單要支援匯入。」我沒有多問，腦中已浮出：上傳 CSV 的表單、解析欄位的程式與對應的資料表。後來才知道，資料來源是另一個系統的排程 API，還需要重送、稽核與版本管理。我先蓋好的上傳表單，解的是自己出的題目。

[一句要求: 支援匯入]
        |
        v
[熟悉方案: CSV 上傳表單]
        |
        v
[介面、資料格式、流程逐步定型]
        |
        +--> [來源、頻率、失敗處理仍未確認]

從一句要求走到結構定型，中途沒有確認過來源、頻率與失敗處理。

熟悉的工具讓我以為自己聽懂了

問題不在使用框架或現成工具，而在選擇時機。熟悉工具會製造已經理解問題的錯覺：CSV 我解析過、上傳表單我寫過，「支援匯入」聽起來就像做過的作業。每一步都有進度感；愈熟練，愈晚發現自己還沒聽懂需求。

被寫進程式碼的，是一排沒人確認過的假設

回頭看，資料格式、同步方式與介面都只是未驗證的假設：資料是檔案、匯入由使用者手動觸發、失敗了重傳一次就好。它們沒有留在文件裡被質疑，而是直接固化成資料表與程式碼。等真正流程浮現，要改的不是幾句描述，而是一套長好的結構。

粉鳥工程筆記：太早選方案的三個徵兆

我先留下三個徵兆：需求還沒複述一遍，就開好專案或資料表；說得出方案細節，卻說不出資料來源與使用情境；聽到不熟悉的條件，先把它翻譯回熟悉做法。

今天可以帶走的練習

回顧一項正在做的功能，花十五至四十五分鐘，用《假設登錄表》列出自己已默認、但沒人正式確認的五個假設，寫下影響與確認方式。產出是可交給讀者檢查的清單，對方能指出最該先確認的一條即通過。小變更口頭可確認時不必填表；不放機密、個資與可辨識人物。

對應工具：《假設登錄表》

# 假設登錄表

用途：在選定方案前，記下已被默認、尚未確認的前提。
使用時機：一句要求可能對應多種做法，且誤解會造成重做時。
不必使用：變更很小、容易復原，口頭確認就足夠時。

| 假設 | 影響範圍 | 如何確認 | 狀態 |
| --- | --- | --- | --- |
| 資料以 CSV 檔匯入 | 上傳介面與解析流程 | 與提出者確認來源 | 未確認 |
| 匯入一次即算完成 | 重送與稽核設計 | 確認失敗與重送需求 | 未確認 |

提醒：只記會改變設計的前提；不填個資、機密與可辨識人物。

下一篇

假設先被看見，才輪得到管理。Day 05｜我該管理的不是框架，而是那些還沒確認的假設，會把這些默認前提整理成真正的任務。