Claude Code 中的 Plan Mode：逐步指南與 2026 年的 4 個階段

更多說明請參閱 Ailoot 說明文件。

Plan Mode 是什麼？為什麼單靠它還不夠？#

在一般模式中，Claude Code 會立即寫入程式碼；如果你沒有持續留意，就可能突然得到一份跨越許多檔案的差異。Plan Mode 反轉了工作步驟：先研究與規劃，再核准，最後才修改。

Anthropic 在官方說明文件中如此描述 Plan Mode：

聽起來很簡單，卻隱藏了最重要的轉變。Plan Mode 改變了工作節奏：先取得共識，再採取行動。這是模式上的改變，不是表面上的微調。vibe coding 開發者的痛點在於，AI 代理往往急著動手。如果你在一般模式中要求「加入 Google 驗證」，Claude 會在一分鐘內寫好程式碼，但其中一半檔案都會選錯。在 Plan Mode 中，同樣的要求會先變成一份文字計畫，你可以花兩分鐘閱讀並修正，而且此時還沒碰到任何程式碼。

有個國際指南沒人提過的陷阱。Plan Mode 本身是個脆弱的工具：計畫只存在目前的對話中。關掉視窗，計畫就不見了。你無法把它交給另一個代理。沒有版本或歷史紀錄。如果任務很大（重構一個 30 個檔案的模組、遷移到新的資料庫），計畫很快就會碰到上下文視窗的上限，開始逐漸失準。

這就是 Plan Mode 適合搭配儲存庫中的 plans/ 資料夾的原因。計畫會儲存為 plans/2026-05-21-google-oauth.md，拆分成多個階段並附上核取方塊，之後任何代理都能接手。這就是上下文工程的做法：在提示詞之前管理上下文，而不是在提示詞過程中管理。

如何在 Claude Code 中啟用 Plan Mode？#

在工作階段中最快的方法是使用鍵盤：

Shift+Tab           # cycles through modes: default → acceptEdits → plan

按兩次後，終端機底部會出現 ⏸ plan mode on 指示器。再按第三次就會回到一般模式。這是最方便的方法——看到任務逐漸擴大時，可以隨時切換。

第二種方法是在單一提示詞前加上前綴：

/plan write a plan to migrate the database from MySQL to Postgres

如果你正在使用 auto-accept 模式，又不想整個工作階段都切換模式，這個選項就很有用。讓一個要求以 Plan Mode 執行，接著就照常繼續工作。

第三種方法是在啟動工作階段時使用：

claude --permission-mode plan

如果你事先知道任務需要規劃，就使用這種方法。例如大型重構或遷移之前。

第四種方法是在專案的 .claude/settings.json 設定預設模式：

{
  "permissions": {
    "defaultMode": "plan"
  }
}

什麼時候適合使用？當團隊正在處理複雜系統，任何變更都可能影響相鄰模組時。此時預設使用 Plan Mode，可以避免大家意外修改內容。

還有一個常被忽略的第五個技巧：按 Ctrl+G 可以在文字編輯器中開啟計畫。如果計畫大致正確，但你需要改寫 2-3 個項目或加入一項限制，就可以使用。手動編輯並儲存後，Claude 會接著使用你的版本。

Anthropic 在 Plan Mode 中訂定的標準 4 階段是什麼：Explore、Plan、Implement、Commit？#

許多指南會介紹 3 個階段（Explore-Plan-Execute），或只介紹 2 個（Plan-Implement）。這些都是簡化版。Anthropic 在其官方最佳實務指南中明確說明了 4 個階段。這個差異很重要：把 Commit 獨立成一個階段，能讓你記錄成果，而不是停留在「我又做了幾個小調整，之後再 commit」——這是最常見的工作遺失原因。

計畫越精確，實作所需的反覆修改就越少。如果你花 10 分鐘規劃，實作只需要一個提示詞。如果你只花一分鐘草擬計畫，實作就會花一個小時修正。

以下是新增 Google OAuth 時 4 個階段的樣貌（範例來自 Anthropic 說明文件）：

