• 菜雞行為：把溝通當成把問題丟給別人
• STAR 階段：S (Situation)
• 本篇定位：呈現我如何把「不會」或「壞了」直接交給別人，沒有提供可判斷資訊。

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

這篇在三日故事中的位置

上一組故事收在 Day 15｜我留下「現在不重構」的理由，反而更敢改。這一組談把溝通當成把問題丟給別人。本篇只寫情境，任務留給 Day 17。

把問題丟出去，球就不在我手上

我以前把提問當成一個動作：把卡住的地方丟出去，等懂的人接住。回頭看，那其實是一張問題轉交單，上面只寫「壞了」，判斷需要的一切都留在我的螢幕裡。案例是虛構的粉鳥工單服務，不對應真實公司與人物。我測匯出功能時卡住，把錯誤畫面貼進群組，只問「為什麼不會動」。環境、預期與實際、輸入、Log、已嘗試與目前判斷，一項都沒有，幫忙的人得先反問一輪。提問沒有傳遞資訊，只是替對方開了一個考古現場。

差別在接手成本：右欄每一格，都是對方原本得用反問換回來的。

幾次「看一眼就猜中」，養出一個壞習慣

這樣問不是故意偷懶。資深的人常看一眼就猜中方向，幾次成功讓我以為提問本來就這麼輕；我也怕寫長浪費時間，怕暴露自己說不清問題。另一些日子我反過來卡很久不開口，把不敢提問當成成熟。兩種樣子相反，效果一樣：資訊都沒流動。

提問的門檻不是先解完，是讓人接得上

好提問不是先把問題解完才有資格問，而是讓對方能從已有資訊接手，不必重走我的路。比起長篇背景，對方更需要證據與目前判斷。這一則提問補得起來，不代表我知道回報進度、送出 Review 意見時各該給什麼；那組共通的資訊結構留給下一篇定義。

轉交單的三個特徵

送出前檢查三件事：只有現象與求救，沒有證據；對方得反問才能開始；我說不出目前判斷。中任何一項，就還是轉交單。

今天可以帶走的練習

找一句最近說過的「這個壞了」，依《高品質提問範本》改寫成背景、預期、實際、環境、證據、已嘗試與具體問題，產出一則可直接送出的提問。驗收方式：讀者不需追問就能複述問題。口頭三十秒能說清的小問題不必填表。

對應工具：《高品質提問範本》。

# 高品質提問範本

用途：提供足以讓他人判斷的背景、證據與具體問題。
使用時機：問題需要別人接手判斷、口頭一兩句說不清時。
不必使用：問題極小口頭確認即可、填表成本高於風險時。

| 背景 | 預期行為 | 實際行為 | 環境 | 證據 | 已嘗試 | 目前判斷 | 具體問題 |
| --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |

提醒：不放密碼、個資與機密；證據與目前判斷比長篇背景重要。

下一篇

提問只是丟問題的一種姿勢，回報與 Review 也有同樣的病。Day 17｜團隊需要的不是進度百分比，而是可行動的資訊，會定義工程溝通真正的任務。