結論

呈現決策時、預設選項清單應包含「現在不決定、先做 X 再回來」這一條 — 而且要主動標出、不是等使用者自己想到。

「立刻決定」與「拖延」之間有第三條路：結構性延後。延後有明確條件（例：等卡片補完、等 context 收斂、等下個 sprint），不是「再說啦」。沒主動給這個選項、使用者會被迫在 context 不足下做決策、產生品質低的選擇。

為什麼「立刻決定」是預設、卻常常錯

被問到時、對話的隱含壓力是「該答了」。這個壓力來自：

  • 對話節奏（沒答 = 流程卡住）
  • 禮貌（不答 = 不尊重對方）
  • LLM / agent 預設「使用者問就執行」（沒延後機制）
  • 「快速決策 = 高效」的迷思

這四條都不必然成立、合在一起變成預設。實際上有的決策本來就不該現在做 — 缺資訊、缺驗證、缺其他關聯決策的結果。在這種情境下「立刻決定」= 在錯誤時點做、品質差、後續還要重做。

三類該延後的決策

類別 1：依賴未完成的 context

需要先讀某些 code / 跑某些測試 / 看某些資料才能判斷。例：

  • 「該用 strategy A 還是 B」依賴 A/B 各自的 cost — 還沒量
  • 「卡片 X 該寫成 pattern 還是原則」依賴知識庫整體形狀 — 還沒看
  • 「ship D 還是先做 B/C」依賴 D 的實作風險 — 還沒展開

延後條件：補完 context 即可決。

類別 2：依賴尚未發生的事件

需要等某個外部事件（其他 PR merge、其他人決策、某個觀測週期結束）。例：

  • 「這個 feature 要不要保留」依賴使用者使用率 — 等 telemetry
  • 「該不該 refactor X」依賴 Y team 的 migration 進度
  • 「flag 何時拔掉」依賴觀測期長度

延後條件：事件發生 / 觀測期到。

類別 3：依賴上層決策

某個下層決策還在等上層決策、現在做下層 = 為上層猜測、可能要重做。例：

  • 「這個 module 該怎麼分」依賴整體架構方向 — 還在討論中
  • 「DB schema 怎麼設計」依賴功能範圍是否擴張

延後條件：上層決策落地。

主動提供「不決定」選項的範本

呈現決策表時、加最後一個選項：

1| 選項 | 適配性 |
2|---|---|
3| A ⋯⋯ | ⋯⋯ |
4| B ⋯⋯ | ⋯⋯ |
5| C ⋯⋯ | ⋯⋯ |
6| **延後（補 X 再決）** | 不立刻決、先 ⋯⋯、回來時 context 完整 |
7
8我推薦 A、不過如果 ⋯⋯（某個 context 還沒展開）、我建議先延後、補完 X 再回來決。

關鍵：主動標出延後條件 — 「補完 X」是具體可執行的動作、不是「再說啦」。延後不是 escape hatch、是有明確 next step 的另一種決策。

反模式：把「不決定」當失敗

反模式為什麼不好修法
隱式假設「問了就要答」使用者沒被告知有延後選項主動列入選項
把「我先想想」當拖延、加壓使用者被迫在不足下決策接受延後、問「需要先補什麼」
延後沒寫條件、變「之後再說」#72 結構性跳過延後條件具體化、寫成 trigger
「不決定 = 不負責」道德判斷阻止使用者用合理選項區分「逃避決策」vs「結構性延後」
一直 retry「那你決定了嗎？」對方沒能力決也催不出來改問「現在缺什麼？要不要先補 X」
延後選項只給自己、不給使用者雙標、使用者沒同等權利互相對等、雙向皆可延後

何時不該延後

情境為什麼
Incident / 緊急修復延後成本 > 決策品質損失
無關緊要的小決策（檔名、次要色）決策成本 > 改錯成本、隨便決即可
已經循環討論過 N 次延後變藉口、強制做出 best-guess
等了幾天 / 幾週 context 還沒補齊結構問題、不是延後解決得了的
需要 user 體驗才能驗證的「決定 + ship + 看反應」比延後更快

四類共同：延後的成本 > 決策品質的收益。其他情境保留延後選項。

跟其他卡的關係

卡關係
#58 模糊指令的篩選三問三問之一就是「現在做 vs 等更多資訊」、本卡是這個維度的展開
#74 決策呈現格式三層格式中「選項列表」應包含「延後」這個選項
#72 高 ROI 無觸發延後若沒 trigger 會變「結構性跳過」、必須寫條件
#68 驗收的時間軸Checkpoint 1（寫之前）有時候答案就是「還不能寫、先補 context」
#42 2 次門檻失敗 2 次後常該延後決策、回頭驗證假設
#79 決策對話的五維度本卡是 #79「時間軸」維度的展開 — 立刻決 vs 結構性延後

判讀徵兆

訊號該做的事
使用者說「不用現在決策」「我再想想」接受、問「要不要先補 X」
使用者反覆改變決定可能 context 不足、提議延後到 X 補齊
自己（agent）每次都立刻答檢查是否真的有資訊判斷、不是的話主動標延後
決策表沒「不決定」欄補上、且寫具體條件
「下次再決」沒寫 trigger寫條件 — 補完 X / 等到 Y / 跑完 Z 觀測
一個決策卡了很久、團隊各自堅持不是延後的問題、是缺 deciding mechanism
「我覺得 A 比較好不過你決定」騎牆不夠明確的推薦 + 延後混在一起、區分清楚

核心：對話中「答 / 不答」是二元的、決策中「決 / 延後 / 拒絕決」是三元的。把延後當合法選項主動提供、品質會比強迫立刻決更好。延後不是禮貌性給出口、是工程上對「context 不足」的正確反應。