# Claude Code 中的 Plan Mode：逐步指南與 2026 年的 4 個階段 > Claude Code 的 Plan Mode：了解它是什麼、如何用 Shift+Tab 啟用、Anthropic 的 4 個階段、可立即使用的提示詞範本，以及用於自主執行隔夜任務的 /goal 命令。 Source: https://ailoot.ai/blog/zh-hant-tw/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/zh-hant-tw/claude-code-plan-mode/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-ee5ab148c7f76bae7486998b71ca3f4a420976355bb2a7c9e08443fef0488791 更多說明請參閱 [Ailoot 說明文件](https://ailoot.ai/docs/)。 ## Plan Mode 是什麼？為什麼單靠它還不夠？
重點摘要 Claude Code 的 Plan Mode 是一種模式，AI 會讀取檔案、分析程式碼並提出變更計畫，但在你核准前不會寫入任何內容。按兩次 Shift+Tab，或使用 `--permission-mode plan` 旗標即可啟用。做法不確定、程式陌生，或有重要跨檔與維運風險時適用；明確低風險的錯字通常不需獨立規劃。
在一般模式中，Claude Code 會立即寫入程式碼；如果你沒有持續留意，就可能突然得到一份跨越許多檔案的差異。Plan Mode 反轉了工作步驟：先研究與規劃，再核准，最後才修改。 Anthropic 在官方說明文件中如此描述 Plan Mode：

Plan mode 會指示 Claude 研究並提出變更，但不實際執行。Claude 會讀取檔案、執行 shell 命令來探索，並撰寫計畫，但不會編輯你的程式碼。

