• 菜雞行為：把職場當成已經出好題目的考場
• STAR 階段：S (Situation)
• 本篇定位：先把我如何將模糊工作誤認成已定義考題的情境說清楚。

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

這篇在三日故事中的位置

本篇只談 Situation；任務留給 Day 02，做法與結果留給 Day 03。「學生味」不是學生身分，而是把職場當成已出好題目、只等我寫標準答案的考卷。

我很會回答，卻沒有先確認該回答什麼

在學校，題目要解什麼、輸入輸出與限制多半寫在題幹裡；我讀題、選解法、開始寫。這套節奏對邊界清楚的小修改很好用；問題是我把它搬到尚未定義的工作上。聽到一句功能要求，腦中就自動補成技術題，卻不知道誰要用、什麼情況用、完成後要做什麼。很會回答問題，不代表已經確認該回答哪個問題。

粉鳥工單服務：一句「加搜尋」長出一串答案

以下是虛構案例，不對應任何真實公司或人物。需求原句只有：「工單要能搜尋。」我立刻翻成「替列表加關鍵字搜尋」，開始想欄位、索引與分頁，覺得自己已經在工作了。可是這些答完，功能仍可能沒解決原本的困難——使用者要找的也許是失敗、未結案、待追蹤的工單，還受權限限制。這些條件才決定題目。

[一句要求] --> [直接選方案] --> [開始實作]
     |
     +--> [使用者、情境、目的仍未知]

留在旁邊的是使用者、情境與目的；三項未知時，技術再漂亮，也只是解自己出的題目。

我真正漏掉的是題目邊界

立刻提出方案看起來有進度，熟悉的技術也給我控制感。漏掉的是三件事：誰遇到問題、在什麼情境發生、完成後要支援哪個行動。邊界未確認前，我無法判斷欄位、權限與效能是否必要，也說不清什麼算完成。

粉鳥工程筆記：先看見自己正在搶答

三個煞車燈：

• 一聽到功能名稱就開始選技術。
• 說不出使用者、情境與行動。
• 拿掉方案後，說不清問題。

它們不是需求分析模型，只是煞車燈。

今天可以帶走的練習

挑一個最近的功能要求，花十五至四十五分鐘，原樣記下要求原句、提出者職責、已知情境與第一個想到的解法，產出一則短紀錄，先不要設計。驗收標準：能分開已知資訊與方案。小修改口頭確認即可，跨角色時再往下用這張卡。

對應工具：《需求澄清卡》。

# 需求澄清卡

用途：把一句功能要求往回追到使用者、情境、問題與驗收。
使用時機：工作跨角色、影響資料或權限、驗收容易各說各話時。

| 需求原句 | 使用者 | 發生情境 | 真正問題 | 目前方案 | 待確認 | 驗收方式 |
| --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |

提醒：只填會影響判斷或驗收的資訊；不放機密、個資與可辨識人物。

下一篇

下一篇的 Task 不是「把搜尋做完」，而是：一句要求要補上哪些資訊，才能成為可分工、可驗收的工程問題——Day 02｜真正的任務，是把一句要求拆成能驗收的問題。