Plan Mode 與直接執行的比較

Plan Mode vs Direct Execution 的抉擇，是 CCA-F 考試 Domain 3（Claude Code 設定與工作流程）的核心。任務說明 3.4 要求考生判斷 Plan Mode vs Direct Execution 在架構上哪個才是正確選擇；社群通過考試的報告一再指出，這是整份考試中陷阱頻率最高的考點之一。問題從來不是「哪個模式比較好」——兩者都是 Claude Code 的一流工作流程。問題永遠是「哪個模式正確匹配了情境中任務的爆炸半徑、模糊程度與可逆性。」

這份學習筆記涵蓋 CCA-F 考生需要熟練的 Plan Mode vs Direct Execution 完整面向：每個模式的精確定義、足以說明強制使用 plan mode 的具體訊號、同樣具體的「direct execution 才是正確預設」訊號、Claude Code 產出的計畫格式、使用者核准語義、CLAUDE.md 設定預設行為的方式、混合模式、永遠開啟規劃功能的成本、用於隔離雜訊探索輸出的 Explore subagent 模式，以及那些懲罰「plan mode 永遠更安全」直覺的考試陷阱。最後有一個專節，將所有概念連回 Plan Mode vs Direct Execution 題目最集中的程式碼生成與開發者生產力情境。

Plan Mode 定義 — Claude 在採取任何行動前先產生執行計畫

Plan Mode 是一種 Claude Code 工作流程：Claude 首先產出一份結構化、可供審閱的執行計畫——包含它打算採取的行動編號列表、它打算觸及的檔案，以及它打算使用的工具順序——然後才發生任何檔案系統變更。計畫會呈現給使用者審閱。在使用者核准、修改或拒絕之前，計畫以外的任何步驟都不會被執行。

Plan Mode 明確為「行動錯誤的代價超過短暫等待審閱的代價」這類任務而設計。在 plan mode 中，Claude 的行為就像一位資深工程師在動手修改 production 程式碼前會先寫一頁的變更說明。這個模式不會讓 Claude 變得更聰明——底層模型是一樣的——但它改變了 Claude 對行動做出承諾的時間點。這個時間差，就是 plan mode 存在的全部意義。

Plan Mode 關乎承諾時機，而非能力強弱

CCA-F 干擾答案最喜歡利用的一個常見誤解，是把 Plan Mode 視為 Claude 更強大或更聰明的變體。事實並非如此。Plan Mode 使用相同的模型、相同的工具，以及 Claude 已擁有的相同 context。改變的是承諾時機：在 plan mode 中，Claude 必須在行動之前將完整意圖說清楚；在 direct execution 中，Claude 則是交織著推理與行動。Plan Mode 以少量延遲換取高爆炸半徑工作的高度可審閱性。

Direct Execution 定義 — Claude 無需明確的規劃步驟即直接行動

Direct Execution 是 Claude Code 的預設工作流程：Claude 推理任務後立即開始執行工具呼叫——讀取檔案、編輯程式碼、執行指令——將短暫的推理爆發與具體行動交織進行。沒有預先核准的計畫；只有一個持續運作的 agentic loop，其工作過程可以即時觀察。

Direct Execution 並非魯莽；它只是不受阻塞。模型仍然能夠在內部規劃、在 Edit 失敗後回滾，或在遇到模糊情況時向使用者升級。Direct Execution 移除的，是強制性的事前核准關卡。對於變更範圍小、可逆且界定明確的任務，這才是正確選擇——產出正式計畫並等待核准的開銷，超過了計畫本身所能帶來的價值。

Direct Execution 是預設值，自有其道理

Claude Code 預設 Direct Execution，因為最典型的開發任務——錯字、單行修正、清楚的測試更新——從即時行動中受益，若強加儀式性規劃反而是懲罰。若把每個任務都強制送進 plan mode，一個十秒的編輯會變成兩分鐘的核准儀式。CCA-F 考試獎勵能夠認識到 Plan Mode vs Direct Execution 是一道配對題、而非偏好題的考生。

