一位資深開發者分享了自己從 AI 程式碼懷疑論者，到完全擁抱 Claude Code Plan Mode 的心路歷程。他認為 Plan Mode 是 AI 輔助開發中最不可或缺的功能——透過「先規劃、再執行、最後測試」的工作流程，不僅讓 AI 的輸出品質大幅提升，更幫助開發者自己釐清需求。本文完整總結了他的 Plan Mode 使用策略與實戰經驗。

---

原影片連結：https://www.youtube.com/watch?v=WNx-s-RxVxk

影片重點

• Plan Mode 是 Claude Code 中最能提升 AI 程式碼品質的功能
• 工作流程循環：Plan → Execute → Test → Commit → 重複
• Plan Mode 會禁用檔案寫入，迫使 AI 先探索程式碼庫再制定計畫
• Claude Code 使用廉價的 Haiku 4.5 子代理進行探索，節省 token 成本
• 規劃不只幫助 AI 載入上下文，也幫助開發者釐清自己的需求
• 在 CLAUDE.md 中加入三行指令就能大幅改善計畫品質
• Plan Mode 特別適合不熟悉的程式碼庫和大型架構變更
• 即使你比 AI 快，也應該培養使用 Plan Mode 的習慣以應對未來變化

詳細內容

[00:00] 從懷疑論者到 Plan Mode 信徒

作者坦承自己曾是徹底的 AI 程式碼懷疑論者——認為 AI 不可能寫出像樣的程式碼、不可能比自己快、不可能理解自己的程式碼庫、更不可能複製多年累積的開發直覺。然而，當 Claude Code 推出 Plan Mode 後，一切改變了。

他現在的每一段程式碼都遵循固定流程：先用 Plan Mode 與 AI 一起規劃，然後讓 AI 執行計畫中的程式碼，接著透過單元測試、型別檢查或手動 QA 進行測試，最後提交程式碼，再開始下一輪規劃。他認為這個流程對於獲得優質的 AI 輸出是「完全不可或缺的」。

[01:15] Plan Mode 是什麼

使用 Claude Code 或任何 AI 程式碼助手時，AI 能做四件事：寫入檔案系統、讀取檔案系統和網頁文件、執行 Bash 腳本、以及使用 MCP 伺服器呼叫工具。

Plan Mode 的核心機制是禁用寫入功能。在 Plan Mode 下，AI 代理不被允許寫入檔案，系統提示詞會指示它先建立計畫再做任何變更。如果 AI 嘗試寫入，會遇到錯誤而被阻止。因為無法寫入檔案，AI 便會轉而探索程式碼庫、收集所有需要的資訊，並將這些整理成一份詳細的執行計畫。

進入 Plan Mode 很簡單，只要在 Claude Code 中按 Shift+Tab 切換即可。目前 Cursor 和 VS Code 也都支援了 Plan Mode。

[02:18] 為什麼規劃對 AI 代理至關重要

作者用了一個生動的比喻：想像你有一個同事，每次提交程式碼後就會忘記他對這個 repo 學到的一切。你會怎麼讓這個同事有生產力？答案是讓他在做任何修改之前先探索整個 repo——這正是 Plan Mode 的作用。

Plan Mode 會將相關資訊載入 LLM 的上下文，讓 LLM 觀察你的程式碼風格和模式。Claude Code 通常使用非常便宜且快速的 Haiku 4.5 模型作為子代理來執行探索任務，子代理可以大量發送請求讀取不同檔案，再將摘要回傳給更昂貴的主代理。

如果不做規劃，上下文就不會載入相關資訊，LLM 可能因為資訊不足而犯下低級錯誤，或使用你的程式碼庫中根本不存在的模式。

[03:35] 為什麼規劃對開發者也很重要

《Pragmatic Programmer》有句名言：「沒有人真正知道自己想要什麼」。當你開始規劃新功能或新想法時，你可能並不完全知道自己要什麼；規劃重構時，你可能不完全理解變更的影響範圍；調整 UI 時，腦中可能有三個不同的方案在競爭。

大多數開發者的解決方式是「橡皮鴨除錯法」——對著另一個人或橡皮鴨把想法說出來，直到在對話中找到最佳方案。Plan Mode 就是這個過程的 AI 版本。你與 AI 來回迭代，直到產出一份你有信心的計畫。

在這個過程中，AI 提出建議、你說「不太對」，到最後雙方都會對需要做什麼有更清晰的認知。執行階段反而變得很簡單，大部分可以讓 AI 自動駕駛。如果跳過這個步驟，你就像一個難搞的客戶——要求修復某樣東西，但 AI 不知道該怎麼滿足你。

[05:02] Plan Mode 實戰演示

作者展示了他的影片課程管理工具中的一個實際案例。他進入 Plan Mode，描述了一個資料庫 bug：系統從 repos 遷移到 repo versions，但部分程式碼尚未完成遷移，導致新增 repo 時出現異常。

他並沒有打字輸入，而是用語音聽寫工具（如 Wispr Flow 或 SuperWhisper）口述問題描述。AI 隨後啟動了探索子代理，消耗了約 40,000 個 token（使用的是便宜的 Haiku 4.5 而非 Opus 4.5）來理解當前的資料庫 schema 和 repo 建立流程。

