Cline 裝好之後該調什麼？Plan/Act、.clinerules、自動核准與花費上限

很多人裝完 Cline 覺得「還好」，問題通常不在模型

Cline 裝起來很快，但預設值是偏保守的：什麼都問你、什麼都要按確認、沒有任何專案規範、也沒有任何花費保護。這種狀態下用起來會有兩種感覺，一種是「一直在按同意，比自己改還累」，另一種是「它好像沒搞懂我的專案在幹嘛」。

這兩種感覺其實是同一件事的兩面，就是你還沒告訴它「什麼可以自己做、什麼要先問、這個專案的規矩是什麼」。

真正會影響體感的設定只有四個：Plan 跟 Act 的切換、.clinerules、自動核准的範圍、花費上限。這篇就只講這四個，調完你會覺得它像另一個工具。

Plan 模式跟 Act 模式：先想清楚再動手

Cline 有兩個模式，這是它跟很多 AI 外掛最不一樣的地方。

Plan 模式是唯讀的。 它可以讀你的檔案、看專案結構、跟你討論要怎麼改，但它不會動任何一個字。這個模式的用途是「先弄懂再說」，尤其是你自己也還沒完全想清楚要怎麼做的時候。

Act 模式才會動手。 改檔、跑指令、產生 diff，都在這個模式。

關鍵在於切換模式的時候，前面聊過的東西會留著。你在 Plan 模式跟它討論了十分鐘、它讀了八個檔案、你們一起決定了作法，切到 Act 之後它記得整段討論，不用重講一次。

所以順手的用法大概是這樣：一開始先進 Plan，把目標講清楚，讓它去讀相關檔案，然後你看它理解得對不對。它如果誤會了，這時候糾正的成本是零，因為它還沒改任何東西。等你覺得「對，就是這樣做」，再切到 Act 讓它執行。

做到一半發現事情比想像中複雜？切回 Plan 重新討論就好，不用整個重來。

還有一個很多人不知道的設定：兩個模式可以用不同的模型。規劃的時候用比較會想的模型，執行的時候換成比較快、比較便宜的模型。這個組合對帳單的影響比你想像中大，因為 Act 階段通常會跑很多次，Plan 階段只跑一次。

複雜一點的任務，還可以用 /deep-planning 指令，讓它在動手前想得更久一點。

.clinerules：把「這個專案的規矩」寫成檔案

如果你每次都要跟它說「這個專案用 TypeScript、不要用 any、測試放在 tests 資料夾、commit 訊息用中文」，那這些話就應該變成檔案，而不是每次重打。

作法是在專案根目錄開一個 .clinerules/ 資料夾，裡面放 .md 或 .txt 檔案，Cline 會把裡面所有檔案讀進來當成規則。因為它就在專案裡，所以會跟著 git 走，團隊每個人拿到的規則都一樣。

如果是你個人的習慣、不想進版控，可以放在系統的 Cline Rules 目錄（Windows 和 macOS 在 Documents/Cline/Rules）。專案規則和全域規則衝突的時候，專案規則優先。

從別的工具搬過來的人可以先鬆一口氣，.cursorrules、.windsurfrules 和 AGENTS.md 它都會自動認得，不用重寫一份。

新手不用一開始就寫長篇規範

看到「規則檔」三個字不要有壓力。不需要先寫一份完整的團隊規約，那通常寫完就沒人看了。

比較實際的作法是，等你第二次糾正它同一件事的時候，再把那句話寫進規則檔。像是「這個專案不要自己 npm install，缺套件先告訴我」、「改完不要順手 commit」這種，一行就夠。累積個五六條，效果就很明顯了。

寫規則的時候有個小訣竅：講理由比講規定有用。「不要用 any」不如「不要用 any，因為 CI 的型別檢查會擋下來」，它知道原因之後，遇到你沒寫到的情況也比較不會亂猜。

條件式規則：只在改到特定檔案時才生效

規則多了之後會有個問題，前端規範、後端規範、測試規範全部塞進去，等於每次對話都要多讀一堆用不到的東西，既佔上下文又花錢。

Cline 支援在規則檔開頭用 YAML 標注生效範圍：

---
paths:
  - "src/components/**"
---

這樣這份規則只有在它碰到 src/components/ 底下的檔案時才會載入。前端規則歸前端、測試規則歸測試，上下文乾淨很多。

規則檔在 Cline 面板裡還可以個別開關，原型階段先把嚴格的測試規則關掉，要進正式的時候再打開，不用刪檔。

自動核准：這是省事跟出事的分界線

這一段請認真看完再去調。

