AI coding agent 的工作速度變快後，先寫一份完整計畫、核准後才開始修改，還是最好的合作方式嗎？Ayman Nadeem 在 2026 年 9 月 24 日回顧自己打造 AI coding app Nuanced 的經驗，給出一個挑釁的標題：Plan mode is dead。但他的文章並不是說工程師不必再思考；他質疑的是，把規劃固定成一份必須先完成、再交給 Agent 執行的文件與階段。

這個區分會改變我們怎麼使用 Plan Mode。規劃仍然重要，計畫也可能有用；真正需要調整的是：要不要讓每個任務都先走同一套模式切換與文件審批流程，以及開始實作後能不能回頭修正原先的理解。

完整計畫，不等於完整理解

Nuanced 的出發點，是讓使用者先談清楚目標、處理模糊決策、留下持續更新的計畫，再交給 Agent 實作。Nadeem 後來觀察到，使用者不太想讀冗長的 AI 生成規格；模型也更能從大型程式庫理解脈絡；而把聊天、規格審查與實作切成固定階段，會讓人覺得思考必須先「完成」，才能開始動手。他把其中一個教訓概括為：規劃和一份叫作 plan 的文件不是同一回事。

這是產品建造者對 Nuanced 使用經驗的回顧，不足以證明所有團隊都不需要計畫文件。它指出的工程問題卻很具體：一份文字可以很完整，仍可能沒有讓人更清楚哪些決策已定、哪些假設待驗、實際改動又會帶來什麼行為。規格愈長，若沒有幫助人掌握系統的變化，就只是多一個需要維護的介面。

Plan Mode 沒有消失，固定流程才值得重新檢查

截至 2026 年 9 月，Anthropic 與 OpenAI 的公開文件都仍把 Plan Mode 列作可依任務選用的功能；從兩家列出的適用情況來看，它不必成為所有變更的固定前置。Anthropic 仍建議在方法不明、涉及多個檔案或程式碼陌生時先規劃；範圍清楚、只需一個小修改時則可以直接開始。Claude Code best practices 同時把 Plan Mode 定義成先探索、提出計畫，再切換到實作的方式。它是一種有成本的選項，不是每題都要經過的儀式。

Plan Mode 也可以是一條權限邊界：在一般設定下，Claude Code 處於 Plan Mode 時會先讀檔與探索，並阻擋原始碼修改；但使用者可以不核准計畫就退出這個模式，所以它限制的是模式開啟期間的寫入，不保證每次修改前都經過計畫審批。互動式 terminal 若啟用 bypass permissions，寫入也不會受同一條限制。Claude Code permission modes 因此，Plan Mode 對高風險工作仍有實際價值，但若團隊需要強制審批，還必須把核准規則放進實際工作流程。

Codex 官方對 Plan Mode 的建議也採條件式用法：任務規格不足、有風險或可能跨越多個系統時，先看它提出的實作路徑；若工作會經過多輪，再用持續目標接住後續執行、測試與修正。OpenAI：Mastering remote engineering work from your phone 這表示模式仍在，重點是把它用在需要人先判斷路徑的地方。

所以，Nadeem 的標題適合當成一次流程設計的挑戰，不是功能退役公告。要淘汰的是「完整文件先核准，接著只能照表執行」的預設；不是探索、審查或人類判斷。

把計畫當作工作假設，而不是執行契約

計畫應先降低錯誤方向的成本，之後仍可被新資訊修正。比較符合實際開發的節奏是：

理解問題 → 採取一個可檢查的步驟 → 檢視結果 → 澄清假設 → 調整方向 → 繼續

這個迴圈不代表 Agent 可以自行決定所有事情。人仍要明確指出哪些決策不能被模型補完、哪些變更要先詢問，以及如何證明結果正確。Agent 可以在低風險、可逆的範圍內自行探索；若新發現會改變使用者行為、資料模型、公開 API、權限或交付範圍，就要把決策帶回人面前。

前一篇把 Agent 規則整理成可驗證開發環境的文章討論的是規則該放在哪裡、如何用測試與回饋驗證。本文補上的問題是：即使規則和目標已經清楚，工作開始後還要保留調整計畫的空間。

先寫決策邊界，再決定要不要寫長計畫

如果任務需要先交代，可以先提供一份短的決策契約。以下是本文整理的格式，不是 Anthropic 或 OpenAI 的官方模板：

目標：要改變的可觀察行為
不變條件：必須保留的相容性、權限與既有行為
可自行判斷：Agent 可以在什麼範圍內選擇做法
必須先問：哪些產品、資料或架構決策不能自行假設
完成證據：用哪些測試、輸出或差異確認結果

接著依風險決定流程：

  • 範圍清楚、改動小、容易還原：提供目標與驗收方式，讓 Agent 先做一小步，再看差異與結果。
  • 做法不確定、跨多個模組或涉及高成本決策：先開 Plan Mode，確認影響範圍與未決選項；切換到實作後，仍允許根據程式碼和測試結果回頭修訂。
  • 需要交接、稽核或多人並行：把重要決策、責任邊界、驗證結果寫下來。保存這些資訊是為了讓下一個人理解變更，不是為了保留每一段 AI 生成的推理文字。

並行 Agent 尤其需要第三種資訊。人不可能逐字讀完所有 session；至少要能追到每個工作目標、修改範圍、未決決策與驗收證據。讓 Agent 工作可以並行驗收談過如何把工作切成可檢查的結果；計畫文件無法取代這種追蹤能力。

下一次，先問「我需要看哪個決策」

下次準備按下 Plan Mode 前，先判斷這次工作是否包含方向不明、難以回復或需要人工選擇的決策。若有，先用它探索與揭露風險；若沒有，讓 Agent 從小步驟開始，並要求它在新資訊改變假設時停下來說明。

這樣一來，計畫不必在第一個檔案被修改前就假裝完整。人保留的是目標、限制與重要判斷，Agent 負責以實作和驗證逐步揭露新的問題；真正有用的工作紀錄，則留下哪些決策改變了系統，以及結果如何被確認。