— Anthropic 說明文件，https://code.claude.com/docs/en/permission-modes
聽起來很簡單，卻隱藏了最重要的轉變。Plan Mode 改變了工作節奏：先取得共識，再採取行動。這是模式上的改變，不是表面上的微調。vibe coding 開發者的痛點在於，AI 代理往往急著動手。如果你在一般模式中要求「加入 Google 驗證」，Claude 會在一分鐘內寫好程式碼，但其中一半檔案都會選錯。在 Plan Mode 中，同樣的要求會先變成一份文字計畫，你可以花兩分鐘閱讀並修正，而且此時還沒碰到任何程式碼。 有個國際指南沒人提過的陷阱。Plan Mode 本身是個脆弱的工具：計畫只存在目前的對話中。關掉視窗，計畫就不見了。你無法把它交給另一個代理。沒有版本或歷史紀錄。如果任務很大（重構一個 30 個檔案的模組、遷移到新的資料庫），計畫很快就會碰到上下文視窗的上限，開始逐漸失準。 這就是 Plan Mode 適合搭配儲存庫中的 `plans/` 資料夾的原因。計畫會儲存為 `plans/2026-05-21-google-oauth.md`，拆分成多個階段並附上核取方塊，之後任何代理都能接手。這就是[上下文工程](https://ailoot.ai/blog/zh-hant-tw/context-engineering/)的做法：在提示詞之前管理上下文，而不是在提示詞過程中管理。 ## 如何在 Claude Code 中啟用 Plan Mode？
重點摘要 官方提供四種啟用 Plan Mode 的方法。在工作階段中，按兩次 Shift+Tab，或在提示詞前加上 `/plan` 前綴。啟動時使用 `claude --permission-mode plan` 旗標。若要全域設定，請在 `.claude/settings.json` 中設定 `defaultMode` 欄位。終端機底部的 `⏸ plan mode on` 是目前模式的指示器。
在工作階段中最快的方法是使用鍵盤： ``` 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 執行，接著就照常繼續工作。 第三種方法是在啟動工作階段時使用： ```bash claude --permission-mode plan ``` 如果你事先知道任務需要規劃，就使用這種方法。例如大型重構或遷移之前。 第四種方法是在專案的 `.claude/settings.json` 設定預設模式： ```json { "permissions": { "defaultMode": "plan" } } ``` 什麼時候適合使用？當團隊正在處理複雜系統，任何變更都可能影響相鄰模組時。此時預設使用 Plan Mode，可以避免大家意外修改內容。 還有一個常被忽略的第五個技巧：按 `Ctrl+G` 可以在文字編輯器中開啟計畫。如果計畫大致正確，但你需要改寫 2-3 個項目或加入一項限制，就可以使用。手動編輯並儲存後，Claude 會接著使用你的版本。 ## Anthropic 在 Plan Mode 中訂定的標準 4 階段是什麼：Explore、Plan、Implement、Commit？
重點摘要 Anthropic 在最佳實務指南中列出四階段的標準工作流程：Explore（讀取檔案並探索上下文）、Plan（建立變更計畫，但不編輯）、Implement（切換到一般模式並依照計畫實作）、Commit（建立附有描述的 commit 並開啟 PR）。每個階段都有各自的工具限制。
許多指南會介紹 3 個階段（Explore-Plan-Execute），或只介紹 2 個（Plan-Implement）。這些都是簡化版。Anthropic 在其[官方最佳實務指南](https://www.anthropic.com/engineering/claude-code-best-practices)中明確說明了 4 個階段。這個差異很重要：把 Commit 獨立成一個階段，能讓你記錄成果，而不是停留在「我又做了幾個小調整，之後再 commit」——這是最常見的工作遺失原因。 計畫越精確，實作所需的反覆修改就越少。如果你花 10 分鐘規劃，實作只需要一個提示詞。如果你只花一分鐘草擬計畫，實作就會花一個小時修正。 以下是新增 Google OAuth 時 4 個階段的樣貌（範例來自 Anthropic 說明文件）： | 階段 | Claude 的工作 | 你的工作 | 模式 | |----|----|----|----| | **Explore** | 讀取 `/src/auth`，尋找工作階段和環境變數的處理方式 | 設定探索範圍 | Plan Mode | | **Plan** | 建立計畫：要修改哪些檔案、要建立哪些新檔案，以及有哪些風險 | 閱讀計畫、按 Ctrl+G 編輯，並核准 | Plan Mode | | **Implement** | 依照計畫實作，撰寫 OAuth 流程程式碼、測試及回呼 | 監看每項變更的套用情況 | Default 或 acceptEdits | | **Commit** | 建立附有描述的 commit，並開啟 Pull Request | 檢查訊息並審查 PR | Default | 每個階段的提示詞也不同。在 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 計畫會列出具體檔案及預定變更、依序排列的步驟、明確的風險，以及成功標準。糟糕的計畫會使用「我會更新驗證模組」這類籠統說法，沒有具體細節。用以下 7 項指標決定是否核准。你可以透過意見回饋來修訂計畫，或直接按 Ctrl+G 編輯。
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 單獨使用時，只適用於目前的對話。關掉視窗，計畫就會消失。儲存庫中的 `plans/YYYY-MM-DD-feature.md` 資料夾可以把計畫變成持久成果：包含階段、核取方塊與狀態的檔案，任何下一位代理都能接手。這是從「記在記憶中的計畫」轉變為「寫進程式碼中的計畫」。
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 | Plan Mode + `plans/` 資料夾 | |----|----|----| | 持久性 | 只在目前的聊天中 | 永久保存在儲存庫中 | | 交接給另一個代理 | 不可能 | `cat plans/file.md` | | 版本與歷史紀錄 | 無 | 透過 git diff 查看 | | 子代理支援 | 只限目前工作階段 | 每個階段 → 一個子代理 | | 核取方塊與狀態 | 只有文字 | Markdown 核取方塊 `[ ]` / `[x]` | | 計畫長度 | 受視窗限制 | 不限長度 | 每項功能都有自己的計畫檔案。三個月後，如果你需要想起為什麼選了某家付款供應商、而沒有選其他方案，只要開啟相關計畫，就能查看決策歷史：討論了什麼、考慮過哪些選項，以及為什麼選擇這條路。 這些是持續更新的工作計畫；靜態文件幾個月內就會過時。 ## 如何結合 Plan Mode 與 /goal，讓 Claude 在你睡覺時繼續工作？
重點摘要 `/goal` 就是 Anthropic 一年來一直在談的自主循環。`/goal` 命令出現在 Claude Code v2.1.139（2026 年 5 月 11 日）。它會設定完成條件，Claude 則不需要人類介入，持續工作直到滿足條件為止。每回合結束後，小型評估模型都會檢查是否已滿足條件。
長時間 AI 工作階段的主要限制不是模型本身，而是那個按下 Enter 的人。每次 Claude 完成一個回合，就會等你回應。`/goal` 可以消除這段等待。 語法很簡單： ```bash /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 在說明文件中特別建議：

若要限制目標的執行時間，請在條件中加入回合數或時間限制，例如 'or stop after 20 turns'。

— Anthropic 說明文件，https://code.claude.com/docs/en/goal
如果你啟用 `/goal` 卻沒有設定 `or stop after`，預算可能一夜之間就會耗盡。 ## 什麼樣的 4 步驟循環能把 Plan Mode 轉化為工程流程？
重點摘要 沒有結構的簡單 Plan Mode 只能產生普通成果。強大的工作流程會在一個視窗中依序執行 4 個步驟：不提出解法，只確認事實；參照網路上的先例，發展各種選項；建立詳細計畫，並提前 2-3 個步驟考慮風險；要求對計畫進行自我檢查，找出「憑空猜測」的假設。這個順序能阻止 AI 討好者模式。
常見的錯誤是問「我要怎麼修好它？」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 個常用任務的即用提示詞？
重點摘要 即用提示詞能讓每項任務節省 10-15 分鐘，並提升計畫品質。這裡有五種通用範本，分別用於重構模組、遷移資料庫、新增功能、撰寫測試，以及偵錯複雜錯誤。每個範本都結合 4 步驟循環，並搭配 `plans/` 資料夾。
**範本 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 與一般模式相比該怎麼選？
重點摘要 做法不確定、程式陌生、架構決策、遷移或有重大副作用時，使用 Plan Mode。檔案數提醒你考慮相依性，不是硬規則。小而已理解、低風險差異可直接處理；能用一句話描述，不代表驗證功能或遷移安全。
Anthropic 在說明文件中直接這樣寫：

Plan mode 很有用，但會增加額外負擔。若任務範圍明確、變更很小（例如錯字、一行日誌、重新命名變數），就直接要求 Claude 執行。當你不確定採用哪種方法、變更涉及多個檔案，或你不熟悉程式碼時，規劃最有幫助。如果你能用一個片語描述差異，就略過計畫。

— Anthropic 說明文件，https://www.anthropic.com/engineering/claude-code-best-practices
只有實際差異小、已理解且低風險，才略過獨立計畫。需要探索做法或協調跨元件風險時先規劃；知道檔名或能一句話總結，不會消除遷移、驗證與資料完整性風險。 決策表： | 任務 | 模式 | 原因 | |----|----|----| | README 中的錯字 | Default | 一個檔案、一項變更，差異明確 | | 在一個檔案中重新命名變數 | Default | 範圍明確且能檢查引用；仍評估副作用 | | 新增一行日誌 | Default | 僅修改一行，不影響邏輯 | | 在頁面上新增按鈕 | Default | 如果只有一個按鈕，而且知道要放在哪裡，就不需要規劃 | | 重構模組 | Plan Mode | 5 個以上檔案，且有副作用風險 | | 資料庫遷移 | Plan Mode + `/goal` | 多步驟流程，需要復原計畫 | | 新增驗證功能 | Plan Mode | 影響 10 個以上檔案；安全性至關重要 | | 為模組撰寫測試 | Plan Mode | 需要判斷要測試哪些內容 | | 偵錯原因不明的錯誤 | Plan Mode + 4 步驟循環 | 沒有診斷，解法就不會切中要點 | | 完整遷移框架 | Plan Mode + `plans/` + `/goal` 隔夜執行 | 長期任務，需要分階段並自主循環 | 選擇模式前，先問做法、副作用與驗證是否已理解。小型局部低風險變更，有明確檢查時可直接處理；有不確定、陌生程式、遷移、驗證或跨元件協調時先規劃，即使已知道全部 3–5 個檔案。 ## 如何結合 Plan Mode + CLAUDE.md + 子代理，讓工作更可靠？
重點摘要 搭配設定完善的 [CLAUDE.md](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/) 和[子代理](https://ailoot.ai/blog/zh-hant-tw/claude-code-subagents/)，Plan Mode 會強大 10 倍。CLAUDE.md 設定 Claude 用來建立計畫的規則。子代理讓你可以把計畫的各階段分配給多個平行代理。沒有這個組合，Plan Mode 就只是一次性的工具。
CLAUDE.md 是 Claude 在每個工作階段開始時都會讀取的檔案，包括 Plan Mode。如果 CLAUDE.md 寫著「絕不硬編碼日期；一律從資料庫取得」，計畫就不會建議硬編碼。若沒有這類規則，計畫就可能提出任何建議。 組合起來的運作方式如下： **第 1 層：CLAUDE.md 設定規則。** 檔案會說明專案技術堆疊、架構原則、禁止事項（「不要使用已棄用的 API」）及要求（「所有電子郵件都要使用共用版型」）。詳細指南：[如何設定 CLAUDE.md](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)。 **第 2 層：Plan Mode 將規則套用至任務。** 啟用 Plan Mode 並要求「新增 OAuth」時，Claude 會讀取 CLAUDE.md，看到規則（「將權杖存放在 Redis，而不是資料庫」），並立即納入計畫考量。這份計畫會符合專案架構。 **第 3 層：子代理拆分工作。** 如果計畫拆成多個階段，每個階段都能指派給一個[子代理](https://ailoot.ai/blog/zh-hant-tw/claude-code-subagents/)。每個子代理會在自己的上下文視窗中工作，不會讓主視窗變得雜亂。`plans/` 中的計畫仍然是唯一的事實來源：子代理會讀取計畫、執行負責的階段，並更新核取方塊。 ## 哪 7 個錯誤會讓 Plan Mode 失效？
重點摘要 Plan Mode 經常因為常見的使用錯誤而失效，不是因為工具本身不夠強大。七個主要錯誤是：只把計畫留在記憶中、不儲存成檔案；把所有任務放在同一個聊天中；計畫沒有階段；省略深入研究；讓 AI 討好者不經診斷就提出解法；跳過自我檢查；在 `/goal` 中使用模糊條件。
**錯誤 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 後，接下來該做什麼？
重點摘要 第一次使用 Plan Mode 只是起點。接下來可以設定 [CLAUDE.md](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)（如果你還沒有設定；沒有它，計畫就會懸在半空中）、在儲存庫中建立 `plans/` 資料夾作為工作方法，並在睡前嘗試讓 `/goal` 執行一項自主任務。Plan Mode、CLAUDE.md 和 `plans/` 三者結合起來，就是一套可運作的系統。
以下是三個具體步驟，難度依序增加： **步驟 1. 如果還沒有 CLAUDE.md，就先設定它。** 如果沒有 CLAUDE.md，Plan Mode 就是在「真空中」運作——Claude 不知道專案規則，提出的計畫可能破壞架構。完整指南：[如何設定 CLAUDE.md](https://ailoot.ai/blog/zh-hant-tw/claude-md-template/)。最精簡的 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`。
### 資料來源 - [Anthropic 說明文件 - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic 說明文件 - Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering - Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic 說明文件 - /goal 命令](https://code.claude.com/docs/en/goal) - [Anthropic 說明文件 - Changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
準備好之後，來認識 [Ailoot](https://ailoot.ai/)。 ## 常見問題：Claude Code 中的 Plan Mode：逐步指南與 2026 年的 4 個階段 ### 知道會改哪些檔案，就能跳過規劃嗎？ 不能。知道檔名不能消除副作用與驗證的不確定性。即使檔案清單明確，遷移、驗證功能及跨元件協調變更仍應規劃。 ### 什麼時候不需要獨立 Plan Mode 階段？ 已理解、範圍小、低風險且檢查明確的差異，例如局部錯字，可直接處理。做法不明、程式陌生，或有維運與跨檔風險時，應先規劃。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。