工具演進文最常見的寫法是按時間軸列：「2021 Copilot」、「2023 ChatGPT」、「2024 Cursor」、「2025 Claude Code」。這種寫法看完你只記得時間點，不記得為什麼換。
每一代切換的真正驅動力是「上一代撞了什麼極限」。這篇是我個人的演進史，聚焦在每次切換的觸發事件——以及一個我認為現在大家最被低估的危險訊號：「無限自動沒有問題」這種想法。
我的演進路線
Stage 1：ChatGPT 複製貼上時代
最早是 ChatGPT 開個 tab，在 IDE 寫 code、卡住就切過去問、把回應複製回 IDE。
體驗很差。Context 永遠不夠——每次都要重新貼一次「我在做什麼專案」「我用什麼框架」「我這個檔案長什麼樣」。複製回去常常 indent 跑掉、import 漏寫、API 寫錯。每次切換都是一次 context switch。
Stage 2：Claude Code / Gemini / Codex CLI
換到 CLI 工具的觸發很單純：體驗差到不能忍。
Claude Code、Gemini CLI、Codex 三個我都試過。CLI 的好處是它住在我的工作環境裡——讀我的檔案、跑我的指令、回應我的 git history，不用每次重新給 context。
Stage 3：完全回到 Claude Code CLI 為主力
這個階段我主力收斂到 Claude Code CLI。原因兩個：
1. Multi-agent 工作流
Claude Code 的 sub-agent / parallel task 機制讓我能把一個複雜 task 拆成多個並行子任務。寫 code 時主 agent 寫，sub-agent 跑 test、查 docs、做 review。這個並行能力是其他工具當時做不到的（後來 Gemini / Codex 也跟上但體驗差）。
2. Code 精準度
Sonnet 4.5 到 4.6 這段我覺得是有史以來最穩定的一段。
社群有一陣子在討論「Claude 降智」——回應變差、判斷變懶、改 code 改不到點。我自己用下來反而覺得這段超級穩定。
我有一個假設：所謂「降智」會不會是一堆人在跟我做差不多的事情，把算力壓榨到 throttle？模型本身沒變，但 GPU 資源被分掉、token rate 被限速、長 context 的處理被降權——體感就是「變笨」，但根本原因是基礎設施跟不上需求成長。
這個假設沒辦法證實，但每次「降智」討論爆出來的時間點，剛好都跟 Claude Code 使用量爆炸的時間點高度吻合。
切換工具的真實成本
我自己感覺單純切換工具的成本不大——CLI 之間語法差不多、prompt 風格遷移得過去。
真正的成本是另一個東西：不同工具看到的問題不一樣。
同一段 code，Claude Code 看會 raise 一組問題、Gemini 看會 raise 另一組、Codex 看又是第三組。如果你三個輪流給意見，很容易掉進「改一改無限循環」的坑——
- Claude Code 說「這裡該抽 helper」→ 你抽
- Gemini 看新版說「這個 helper 沒必要，inline 就好」→ 你 inline
- Codex 看再新版說「inline 太多，該抽 helper」→ 你又抽
每個工具的意見都不算錯，但累加起來你在原地打轉。
找平衡的能力比工具切換重要。需要你自己有一條判斷線：什麼意見要採、什麼意見要忽略、什麼時候該收手。
不能完全 multi-agent 的原因
我看過很多人——尤其是 AI 重度使用者——在 push 一個方向：「無限自動就好，AI 自己跑、自己 review、自己 commit、自己 deploy」。
我不能完全 multi-agent 自動的原因很簡單：我自己的判斷力有限。
Multi-agent 跑出來的結果如果我看不懂、check 不出問題、判斷不出哪段該收哪段該擋——那 multi-agent 給我的不是 leverage，是定時炸彈。我會 commit 一堆我不知道對錯的 code 進 codebase。
「無限自動沒有問題」這個立場我覺得超級恐怖。
恐怖的點不是「AI 會出錯」——AI 出錯這件事所有人都知道。恐怖的點是「持有這個立場的人會在判斷力不足的情況下，把自動化推到他無法判斷對錯的範圍」。AI 出錯不是問題本身，人放棄判斷才是問題。
演進驅動力：每一代解前代什麼極限
把上面 stage 串起來看，每一代切換解的是上一代撞牆的具體問題：
| 從 | 撞了什麼極限 | 下一代解了什麼 |
|---|---|---|
| ChatGPT 複製貼上 | Context 重複給、IDE 切換成本 | CLI 工具住進工作環境 |
| Claude Code 1 / Gemini / Codex CLI | 複雜 task 還是一個 agent 在跑 | Multi-agent / parallel |
| Multi-agent | 模型本身的判斷品質 | Sonnet 4.5-4.6 級的精準度 |
| Sonnet 4.5-4.6 | （現在這代撞的牆）人放棄判斷導致無限自動失控 | ?? |
下一代解什麼？我不知道，但會不會是「auto」的反面——更主動的 human-in-the-loop 設計？把「人為 check」變成 first-class workflow，而不是現在這樣「自動跑、出事再回頭找原因」？
反思一句話
工具演進每一代解的是上一代的痛點，但解了一個痛點通常會開新的痛點。
從 ChatGPT 到 Claude Code CLI，工具變強，但人放棄判斷的傾向也變強。下一個世代不會是「更自動」，會是「在自動裡保留人的判斷位置」。
如果你看完這篇覺得「無限自動聽起來不錯」，那我希望這篇至少讓你停一下——你能判斷自動化跑出來的東西嗎？如果不能，自動化給你的不是效率，是不知道在哪裡爆的炸彈。