每個階段的提示詞也不同。在 Explore 階段：「讀取 /src/auth，了解我們如何處理工作階段與登入」。在 Plan 階段：「我想加入 Google OAuth。哪些檔案需要修改？請建立計畫」。在 Implement 階段：「依照你的計畫實作 OAuth 流程、撰寫測試、執行測試套件並修正失敗項目」。在 Commit 階段：「使用描述性的訊息建立 commit 並開啟 PR」。

有個重要細節：Plan Mode 不會阻止 Claude 執行研究用命令。Read、LS、Glob、Grep、web fetch 及用於探索的 shell 命令都可以使用。只有 Edit、Write 和所有會修改檔案系統的操作會遭到禁止。也就是說，Claude 可以讀取專案結構、執行 git log、查看測試，但不會意外修改任何內容。

如何閱讀 Claude 的計畫並決定是否核准？#

Claude 完成計畫後，會顯示接下來可執行的選項：

• 核准並以 auto 模式開始
• 核准並接受編輯
• 核准並手動審查每項編輯
• 提供意見並繼續規劃
• 使用 Ultraplan 精修（瀏覽器審查）

知道該不該核准計畫，是使用 Plan Mode 的關鍵技巧。很容易就會反射性地按下「Approve」，接著又得還原 commit。AI 討好者想要快速回答，你則想趕快開始寫程式。你們兩個都錯了。

好的計畫符合 7 項標準：

1. 具體檔名。 不要寫「我會更新 auth」，而要寫「我會修改 src/auth/login.ts:42-58、建立 src/auth/oauth-callback.ts，並更新 src/auth/session.ts:103。」
2. 列明執行順序。 計畫應拆成階段或步驟，而不是「我會在某處把這些全做完」。
3. 列出外部相依項目。 如果任務需要新函式庫，就要列出來。若需要環境變數，也要列出來。
4. 列出風險。 好的計畫會寫：「遷移可能會使現有工作階段失效；需要檢查 X。」糟糕的計畫則對副作用隻字不提。
5. 列出成功標準。 「test/auth 測試通過、linter 沒有問題，而且開發伺服器啟動時沒有錯誤。」
6. 不要做出憑空猜測。 如果 Claude 說「我會使用函式庫 Z」，請確認：你有在專案中安裝它嗎？如果這是 AI 編造的，就會看到 package.json 中沒有提到它。
7. 計畫長度要能在畫面上看完。 如果一個簡單功能的計畫有 200 行，任務可能對一份計畫來說太大了。請拆分成幾個部分。

如果計畫沒通過檢查，有三種選擇：

• 提供意見並繼續規劃——具體告訴 Claude 哪裡不理想，Claude 就會重寫計畫。
• Ctrl+G——在編輯器中開啟計畫，手動修改並儲存。Claude 會接著使用你的版本。
• 使用 Ultraplan 精修——計畫會送到 Claude Code 網頁版的瀏覽器模式，你可以審查各個部分並留言，之後在本機或雲端執行。

如果實作到一半出了問題，不要硬撐。回到 Plan Mode 重寫計畫。這比之後還原 40 個 commit 便宜 10 倍。

Plan Mode + plans/ 資料夾：適用於長上下文的組合#

Plan Mode 是 Claude Code 的一種模式。plans/ 資料夾則是在其上建立的方法論。如果使用 Plan Mode 卻沒有資料夾，工作一個小時後就會碰到上限。

原理如下。Claude 的上下文視窗就是該工作階段的記憶。Opus 4.7 可以容納 1 million tokens，但那是整段對話的總容量。如果你在同一段對話中規劃複雜任務、接著要求實作、再討論錯誤、然後又談別的事情，上下文視窗就會「膨脹」。Claude 會開始忘記早期決策、混淆上下文，並重複提問。

解決方法是黃金法則：一個任務，一段對話。

做法如下：

