• 菜雞行為：把溝通當成把問題丟給別人
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何以共同資訊結構改善提問、進度、Review 與架構說明。

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

這篇在三日故事中的位置

Day 17｜團隊需要的不是進度百分比，而是可行動的資訊，把任務定成讓收到的人能判斷、驗收或接手。本篇交代改法、結果與限制。

三種溝通，其實共用同一組欄位

我沒有替每種溝通各背一套模板，而是發現它們共用同一組資訊：背景、證據、目前判斷、風險與需要對方採取的行動。以下仍用虛構的粉鳥工單服務。提問開始附上重現步驟、錯誤訊息、已嘗試方法與目前的懷疑；回報把「做到 70%」換成成果、證據、阻礙與需要的決策；架構說明也照同一組欄位重寫，方框旁補上誰負責、資料往哪流。先改提問，頻率最高、成本最低。

Review 意見也分級，別讓偏好擋住合併

輪到我當審查者，問題換了方向：我的意見對作者是不是也是轉交單？「這樣寫不好」沒說明影響、沒有證據，也沒說要不要擋。我開始把意見分成四級：

分級後，作者能先處理阻擋項，不必猜哪句是閒聊、哪句是底線。

結果：別人能從我停下的地方接手

結果只寫可支持的質性觀察：附了重現步驟與判斷的提問，對方通常能從我停下的地方接手，不必重走探索；回報改寫後，討論從「現在到底怎樣」變成針對阻礙與決策。證據就是這些訊息本身，留在工單與討論串裡可回顧。限制也真實：小事不必填滿模板，一句話能解決的事硬填表只是儀式；這套結構保證對方看得到我的判斷，不保證同意；習慣也會退步，趕時間時我還是會只丟一句「壞了」，只是現在自己看得出來。

粉鳥工程筆記：讓對方能接手，溝通才算完成

動筆前想清楚對方接手還缺什麼；證據與目前判斷永遠附上；意見要說影響與等級；小事保持小。

今天可以帶走的練習

用一小時完成兩件事：先把手上一項工作寫成含成果、證據、阻礙與下一步的可交接回報；再用《Code-Review分級表》把最近十則 Review 意見分成阻擋、重要、建議與偏好。驗收方式：讀者能指出哪些意見必須先處理。變更很小、意見一眼可判斷時不必分級。

對應工具：《Code-Review分級表》。

# Code Review 分級表

用途：將審查意見分成阻擋、重要、建議與偏好。
使用時機：意見較多、作者難以判斷修改優先順序時。
不必使用：變更很小、意見一眼可判斷時。

| 意見 | 分類 | 影響 | 是否阻擋 | 建議修改 |
| --- | --- | --- | --- | --- |
|  |  |  |  |  |

提醒：偏好註明可忽略；阻擋項要說明具體影響與證據。

下一篇

溝通能被接手了；但接手的前提是證據可信。下一組換一個問題：Day 19｜我說昨天測過會動，隔天卻連自己都重現不了。