工程師的鋼鐵人裝甲：GitHub Copilot、Cursor、Cline 的推薦用法

適合對象

先簡單介紹一下我的背景，讓大家可以判斷這篇文章是否適合你。我程式開發經驗約 10 年，主要使用 JavaScript 進行前後端開發，也使用 Flutter 開發 Android 和 iOS APP。

這篇文章適合：

• 正在研究各家 AI 輔助開發的工程師，想了解哪款工具適合。
• 有一定經驗的工程師，分享我的做法給你參考，或者你也可以給我反饋。

工具總覽與版本資訊（2025/02/12）

因為工具迭代速度很快，可能下個月這篇就沒用了QQ，先提供簡單整理以及我目前使用的版本

各家工具的功能與價格可能隨時更新，請以官方最新資訊為準。

先說結論：我的工作流

1. 主力開發、功能複雜時
   → 主要使用 Cursor，但要注意一個月 API 500 次的限制。
2. 修 Bug 或小調整時
   → 用 Cline，利用 Copilot API 省下 Cursor 的使用次數。

3. 如果 Cline 也達到 Copilot API 限制
   → 等下一個可用時段，或者乾脆休息一下。

   如果想知道 Copilot API 何時可用 → 在 VS Code 裡隨便呼叫一次 Copilot，它會告訴你解鎖時間。

4. 每完成一個小功能
   → 打開 VS Code Insider，用 Copilot 生成 commit log 上去。

GitHub Copilot：CP 值的代言人

AI 輔助開發啟蒙

我最早使用 GitHub Copilot，它剛推出時的 自動補全功能 就像工業革命一樣，讓開發效率瞬間提升。

隨著功能的更新，我開始用 Copilot 來問問題、讓它產生程式碼，然後複製貼上，掌握了和 AI 提需求的技巧後，我幾乎沒再上過 stackOverflow 查資料。

此時工程師們的日常已經改變：從網路上 Google 然後複製貼上 → 變成問 Copilot 然後複製貼上

沒想到 Copilot Edit 出來後就連複製貼上都懶了…

Copilot Edit

這個功能你只需要描述需求，Copilot 就會根據完整的程式碼上下文，快速在多個檔案中修改，然後你就是檢查、審核修改、通過修改，不用再複製貼上，感覺很像在給 AI 做 code review

Copilot Edit vs. Cursor Composer

如果你不太清楚各家功能的名字，你可以這樣記

Github Copilot 的 Edit = Cursor 的 Composer = Cline

Cursor 的 Composer 其實比較早出來，Composer 推出後我就有試用了，體驗完後忍了兩個禮拜試用（那時候試用還有 500 次 API 次數，超佛），試用完就刷卡了，爽了一陣子都快要考慮把 Github Copilot 訂閱停了，Copilot Edit 就推出了。

但這裡有一個很大的問題：Copilot Edit 的速度非常慢。

當你要修改某段程式碼時：

• Copilot Edit 的做法像是 重新生成整個檔案，所以如果這個檔案很長，你就會等超久。
• Cursor Composer 的做法是 只生成需要修改的部分，然後去比對你的檔案然後修改，這樣的速度快很多。

• Cline 也有類似的機制，速度和 Cursor 差不多，他會說他要用 replace_in_file 工具來修改檔案，但有時他會有 bug，replace_in_file 工具會失效，我感覺是要修改的檔案經過編輯，和它暫存的檔案內容不同，此時已經無法用程式去比對，這時他就會說他要用 write_to_file 工具，那就是又從頭生成程式碼，然後再寫入檔案，就會很慢，而且要是生成的程式碼太長，還會失敗，失敗後他又從頭生成又太長失敗，一直看他鬼打牆，如果是 call api 的話，錢包就會哭

  

所以如果是要快速修改一段程式碼，Cursor 快又舒服，Cline 不要太難的工作體驗和 Cursor 差不多，兩個都比 Copilot 好，不過這個功能也不是多難的事，相信很快 Copilot 也會有這個功能。

