VS Code / JetBrains 用了多年，最近半年裡，越來越多實際改動其實是發生在 Cursor 的 Composer、Claude Code 的終端對話與 Windsurf 的 Cascade 之中。「游標停在哪一行」已經不是主要操作單位，檔案樹也不再是主要導航。本文不寫業界新聞，只談 AI 工具如何改變開發者每天真實的動作：輸入方式、回饋迴路、並行度，以及這些變化如何把瓶頸推回到本地 Mac。最後給出一份 六步把工作流升級為 AI 原生 的清單，並解釋為何下一步是把高效能 Mac 當作 可獨佔、可 SSH 接入的運算節點。
放棄傳統 IDE 並非因為編輯器不好用，而是原本以「敲程式碼 + 自動補全」為核心的動作，在 AI 介入研發後越來越拖慢節奏。下列六個徵兆幾乎每天都發生，若已中三條以上，基本上就是工作流要換的信號，而不是再多裝幾個外掛。
跨檔案改動仍在「逐個分頁打開」：修一個 API 重命名，要手動跳轉五個檔案：路由、服務、測試、文件，逐一對照與回寫。
每次跑指令都要切視窗：測試、遷移、部署的入口分散在多個終端分頁，把錯誤訊息複製回 IDE 對話框已成肌肉記憶。
等建置時只能乾等：測試要跑六分鐘，沒辦法切到下一個任務，因為「同時跑兩個改動」會弄亂本地狀態。
失敗只能靠自己察覺：建置掛了、測試紅了，你得切到終端看日誌、複製堆疊，再回 IDE 請 AI 解讀。
架構級改動不敢交給 AI：只有「目前打開的檔案」進到上下文，AI 修了一處往往會破另一處。
風扇先撐不住：開著 IDE Agent、跑著本地推理，再來一個 Webpack——MacBook 噪音拉滿，輸入開始掉影格。
這六個徵兆有同一個根因：傳統 IDE 的核心抽象是「檔案 + 游標 + 自動補全」，而 AI 原生工作流的核心抽象已變成「任務 + 上下文 + 並行 Agent」。在舊抽象上繼續堆外掛，邊際效率越來越低。後面六節，每節對應工作流中被替換掉的一個動作。
回想最近一次跨檔案重構。在傳統 IDE 裡，你要先想好「先改哪個檔案、要改成什麼樣、要不要先建分支」，動作單位是一行一行往裡寫。現在情境換了：在 Cursor 的 Composer 裡，你把目標寫成一句話——「把 session 驗證換成 JWT，並更新所有呼叫點與測試」——它會讀取相關檔案、提出改動計畫、一次寫完八個檔案並跑測試，你的工作是審閱 diff 與最終行為。
同樣的事情發生在 Windsurf 的 Cascade：Cascade 在背景沿著任務推進，你不用每一步都按「核准」，更像收到一位同事「我已做了 A、B、C，你來檢查」的回報。差別在於注意力的對象——以前盯游標，現在盯產出。這也意味著你在 IDE 上花的時間被重新切分：少量時間打字，多數時間在讀 diff 與跑驗證。
「游標」不再是工作流的基本單位，「任務」才是。IDE 的價值從「讓你寫得更快」轉為「讓你審得更準」。
這也說明了為何離開傳統 IDE 幾週再回去會覺得「卡」——不是按鍵延遲，而是每次只能改一個檔、每次只能問一個問題的迴路本來就太短，而 AI 已能跨檔案、跨步驟一次走完。
第二個顯著變化：越來越多實際工作發生在終端機裡，而不是 IDE 裡。測試失敗的修復、資料庫遷移、相依升級、CI 流水線排錯、容器建置——這些動作本來就在命令列。過去 IDE 提供的「整合終端」其實是把命令列塞進編輯器。現在反過來：終端機原生的 Agent 才是入口。
具體情境：在 Claude Code 裡輸入「把這次 CI 紅掉的測試全部修好，跑通後給我看一下改動」，它會讀整個 repo、定位失敗、改程式碼、跑測試、迭代到綠，最後回報結果——全程不離開終端機。Codex CLI 在遷移類任務上同樣是這個模式：請它把 ORM 從 v1 升級到 v2，它會掃描呼叫點、產出 patch、本地跑一次自檢。共同特徵是「讀全 repo → 規劃 → 執行 → 驗證」，把人從複製貼上錯誤訊息的工作裡解放出來。
| 工作方式 | 主操作單位 | 適合情境 | 對運算壓力 |
|---|---|---|---|
| 傳統 IDE + 補全 | 游標 / 單一檔案 | 小改動、閱讀程式碼、UI 微調 | 低；偶發 CPU 高峰 |
| AI 原生 IDE（Cursor / Windsurf） | 任務 / 多檔案 diff | 跨檔案重構、完整功能實作 | 中；上下文索引常駐記憶體 |
| 終端機原生 Agent（Claude Code / Codex CLI） | 自然語言指令 | 測試、遷移、部署、CI 修復 | 中高；長對話 + 工具呼叫持續占用 |
| 多 Agent 編排器（Verun / mcode） | 任務佇列 + worktree | 同時推進多條研發線 | 高；多行程並發 + 連接埠占用 |
由上而下讀這張表會發現一個明確趨勢：越往下，運算壓力越大。這也是後面反覆回到的主題——工作流變了，硬體需求也隨之改變。
真正讓工作流被徹底改造的是並行。在傳統 IDE 裡，同時跑兩個改動幾乎不可能：狀態衝突、連接埠衝突、測試互相干擾。新的做法是給每個任務一份獨立的 git worktree 與一組獨立連接埠，由編排器負責協調。
情境一：用 Verun 起三個任務——「處理 PR 評論」、「升級相依」、「修 CI 紅掉的測試」——每個任務自動拿到一個分支名（例如 sleepy-capybara-472）、獨立 worktree 與單獨的 dev server 連接埠；生命週期 hook 自動複製 .env、安裝相依、啟動服務，三個 Agent 互不干擾。情境二：用 mcode 的平鋪檢視同時盯五個 Claude Code 對話，外加一個 task 佇列把後續指令排到空閒對話；建置失敗透過 hook 直接在狀態列彈出。
# 每個 Agent 自帶獨立 worktree 與連接埠（基本概念示意） git worktree add ../app-pr-review feature/pr-review-fix git worktree add ../app-deps-bump chore/deps-2026q2 git worktree add ../app-ci-green fix/ci-flaky-tests # 編排器自動注入 .env 並依任務分配連接埠（示意） verun start ../app-pr-review --port 5174 --agent claude-code verun start ../app-deps-bump --port 5175 --agent codex verun start ../app-ci-green --port 5176 --agent claude-code # Hook：建置失敗時讓 Agent 自行讀日誌、提出修補 claude-code hook on-build-fail "explain failure, propose patch, do not commit"
事件驅動是另一半。Hook 讓 Agent 不必等你回頭看日誌：測試一紅，Agent 自己讀錯誤、提出修補、等你按「執行」。這意味著「等 Agent」與「自己做事」終於可以並行——你在另一個 worktree 做審核，被監聽的 Agent 在第一個 worktree 準備好補丁。
提示：並行 Agent 的設計原則是「任何共享狀態都要隔離」：worktree 隔離檔案、連接埠範圍隔離服務、獨立快取目錄隔離 node_modules / DerivedData，否則三個任務最終會變成一條序列佇列。
注意：並發越高，本地 Mac 的記憶體與磁碟瓶頸越快暴露；下一節會把這件事展開。
最後一個被替換掉的動作是「打開很多分頁來記住程式碼放在哪」。當 Agent 一次把整個 repo 的結構讀進上下文再做架構級改動，「跳到定義、回到呼叫點、切換面板」這整套傳統導航方式就被壓到次要位置。Claude Code 在做大型重構時就是這樣：先掃 repo、畫出相依、再決定從哪改起，而非依你打開檔案的順序推進。
但這套「整個 repo 在腦中」的能力是有物理代價的：每一個長對話都意味著上下文索引常駐記憶體；每一次本地推理都意味著大模型權重佔用統一記憶體；每一次並行 Agent 都意味著多份 Node / Bun / Python 行程同時跑。下面這些數字解釋了「為何 Mac 突然不夠用」：
換言之，AI 原生工作流的第一性瓶頸，正從「人打字的速度」遷移到「硬體能並行多少 Agent」。這不是再換一條記憶體能解決的——MacBook Pro 的統一記憶體出廠即固定，外接 SSD 只能緩解 DerivedData，緩解不了模型權重。
以下這套順序，是從「傳統 IDE + 外掛」真正切換到「AI 原生 + 多 Agent」的最短路徑。並非一次把六件事全做完，而是依序逐步替換，每一步都對應前文被替換掉的某個動作。
把「補全」降級為輔助：跨檔案改動改用 Cursor 的 Composer 或 Windsurf 的 Cascade；自動補全保留，但不再是主要輸入方式。
把測試 / 遷移 / 部署搬到終端機 Agent：在 Claude Code 或 Codex CLI 裡用一句話替代「打開 IDE → 找指令 → 跑 → 複製錯誤」的舊迴路；CI 排錯同樣下放到終端機。
每個並行任務一份獨立 worktree：用 git worktree + Verun / mcode 這類編排器，做到連接埠、檔案、快取三層隔離；不再容忍「為了不衝突只能序列」。
接 Hook 讓 Agent 自行監聽：建置失敗、測試失敗、長任務結束都走事件觸發，由 Agent 先反應，你只看結果。
把架構級改動交給大上下文 Agent：跨模組重構先讓 Agent 整個 repo 讀完再動手，停止用「打開多少分頁」做導航。
重新計算本地硬體帳：把 IDE Agent + 終端機 Agent + 本地推理 + 建置任務的同時記憶體佔用與並發量相加，看本地 Mac 是否仍裝得下；裝不下時，將高效能 Mac 當作可獨佔、可 SSH 接入的運算節點納入工作流，本機只保留編輯與輕量任務。
把這六步走完，再回看「傳統 IDE + 外掛」這種方式，就能清楚看到它的真實侷限：補全心智與並行任務在搶同一份注意力，無法升級；本地 MacBook 在並行 Agent + 本地推理疊加下風扇拉滿、記憶體吃緊，硬體天花板出廠就鎖死；外掛式安全審查也跟不上 AI 自行發起的工具呼叫，權限邊界難以收斂。對於希望AI 原生工作流跑得穩、又不想每年換一台頂規 MacBook 的開發者，把高效能 Mac 推到雲端獨佔節點上、以 SSH 為主線接入，NodeMini 的 Mac Mini 雲端租賃通常是更優解：與 秒級開通與 API 化算力、SSH 長對話與常駐 AI Agent、多地區 M5 節點 等場景一一對應；規格與計費請見雲端租賃價格說明，SSH 接入細節請見幫助中心。
不必。按情境挑選即可：跨檔案改動交給 Cursor Composer 或 Windsurf Cascade；測試、遷移、部署、CI 排錯交給 Claude Code 或 Codex CLI；架構級重構由 Claude Code 主導，並行任務交給 Verun / mcode 這類編排器。三者是分工關係，不是替代關係。
IDE Agent、終端 Agent、本地推理與建置同時常駐時，48GB 統一記憶體會先出現 swap 與節流，輸入延遲最先被察覺。可行做法是把高效能 Mac 當作獨佔運算節點，以 SSH 接入，本機只負責編輯與輕量任務；規格與計費可參考 雲端租賃價格說明。
以 SSH 為主線時，絕大多數終端 Agent、建置與測試對延遲並不敏感；只有少量需要圖形介面的偵錯場景才需要 VNC。接入方式與節點選擇請見 幫助中心 與 SSH vs VNC 決策清單。