TL;DR：這一兩年 AI 寫 code 的重心，悄悄從嵌在編輯器裡的補全，搬回了終端機（Claude Code、Codex CLI 那一類）。我覺得這不是復古情懷。編輯器整套設計是繞著「鍵盤前的那個人」轉的；終端機是繞著「你不會盯著看的 process」轉的。當 AI 從「幫我打下一行」變成「替我把這件事做完」，它就搬回了那個本來就為自動 process 而生的地方——pipe、背景執行、log、exit code，這些終端機早就有了。

前陣子我才意識到，自己已經很少在編輯器裡按 Tab 接受補全了。大部分時間是開著一個終端機，丟一句話給 agent，然後去做別的事，回頭看它寫了什麼、跑了沒。

一開始我沒多想，就當是換了個順手的工具。但這陣子越用越覺得，搬回終端機這件事好像不只是工具偏好，底下有個更基本的形狀在那。

編輯器是為「打字的人」設計的

你想想 IDE 的設計中心是什麼。是游標。

補全跳在游標旁邊，diff 標在 gutter 上，你即時 accept 或 reject。整套體驗都繞著「一個人正在編輯、即時收到建議」這件事轉。對「AI 幫我打字」這個任務，這個設計剛剛好——互動的單位是一個小建議，小到你掃一眼就能隨手接受，視線幾乎不用離開那一行。

2021、2022 年那一代的 Copilot 就是長這樣，它本質上是一個很聰明的自動補全。嵌在編輯器裡是對的，因為它做的事，就是編輯器最擅長的事。

但 agent 不是「打字」這個尺寸的東西

你叫 agent「幫付款模組加上合理的錯誤處理」，它得先讀十幾個相關檔案、摸清架構、提一批改動、跑一下測試、看結果不對再改。這一跑就是好幾分鐘。

互動的單位變了。不再是「一個建議」，是「一個任務」。而任務想要的東西，跟建議想要的幾乎沒有交集：它想被丟到背景去跑、想留下一份 log 讓你事後翻、想一次開好幾個平行做、跑完給你一個乾淨的結果，最好還有個明確的成功或失敗。

這些需求列出來，你會發現有點眼熟。

因為終端機做這件事做了五十年

pipe、重導向、exit code、背景執行、&、nohup、tmux——終端機天生就是拿來跑「你不會一直盯著的 process」的地方。它整個抽象就建立在這個前提上。

agent 剛好就是這種 process。所以 Claude Code、Codex CLI、Aider 會長成終端機程式、而不是 IDE 外掛，我覺得是回到了本來就為這種工作而生的地方，跟復古沒什麼關係。

真正的槓桿是 composability。在終端機裡，一個 coding agent 就只是一個 process：你可以 git worktree 開三份工作目錄、平行跑三個 agent 各做一塊；可以把它的輸出 pipe 給別的工具；可以包進 shell script、丟進 CI、半夜自己跑；全程都有 log 可以回頭看。在編輯器裡，agent 是關在那個 IDE 事件迴圈裡的客人，能做的事被框死在「外掛被允許的範圍」內，不是一個你能自由擺弄的公民。

（這跟我之前寫 dynamic workflows 那篇 是同一件事的延伸：當 orchestration 本身變成一段可以被 script、被存起來重跑的 code，你需要的就不是一個更聰明的面板，是一個能跑 process 的地方。）

那 IDE 就沒用了嗎？才不是

這篇要是寫成「終端機完勝」就太偷懶，也不是事實。

IDE 還是有它真的贏的地方。最明顯的是看 diff——並排、點一下跳到定義，比在 pager 裡捲一份 unified diff 舒服太多。導航那一整套（LSP、跳定義、找 reference）你 review agent 改了什麼的時候天天在用。至於新手怎麼上手、怎麼隨手接受一個小修改，那本來就是編輯器的主場，沒什麼好爭的。

所以實際上多數人不是二選一，是兩個一起開：終端機那邊派任務，IDE 這邊讀程式碼、看 agent 改了什麼。與其說誰取代誰，比較像是「變成 process 的那一半」搬去了終端機，「還是鍵盤尺寸的那一半」留在編輯器。

看工具自己往哪邊長

最能說明方向的，其實不是我講什麼，是工具自己在往哪裡長。

連 Cursor 這種 IDE 出身、做得很好的工具，後來也加了 agent mode、background agent。它的 background agent 甚至是開一台雲端機器自己跑、在一條分支上做完、丟一個 PR 回來——你要的話，這比本機的 process 還更「不用盯著」，而且正是 IDE 在伸手去抓這篇講的那個形狀。另一邊，Terminal-Bench 那個榜的前段，清一色是終端機型的 agent（自己寫的 harness 跟 Codex CLI、Claude Code 那類 CLI 工具都在上面），IDE 出身的工具一個都沒擠進去。

（老實說這個榜也不能說死——它量到的比較是底下那顆模型，不全是 harness 在不在終端機；CLI 工具排前面，一部分是因為它們配的是前沿模型。榜上能看出來的是「終端機型的工具站得上去」，不等於「因為在終端機所以才贏」。）

當對立的兩邊開始長出對方的形狀，底下通常是有個真的東西在拉。我猜那個東西就是上面講的：寫 code 這件事，有一塊從「打字」變成了「派工作」。

下次開新任務的時候

我不會假裝這題有標準答案，工具還在動，半年後長怎樣我也說不準。但如果你最近也隱約覺得，自己越來越常對著一個終端機講話、越來越少在編輯器裡點接受，那大概不是錯覺。

下次開一個新任務的時候，你可以順手留意一下：你是在「打字」，還是在「派一件工作出去」？如果是後者，終端機那邊本來就比較順手——它等這種工作，等很久了。

延伸閱讀：

English version：Why coding agents are moving back to the terminal