1. 對話 1——擬定計畫。 啟用 Plan Mode，描述任務，Claude 就會建立計畫。將計畫儲存在 plans/2026-05-21-feature-name.md。關閉視窗。
2. 對話 2——拆分階段。 開啟新的聊天。要求：「讀取 plans/2026-05-21-feature-name.md 並拆分成多個階段。」儲存更新後的檔案。
3. 對話 3——實作階段 1。 開啟新的聊天。要求：「實作 plans/2026-05-21-feature-name.md 中的 Phase 1，並在完成項目時將其勾選。」關閉視窗。
4. 對話 4——實作階段 2。 照著做。

這樣做有什麼好處？每段對話的上下文視窗都保持清爽。負責階段 3 的 Claude 不知道階段 1 的細節，但它能讀取儲存庫中的 plans/ 檔案，了解計畫。任何下一位代理（無論是子代理、新工作階段，或透過 /goal 執行的工作階段）都能接手並繼續。

做法比較：

每項功能都有自己的計畫檔案。三個月後，如果你需要想起為什麼選了某家付款供應商、而沒有選其他方案，只要開啟相關計畫，就能查看決策歷史：討論了什麼、考慮過哪些選項，以及為什麼選擇這條路。

這些是持續更新的工作計畫；靜態文件幾個月內就會過時。

如何結合 Plan Mode 與 /goal，讓 Claude 在你睡覺時繼續工作？#

長時間 AI 工作階段的主要限制不是模型本身，而是那個按下 Enter 的人。每次 Claude 完成一個回合，就會等你回應。/goal 可以消除這段等待。

語法很簡單：

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

條件最多可有 4000 個字元。每個工作階段只能設定一個目標。每回合結束後，Haiku mini 模型會查看逐字稿並做出判斷：「條件已滿足——結束」或「尚未滿足——繼續下一回合」。評估器不會呼叫工具，只會讀取內容。

清除目標的別名有：/goal stop、/goal off、/goal reset、/goal none、/goal cancel。

Plan Mode 的搭配方式如下：

1. 啟用 Plan Mode（按兩次 Shift+Tab）。
2. 要求：「建立從 MySQL 遷移到 Postgres 的計畫，並儲存為 plans/2026-05-21-postgres-migration.md，附上各階段與標準。」
3. 檢查計畫、編輯並核准。
4. 離開 Plan Mode（再按一次 Shift+Tab）。
5. 設定目標：「完成 plans/2026-05-21-postgres-migration.md 中的所有階段，勾選各項目，所有測試通過，或在 50 個回合後停止。」
6. 關上筆電去睡覺。

早上檢查結果：你會看到「✓ 目標已完成」或「◎ 在 50 個回合後停止」，並附上已執行工作的歷史紀錄。

使用 /goal 有三項重要規則，否則會浪費 tokens：

規則 1：設定可衡量的最終狀態。「讓它看起來漂亮」是不好的條件。「npm test 傳回 0、npm run lint 傳回 0，而且已在 CHANGELOG.md 加入一筆紀錄」才是好的條件。

規則 2：明確要求驗證。 條件應該指向可驗證的項目：命令、檔案或端點。不要寫「一切正常」，而要寫「curl localhost:3000/api/users returns 200」。

規則 3：限制回合數。 務必加上 or stop after N turns。Anthropic 在說明文件中特別建議：

如果你啟用 /goal 卻沒有設定 or stop after，預算可能一夜之間就會耗盡。

什麼樣的 4 步驟循環能把 Plan Mode 轉化為工程流程？#

常見的錯誤是問「我要怎麼修好它？」Claude 給出解法，你照著做，但結果完全無效，或是問題變得更糟。這就是「AI 討好者」：它受過訓練，會快速回答，而你則想更快開始寫程式。4 步驟循環可以解決這個問題。

這個 4 步驟循環會阻止這種模式，並在單一 Plan Mode 工作階段中依序使用：

步驟 1. 不提出解法，只確認事實。

提示詞：「我遇到以下狀況：[症狀描述]。你現在的任務是確認事實。禁止提出任何解法、想法或建議。只能說明：我觀察到什麼、哪些步驟可以重現、有哪些資料，以及缺少哪些資料。明確的停止條件：不得提出解法，只記錄診斷結果。」

這會阻止 AI 的第一個本能反應：「解法在這裡。」Claude 必須停在「已知與未知的資訊」上。

