寫於 2026 年 8 月 16 日(補 8 月 14 日的排程),9 月才上線(部落格的發佈額度 8 月 10 日就用完了,這批稿子要等到九月才發得出去)。文中對 Cline 與 Claude Code 的描述以 8 月 16 日查到的官方文件為準,你讀到時文件可能已經改版。

一個開關按下去同時換掉兩件事,在設計上通常是壞味道。耦合、副作用、debug 到懷疑人生,教科書上寫得很清楚。

Cline 偏偏就這樣做了。而且這是我今年看過最划算的一個耦合。

它那個開關叫 Plan / Act。按過去,agent 的權限變了,同一秒鐘,它背後的模型也可能整顆換掉。兩件本來八竿子打不著的事,被同一個動作綁在一起。聽起來像懶得拆的設計債,實際上它省掉的東西比省掉的錢多很多。

Plan 模式是真的被綁住手腳,不是講好聽的

先把事實釘死。官方文件對 Plan 模式的描述是這句:

In this mode, Cline can read your codebase, run searches, and discuss strategy, but cannot modify any files or execute commands.

讀 codebase、搜尋、討論策略,可以。改檔案、跑指令,不行。注意後半句是 cannot ... execute commands,連指令都不准跑,不是「跑之前先問你」。這個限制比我原本預期的還硬。

切到 Act 之後,前面聊的東西不用重講。文件寫得很直白:

The conversation history carries over when you switch modes. Cline remembers everything you discussed in Plan mode, so you don’t need to repeat yourself.

對話歷史直接帶過去,不是重新摘要一份計畫再餵進去。所以 Plan 階段那些「等等這個假設不對」「這張表其實已經沒人用了」的碎片,全部原封不動留在上下文裡。

至於怎麼切換(快捷鍵、按鈕在哪),我查的那頁沒有寫。文件只說 when confident in the plan, switch to Act mode,沒交代切換的操作方式。它另外提到一個 /deep-planning 指令,會啟動一次比較長的規劃流程,先把受影響的檔案跟相依關係摸清楚再問你問題。

那個開關真正省下的不是錢

重點來了。Cline 設定裡有一個選項叫 Use different models for Plan and Act,打開之後,兩個模式各自指定一顆模型。官方給的理由是這句:

This is useful when you want to use a stronger reasoning model for planning and a faster model for implementation.

有個字值得停一下。官方寫的是 faster,不是 cheaper。文件通篇沒有把這個功能包裝成省錢工具,它賣的是「該慢的地方慢,該快的地方快」。省錢是副作用,不是主張。

文件給了三組範例搭配:成本取向是 GLM 4.6 配 Grok Code Fast,品質取向是 Claude Opus 配 Claude Sonnet,速度取向是 Gemini 3 Flash 配 Cerebras。看得出來設計者心裡想的是一個光譜,不是一張推薦清單。

實際有人這樣用嗎?Cline 官方部落格有一篇專門統計 Plan/Act 的模型搭配,裡面寫 Claude Opus 4.1 接 Claude Sonnet 4 這組佔了所有跨模式使用的 25.3%,是最大宗。那篇沒有標資料區間的起訖日期,只寫了 last 7 days,樣本數也沒給。型號本身也透露了年紀,Opus 4.1 跟 Sonnet 4 距離現在的世代已經隔了好幾輪,那份數字現在大概只能當「這個用法真的有人在用」的證據,不能當比例參考。

回到設計本身。把模型綁在模式上,划算在哪?

划算在你本來就會按那個開關

你切到 Plan 不是為了換模型,是因為這件事你自己也還沒想清楚。這個判斷你反正要做。模型換掉是搭順風車,額外決策成本是零。

對照一下另一種做法:每次派工的時候自己挑模型。粒度更細,理論上更精準,代價是每一次都要判斷一次。這題該用貴的還是便宜的?我前天怎麼判的?判斷本身是要花力氣的,而且很容易在第七次的時候開始擺爛,全部用同一顆了事。

站上之前寫過一篇 Claude Code Multi-Model 混用策略,談的正是這種「每次派工挑一顆」的玩法。那篇的重點是怎麼挑,這篇的重點是挑的動作本身有成本。同一件事的兩個繫結層級,貴的那個是決策次數。

一個介面好不好,我現在看的是它幫我省掉幾次選擇。

Claude Code 的 plan mode 掛在另一條軸上

Claude Code 也有 plan mode,看起來像同一個東西,其實住在完全不同的地方。