Plan Mode 觸發條件 — 任務複雜度訊號、風險訊號、使用者明確要求

有四類訊號足以說明將任務導入 Plan Mode 的必要性。

任務複雜度訊號

複雜度訊號直接出現在請求中。「將單體應用程式重構為微服務」、「將所有 API 路由從 v1 遷移至 v2」、「重構身份驗證層以支援 SSO」、「將共用日誌工具提取為新套件並更新每個呼叫端」——每一項都暗示跨越許多檔案的變更、多個架構決策，以及多種有效方法。這些都是 plan mode 任務，因為方法本身就是值得審閱的決策，而不只是最終的 patch。

風險訊號

風險訊號凸顯爆炸半徑。觸及建置設定、資料庫遷移腳本、部署清單、付款處理程式碼或安全關鍵模組，意味著一個錯誤會帶來超乎尋常的後果。只要任務改變了系統的啟動、部署、身份驗證或計費方式，plan mode 就是必要的——不是因為 Claude 不可信，而是因為審閱步驟是低成本的保險。

模糊性訊號

當請求存在多種有效解讀時，模糊性訊號就會出現。「清理 user 模組」可能意味著刪除廢棄程式碼、重新格式化、拆分檔案，或三者兼具。當請求無法唯一決定預期的變更時，plan mode 迫使模糊性浮上檯面，讓使用者在任何程式碼移動之前先行解決。

使用者明確要求

使用者可以明確要求 Claude 在行動前先規劃。「在修改任何東西之前先把這個規劃好」、「先跟我講一下你的做法」、「你會動到哪些檔案？」這類措辭，都是對 plan mode 的直接調用。CCA-F 考試常常測試考生是否能認識到，明確的使用者要求會覆蓋 CLAUDE.md 中設定的任何預設模式。

何時強制使用 Plan Mode — 高爆炸半徑任務、陌生程式碼庫、多檔案重構

Plan Mode 應該被強制使用——而非設為可選——針對考試視為定論的三類典型任務。

高爆炸半徑任務

當一個不正確的行動無法快速回滾時，任務就具有高爆炸半徑。資料庫 schema 遷移、production 設定變更、全面的相依套件升級，以及觸及公開 API 合約的重構，都屬於這個類別。回滾一個壞計畫的代價是五分鐘；回滾一個執行到一半的壞重構的代價是一個下午。

陌生程式碼庫

當 Claude 在一個沒有廣泛探索過的程式碼庫中工作時，plan mode 是正確的第一步。計畫本身成為探索的產物：Claude 提出它認為相關的檔案，使用者糾正這份地圖，然後才開始執行。這將探索從一個沉默消耗 context 的活動，轉化為一份可審閱的文件。

多檔案重構

任何跨越檔案邊界的任務——尤其是受影響檔案數量模糊時——都屬於 plan mode 的範疇。考試使用的典型範例，是影響 45 個以上檔案的單體應用程式轉微服務重構。這類任務若用 direct execution，在任何程式碼移動之前，context 就會被探索輸出耗盡；plan mode 預先確定結構性決策，讓後續的執行階段保持聚焦。

Direct Execution 適用時機 — 界定明確、可逆、單一檔案任務

當情境明確預示小範圍時，Direct Execution 同樣是一流的答案。

界定明確的任務

界定明確意味著預期的變更無歧義地被指定。「在 auth.ts 第 42 行的 token.verify() 呼叫之前加入 null 檢查」就是界定明確的；沒有什麼需要規劃的。請求本身就是計畫。

可逆任務

當一個不正確的變更能夠輕易撤銷時，任務就是可逆的——一個有版本控制的單一檔案編輯、一個本地設定調整、一個測試更新。Direct Execution 適合可逆任務，因為對一個略為錯誤的解讀採取行動的代價，不過是一個便宜的 git checkout。