探索完成後，AI 識別出 api.repos.add.ts 在建立 sections 時缺少 version 資訊。AI 進一步自行搜索 repo 中的 create repo version 相關程式碼，確認 schema 定義，最終產出了完整的計畫文件，儲存在檔案系統中供日後查閱。

[06:30] 迭代式問答完善計畫

在制定計畫的過程中，AI 主動提出了一些問題，例如「新的 repo 是否應該預設以 v1.0 作為初始版本名稱？」作者回答「是」。這個問題是他在最初的兩行提示中沒有提到的——AI 發現缺少這個資訊，便主動詢問。

作者用這個例子說明：開發者往往像「糟糕的客戶」一樣，不會預先提供所有資訊。Plan Mode 的迭代問答機制正好彌補了這個缺陷。

批准計畫後，他退出 Plan Mode 進入執行模式。執行過程中又發現了一個雙方都沒預料到的問題：sections 上還留有前一個版本的 repo ID。他認為應該只保留 repo version ID，於是再次啟動 Plan Mode，AI 進行了更多探索，發現這實際上是一個完全不同的任務，於是更新了計畫文件。

[07:50] Plan Mode 的延伸應用

這個「Plan → Execute」的循環可以從小型修改擴展到大型架構變更。作者提到一些很酷的做法：

• 把計畫放到 GitHub Issues 中讓其他人評論，類似 RFC（Request for Comment）提案
• 把計畫附在 GitHub PR 中，讓 code reviewer 理解當初的設計意圖

[08:20] 讓計畫更易讀的三行 CLAUDE.md 設定

作者分享了他在 CLAUDE.md 中加入的關鍵指令，能讓計畫從 2,000 字縮減到 400 字：

1. 「Make the plan extremely concise.」 — 讓計畫極度精簡
2. 「Sacrifice grammar for the sake of concision.」 — 為了簡潔可以犧牲文法
3. 「At the end of each plan, give me a list of unresolved questions to answer if any.」 — 在每份計畫最後列出未解決的問題

第三條指令會給 AI 一個額外的推力，讓它主動詢問不確定的事項，使 AI 進入一種「帶有警覺的探索模式」。作者強調 CLAUDE.md 的內容應該保持精簡，因為它會被注入到每個 session 中——指令越少，LLM 就有越多的「指令預算」去處理其他事情。

[09:50] 回應「我自己做更快」的質疑

作者預見到最常見的反對意見：「我自己直接改程式碼更快，何必走一遍 Plan Mode？」他坦承，在某些情況下這完全正確——當你對程式碼庫瞭若指掌、清楚知道要改什麼時，你比 LLM 有巨大優勢，因為你已經擁有所有上下文，不需要花 token 來理解程式碼庫。

但他提出了幾個反駁觀點：

• 適用範圍有限：在大型組織中，你深入理解的 repo 數量是有限的。Plan Mode 能讓你有效地貢獻到不熟悉的 repo，因為你和 LLM 帶著相同的上下文量進入
• 語言壁壘：Plan Mode 幫助你在不太熟悉的程式語言中工作
• 簡單才會比 AI 快：你能比 AI 快的場景，通常是比較簡單的變更。大型架構調整仍然需要「橡皮鴨」過程
• 善用 AI 而非同事：你可以跟同事 rubber duck，但那會占用同事的時間。用 AI 來 rubber duck，然後把計畫文件發給同事審閱，效率更高

[11:15] 為什麼現在就該開始使用

作者做了一個重要的預測：AI 工具是否會變得更聰明，這是個開放問題（他認為會變聰明一些，但不會大幅提升）。但可以確定的是，AI 工具會變得更快。如果你對 AI 的唯一優勢只是速度，那這個優勢會被不斷侵蝕。

因此他選擇每次都使用 Plan Mode，目的是培養對這些工具的熟悉度、理解它們的運作方式和固有弱點。這些弱點是「烤進蛋糕裡的」，不會隨著時間推移而消失。對 AI 工具有越多直覺，未來的職業發展就越有保障。

我的想法

這部影片最有價值的觀點不是「Plan Mode 很好用」這種表面結論，而是背後的思維模型：Plan Mode 本質上是把軟體工程幾十年來的最佳實踐——需求分析、設計審查、迭代溝通——自然地融入了 AI 輔助開發流程中。

特別值得注意的是他對 CLAUDE.md 設定的見解。許多人傾向在 CLAUDE.md 中塞入大量詳細指令，但作者反其道而行，只用三行精簡指令。這背後的邏輯是 LLM 有「指令預算」的概念——系統提示詞越冗長，模型在處理實際任務時的靈活性就越低。這個觀點對於所有使用 AI 程式碼工具的人都很有參考價值。

另一個值得深思的點是他對「AI 會更快但不一定更聰明」的判斷。這意味著單純的「手速優勢」會越來越不值錢，而理解 AI 工具特性、知道何時該規劃何時該直接動手的「判斷力」才是真正的護城河。與其抗拒 AI 工具，不如現在就開始累積使用經驗，建立自己的直覺。