補充：我的大大朋友說，近期又有一個新的工具 Roo code，看起來是從 Cline 分支出來的，在處理大型或複雜修改上表現得更為穩定，我還沒用過（快要學不動了）有興趣的朋友可以關注相關動態。

Git Commit Message 自動生成

Copilot 也是有別家沒有的優勢，他有 Git 版控提交（commit message）自動生成 的功能。這點在 Cursor 上也有，不過 Copilot 可以自訂 Prompt 指令。

為什麼這很重要？
如果你希望 commit 訊息更清楚、有結構，讓團隊更容易理解每次變更，可以參考這個網站Conventional Commits ，這是一個 commit 的規範文件，你可以把這個標準 直接寫進 Copilot 的 Prompt 指令裡，讓它每次產生的 commit 描述都符合規範。這對於團隊開發、版本管理來說是一個很棒的提升，而我們也不用再去背 commit 規範，不然每次都亂寫。

Cursor：開發體驗最佳，但有使用次數限制

當我開始使用 Cursor，最讓我驚艷的是 Composer 功能，因為它能夠 自動處理多個檔案的修改，不需要我手動複製貼上，這大幅減少了開發過程中的「手工活」。

Cursor 的自動補全：比 Copilot 更「懂」你在幹嘛

相較於 Copilot 透過「預測」來補全程式碼，Cursor 更像是「理解」我現在的開發情境，並主動提供相關建議。例如在調整 UI 時：

• 當我修改樣式時，我通常會直接手動調整，因為畫面可以馬上看到變化。但如果是一次要調整一堆小地方，可能需要同時修改多個地方（例如 class、margin、padding），然後其實又懶得跟 AI 說清楚。
• 在這種情境下，Cursor 會自動推測出哪些地方應該一起修改，並主動彈出推薦補全，我只需要按下 Tab 就能一次性修改所有相關內容。

Cursor 訂閱方案的使用次數限制

Cursor 的訂閱方案是 每月 20 美元，包含 500 次 API 使用額度。我有時候 半個月就用完了。

 我的解法是：

• 如果是主力開發、較複雜的功能，就優先用 Cursor。
• 如果只是修 Bug、調整小功能，就用 Cline，因為 Cline 現在可以 免費使用 Copilot API（後面會講）。

Cline：體驗絲滑，現在還能用 Copilot API！

Cline 是我一個大大朋友推薦的，基於大大推薦，我也是馬上試用。他有一個部分，我不知道算不算缺點：他沒有自動補全功能，不過我真的覺得沒有那麼嚴重，反正你叫 AI 補也是一樣。

不過如果你是使用 Github Copilot + Cline的方案（下面會提到），你就能使用到 Github Copilot 的自動補全功能，不然你也可以用 continue.dev 來做自動補全，也是免費

 最早使用 Cline 時，它的特點：

1. 它是一個 VS Code Extension，不像 Cursor 需要獨立安裝，有些人就是不想再安裝應用程式。
2. 可以自己選擇 AI 模型的 provider（例如 OpenAI、anthropic、甚至本地端的 AI 模型）。
3. 但缺點是使用者付費，根據你呼叫的 API 次數你自行付費。Cline 還會在每次你呼叫的任務上告訴你花了多少摳摳，因為是依使用量付費，所以我也不知道會花多少錢，所以我就註冊了 anthropic 帳號，想說那我就 Claude 3.5 Sonnet 爽爽用，結果第一個月還沒結束我就花了 30鎂，比 Cursor + Copilot 加起來還貴！我就乖乖回去用 Cursor 的 Claude 3.5 Sonnet 了。

Cline 最新功能：免費使用 Copilot API

不過，Cline 最近推出了一個新的功能，讓它又復活了。它現在可以：

