Claude Code 的 Plan Mode 與 Task 管理：大型任務的拆解策略
這是 Claude Code 系列的進階篇。建議先閱讀： 📖 Claude Code 自訂 Slash Commands：打造你的專屬 AI 工作流
🎯 前言
在自訂 Slash Commands 那篇中，我分享了 /interview 指令——先釐清需求，再探索 codebase，最後產出執行計劃。
但 /interview 是我自己設計的流程。Claude Code 其實有兩個內建機制做類似的事：
- Plan Mode：讓 Claude 只規劃不執行，專注思考
- Task 系統：把工作拆成多個步驟，追蹤進度
這篇文章介紹這兩個機制怎麼用，以及它們和 /interview 的差異。
📂 Plan Mode：只想不做
什麼是 Plan Mode？
Plan Mode 是一種模式切換——進入後，Claude 會只分析和規劃，不執行任何修改。
正常模式：Claude 分析 → 直接動手改
Plan Mode：Claude 分析 → 產出計劃 → 等你確認 → 退出 Plan Mode → 才開始改怎麼進入和退出
進入：
- 按快捷鍵 Shift+Tab 切換到 Plan Mode
- 或在對話中說 "進入 plan mode"
退出：
- 再按 Shift+Tab 切回 Normal Mode
- 或在對話中說 "退出 plan mode，開始執行"進入 Plan Mode 後，輸入框會顯示 (plan) 標記，提醒你目前是規劃模式。
Plan Mode 中 Claude 會做什麼？
| 可以做 | 不可以做 |
|---|---|
| 讀取檔案 | 修改檔案 |
| 搜尋程式碼 | 執行 Bash 指令（破壞性的） |
| 分析架構 | 寫入新檔案 |
| 列出計劃步驟 | 建立 commit |
本質上就是「唯讀模式」加上「強制輸出計劃」。
適合使用 Plan Mode 的場景
場景 1：大型重構
你要重構一個涉及 20 個檔案的模組。先進 Plan Mode，讓 Claude 全面分析影響範圍，列出所有需要修改的檔案和順序，你確認後再開始。
你：（Plan Mode）我要把 auth 模組從 Session 改成 JWT
Claude：
📋 重構計劃
## 影響分析
- 核心檔案：src/lib/session.ts（需完全重寫）
- 中間層：src/middleware/auth.ts（修改驗證邏輯）
- 頁面：12 個使用 getSession() 的頁面
- API 路由：8 個需要更新認證的端點
- 測試：5 個測試檔案需要更新
## 執行順序
1. 新增 src/lib/jwt.ts（JWT 工具函數）
2. 修改 src/middleware/auth.ts（替換驗證邏輯）
3. 逐一更新 12 個頁面...
4. 更新 API 路由...
5. 更新測試...
6. 移除 src/lib/session.ts
## 風險
- 步驟 3 和 4 之間有一段時間 auth 是壞的
- 建議用 feature branch 隔離
確認這個計劃？退出 Plan Mode 後我會開始執行。場景 2：不確定該怎麼做
你有一個需求但不確定最佳做法。用 Plan Mode 讓 Claude 列出多個方案比較。
你：（Plan Mode）我想加一個全站搜尋功能，
這個 Astro blog 有什麼做法？
Claude：
📋 方案比較
## 方案 A：靜態搜尋（Pagefind）
- 建置時產生搜尋索引
- 零 server cost
- 限制：只搜尋建置時的內容
## 方案 B：Algolia
- 全託管搜尋服務
- 免費額度足夠小型 blog
- 限制：外部依賴
## 方案 C：自建 Fuse.js
- 純前端模糊搜尋
- 完全自控
- 限制：文章多時效能差
建議：方案 A（Pagefind），最適合靜態 blog。場景 3：Code Review
讓 Claude 審查但不修改：
你：（Plan Mode）review 一下 src/lib/auth.ts 的安全性Claude 會列出問題清單但不會自己去改。
📋 Task 系統：追蹤進度
什麼是 Task？
Task 是 Claude Code 內建的工作追蹤機制。你可以把一個大任務拆成多個 task，Claude 會逐一完成並標記進度。
📋 任務清單
[✅] 1. 建立 JWT 工具函數
[🔄] 2. 修改 auth 中間層
[ ] 3. 更新頁面
[ ] 4. 更新 API 路由
[ ] 5. 更新測試Task 的特性
| 特性 | 說明 |
|---|---|
| 範圍 | 當前 session，session 結束就消失 |
| 建立方式 | Claude 自動建立，或你指定 |
| 狀態 | pending → in_progress → completed |
| 可見性 | 你可以隨時查看進度 |
怎麼使用
你不需要手動操作 task——Claude 在處理複雜任務時會自動使用。但你可以主動要求：
你：幫我重構 auth 模組。先列出所有步驟，用 task 追蹤。
Claude：
建立了 5 個任務：
[🔄] 1. 建立 JWT 工具函數
[ ] 2. 修改 auth 中間層
[ ] 3. 更新頁面（12 個）
[ ] 4. 更新 API 路由（8 個）
[ ] 5. 更新測試
開始執行任務 1...每完成一個 task，Claude 會更新狀態：
[✅] 1. 建立 JWT 工具函數
[🔄] 2. 修改 auth 中間層 ← 正在做
[ ] 3. 更新頁面（12 個）
[ ] 4. 更新 API 路由（8 個）
[ ] 5. 更新測試Task 的好處
1. 不會忘記步驟
大型修改做到一半，Claude 可能因為 context 壓縮而忘記後面的步驟。Task 系統是外部的追蹤機制，不受 context 壓縮影響。
2. 你可以中途介入
看到某個 task 的結果不對，你可以暫停：
你：等一下，任務 2 的做法不對。auth 中間層要用這種方式...
Claude：了解，我修改任務 2 的做法，然後繼續。3. 清楚的完成度
長時間的工作 session，你可以隨時問「現在做到哪了？」，Claude 會回報 task 進度。
🔄 Plan Mode + Task：完整流程
兩個機制搭配使用效果最好：
第一階段：Plan Mode（規劃）
├── Claude 分析需求
├── 探索相關檔案
├── 產出執行計劃
└── 你確認計劃
第二階段：Normal Mode + Task（執行）
├── Claude 把計劃拆成 task
├── 逐一執行，標記進度
├── 你可以隨時查看、中途介入
└── 全部完成，回報結果實際操作：
你：（Shift+Tab 進入 Plan Mode）
你：我要把 blog 加上標籤系統
Claude：（Plan Mode — 只分析不執行）
📋 計劃
1. 修改 content.config.ts，在 schema 加上 tags 欄位
2. 建立 src/pages/tags/index.astro（標籤總覽頁）
3. 建立 src/pages/tags/[tag].astro（單一標籤頁）
4. 修改 BlogPost.astro layout，顯示標籤
5. 修改 blog/index.astro，加上標籤篩選
6. 在現有文章加上 tags
確認？
你：確認
你：（Shift+Tab 退出 Plan Mode）
Claude：建立 6 個任務，開始執行。
[🔄] 1. 修改 content.config.ts
[ ] 2. 建立標籤總覽頁
...📊 Plan Mode vs /interview vs 直接下指令
三種方式的比較：
| 面向 | 直接下指令 | Plan Mode | /interview |
|---|---|---|---|
| 啟動方式 | 直接說 | Shift+Tab | 打 /interview |
| 需求釐清 | 不會問你 | 不會問你 | 會主動問你問題 |
| Codebase 探索 | 視情況 | 會做 | 一定會做 |
| 產出計劃 | 不一定 | 一定會 | 一定會 |
| 等你確認 | 不一定 | 一定等 | 一定等 |
| 適合 | 明確的小任務 | 複雜但需求明確 | 需求模糊的任務 |
選擇建議：
需求很明確 + 小修改 → 直接下指令
需求很明確 + 大修改 → Plan Mode
需求不明確 → /interview/interview 的優勢在於主動追問。如果你說「加一個匯出功能」，Plan Mode 會直接開始規劃，但 /interview 會先問「匯出什麼格式？匯出哪些資料？誰在用？」。
兩者可以結合：先用 /interview 釐清需求，再用 Plan Mode 做更細的技術規劃。
💡 使用建議
什麼時候該用 Plan Mode
| 情境 | 建議 |
|---|---|
| 修改超過 5 個檔案 | 用 Plan Mode 先看全貌 |
| 不確定影響範圍 | 用 Plan Mode 讓 Claude 分析 |
| 需要和別人討論方案 | 用 Plan Mode 產出計劃，拿去討論 |
| 簡單的 bug fix | 不需要，直接做 |
| 修改一兩行程式碼 | 不需要，直接做 |
什麼時候該用 Task
| 情境 | 建議 |
|---|---|
| 工作需要超過 10 分鐘 | 用 Task 追蹤進度 |
| 步驟超過 3 個 | 用 Task 避免遺漏 |
| 你可能中途離開 | 用 Task 回來後能接上 |
| 快速修改 | 不需要 Task |
Plan Mode 不是萬靈丹
Plan Mode 最大的風險是過度規劃。
❌ 花 10 分鐘規劃一個 2 分鐘能做完的修改
❌ 規劃到每一行程式碼的層級
❌ 所有任務都先進 Plan Mode
✅ 規劃到「修改哪些檔案、用什麼策略」的層級
✅ 只在修改範圍大或不確定時才用⚠️ 注意事項
1. Plan Mode 中的操作仍會消耗 context
Plan Mode 中 Claude 讀取的檔案、搜尋的結果都會佔用 context window。如果你在 Plan Mode 中讓 Claude 讀了 50 個檔案，context 可能已經很擠了。
建議：Plan Mode 中的探索要有目的性，不要「先全部看一遍」。
2. Task 在 session 結束後消失
Task 是 session 級別的追蹤機制。如果你關掉 Claude Code 再重開，之前的 task 就不見了。
如果任務需要跨 session：把計劃寫進 CLAUDE.md 或 Memory，而不是依賴 Task。
3. Plan Mode 的計劃不會自動轉成 Task
進入 Plan Mode 產出計劃後，退出 Plan Mode，Claude 不會自動把計劃的每個步驟建成 Task。你需要說：
你：按照剛才的計劃執行，用 task 追蹤進度4. 計劃可能和現實不符
Plan Mode 中 Claude 分析的是「當下的 codebase」。如果你在 Plan Mode 和實際執行之間修改了某些檔案，計劃可能會失效。
建議：確認計劃後盡快執行，不要隔太久。
🎉 結語
Plan Mode 和 Task 是 Claude Code 內建的「先想再做」機制。
| 機制 | 用途 |
|---|---|
| Plan Mode | 強制 Claude 先分析再動手 |
| Task | 把大任務拆成可追蹤的步驟 |
| 兩者搭配 | Plan Mode 產出計劃 → Task 追蹤執行進度 |
和之前介紹的 /interview 相比，Plan Mode 更「工具化」（按個快捷鍵就好），/interview 更「流程化」（會主動追問需求）。根據場景選擇適合的方式。
我的習慣是：需求模糊時用 /interview，需求明確但修改範圍大時用 Plan Mode。
📎 相關文章：