蓋房子的師傅不會拿到一塊地就開始砌牆。他先畫圖。樑柱位置、管線走向、承重計算——圖紙確認了，才叫水泥車進場。

你讓 AI 改程式碼的時候呢？直接下指令，它立刻開始動檔案。改了三個、砍了兩個、建了一個——你還沒搞清楚它的邏輯，事情已經做完了。運氣好，結果是對的。運氣不好，你在 git diff 裡面撈殘骸。

Plan Mode 就是那張圖紙。Claude 進入唯讀狀態——可以讀檔案、搜程式碼、分析依賴，但不能改任何東西。它把整個計畫攤開給你看，你確認了，它才動手。

為什麼「先規劃」反而更快

這裡有個違反直覺的現象。

你可能覺得多一個規劃步驟會拖慢速度——原本直接做就好，現在還要先寫計畫、review 計畫、確認計畫，不是多繞了一圈？

實際操作完全相反。Anthropic 觀察到最有效率的 AI 輔助開發者遵循一個 80/20 比例——80% 的時間花在規劃（理解需求、對應依賴、辨識邊界條件），只有 20% 的時間在監督程式碼執行。（來源：Anthropic Claude Code Best Practices）

不是因為他們動作慢。是因為計畫做好了，執行階段幾乎不需要回頭修。

反過來，不做計畫直接衝的人，表面上動作很快——Claude 噼里啪啦改了二十個檔案——但有三個改壞了，兩個漏了邊界條件，一個引入了 circular dependency。修這些問題花的時間，比一開始規劃的時間長三倍。

蓋房子也是。砌牆很快，拆牆重砌很慢。

三種方式進入 Plan Mode

看你的使用情境選一個。

Shift+Tab 按兩次

在任何 prompt 輸入框裡，按兩次 Shift+Tab，底部狀態列會切換到 plan mode。再按兩次切回正常模式。

這是最常用的方式。你正在跟 Claude 來回工作，突然遇到一個需要先想清楚的任務——按兩下，進 plan mode，描述需求，看完計畫，再按兩下切回去讓它執行。

/plan 指令

在 prompt 裡輸入 /plan，Claude 只會在這一輪回覆使用 plan mode。下一輪自動回到正常模式。

適合「偶爾想看一下計畫」的場景。你不想切換整個 session 的狀態，只是這一題想讓它先規劃。

啟動時指定

1
claude --permission-mode plan

整個 session 預設都在 plan mode。Claude 全程唯讀，只分析不動手。

什麼時候用？你拿到一個不熟悉的 codebase，想讓 Claude 幫你摸清楚結構、畫出模組關係、標記技術債——但你完全不想讓它改任何東西。

計畫出來了，然後呢

Claude 產出計畫之後，你不是只能說「好」或「不好」。

按 Ctrl+G，計畫檔案會在你的預設文字編輯器裡打開。你可以：

  • 在步驟旁邊加行內備註——「這一步要注意 backward compatibility」
  • 刪掉你不同意的步驟——直接整段砍掉
  • 重新排列順序——你覺得應該先處理 migration 再改 API，把它拖上去
  • 補充遺漏的步驟——加一行「記得更新 README」

存檔關閉，Claude 會讀取你的所有修改，更新後的計畫就是它接下來的執行藍圖。

這是 Plan Mode 跟「叫 Claude 先想一下」的根本差別。不是 Claude 想完你看一眼就算了——你可以動手改計畫，而且它會照著改過的版本做。

停一下。

你可能會問：「我直接在 prompt 裡跟 Claude 說『先列出步驟再做』，效果不是一樣嗎？」

不一樣。差在權限。

用自然語言要求 Claude「先規劃」，它可能一邊規劃一邊就開始改檔案了——它覺得自己「已經想清楚了」。Plan Mode 是強制鎖定：Claude 在唯讀狀態下沒有修改檔案的權限，物理上做不到「邊想邊動手」。

就像你跟包商說「先畫圖再施工」，他可能畫到一半就開始敲牆了。但如果你把工具鎖在倉庫裡，他拿不到鐵鎚，就只能老老實實畫完。

什麼時候該用、什麼時候不用

不是每個任務都需要 Plan Mode。用在對的地方是省時間，用在錯的地方是浪費時間。

該用的場景

涉及三個以上檔案的改動。 一個檔案的改動，看完 diff 就知道對不對。三個以上的檔案，改動之間有依賴關係、有順序問題、有可能互相衝突——先看計畫再動手，可以預先抓到這些問題。

