AI Coding 工具不是三代淘汰：從補全、IDE Agent 到 CLI 與 Cloud Agent
本篇是「AI Coding CLI 觀察筆記」系列的第 2 / 3 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
我以前會把 AI Coding 工具分成三代：Copilot 補字、IDE Chat 給 diff、CLI agent 直接做完。這個分類很好懂，但到了 2026 年已經不夠準確。
GitHub Copilot 現在有完整 CLI 和 coding agent；Cursor 也能在 terminal 執行 agent；Claude Code 與 Codex 同時存在於 CLI、IDE、Desktop 和 Cloud。後來的介面沒有消滅前面的介面，而是把同一個 agent loop 放到不同執行環境。
真正的演化不是「大家最後都跑去 terminal」，而是 AI 從產生文字，走到能取得 context、採取行動、驗證結果。
這是系列第 2 篇。上一篇介紹 Grok Build 的 Plan Mode、相容性與 early beta 邊界。
起點：inline completion 把等待變成預測
GitHub Copilot 在 2021 年公開 technical preview時，最有代表性的體驗是 inline completion：你在 IDE 裡打字，它根據目前檔案和游標附近內容預測下一段程式。
這個模式的分工很清楚：
- 人決定要編輯哪個檔案；
- 人把問題拆成函式或片段；
- AI 提供候選內容；
- 人逐段接受或拒絕；
- 人負責執行與驗證。
它很適合樣板、重複片段與熟悉 API 的補全。它沒有消失，因為「我知道要寫什麼，只想少打一些字」至今仍是高頻需求。
下一步：Chat 與 IDE Agent 擴大 context 和 action
接著，Cursor、Continue、GitHub Copilot Chat 與其他 IDE 工具把自然語言對話放進編輯器。AI 不只看游標附近，也能讀多個檔案、理解錯誤訊息、產生跨檔 diff。
早期 IDE Chat 多半停在「建議—套用」；現在的 IDE Agent 已能呼叫 terminal、跑測試、搜尋整個 repo，甚至把任務交給 cloud agent。把它們一律描述成「只能給建議、不能做事」已經過時。
IDE 的持續優勢是視覺 context：
- 目前選取範圍；
- type error 和 diagnostics；
- definition、reference 與 symbol；
- inline diff；
- breakpoint 和測試 UI。
當任務需要人持續看著程式、逐段調整，IDE 仍然比純 terminal 更自然。
Agentic 的關鍵：把執行迴圈交給工具
Claude Code 官方把 agentic loop 拆成三段：gather context、take action、verify results。這個模型比「第幾代工具」更有用。
以「修好登入測試」為例：
- 找出測試與實作位置；
- 執行測試取得真正錯誤；
- 讀取相關程式和 repo instructions；
- 提出或確認修改計畫；
- 編輯程式；
- 再跑測試；
- 失敗就回到前面，成功才回報。
Autocomplete 只參與第 5 步。Agent 則被允許推動整個迴圈，但人仍要決定它能讀什麼、寫什麼、是否能連網，以及什麼才算完成。
「Agentic」不是 AI 變得不用管，而是 action 和 iteration 的責任重新分配。
為什麼 terminal 仍然重要
CLI 沒有成為唯一答案，但它確實解決幾個 IDE 不容易單獨處理的問題。
1. 它靠近真正的執行環境
Build、test、git、Docker、資料庫 migration 和雲端 CLI 原本就在 shell。Local coding agent 可以直接使用 repo 現有工具，不必為每一個動作設計新的 UI。
這同時也是風險：agent 看到的 credentials、Docker socket、SSH agent 和家目錄，可能比你以為的更多。Terminal-native 不等於安全；權限、沙箱和隔離環境反而更重要。
2. 它容易被 script 化
幾個目前常見的非互動入口：
claude -p "Review the current diff"
codex exec "Review the current diff"
grok -p "Review the current diff"GitHub Copilot CLI 與 Cursor CLI 也提供 terminal agent 和 programmatic workflow。這表示「可組合」已從少數 CLI 的賣點，逐漸變成 coding agent 的基本能力。
自動化時不能只把 prompt 塞進 CI。還要固定工作目錄、輸出格式、timeout、權限、secrets 和失敗策略，否則只是把互動時的不確定性搬進 pipeline。
3. 它適合遠端與沒有 GUI 的環境
SSH、dev container、CI runner 和臨時 VM 不一定有完整 IDE。CLI 可以在相同 shell 裡讀 log、跑指令和查看 diff，對基礎設施與後端除錯很方便。
但若任務需要長時間執行，cloud agent 往往比自己維護 tmux session 更穩定。介面選擇應從「程式在哪裡執行」開始，而不是從個人 CLI 偏好開始。
Cloud Agent 又改變了什麼
Local agent 使用你電腦的 repo、工具和 credentials；cloud agent 則在供應商管理的環境裡 checkout repo、執行任務，再交付 diff 或 PR。
Cloud 的優點：
- 斷線後仍能繼續；
- 容易同時跑多個任務；
- 執行環境較容易重建；
- 適合 issue 到 PR 的非同步工作。
代價則是環境重現：private dependency、內網服務、測試資料和 secrets 都要重新配置。Local 能跑，不代表 cloud 也能跑。
Claude Code、Codex、GitHub Copilot 等工具現在都跨越多個 surface。官方產品也不再把 CLI 當唯一終點，而是讓 session、project instructions 與任務能在 terminal、IDE、Desktop、Web 或 Cloud 之間移動。
不要再用「三代」選工具，改看五個軸
| 問題 | 你真正要決定的事 |
|---|---|
| Context 從哪裡來？ | 游標、選取檔案、整個 repo、issue、PR、外部 MCP |
| Action 在哪裡執行？ | 本機、container、cloud VM、CI runner |
| 自主程度多高？ | 每步批准、先審 plan、允許工作區寫入、完全自動 |
| 如何驗證？ | diagnostics、測試、build、review、人工驗收 |
| 結果如何交付？ | inline completion、diff、commit、PR、結構化輸出 |
同一個人可能在一天內使用三種模式：
- 寫熟悉的函式時用 inline completion；
- debug 型別錯誤時用 IDE agent；
- 執行跨檔 migration 時用 local CLI；
- 把獨立 issue 交給 cloud agent；
- 最後再用另一個 agent review diff。
這些不是互斥世代，而是不同粒度的控制面。
從「寫 code」到「設計可驗證的任務」
工具越能自主執行，人越需要把需求寫得可驗證。好的任務至少包含：
- Goal：要改變什麼行為；
- Context：哪些檔案、錯誤、issue 或文件重要；
- Constraints：不能改什麼、權限到哪裡；
- Done when：哪些測試、輸出或人工驗收代表完成。
這四項也是 Codex 官方 best practices 建議的 prompt 結構。它們不只適用 Codex，放在任何 coding agent 上都能降低猜測。
AI Coding 的演化沒有把工程師變成只會按批准的人。它把工程師的重心往前移：先定義邊界與證據，再讓 agent 跑迴圈，最後根據 diff 和驗證結果做決定。
下一篇不再比固定模型名稱或月費，而是用這五個軸比較 Claude Code、Codex 與 Grok Build。
上一篇：Grok Build CLI 是什麼？ · 下一篇：Claude Code、Codex、Grok Build 怎麼選？
