Windsurf 讓 IDE 編輯變代理工作

我用 AI 編輯器一陣子了，最煩的永遠是同一件事：我明明想要它幫我改 code，它卻像在陪聊；我一旦真的放手讓它動手，它又常常把整個 repo 弄得像被外包團隊掃過。工具看起來很聰明，實際上我還是在當保姆。

我拆 Windsurf 的 Devin Desktop、Cascade 模式、匯入設定和 .codeiumignore，整理成我會直接照抄的工作流。

我後來看了 Tech Jacks Solutions 這篇教學，才把 Windsurf 這套東西看懂一點，原文在這裡：https://techjacksolutions.com/ai-tools/windsurf/how-to-use-windsurf/。它講的不是「這產品很酷」，而是怎麼把編輯器、代理、模型選擇串成一個真的能用的流程。這篇我會照這個方向拆：什麼時候用聊天，什麼時候交給 Cascade，怎麼避免它亂碰私人專案，還有我會怎麼落地。

Windsurf 先是 IDE，才是 AI

“Windsurf is an AI code editor, a full desktop IDE with autocomplete, syntax highlighting, and debugging, plus Cascade, the agent that can plan and carry out changes across your whole project.”

翻譯一下就是：它不是掛在你原本編輯器上的小插件，它本身就是工作區。這件事很重要，因為我如果還用「裝個外掛就好」的心態看它，第一個判斷就會錯。Windsurf 的核心不是補一個聊天側欄，而是把整個編輯體驗改成 agent-first。

我以前最常踩的坑，就是把這類工具當成裝飾品。先期待它能無痛接上舊 IDE，再期待它只在我需要時出現，最後才發現它根本不是那種產品。Windsurf 的設計很明確：它要你把日常編輯搬進它自己的桌面環境。

這裡還有一個現實點：文中提到它已經透過 OTA 更新改名成 Devin Desktop，而且 plan、pricing、extensions、settings、進行中的工作都會自動帶過去。這代表它不是遷移專案，比較像換招牌。你如果已經裝過 Windsurf，這次比較像是產品方向再往 agent 那邊推了一格。

實操上，我會這樣看待它：先問自己願不願意把主力編輯器搬家，而不是先問它能不能「整合」進現有工具。這個問題很土，但很省時間。因為如果答案是不要，那你從一開始就不該花力氣研究它。

• 把 Windsurf 當成目的地，不是外掛。
• 先接受它有自己的工作流，再談習不習慣。
• 如果你只想加一個側欄，它大概不是你的菜。

第一次啟動，才是省時間的地方

我最在意的其實是第一次打開時怎麼接手舊習慣。原文有提到可以從 VS Code 或 Cursor 匯入 settings、extensions、keybindings，也可以直接從零開始。這不是小事，因為新工具最常死在「你得重學一套肌肉記憶」這件事上。

白話一點說，Windsurf 想做的是減少新工具稅。你不用先忍受三天快捷鍵失憶、插件重裝、偏好設定重配，才開始評估 Cascade 好不好用。它希望你一開機就把舊環境搬過來，然後只測 agent 功能值不值得留下。

我自己遇過最煩的情況，就是團隊有人換工具後，第一天不是在評估功能，而是在抱怨 keybinding、extension、字體跟主題。那種抱怨通常不會被講成「這產品 onboarding 很差」，而是直接變成「這東西很煩」。結果都一樣，工具被放棄。

原文也提到支援 Mac、Windows、Linux。這句看起來很無聊，但對團隊很實際。至少你不用擔心某個人拿到的是 demo 版、另一個人是半殘版。混合環境本來就麻煩，能少一層摩擦就少一層。

我會這樣做：先花五分鐘把 import 走完，再決定哪些 extension 要刪、哪些 keybinding 要保留。真的要導入團隊時，最好先定一份標準清單，不然每個人都會把自己的 IDE 習慣帶進來，最後大家看起來像在用同一套工具，實際上根本不是。

• 先匯入，再評估，不要反過來。
• 把你真的需要的 extension 列成標準。
• 不要讓每個人各自定義到無法溝通。

Cascade 才是你要先學的那個入口

“You open it with a single shortcut: Cmd+L on Mac, or Ctrl+L on Windows and Linux.”