單一檔案任務

單一檔案任務幾乎不值得付出規劃開銷。「修復 validator.py 中的這個 bug」、「重新命名這個函式」、「加入這個 import」——規劃文件會比 patch 本身還長。強制使用 plan mode 只會增加延遲，卻沒有提升可審閱性。

樣本 Q5 模式 — 新增日期驗證條件式

CCA-F 考試指南的樣本 Q5 使用完全這樣的形狀作為干擾：情境描述在現有函式中新增一個單一的日期範圍驗證條件式，而其中一個答案選項建議切換到 plan mode。那個答案是錯的。這個任務是單一檔案、可逆、界定明確的變更——direct execution 的原型案例。預設「plan mode 永遠更安全」的考生會在這道題失分。

計畫格式 — 編號步驟、工具順序、檔案影響清單

Claude Code 的 plan mode 產出一種可預測的計畫形狀，考試期望考生能夠認識。

編號步驟

每份計畫都是一份有編號的離散步驟列表。編號讓計畫可以逐步審閱，並讓部分核准成為可能——使用者可以說「核准第 1 至 3 步，讓我再想想第 4 步。」自由格式的散文不是計畫；帶有項目符號的編號列表才是。

工具順序

每個步驟指定預期使用的工具：Read src/auth.ts、Grep -r "verifyToken"、Edit src/auth.ts、Bash npm test。事先宣告工具順序，讓使用者能在危險操作（Bash、對現有檔案 Write）執行前就發現它們。

檔案影響清單

每份計畫都包含計畫將建立、修改或刪除的檔案明確列表。檔案影響清單是審閱大型重構時最有價值的單一元素；它讓完整的爆炸半徑一目瞭然，並能捕捉意外的涵蓋範圍。

風險與假設說明

格式良好的計畫還會列舉 Claude 對環境做出的假設（「假設測試套件透過 npm test 執行」），以及它預見的風險（「這次遷移將需要短暫的停機時間」）。這些說明是使用者最仔細審閱的產物。

計畫驗證 — 執行前的使用者審閱與核准

計畫本身是惰性的，直到使用者做出回應。有三種可能的結果。

照原樣核准

使用者逐字核准計畫。Claude Code 退出 plan mode 並依序執行各步驟。核准不是沉默的同意——使用者明確確認。

帶修改核准

使用者核准計畫但要求具體變更。「核准，但跳過第 4 步，並在第 6 步加入回滾腳本。」Claude Code 根據修改內容修訂計畫，並在執行前提交修訂版本重新核准。

拒絕

使用者完全拒絕計畫，通常是因為選擇的方法是錯的。拒絕不會終止對話——它讓 Claude 帶著使用者的回饋重新規劃。反覆規劃是正常的；在複雜工作上，第一份計畫幾乎不是最終計畫。

在 CLAUDE.md 中強制使用 Plan Mode — 設定預設行為

在專案層級的 CLAUDE.md 中加入一條指令，可以將 Plan Mode 設定為專案的預設值。例如「在此存放庫中，對任何會變更檔案系統的操作，一律先產出計畫」這樣的指令，無論任務大小都強制進入 plan mode。這適合大多數變更都屬高風險的程式碼庫（基礎設施即程式碼、付款服務、受監管系統），但對大多數應用程式存放庫並不適合，因為它會在每個任務上強加儀式感。

目錄層級覆蓋

由於 CLAUDE.md 支援層級結構，專案範圍的 plan mode 預設值可以針對任務一貫屬低風險的目錄選擇性放寬（例如，變更僅為外觀的 /docs 目錄）。目錄層級的 CLAUDE.md 補充專案預設值。

Plan Mode 與非互動式 CI

Plan Mode 從根本上是互動式的——它需要使用者核准、修改或拒絕計畫。在使用 -p 旗標的非互動式 CI 流水線中，強制 plan mode 會破壞自動化，因為沒有使用者在場核准。必須以非互動方式執行 Claude Code 的流水線，應完全避免 plan mode，或以程式化方式提供核准。CCA-F 考試測試這個互動關係。