• 使用 VS Code LM API Provider，等於說你只要有訂閱 GitHub Copilot，就可以用 Cline 來呼叫 GitHub Copilot 的模型額度，Claude 3.5 Sonnet、o1、o3-mini 都能用。
• 這樣一來，就不用額外付 API 的錢，但是 GitHub Copilot 也是有使用限制。不過如果達到使用限制，我就跳回去 Cursor，等一下就能繼續用 Cline 了。
• 等於用 GitHub Copilot API，但體驗比 GitHub Copilot 還好（體驗更絲滑、產生速度更快）。

Cline 的自動修復功能（但要小心 API 使用量）

Cline 另一個有趣的功能是你可以 Auto-approve 檔案讀取、編輯等操作，它的運作方式就像是：

1. 你輸入一個指令，讓 AI 生成程式碼，編輯你的檔案，然後自動存檔。
2. 它會自動檢查存檔的檔案的結果，如果發現問題，會自動再呼叫 API 修正，再存檔。
3. 這個過程可能會重複多次，直到 AI 覺得沒問題了。

這功能聽起來很強，但有個問題：

• 每一次修正都會額外呼叫 API，所以如果 Cline 在背景一直自動檢查、修復，可能一下子就用掉大量的 API 額度。如果 Copilot API 使用額度滿了，你就得等下一個時段才能繼續用。
• Cline 不會一次修到位，它通常會分步驟或拆分細節去處理。順利的話他在跑，你去泡個咖啡回來就好了；不順利的話會一直鬼打牆，刪了剛剛修的，又修成剛剛被刪的。

保護荷包：在 Cline 設定中調整 max_request 參數，確保 API 請求不會超過上限，避免連續調用導致額度耗盡

回到一開始，我的工作流：

1. 主力開發、功能複雜時
   → 主要使用 Cursor，但要注意一個月 API 500 次的限制。
2. 修 Bug 或小調整時
   → 用 Cline，利用 Copilot API 省下 Cursor 的使用次數。
3. 如果 Cline 也達到 Copilot API 限制
   → 等下一個可用時段，或者乾脆休息一下。
   如果想知道 Copilot API 何時可用 → 在 VS Code 裡隨便呼叫一次 Copilot，它會告訴你解鎖時間。
4. 每完成一個小功能
   → 打開 VS Code Insider，用 Copilot 生成 commit log 上去。

真心推薦

這套組合拳的成本 = Cursor 20鎂 + Github Copilot 10鎂

如果你還沒體驗過，Github Copilot + Cline 你可以先試試，本篇我沒有說太多如何使用 AI 的技巧，如果你想知道基本操作技巧，推薦 Will 保哥的課程《GitHub Copilot 進階開發實戰》

也在此感謝我的大大朋友 Wayne Wang，分享給我這些工具資訊

我的預設 Prompt 設定

以下是我預設給 AI 的 Prompt ，供大家參考，也歡迎分享你的指令給我

DO NOT GIVE ME HIGH LEVEL SHIT, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION!!! I DON'T WANT "Here's how you can blablabla"
- Be casual unless otherwise specified
- Be terse
- Suggest solutions that I didn't think about—anticipate my needs
- Treat me as an expert
- Be accurate and thorough
- Give the answer immediately. Provide detailed explanations and restate my query in your own words if necessary after giving the answer
- Value good arguments over authorities, the source is irrelevant
- Consider new technologies and contrarian ideas, not just the conventional wisdom
- You may use high levels of speculation or prediction, just flag it for me
- No moral lectures
- Discuss safety only when it's crucial and non-obvious
- If your content policy is an issue, provide the closest acceptable response and explain the content policy issue afterward
- Cite sources whenever possible at the end, not inline
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
- Please respect my prettier preferences when you provide code.
- Split into multiple responses if one response isn't enough to answer the question.
- 替生成的程式碼加上註解方便閱讀理解
- Always respond in 繁體中文