Cline 的自動核准可以分項目開，大致分成幾類：讀專案內的檔案、讀專案外的檔案、改專案內的檔案、改專案外的檔案、跑終端機指令、用瀏覽器、呼叫 MCP 工具。

它判斷「指令安不安全」的方式不是固定的白名單，而是模型自己替每個指令標一個「要不要核准」的旗標。跑測試、跑 build 這種通常算安全，刪東西這種預設要你確認。

這句話值得多想一秒：判斷安全與否的，是那個有可能誤解你意思的模型本身。

建議的調法

第一階段只開「讀專案內的檔案」。 這個幾乎沒有風險，但可以省掉大量按確認的次數，因為 agent 光是搞懂你的專案就要讀十幾個檔案。

第二階段再開「改專案內的檔案」。 開這個之前先確認兩件事：這個專案有 git，而且你目前的變更已經 commit 或 stash 過。Cline 有 Checkpoints 功能可以回復到任務中的某個時間點，但你自己的 git 仍然是最後一道保險。

終端機指令留到最後。 而且先只開「安全指令」，不要一次開到全部。

「改專案外的檔案」這一項，除非你很清楚自己在幹嘛，否則不要開。 這代表它可以動到你專案資料夾以外的東西。

YOLO 模式會怎樣

Cline 有一個把全部都自動核准的模式，官方文件自己寫得很清楚：它會關掉所有安全檢查，決定什麼就執行什麼，不會問你。

具體會怎樣？它可能在你還在看別的視窗的時候，把一個它誤判成過時的檔案刪掉、裝了一堆你不想要的套件、或是跑了一個對外部服務有後果的指令。它不是惡意的，是它誤會了你的任務，而這個誤會直接變成已經執行的動作。

如果真的要用，至少做到三件事：跑在一個丟掉也不心疼的環境、任務講得非常具體、以及人在旁邊看著輸出。正式專案不要碰。

花費上限：第一天就該設

Cline 這個外掛免費，但模型要錢，而 agent 的用量跟一般聊天不是同一個量級。它為了完成一個任務會反覆讀檔、思考、跑指令、看錯誤訊息再重來，每一輪都在燒 token。

一個任務跑歪、它在錯誤的方向上來回試二十次，帳單會很有感。

所以不管你用 Cline 帳號還是自帶 API key，第一天就去後台設一個月的花費上限。這不是為了省錢，是為了讓「跑歪」的損失有天花板。

想理解 token 到底怎麼算、為什麼 agent 特別貴，可以看 token 是什麼、AI 成本怎麼算，還有上下文視窗為什麼會讓 AI 忘記事情。

順手之後可以再加的東西

上面四個調完，Cline 基本上就順了。如果你還想再往前走一步，MCP 是下一站。

MCP 可以讓 Cline 接上外部的資料來源和工具，像是直接操作 GitHub、查最新的套件文件、連資料庫。Cline 有內建的 MCP Marketplace，安裝門檻比自己接低不少。

站內有兩篇可以接著看：GitHub MCP Server 怎麼讓 AI 直接操作你的 repo，還有 Context7 MCP 怎麼讓 AI 讀到最新版文件。

要注意的是，MCP 工具也在自動核准的名單裡。多接一個 MCP，就是多開一個它能碰到的東西，接之前先想一下那個工具的權限範圍。

我會建議的調整順序

如果你現在就要動手，照這個順序走最不容易出事。

先把自動核准全部關掉，只開「讀專案內的檔案」，用一個禮拜。

這禮拜裡每次你糾正它同一件事第二次，就寫一行進 .clinerules。

養成習慣：不確定怎麼做的任務先進 Plan 模式，確定了再切 Act。

去模型後台設一個月的花費上限，數字設在你覺得「這個數字沒了會不爽但不會痛」的地方。

一個禮拜後，如果你發現按確認按到煩、而且它改的東西一直都沒問題，再把「改專案內的檔案」打開。

終端機指令和 MCP 留到你已經很清楚它的行為模式之後再說。

Cline 調得好不好，差別不在它有多聰明，在你有沒有把邊界畫清楚。邊界畫清楚了，它可以放手做很多事；沒畫清楚，你只能一直盯著按同意。

資料來源

本文依 Cline 官方文件整理，Cline 更新頻率高，設定項目的名稱與位置可能變動，實際操作請以你安裝的版本為準。自動核准與花費上限的建議屬於一般 agent 安全實務，不是官方保證。

https://docs.cline.bot/features/plan-and-act
https://docs.cline.bot/features/cline-rules
https://docs.cline.bot/features/auto-approve
https://github.com/cline/cline