步驟 2. 參照先例，發展各種選項。

提示詞：「診斷完成後，請在線上尋找解決類似問題的先例。至少列出 3 種不同方法。每種方法都要提供主要來源的連結、簡短說明，以及對我們情境的優點和缺點。」

這會阻止 AI 的第二個本能反應：「隨便想一個解法。」我們要求它走出封閉環境，帶回可供查證的方法。

步驟 3. 制定包含風險的詳細計畫。

提示詞：「從步驟 2 選出最佳方案，並列出詳細計畫：要修改哪些具體檔案、新增什麼、移除什麼、要撰寫哪些測試、可能會出現什麼問題，以及接下來 2-3 個步驟有哪些風險。」

這就是我們熟悉的 Plan 階段，但有一項差異：計畫根據的是步驟 2 中已查證的方案，而不是 Claude 猜測的內容。

步驟 4. 自我檢查計畫。

提示詞：「現在必須進行自我檢查。請誠實地重新檢查計畫：有沒有任何地方是憑空猜測，且未透過程式碼、文件，或步驟 2 的先例查證？如果有，請標示並修訂計畫。」

這是最後一道篩選。Claude 必須檢查自己的推理，並承認自己在哪些地方產生幻覺。通常這個步驟會修訂至少 2 個計畫項目。

完成 4 個步驟後，計畫就可以核准了。你可以放心開始實作，因為任務已經釐清、各種選項都已衡量，風險也已考慮周全。

這套方法論適用於診斷棘手錯誤，以及做出高代價風險的架構決策。將它用在 Plan Mode，可以消除 vibe coding 開發者最頭痛的問題：「AI 給了我一個解法，我照著做，結果一切都壞了。」

Plan Mode 中有哪些 5 個常用任務的即用提示詞？#

範本 1. 重構模組。

我正在啟用 Plan Mode。任務：重構 {module-name} 模組。

步驟 1：研究 {module-path} 模組目前的結構。說明：
- 模組包含哪些檔案
- 有哪些外部相依項目
- 哪些部分重複
- 哪些函式過於複雜

步驟 2：在線上尋找 2-3 個重構類似模組的範例。
至少 1 個來源必須是 Anthropic 官方文件或相關框架文件。

步驟 3：在 plans/YYYY-MM-DD-refactor-{module}.md 建立重構計畫：
- 要重新命名哪些檔案
- 要將哪些函式抽取至獨立模組
- 哪些測試要保留，哪些要改寫
- 風險：使用者可能遇到什麼問題

步驟 4：自我檢查。計畫中是否有「憑空猜測」的假設？
請改寫或移除這些假設。

範本 2. 資料庫遷移。

我正在啟用 Plan Mode。任務：將資料庫從 {old} 遷移到 {new}。

步驟 1：使用 {schema-reading-command} 研究目前的資料庫結構描述。說明：
- 有哪些資料表及其大小
- 有哪些關聯、索引和限制
- 遷移檔案存放在哪裡
- 哪些資料至關重要

步驟 2：尋找正式環境專案中 {old → new} 遷移的先例。
至少 3 種不同方法：pg_dump、dual-write、blue-green。
逐一列出它們對我們資料量的優點及風險。

步驟 3：在 plans/YYYY-MM-DD-db-migration.md 建立遷移計畫：
- 階段（備份、遷移、驗證、切換）
- 各階段的成功標準
- 出問題時的復原計畫
- 停機或不中斷服務

步驟 4：自我檢查。所有數據都有文件佐證嗎？
是否已依照開發環境仔細檢查所有步驟？

範本 3. 新增功能。

我正在啟用 Plan Mode。任務：為專案新增 {description} 功能。

步驟 1：研究專案中目前類似功能的運作方式。
具體來說，請查看：
- {file-1}
- {file-2}
- 使用了哪些架構模式
- 類似功能有哪些測試

步驟 2：尋找開放原始碼專案中，採用類似架構實作此功能的方法
至少列出 2 種不同做法。