Schema 變更。 資料庫 schema 一改，連帶影響 model、repository、service、controller、migration、test。這種牽一髮動全身的改動，不看計畫就執行是在賭運氣。

安全敏感的程式碼。 Authentication、authorization、encryption——這些地方改錯一個地方可能就是資安事件。Plan Mode 讓你在任何程式碼被修改之前就能審查整個策略。

大型重構。 把一個 module 拆成三個、把 REST 換成 GraphQL、把 monolith 拆 microservice。這種量級的改動，沒有計畫等於沒有方向。

不熟悉的 codebase。 接手一個新專案，讓 Claude 在 plan mode 下跑一遍——它會讀目錄結構、主要檔案、import 關係，幫你畫出一張地圖。比你自己一個一個檔案點開來看快十倍。

不需要的場景

單一檔案的小改動。 改一個 typo、調一個 CSS 數值、加一行 log。直接做就好，規劃反而多此一舉。

純讀取的問題。 「這個 function 回傳什麼型別？」「package.json 裡 express 是哪個版本？」——Claude 本來就只需要讀，不需要特別鎖唯讀。

跟其他功能怎麼搭

Plan Mode 單獨用已經有價值，但跟其他功能組合起來效果更強。

Plan Mode + Extended Thinking。 Thinking 是 Claude 內部的推理深度，Plan Mode 是外部的權限控制。兩個同時開：Claude 用 thinking 做深度分析，用 plan mode 確保分析結果先給你看，不會直接變成程式碼。適合架構決策、技術方案比較這類需要深度思考的規劃任務。

Plan Mode + Sub-agents。 先在 plan mode 下產出完整計畫，確認後退出 plan mode，讓 Claude 把計畫拆分成多個子任務，分派給 sub-agents 平行執行。規劃是一個人想清楚，執行是一群人同時做。

Plan Mode + Git Worktrees。 用 plan mode 規劃一個實驗性的改動，確認計畫後在 worktree 裡執行——主分支完全不受影響。計畫不滿意？整個 worktree 砍掉重來，零成本。

一個完整的工作流範例

用一個實際場景走一遍。

假設你要在一個 Spring Boot 專案裡加上 OAuth2 登入功能。這涉及 security config、filter chain、user entity、repository、controller、前端 callback handling——至少六七個檔案。

1
2
3
4
5
6
7
8
9
10
11
1. Shift+Tab x2 → 進入 Plan Mode
2. 輸入：「加上 Google OAuth2 登入，要支援既有的 JWT token 機制」
3. Claude 開始分析——讀 SecurityConfig、現有的 filter chain、User entity 結構
4. 產出計畫：列出要修改的檔案、每個檔案改什麼、改動的順序、需要新增的依賴
5. Ctrl+G → 在編輯器裡打開計畫
6. 你看到它打算用 spring-security-oauth2-client，但你的專案已經有自訂的 token 處理邏輯
7. 在對應步驟旁邊加備註：「保留現有 JwtTokenProvider，OAuth2 登入成功後走同一套 token 簽發流程」
8. 存檔
9. Claude 讀取你的修改，調整計畫
10. 確認沒問題 → Shift+Tab x2 → 退出 Plan Mode
11. Claude 照著計畫開始執行

整個過程你全程掌握方向。不是 Claude 決定怎麼做，是你決定怎麼做，Claude 負責執行。

你帶走的那張圖

回到一開始的蓋房子。

圖紙的價值不是讓施工變慢。是讓你在第一根樑柱立起來之前，就能看到整棟房子的樣子——哪裡承重不夠、哪裡管線打架、哪裡動線不合理。

Plan Mode 就是這張圖紙。Claude 在唯讀狀態下畫出完整的施工計畫，你審查、標註、修改，確認了才讓它動工。

有個更深層的 insight：大部分人用 AI 寫程式的方式是「描述需求 → 等結果 → 看對不對」。這是把 AI 當成黑盒。Plan Mode 把這個流程改成「描述需求 → 看計畫 → 調整計畫 → 執行計畫」——你介入的不是結果，是過程。

能介入過程的人，控制的是方向。只能看結果的人，控制的是運氣。

試一次就知道差別。下次遇到一個涉及三個以上檔案的改動，按兩下 Shift+Tab，讓 Claude 先畫圖再動工。

不過有一個我還在摸索的問題——當計畫很長（超過 50 個步驟），Ctrl+G 打開的編輯器體驗其實不太好，scroll 來 scroll 去很容易迷路。如果你有更好的 review 大型計畫的方式，歡迎跟我說。