沒有人在白板上畫過的 AI 寫程式工作流：Cursor、Claude Code、Codex 已經合體

這個禮拜在開發者 Twitter 與 Hacker News 被轉最多次的一篇文章，是 The New Stack 那篇〈Cursor、Claude Code、Codex 正在合併成一套沒人規劃過的 AI 寫程式工作流〉。標題很聳動，底下的觀察很精準。2026 年 4 月第一週，Cursor 3（代號 Glass）推出全新 Agents Window 介面用來統籌平行代理人；OpenAI 釋出 codex-plugin-cc，可直接安裝在 Anthropic Claude Code 內部；早期採用者開始把三套工具一起跑。到了 5 月，IBM Bob 突破八萬開發者並宣稱 45% 生產力提升，GitHub Copilot 也全面改成使用量計費。「哪一套 AI 工具會贏」這個問題已經過時了，2026 年的真正關鍵字是「分層工具」。

一、這個 stack 的形狀

實務上「composable（可組合）」是這樣運作的：Cursor 在最上層當編輯器與平行代理人指揮中心；Claude Code 在側邊終端機執行需要長上下文的架構級工作；Codex（或 OpenAI 插件）處理大量重複的轉換型任務。沒有一個工具想吃下整條工作流，開發者也明確選擇不要標準化到單一工具。這跟 2018 年的 JS bundler 棧（webpack + Babel + ESLint + Prettier）、2021 年的資料棧（dbt + Airflow + Snowflake + Looker）發展軌跡一模一樣。這是穩定均衡，不是過渡期。

二、為什麼「70% 的開發者都在用」是個被過度引用的數字

是的，2026 年超過七成開發者表示正在使用 AI 編碼助手。但真正該看的指標不是這個，而是「每個開發者用幾套工具」。在生產力曲線高端，答案是 2 到 3 套，不是 1 套。拉開距離的團隊：編輯器裡跑一個自動補全模型、重構時切到 agent 模式模型、設計審查時換到長上下文模型——並且會根據任務類型直接換廠商。被綁死在單一 AI 助手，反而成了 2026 年最大的生產力瓶頸。

三、經濟模型的轉變：使用量計費正式進場

GitHub 在 5 月 3 日把 Copilot 從「每席次計費」改為「使用量計費」是新聞頭條。但結構性意義更值得看：當模型在「每 token 投入產出比」上正面競爭，那些拿不出更好上下文管理或更少重試次數的廠商，定價會被市場快速重新校正。Anthropic Claude 系列與 OpenAI Codex agents 都正在往「不買席次、買產出」的方向收斂，採購決策也從 IT 採購流程下放到工程經理手上。

四、對外包工作室與接案者意味著什麼

三個短期實作影響。第一，你的時薪要站得住，必須讓自己的 AI 工具棧至少不輸客戶內部工程師的工具棧——客戶現在會直接比較速度。第二，在交付筆記裡明確標示「這段是 agent 寫的」「這段是哪個模型輔助」——2026 年這是合理的工作說明，不是自白書。第三，做估價時要從「幾人時」改成「幾 agent 時 + 幾人時審查」，而後者才是決定品質的數字。

五、與 AEO/GEO 的交叉路口

一個被忽略的副作用：AI 編碼工具正在加速 AEO/GEO 的內容工程工作。AEO 顧問建議的 /ai-summary/ 路由、FAQ schema 注入、JSON-LD 結構化資料生成——全部都是 Codex 等級代理人的標準作業。採用 composable AI 棧的工程團隊，會「順便」變成 AEO/GEO 團隊，因為產出 AI 可讀內容的邊際成本已逼近零。這是新聞底下，比較安靜但正在加速的次級趨勢。

我的觀點

早期的炒作是「一個 AI 工具會吃掉工程師的工作」。2026 年的現實更有趣，也更刺：少數工程師——每個人手上跑著三到四套被精細調校過的 AI 工具——正在吃掉中型工程團隊的工作。差距不是工具本身，工具誰都能訂閱；差距是「指揮」——知道什麼問題該丟給哪個模型、什麼時候該把任務切成兩半並行、什麼時候該整段放棄 agent 的草稿。這套指揮力是 2026 年資深工程師的新核心能力，而且是可教的。今年認真把這套能力訓練起來的團隊，到第四季速度會完全不同。等待「最終勝出 AI 工具」的團隊，會輸掉整個 2026 年。