這只是開啟方式，真正重要的是 Cascade 在做什麼。原文把它描述成內建 agent，會感知編輯器狀態，還有一個 Fast Context 系統會抓出跟當前任務相關的程式碼。也就是說，它不是只看你貼進去的幾段字，它是在整個專案脈絡裡工作。

這個差別很大。當我只是在問一個函式怎麼寫、某個變數要不要改名，普通 inline editing 或 tab completion 就夠了。但如果我要跨檔案改動、補測試、順便整理流程，那我會想把工作交給 agent。這時候 Cascade 才像真的有用，不然就只是比較會聊天的 autocomplete。

我也喜歡它有 todo list 這件事。原文說它會先把大型請求拆成步驟，再開始改檔案。這比「直接動手」可靠多了，因為我更想知道它是不是理解任務，而不是看它有多快下刀。能先列計畫，至少代表它有在想，不是只在亂補。

實操上，我會用一個很簡單的規則：只要任務超過一個檔案，或者我想先讓機器幫我整理思路，就交給 Cascade。像是「改 auth flow 並同步測試」這種，就很適合。像是「把這個變數名改掉」，我不會浪費 agent。

我還會要求它先講計畫再動手。你可以直接問：會改哪些檔、會跑哪些測試、風險在哪。只要它的回答看起來怪，我就先停。這比事後收拾一個亂 diff 便宜太多。

Chat mode 跟 Code mode 本來就該分開

很多人用 AI 編輯器卡住，就是因為他們把「問問題」跟「動手改」混在一起。Windsurf 把 Cascade 分成兩個模式：Code mode 直接改檔，Chat mode 只負責解釋、規劃、建議，不會真的改東西。這個切法很樸素，但我覺得很對。

翻成白話，Chat mode 是用在不確定的時候，Code mode 是用在已經決定要做的時候。當我在摸一個陌生 codebase，或只是想知道某條 auth path 怎麼走，我會先留在 Chat。當我已經知道要改什麼，才切到 Code 讓它執行。

我用過太多工具，界線都糊在一起。你只是想問一個問題，它卻開始熱心幫你改檔；你明明想做變更，它又一直講解，像個不肯碰鍵盤的顧問。Windsurf 至少把這件事拆開，讓你知道你現在是在問，還是在交代工作。

我自己的做法很固定：先用 Chat 問路，確認影響範圍；確定方向後切 Code；改完再看 diff。這流程很笨，但很穩。尤其是你在看 legacy repo 或幫別人接手專案時，Chat mode 真的能省掉很多瞎猜。

如果要我給團隊一條簡單規則，我會寫成這樣：

• 不確定時，先用 Chat mode。
• 已經知道要改什麼，再切 Code mode。
• 跨檔案、跨測試、跨流程的工作，才值得交給 agent。

代理能動 repo，前提是你先畫好邊界

“Before you point it at a private repository, add a .codeiumignore file for anything it should not touch.”

這句我覺得很多人會直接跳過，然後再抱怨 agent 看到太多東西。原文其實講得很直白：Cascade 可以讀整個專案，也可以幫你跑工具。既然它有這種權限，你就不能假裝 repo 裡所有東西都可以隨便看、隨便改。

白話就是，檔案層級的邊界要先定好。像 secrets、generated assets、build artifacts、敏感文件，這些都該先排除。你不會把一個新進實習生直接丟進私人 repo 然後說「反正你自己看著辦」，我也不會對 agent 這樣做。

我看到原文提到 Codeium 風格的 ignore 機制，反而覺得這很實際。它不是在賣神秘感，而是給你一個很熟的模型：先定義不能碰的區域，再讓工具在安全範圍內工作。這種做法雖然不花俏，但真的比較像工程。

我會這樣落地：先建 `.codeiumignore`，把 secrets、build 產物、生成檔、敏感 docs 全丟進去。然後先拿一個小改動測試 Cascade，確認它在安全範圍內做事沒問題，再放它去碰比較重要的地方。

如果你帶團隊，我甚至會把這件事寫進 onboarding。不是為了阻擋 agent，而是為了讓它的活動範圍固定、可預測。工具只要開始亂碰，大家就會開始不信任它。

模型與 quota 會決定你到底用不用得起