步驟 3：在 plans/YYYY-MM-DD-feature-{name}.md 建立計畫：
- 新檔案清單
- 列出變更檔案及具體行數
- 實作順序
- 要新增哪些測試
- 要新增哪些規則至 CLAUDE.md，供未來工作階段使用

步驟 4：自我檢查。計畫是否符合專案架構？
是否假設使用了尚未安裝的函式庫？

範本 4. 撰寫測試。

我正在啟用 Plan Mode。任務：為 {name} 模組撰寫測試。

步驟 1：研究 {path} 模組。找出：
- 公開函式及其簽章
- 不會測試的內部函式（實作細節）
- 邊界案例：空輸入、錯誤、並行存取

步驟 2：在使用相同框架的熱門開放原始碼專案中
尋找類似任務的測試範例。

步驟 3：在 plans/YYYY-MM-DD-tests-{module}.md 建立測試計畫：
- 為每個公開函式列出測試
- 需要哪些 mock
- 需要哪些 fixtures
- 採用哪種驗證方式（斷言風格）

步驟 4：自我檢查。所有測試檢查的是行為，而不是實作方式嗎？
測試是否涵蓋邊界案例？

範本 5. 偵錯複雜錯誤。

我正在啟用 Plan Mode。任務：了解錯誤 {symptom-description} 的原因。

步驟 1：確認事實。禁止提出解法或想法。只能說明：
- 我觀察到什麼（錯誤的確切文字）
- 可重現的步驟
- 目前有哪些資料（日誌、追蹤、函式庫版本）
- 缺少哪些資料（還需要額外收集什麼）

步驟 2：尋找此錯誤的先例。
至少列出 3 個來源：GitHub issues、技術問答網站、文件。
每個來源都提供連結及解決方法的簡短摘要。

步驟 3：在 plans/YYYY-MM-DD-bug-{name}.md 建立診斷計畫：
- 要檢查哪些假設（依可能性排序）
- 要執行哪些命令或腳本來檢查每個假設
- 每項檢查的預期結果

步驟 4：自我檢查。計畫中是否有「憑空猜測」的假設？
所有假設都能追溯到步驟 1 的事實嗎？

複製各範本，將 {parameters} 替換成你自己的內容，然後在 Claude Code 的 Plan Mode 中貼上。結果會是一份儲存在 plans/ 中、由你核准並用於實作的工作計畫。

Plan Mode 與一般模式相比該怎麼選？#

Anthropic 在說明文件中直接這樣寫：

只有實際差異小、已理解且低風險，才略過獨立計畫。需要探索做法或協調跨元件風險時先規劃；知道檔名或能一句話總結，不會消除遷移、驗證與資料完整性風險。

決策表：

選擇模式前，先問做法、副作用與驗證是否已理解。小型局部低風險變更，有明確檢查時可直接處理；有不確定、陌生程式、遷移、驗證或跨元件協調時先規劃，即使已知道全部 3–5 個檔案。

如何結合 Plan Mode + CLAUDE.md + 子代理，讓工作更可靠？#

CLAUDE.md 是 Claude 在每個工作階段開始時都會讀取的檔案，包括 Plan Mode。如果 CLAUDE.md 寫著「絕不硬編碼日期；一律從資料庫取得」，計畫就不會建議硬編碼。若沒有這類規則，計畫就可能提出任何建議。

組合起來的運作方式如下：

第 1 層：CLAUDE.md 設定規則。

檔案會說明專案技術堆疊、架構原則、禁止事項（「不要使用已棄用的 API」）及要求（「所有電子郵件都要使用共用版型」）。詳細指南：如何設定 CLAUDE.md。

第 2 層：Plan Mode 將規則套用至任務。

啟用 Plan Mode 並要求「新增 OAuth」時，Claude 會讀取 CLAUDE.md，看到規則（「將權杖存放在 Redis，而不是資料庫」），並立即納入計畫考量。這份計畫會符合專案架構。

第 3 層：子代理拆分工作。

如果計畫拆成多個階段，每個階段都能指派給一個子代理。每個子代理會在自己的上下文視窗中工作，不會讓主視窗變得雜亂。plans/ 中的計畫仍然是唯一的事實來源：子代理會讀取計畫、執行負責的階段，並更新核取方塊。