混合模式 — 針對特定檔案路徑自動規劃，其餘直接執行

成熟的 Claude Code 設定透過訊號路由，結合兩種模式。三種混合模式在考試情境中反覆出現。

基於路徑的路由

Plan mode 強制用於符合基礎設施路徑模式的路徑（infra/**、migrations/**、.github/workflows/**），而存放庫其餘部分預設為 Direct Execution。.claude/rules/ 路徑特定規則系統（任務 3.3）是執行這種路由的機制。

基於操作的路由

Plan mode 強制用於涉及 schema 變更、相依套件版本升級或公開 API 修改的任務，而單一檔案內的本地編輯預設為 Direct Execution。CLAUDE.md 指令編碼了需要規劃的操作類型。

探索—規劃—執行組合

對於最複雜的任務——函式庫遷移、框架升級、大型重構——最佳工作流程分為三個階段。首先，Explore subagent 執行探索並回傳摘要。其次，Claude Code 在 plan mode 中根據摘要產出計畫。第三，Claude Code 在 direct execution 模式中逐步實作已核准的計畫。這個三階段模式在涉及函式庫遷移的考試情境中被明確提及。

Explore Subagent — 隔離冗長的探索輸出

Explore subagent 是一種專用的調查模式，天然與 Plan Mode 搭配用於大型程式碼庫。

為何要隔離探索輸出

大型程式碼庫探索是 token 密集的工作。讀取三十個檔案以繪製模組的相依圖，可能消耗數萬個 token，其中大多數都是雜訊——主對話需要的是結論（「以下是必須更新的 45 個呼叫端」），而不是原始檔案內容。在 subagent 中執行探索，讓主協調者的 context 保持聚焦於決策。

Context Window 耗盡

沒有 Explore subagent，探索密集的任務往往在實際工作開始之前就耗盡 context window。Claude Code 因此失去對先前指令、CLAUDE.md 內容或使用者原始請求的存取。Explore subagent 是這個問題的典範緩解方案。

Explore 與 Plan Mode 的搭配

典範模式是：生成一個 Explore subagent 繪製受影響的範圍，接收其摘要，切換到 Plan Mode 根據摘要產出執行計畫，然後執行已核准的計畫。這是函式庫遷移與大型重構的建議形狀——CCA-F 考試在程式碼生成情境中直接測試這個模式。

Agentic Loop 中的 Plan Mode — 將規劃步驟用作迴圈第一次迭代

在 Agent SDK 中，Plan Mode 可以被編碼為 agentic loop 的第一次明確迭代。第一次迴圈產出計畫；使用者核准；後續迭代逐步執行計畫步驟，每次行動後以 tool_result 觀察結果回饋。

計畫優先的迴圈形狀

計畫優先的迴圈有可預測的訊息軌跡：使用者請求 → 計畫（assistant）→ 使用者核准 → tool_use（步驟 1）→ tool_result → tool_use（步驟 2）→ tool_result → ... → end_turn。stop_reason 值遵循標準 agentic loop 語義；plan mode 改變的是 Claude 在早期迭代中說什麼，而不是迴圈如何終止。

Plan Mode 與 Subagent 生成

當整體工作跨 subagent 分解時，每個 subagent 可以獨立決定是否規劃。協調者可以在 plan mode 中運作（產出整體執行計畫），而每個 subagent 則以 direct execution 模式執行其葉節點任務。這反映了真實的工程實務：資深工程師規劃，執行人員實作。

規劃的代價 — 永遠開啟 Plan Mode 時的延遲與 Token 開銷

Plan Mode 並非免費。兩種代價在架構判斷上至關重要。

延遲開銷

Plan mode 插入一個等待使用者審閱的同步暫停。對小任務而言，這個暫停主導了總掛鐘時間。一個十秒的編輯變成兩分鐘的儀式：計畫生成、使用者閱讀計畫、使用者核准、執行。對界定明確的工作而言，這個開銷是純粹的浪費。

Token 開銷

每份計畫本身都是一個生成的產物——編號步驟、檔案清單、風險說明——這會消耗輸出 token。計畫接著在 session 剩餘時間內佔用 context。在一個有許多計畫的長任務中，花在規劃後設工作上的 token，與花在實際程式碼上的 token 形成競爭。

何時代價值得付出

當替代代價（執行到一半的重構、錯誤的架構方向、不可逆的變更）實質上更大時，規劃代價就值得付出。任務的爆炸半徑是校準標準。對 production schema 遷移而言，規劃稅是微不足道的保險。對錯字修正而言，它是儀式劇場。

白話文解釋 Plan Mode vs Direct Execution

Plan Mode vs Direct Execution 一旦錨定在日常生活中熟悉的具體情境上，就會變得直觀。以下三個類比涵蓋了完整的決策空間。

類比一：辦桌總鋪師 — 備料單 vs 現場直接開炒

路邊快炒師傅做一道蛋炒飯，沒有備料單、沒有書面流程、沒有二廚確認：鍋熱、蛋下、飯入、上桌。這就是 Direct Execution。同一個師傅承包一場三百人的尾牙辦桌，情況就完全不同了。開席前兩天，他要寫出完整的菜單備料單：哪桌幾點上什麼菜、哪個攤位負責哪道料理、火候與時間怎麼安排。二廚、採購、現場人員全部確認簽核之後，才開始動工。這份開席前的確認會，就是 Plan Mode。

兩個師傅的廚藝一樣好。選擇哪種工作流程，由出錯的爆炸半徑決定。一盤炒壞的飯，損失的是一盤飯。一場辦桌時序錯亂，毀的是整個宴席。Claude Code 就是那個師傅——一套廚藝、兩種工作流程，視訂單規模而定。

這個類比同樣說明了 Explore subagent：辦桌師傅在寫備料單之前，會先派助手去清點冰庫——「現有幾斤花枝、幾隻烏骨雞、有沒有備足沙茶醬」。助手回來報告精簡摘要，師傅才根據摘要擬定菜單。助手清點冰庫的全程細節（每格每個容器）不進師傅的腦袋，只有摘要進來。這正是 Explore subagent 保留主對話 context 的方式。

類比二：申論題 vs 選擇題 — 先列提綱 vs 直接作答

大學學測考場上，有兩種策略。對於你一眼就認出答案的選擇題，直接圈選答案繼續作答。這就是 Direct Execution——題目界定明確、答案可以更改、代價很低。

換到你沒見過這種問法的長篇申論題，你不會提筆就寫四頁。你先列提綱：論點一、論點二、論點三、結論、反例。提綱站得住腳之後，才展開成段落。那份提綱就是 Plan Mode。沒有提綱就貿然下筆，風險是寫到第三頁才發現論點方向全錯，時間卻不夠重寫了。

考試獎勵能夠正確配對策略與題型的考生。CCA-F 考試獎勵能夠正確配對 Plan Mode vs Direct Execution 與情境中所描述任務的考生。

類比三：裝潢工地 — 工程施工單 vs 現場直接修繕

承包商在工地陪業主驗收，會碰到兩種工作。鬆掉的鉸鏈當場鎖緊——一把螺絲起子、三十秒、完成。這就是 Direct Execution。同一個承包商若被要求把廚房格局全部打掉重做，他不會立刻拿起大鎚。他先出一份工程施工單：這面牆拆除、這裡重配電路、瓦斯管線移位、地磚重鋪、新廚具安裝。業主逐行確認之後，各工班才進場動工。這就是 Plan Mode。

這個類比對多檔案重構的說明特別到位。廚房格局改造涉及水電、泥作、木工、磁磚——多個「檔案」，彼此之間有相依關係。沒有施工單就開拆，很可能鎚到一半才發現打穿了瓦斯管。CCA-F 樣本題中那個影響 45 個以上檔案的單體轉微服務重構，正是一場廚房格局大改造：相依關係太多，不適合即興發揮。

考試當天選用哪個類比

• 測試依任務規模選擇模式的情境 → 辦桌師傅（快炒 vs 辦桌）。
• 測試探索隔離（Explore subagent）的情境 → 助手清點冰庫。
• 測試跳過規劃在模糊工作上的代價的情境 → 申論題提綱。
• 測試多檔案爆炸半徑的情境 → 廚房格局改造施工單。

Plan Mode 與 Claude Code 功能面的關係

Plan Mode 不是孤立存在的——它與 CCA-F 考試在 Domain 3 中測試的其他 Claude Code 功能相互組合。

與 CLAUDE.md 的互動

專案 CLAUDE.md 可以為存放庫強制 plan mode。使用者 CLAUDE.md 可以全域強制 plan mode。目錄 CLAUDE.md 可以針對特定子樹覆蓋前兩者。這個層級結構與任務 3.1 測試的三層層級結構相同，只是應用於 plan mode 預設值。

與 Slash Command 的互動

在 .claude/commands/ 中定義的自訂 slash command，可以在其模板中明確調用 plan mode。例如，一個 /refactor 指令可以在其主體中硬編碼「在任何編輯前先產出計畫」，確保每次調用 /refactor 都觸發規劃，無論預設設定為何。

與 Subagent 的互動

Subagent 可以有與協調者不同的 plan mode 預設值。Explore subagent 通常在 direct execution 中運作（其「行動」是唯讀的工具呼叫），而重構 subagent 可能預設為 plan mode。context: fork skill 模式保留了這種分離。

與路徑特定規則的互動

.claude/rules/ YAML 檔案可以編碼基於路徑的 plan mode 強制規定：「符合 migrations/** 的檔案在任何寫入前都需要一份計畫。」這是混合路由的 production 等級機制。

常見考試陷阱 — Plan Mode 不是獨立的模型；Direct Execution 並非能力較弱

CCA-F 考試積極利用三種與 Plan Mode vs Direct Execution 相關的陷阱模式。

陷阱一：「Plan Mode 是獨立的 Claude 模型」

答案選項有時暗示 Plan Mode 將請求路由到不同的、更強大的模型。事實並非如此。兩種模式使用相同的模型。Plan Mode 是一種工作流程紀律，不是模型變體。如果答案選項說「plan mode 使用更大的模型」，那就是錯的。

陷阱二：「Direct Execution 能力較弱」

Direct Execution 不會降低 Claude 的能力。它移除的是強制性的事前核准關卡。聲稱「direct execution 無法處理多檔案任務」或「direct execution 跳過測試」的答案選項是錯的。在 direct execution 模式中，Claude 仍然可以測試、回滾、升級或提出澄清問題——它只是不預先承諾一份計畫。

陷阱三：「先直接執行，若複雜度浮現再切換到 plan mode」

這聽起來合理，但當情境已經說明了複雜度時就是錯的。如果任務被描述為「跨越 45 個以上檔案的單體應用程式轉微服務重構」，複雜度是預先已知的。在 direct execution 中開始並稍後切換，會在模式切換前浪費 context 在 direct execution 執行的探索工作上。當需求中已明確說明複雜度時，Plan Mode 應該從一開始就啟用。

陷阱四：「Plan Mode 永遠更安全」

Plan Mode 用在單一檔案 bug 修復上，增加延遲卻沒有增加安全性。CCA-F 樣本 Q5 模式（新增日期驗證條件式）刻意誘導考生「為了安全起見」選擇 plan mode。考試將那個選擇標記為錯誤。

陷阱五：「Plan Mode 在非互動式 CI 中可以正常運作」

互動式 plan mode 需要在場的使用者核准。在以 -p 運行的 CI 流水線中，互動式 plan mode 破壞自動化。圍繞互動式 plan mode 設計 CI 工作流程的考生，會產生永遠掛起的流水線。

練習錨點 — 任務 3.4 情境題

與 Plan Mode vs Direct Execution 相關的 CCA-F 題目，集中在兩個情境家族中。

以 Claude Code 生成程式碼 — 典範情境

程式碼生成情境是 Plan Mode vs Direct Execution 被測試最密集的地方。考試指南的樣本 Q5 使用這個形狀：

一個開發團隊需要將一個 Python 單體應用程式重構為微服務架構。這項工作將影響身份驗證、計費和報表模組的約 45 個檔案。存在多種有效的分解策略，且團隊希望在任何程式碼變更發生之前先審閱方法。哪種 Claude Code 工作流程最適合？

正確答案是 Plan Mode。任務訊號——大規模變更、多種有效方法、架構決策、多檔案範圍、明確的「變更前審閱」需求——共同符合每一個 plan mode 觸發條件。

一道配對的樣本題反轉了這個形狀：

一名開發者有一個失敗的單元測試，直接指向 date-validator.ts 第 87 行。堆疊追蹤指出在一個條件式之前缺少 null 檢查。哪種 Claude Code 工作流程最適合？

正確答案是 Direct Execution。單一檔案、清楚的堆疊追蹤、界定明確——規劃開銷會超過修復本身。「以防萬一切換到 plan mode」是錯的。

以 Claude 提升開發者生產力 — 混合模式情境

開發者生產力情境測試探索—規劃—執行的組合：

一名開發者正在計畫將一個大型 Python 程式碼庫從 requests 遷移到 httpx。受影響的呼叫端數量未知，且遷移涉及一些行為變更（逾時語義、回應物件形狀）。哪種 Claude Code 功能組合最適合？

正確答案結合了：用 Explore subagent 繪製呼叫端而不淹沒主 context、在已知範圍後用 Plan Mode 審閱遷移方法，以及在核准後用 Direct Execution 逐步實作計畫。孤立選擇任何單一模式的答案選項都是錯的——情境明確呼叫三階段模式。

Claude Code 用於持續整合 — 非互動陷阱

CI 情境常常測試 plan mode 與非互動流水線的不相容性：

一個團隊使用 -p 旗標在 GitHub Actions 中執行 Claude Code 以自動化相依套件更新。一個全專案的 CLAUDE.md 設定目前強制所有變更使用 plan mode。流水線掛起了。根本原因是什麼？

正確答案是互動式 plan mode 需要使用者核准，而在非互動式 CI 中無法取得此核准。修正方式是放寬 CI context 的 plan mode 強制規定，或以程式化方式提供核准。回答「-p 旗標是錯的」或「使用不同的模型」的考生，會錯過這個互動關係。

Plan Mode vs Direct Execution 常見問題（FAQ）

在 CCA-F 考試中，我應該何時選擇 Plan Mode 而非 Direct Execution？

當情境描述高爆炸半徑（遷移、基礎設施、安全關鍵程式碼）、架構模糊性（多種有效方法）、多檔案範圍（尤其是明確說明檔案數量很大）或陌生程式碼庫 context 時，選擇 Plan Mode。典範觸發措辭是「多檔案」或明確的檔案數量如「45 個以上檔案」。當情境描述單一檔案、可逆、界定明確的變更時——以清楚的堆疊追蹤、明確的規格或單行條件式為典型——選擇 Direct Execution。當情境事前就明確說明複雜度時，不要在 Direct Execution 中開始並計劃「若複雜度浮現再切換」——複雜度已經已知，plan mode 應該從一開始就啟用。

Plan Mode 永遠是更安全的選擇嗎？

不——這是任務 3.4 上最常見的 CCA-F 陷阱。Plan Mode 用在單一檔案 bug 修復上，增加延遲和 token 開銷卻沒有增加安全性，因為修復本身就很容易驗證也很容易回滾。CCA-F 樣本 Q5 模式刻意將界定明確的任務與「為了安全起見切換到 plan mode」的干擾選項配對；那個干擾選項是錯的。Plan Mode 是爆炸半徑的架構配對，不是萬用最佳實務。

Plan Mode 如何與非互動式 CI 流水線的 -p 旗標互動？

Plan Mode 從根本上是互動式的——它需要使用者核准、修改或拒絕計畫。-p 旗標在 CI 中以非互動方式運行 Claude Code，沒有使用者在場。如果專案 CLAUDE.md 強制 plan mode，而同一個專案以 -p 調用，流水線將掛起等待永遠不會到來的核准。希望在 CI 中自動化 Claude Code 的團隊，應該在 CI context 停用 plan mode，使用省略 plan 強制指令的 CI 專用 CLAUDE.md 路徑，或透過 SDK 以程式化方式提供核准。

什麼是 Explore subagent？什麼時候搭配 Plan Mode 使用？

Explore subagent 是一種專門的 Claude Code subagent，其角色是在隔離的 context 中執行冗長的探索工作——遞迴檔案讀取、呼叫圖追蹤、模式搜尋——並將精簡摘要回傳給主對話。當任務複雜到值得規劃，但規模大到探索可能耗盡主 context window 時，搭配 Plan Mode 使用 Explore subagent。典範三階段模式是：生成 Explore subagent 繪製範圍，切換到 Plan Mode 根據摘要產出執行計畫，然後在 Direct Execution 中執行已核准的計畫。函式庫遷移與大型重構是典範用例。

Plan Mode 使用與 Direct Execution 不同的 Claude 模型嗎？

不。Plan Mode 和 Direct Execution 使用相同的底層模型，能力相同。Plan Mode 是一種工作流程紀律，改變的是 Claude 對行動做出承諾的時間點——它事前產出完整計畫並暫停等待使用者核准——而不是不同的或「更聰明的」模型。CCA-F 考試中暗示 Plan Mode 路由到更大模型的答案選項是錯的。

Plan Mode 可以設定為專案的預設行為嗎？

可以。專案層級的 CLAUDE.md 可以包含「在任何會變更檔案系統的操作前一律先產出計畫」這樣的指令，強制 plan mode 成為存放庫中所有任務的預設值。由於 CLAUDE.md 支援三層層級結構（使用者 → 專案 → 目錄），對於典型任務屬低風險的目錄，可以選擇性放寬預設值。使用者層級的 CLAUDE.md 也可以設定個人預設值。對於典型變更是小型編輯的應用程式存放庫，要謹慎使用永遠開啟的 plan mode——儀式感開銷會不斷累積。

如何在單一工作流程中結合 Plan Mode 與 Direct Execution？

典範混合模式是三階段組合：使用 Explore subagent 蒐集 context 而不淹沒主對話，然後切換到 Plan Mode 與使用者審閱方法，然後以 Direct Execution 逐步實作已核准的計畫。這個模式在 CCA-F 考試的開發者生產力情境題中明確出現，尤其是函式庫遷移和框架升級。當情境描述了所有三個階段，卻孤立選擇任何單一模式，就是錯的。

延伸閱讀

• Claude Certified Architect — Foundations Exam Guide: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Plan Mode and Iterative Refinement — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/plan-mode
• Claude Code Features Overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Create Custom Subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Context Windows — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Integrate Claude Code into CI/CD Pipelines: https://docs.anthropic.com/en/docs/claude-code/ci-cd
• Kishor Kukreja — Passed Anthropic's CCA-F 893/1000: https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

Related ExamHub topics: CLAUDE.md Files — Hierarchy, Scoping, and Modular Organization, Task Decomposition Strategies, Iterative Refinement Techniques, Multi-Step Workflows with Enforcement and Handoff Patterns, Context Management in Large Codebase Exploration.