原文提到免費方案包含 unlimited inline edits、Tab completions，加上一點 agent 額度；Pro 以上才有更重的 agent 使用、完整模型清單，還有 free SWE-1.6。這種資訊我很在意，因為它直接告訴我產品的成本點在哪裡：不是基本打字幫手，而是 agent 工作量跟模型存取。

也就是說，不是每個任務都該丟同一個模型。小改動、局部補字、單檔修正，用免費層級可能就夠了。可是如果我一天到晚都在叫 Cascade 做多檔案任務，那我就得先想 quota，而不是先想 workflow 多漂亮。

我看過太多團隊導入 AI 工具後，最後帳單出來才開始後悔。通常不是工具太貴，而是大家根本沒有把「簡單 autocomplete」跟「真的讓 agent 幹活」分開。Windsurf 這份說明至少把這條線畫出來了。

原文還提到每個 prompt 最多 20 次 tool calls。這種數字很有用，因為它提醒你 agent 不是無限黑箱。你如果丟一個超大的任務進去，它可能根本不適合一次做完。把工作切成幾段，通常比硬塞一包更有效。

實操上，我會這樣分配：局部修改走 inline edit；跨檔案變更走 Cascade；真的碰到 quota 或 tool-call 限制，就把任務拆小。不要跟系統硬拚，因為最後輸的通常是你自己。

可抄的模板

# Windsurf / Devin Desktop 我會直接照抄的工作流

## 1) 安裝與啟動
- 從 https://windsurf.com/ 下載 Windsurf / Devin Desktop
- 安裝到 Mac / Windows / Linux
- 先登入免費帳號，確認基本流程能跑

## 2) 匯入舊環境
- 第一次開啟時，從 VS Code 或 Cursor 匯入
- 帶上這三個東西：
  - settings
  - extensions
  - keybindings
- 如果你要測預設體驗，就不要匯入，直接開新環境

## 3) 先開 Cascade，再決定要不要動手
- Mac：Cmd+L
- Windows / Linux：Ctrl+L
- 用 Cascade 處理跨檔案、跨測試、跨流程的任務
- 單檔小改動就用 inline edit 或 tab completion

## 4) 先選模式
### Chat mode
用在：
- 問問題
- 看 codebase
- 先規劃再改動

### Code mode
用在：
- 直接修改檔案
- 已經確認方向後的實作
- 需要 agent 真正執行的工作

## 5) 先保護 repo
在 private repo 開始用 Cascade 前，先建立 `.codeiumignore`
把這些排除掉：
- secrets
- generated files
- build artifacts
- 敏感文件
- 不該讓 agent 看到或改到的資料夾

## 6) 先叫它講計畫
在它動手前先問：
"先列出你預計會改的檔案、會跑的測試、以及你覺得最大的風險。"

## 7) 我自己的決策規則
- 1 個檔案內的改動：手動或 inline AI
- 2 個以上檔案：用 Cascade
- 還不確定：先 Chat mode
- 已經要交付：切 Code mode

## 8) 盯 usage
- 免費方案：適合學習和輕量使用
- Pro 以上：適合每天都靠 agent 幹活的人
- 遇到 tool-call 限制：把任務拆小，不要硬塞

## 9) 團隊 rollout
- 統一匯入來源
- 列出必裝 extensions
- 寫清楚 ignore 規則
- 定義哪些 agent edits 需要人工 review

## 10) 我的預設 prompt
"先檢查相關檔案，提出計畫，再做最小且安全的修改。如果有任何不清楚的地方，先問我，不要直接改。"

我不會把這份模板吹成什麼完整解法，但它是我真的會丟給 teammate 的版本。重點就是把流程固定下來：先安裝、再匯入、打開 Cascade、選對模式、先保護 repo、最後盯 usage。這樣用起來才不會像在跟一台情緒不穩的聊天機器人賭運氣。

如果要我一句話收尾，我會這樣講：Windsurf 真正有意思的地方，不是它會不會聊天，而是它把 IDE 編輯變成可控的 agent 工作流。這就是我會想留下來的原因。

來源致謝：我主要拆解的是 Tech Jacks Solutions 的 Windsurf 教學，並對照 Windsurf 官方站、VS Code、Cursor、Codeium 文件。上面的架構、案例和模板是我自己整理的，產品事實與引用內容來自原始來源。