大多數開發者剛開始接觸 Claude Code 時，習慣直接丟一個任務，看它跑完後刷一下 diff。這對修補小 bug 確實管用，但一旦涉及到跨文件的重構或新功能開發，這種「邊跑邊想」的模式很快就會翻車。
原因很簡單：決策路徑越長，錯誤率越高。如果 AI 在每個決策點的準確率是 80%，那麼連續做 20 個決策後，最終正確的機率會跌到 1% 左右。這就是為什麼我們需要 Claude Code 的 Plan Mode（計畫模式）。它強制 AI 在動手前先進入「唯讀階段」，透過審閱計畫來切斷錯誤的連鎖反應。
什麼是 Plan Mode？
簡單來說，計畫模式把 Claude 關進了一個唯讀的籠子裡。它能讀取代碼、搜索 codebase、向你提問，但絕對禁止修改文件或執行 shell 指令。
你可以透過幾種方式開啟它：
- 在輸入框連按兩次
Shift+Tab。 - 輸入
/plan指令。 - 啟動時加上
--permission-mode plan標記。
Claude 生成的計畫會以 Markdown 格式存存在 ~/.claude/plans/ 下。我建議在 settings.json 中將 plansDirectory 設為項目的相對路徑（如 ./plans），這樣計畫文件就能進入版本控制，在 Pull Request 中供團隊成員審閱。
探索-計畫-執行：三段式重構工作流
要完成一次高質量的重構（比如將一個混亂的 FastAPI 項目拆分成模組化結構），標準的操作流程分為三個階段：
1. 深度探索（Gather Context）
在計畫模式下，先讓 Claude 去掃描代碼庫。不要只是給個模糊的指令，要明確要求它找出依賴風險。
例如：「我想把這個 FastAPI 博客 API 重構成清晰的模組結構。先讀 main.py、models.py 和 utils.py，理出函數歸屬，並標註循環依賴的風險。」
此時 Claude 會啟動子代理進行調研，並主動提出問題。這一步非常關鍵。比如它會問你：「要用扁平的 Router 還是完整的 Service 層？」這種決策如果讓 AI 自己猜，它通常會選訓練數據中最常見的方案，而不一定是對你最合適的方案。
2. 生成與人工審閱（The Contract）
答完問題後，Claude 會生成一份包含目標目錄結構、實施步驟和驗證指令的計畫書。
這時候，千萬不要直接點「執行」。按下 Ctrl + G 呼叫編輯器打開計畫文件。這就是我所說的「設計先行」。你可以在計畫中直接添加批註：
- 「注意：在拆分路由前，先提取 Auth 中間件。」
- 「把資料庫連接留在
db.py，別塞進models.py。」
修改並保存後，Claude 會讀取你的調整。這種反饋循環能消除絕大多數的執行偏差。
3. 嚴格執行（Execution）
執行階段是把計畫轉化為代碼。此時你需要警惕「執行偏移（Drift）」。
有時候計畫說要先提取 Auth 模組，但 Claude 執行時為了圖省事，可能順便把路由也改了。這會導致代碼進入半遷移狀態。一旦發現 AI 偏離了計畫步驟，立刻用 Shift + Tab 切回計畫模式，讓它修正剩餘步驟。
實踐中的進階策略
什麼時候該用計畫模式？
如果你只需修個錯字或改個變數名，計畫模式純粹是浪費時間。但有個經驗法則：如果修改涉及 3 個以上的文件，或者你沒法用一句話描述完整的變化，那就必須先寫計畫。
TDD：讓計畫更強大
一個差勁的計畫通常是「先改代碼，最後加測試」。這種做法沒有反饋環，AI 寫完 10 個文件後才發現基礎設施跑不通，那重來代價極大。
更好的做法是在計畫中實施測試驅動重構。要求計畫在提取每個模組後，立即跟隨一個「驗證測試」步驟。每一步測試通過，才是真正的重構進展。
應對大型重構的 Agent Teams
對於涉及到數十個文件的重組，單個對話窗口的 Context 會很快飽和。這時可以利用 Claude Code 的實驗功能 Agent Teams。
你可以讓一個「領隊」負責審閱計畫，然後把具體的「路由重構」、「模型遷移」、「測試編寫」分別指派給三個不同的子代理。每個代理都有獨立的上下文窗口，領隊則根據計畫依賴項控制他們的執行順序。這種分治法是處理複雜系統重構的終極手段。
結語
Plan Mode 的核心價值在於：它將 AI 從一個「敲鍵盤的黑盒」變成了一個「能溝通的架構師」。
開發者不應該把所有決策權交給概率模型。透過 Ctrl + G 的介入和「探索-計畫-執行」的紀律約束，我們可以確保 AI 的產出始終在預期軌道上。下次進行複雜重構時，試著先鎖住寫入權限，讓計畫多飛一會兒。
关于
关注我获取更多资讯