哪 7 個錯誤會讓 Plan Mode 失效？#

錯誤 1. 計畫只存在聊天中。

症狀：你寫好計畫、關閉視窗，隔天想繼續，但什麼都不在了；上下文已經消失。解法：一律將計畫儲存在儲存庫中的 plans/YYYY-MM-DD-feature-name.md。聊天是桌面，檔案才是檔案庫。

錯誤 2. 所有任務都在同一個聊天中。

症狀：你在一個工作階段中先討論驗證、再談遷移、接著討論 UI 設計，最後又處理錯誤。上下文視窗逐漸「膨脹」，Claude 會忘記先前內容。解法：一個任務，一段對話。完成計畫後，就關閉視窗。開始實作時，再開啟新的對話。

錯誤 3. 一份 3000 行的計畫，沒有階段。

症狀：計畫是有了，但沒有核取方塊或區分階段，無從判斷完成了哪些項目。也不可能委派工作。解法：將每份計畫拆成 3-7 個階段。每個階段都是一份列出具體行動的核取方塊清單。

錯誤 4. 計畫前沒有深入研究。

症狀：因為你沒有要求 Claude 尋找先例，它就隨便想出一個解法。一週後，你才發現開放原始碼社群早就有更好的方法。解法：執行 4 步驟循環的步驟 2——讓 Claude 在擬定計畫前先在線上找到 2-3 個先例。

錯誤 5. AI 討好者不經診斷就提出解法。

症狀：你問「如何修正錯誤 X？」Claude 給了你一個解法，你照著做，結果完全無效，或是問題變得更糟。解法：一律從「確認事實；禁止提出解法」開始。診斷完成後，再進入選項階段。

錯誤 6. 跳過自我檢查。

症狀：計畫看起來合理，卻含有 2-3 個「憑空猜測」的假設（虛構的函式庫、不存在的 API 或錯誤版本）。實作就會在這些地方出問題。解法：執行 4 步驟循環的步驟 4——要求 Claude 誠實地重新檢查計畫並指出假設。

錯誤 7. /goal 中的條件太模糊。

症狀：你設定 /goal make it look nice，讓它執行一晚，醒來時發現配額已耗掉 $200。解法：只使用可衡量的條件，加上驗證命令，並且一定要設定 or stop after N turns。不要寫「讓它變好」或「潤飾一下」。

vibe coding 開發者最常犯的第八個錯誤，就是忽略 plans/ 資料夾的概念。沒有 plans/ 資料夾的 Plan Mode 算不上方法論，只是玩具。如果你使用 Plan Mode 卻不建立檔案，就只發揮了 10% 的功能。

第一次使用 Plan Mode 後，接下來該做什麼？#

以下是三個具體步驟，難度依序增加：

步驟 1. 如果還沒有 CLAUDE.md，就先設定它。

如果沒有 CLAUDE.md，Plan Mode 就是在「真空中」運作——Claude 不知道專案規則，提出的計畫可能破壞架構。完整指南：如何設定 CLAUDE.md。最精簡的 CLAUDE.md 有 50-80 行，描述技術堆疊、規則及禁止事項。長度不是重點，具體程度才是。

步驟 2. 在儲存庫中建立 plans/ 資料夾。

在專案根目錄新增 plans/ 資料夾。商定檔名格式：YYYY-MM-DD-feature-name.md。每份計畫各自存成一個檔案。一個月後，你會有 20-30 個檔案；六個月後則會有 100 個以上。這是一份持續更新的專案決策歷史。

步驟 3. 在一項任務中試用 /goal。

選一項你平常會手動處理 30-40 分鐘的任務。啟用 Plan Mode、建立計畫，並儲存到 plans/。離開 Plan Mode。設定 /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns。闔上筆電一小時，去做別的事。回來後檢查結果。

這三個步驟是最低限度。這是逐漸建立起來的；不要試著在一個晚上完成全部內容。先從 CLAUDE.md 開始，一週後加入 plans/，一個月後再試著隔夜使用 /goal。

準備好之後，來認識 Ailoot。