線索藏在文件的位置。Cline 的 Plan & Act 放在 core workflows 底下,是「你該怎麼工作」。Claude Code 的 plan mode 放在一份叫 Choose a permission mode 的文件裡,跟 defaultacceptEditsautodontAskbypassPermissions 這幾個並列。它是六個權限模式之一,跟「工作流」沒關係,跟「你這個 session 可以動什麼」有關係。

官方定義是這句:

Plan mode tells Claude to research and propose changes without making them. Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source.

這裡有個跟 Cline 相反的細節。Claude Code 的 plan mode 明講 runs shell commands to explore,唯讀範圍內的指令照跑;Cline 的 Plan 模式是 cannot ... execute commands。同樣叫「計劃模式」,一個准你出門勘查,一個要你坐在辦公室看藍圖。

離開的方式也不一樣。Cline 那邊是你覺得可以了就切過去。Claude Code 這邊,計畫寫完會停下來問你三選一:Yes, and use auto modeYes, manually approve editsNo, keep planning。文件寫得很清楚:

Approving a plan exits plan mode and switches the session to the permission mode each approve option describes, so Claude starts editing.

核准這個動作本身就是模式切換。你選哪個選項,決定接下來 Claude 動手時要不要每一筆都問你。Shift+Tab 可以直接退出不核准,但那等於放棄這份計畫的授權。

那份文件裡 plan mode 的專節,從頭到尾沒有一個字提到模型(文件其他地方提到模型,講的是 auto mode 那顆審查用的 classifier 要什麼版本,跟 plan 無關)。模型在 Claude Code 裡是另一條完全獨立的線,/model 管的、subagent 的 model 參數管的,跟你現在處在哪個權限模式互不相干。

分水嶺是「誰決定換模型」

拆到這裡,兩邊的差別就不是功能多寡了。

Cline 押的是:規劃跟執行是兩種認知活動,值得配不同的腦。你設定一次,之後產品幫你在正確的時機換。

Claude Code 押的是:規劃跟執行是兩種風險等級,值得配不同的權限閘門。模型誰來配?呼叫端自己決定,每次派工的時候現場挑。

想在 Claude Code 這邊做到「規劃用貴的、執行用便宜的」,路徑是有的,靠 subagent 的 model 參數,或是自己在 /model 之間手動切。差別在於這件事沒有被綁進任何一個你本來就會按的開關,所以它永遠是一筆額外的決策。你可以做,但你要記得做。

哪個比較好,看你的失敗模式。如果你的痛是「一路寫下去才發現方向錯了」,Cline 那種強制性的規劃/執行分離比較對症。如果你的痛是「它自己亂改我沒看到的檔案」,Claude Code 把 plan 放進權限體系才是解法,因為它擋的本來就是動作,不是笨。

兩個都不是錯的設計。它們只是把「先計劃再動手」這個直覺,投影到了不同的軸上。

我沒跑過的部分

這篇對 Cline 的所有描述都來自官方文件,我沒有裝過 Cline,沒有跑過一次 Plan/Act 切換,更沒有實際設定過雙模型。上面每一段引號裡的英文都是照抄,中文部分是我的解讀,這兩者請分開看。

有幾件事文件沒寫,我也就沒補:模式切換的快捷鍵是什麼、模型換掉的那一瞬間上下文是整包重送還是走快取、Act 模式中途切回 Plan 時前面的執行紀錄會怎麼處理。這些我全部不知道,寫成「應該是」對誰都沒好處。

Claude Code 那半邊不一樣,plan mode 是我每天在用的東西,Shift+Tab 按到有肌肉記憶,那三個核准選項也是實際看過的畫面。文件引用跟日常經驗都在,只是一樣要提醒:Claude Code 改版很快,我引的是 8 月 16 日查到的版本。

找出你本來就會按的那個開關

Cline 這個設計真正教會我的,不是「Plan 該用強一點的模型」這種操作層面的事。

是這個:任何一個你本來就會頻繁切換的狀態,都是一個免費的掛勾。

你切分支的時候,本來就在宣告「我現在要做另一件事」。你進 plan mode 的時候,本來就在宣告「我還沒想清楚」。你開 UAT session 的時候,本來就在宣告「這裡可以壞」。這些宣告你天天在做,做的時候沒有任何額外成本,因為那個判斷你反正要下。

貴的決定不該有自己的開關。貴的決定應該掛在便宜的開關上。

模型只是第一個被掛上去的東西。溫度參數、工具白名單、要不要開 web search、每次呼叫的 token 上限,這些現在全部散在各自的設定頁,等你有空的時候一個一個去調。它們都可以掛。

所以下次覺得某個設定「明明知道該調卻總是懶得調」的時候,先別怪自己。真正該問的是:我一天到底按幾次開關,而這個設定為什麼沒有掛在上面。


參考來源