「為什麼押多工具 stack 不押單一」最常見的答案是「各自擅長不同領域」——Claude Code 擅長 X、Gemini 擅長 Y、Codex 擅長 Z。
這個 framing 我覺得不準。
我用 Claude Code + Gemini + Codex 一段時間了，真實理由不是「各自擅長領域」——三個工具其實都能完成大部分 task。真實理由是：AI 有個性跟品味，每個工具都有盲點，多工具 stack 的價值是讓它們互相 review 平衡盲點。
AI 有個性跟品味
寫 code 不只有「對與錯」，還有「品味」——
- 這個邏輯該抽 helper 還是 inline？
- 這個 type 該寫死還是用 generic？
- 這個 error 該丟 exception 還是 return Result？
- 這個 component 該拆還是合在一起？
這些問題沒有絕對答案，但每個 AI 都有自己的傾向。Claude Code、Gemini、Codex 寫同一段 code 會做不同的判斷——不是哪個對哪個錯，是各有各的品味。
OpenClaw 大紅那段時間，社群在推 Claude Code 的真實理由就是個性問題：
- ChatGPT 那時候會唬爛——編 API、編 import、編 type signature
- ChatGPT 的做事方式經常是「這個角度看沒問題、但整體可能會出事」——它會給你一個短期 work 的方案，但忽略長期維護成本
Claude 的個性比較收斂、比較會 push back、比較會問「這個真的該這樣做嗎」。所以社群推 Claude Code 不是因為它「擅長 coding」，是因為它的個性在 coding 場景比較不會踩雷。
但每個工具都有盲點
Claude Code 的個性也有它的盲點：
- 太謹慎、有時候會在邊界 case 上 over-engineer
- 對某些 framework / library 的熟悉度不如其他模型
- 輸出長度有時候會收斂過頭，把該講清楚的細節壓縮掉
Gemini 有 Gemini 的盲點。Codex 有 Codex 的盲點。沒有「最好的工具」這種東西——每個工具都會在某類任務上踩雷，差別只是踩雷的方向不同。
多工具 stack 真正的價值：互相 review
把多工具當成「不同個性的 reviewer」來用，工作流就會打開：
例 1：Claude Code 寫，Codex review 我用 Claude Code 寫完一個 feature，讓 Codex 走一遍 review + 導讀：「這段在做什麼？有什麼風險？跟既有 pattern 一致嗎？」Codex 會看到 Claude Code 沒看到的東西——可能是 typing 不夠精準、可能是 edge case 沒考慮、可能是命名習慣不一致。
例 2：反過來也是真的 有時候我用 Codex 寫，讓 Claude Code review。Claude Code 會 raise Codex 沒注意到的問題——通常是架構 / 維護性層面。
例 3：Gemini 補長 context 任務 Claude Code 跟 Codex 在「需要讀 50 個檔案才能判斷」這種長 context 任務上偶爾會吃力，Gemini 在這層有它的優勢。但 Gemini 寫完後我還是會丟給 Claude Code 做 final review。
關鍵：多工具不是並列做事，是互相 review 平衡盲點。
多工具的真實成本：cognitive overhead
多工具 stack 不是免費的。最大的成本不是錢，是 cognitive overhead——
- 改一改無限循環：Claude 說 A、Codex 說 B、Gemini 說 C，三個都不算錯但你會在原地打轉。需要你自己有一條判斷線決定收哪個意見。
- prompt 風格不一致：每個工具的 prompt 寫法略有不同，切換時要 mental switch。
- 結果整合：三個工具回的結果要 merge 進你最終的 commit，你要決定每段採誰的。
這個 overhead 不會自己消失。我自己處理 overhead 的方式是：主力定一個（Claude Code），其他工具當 reviewer / second opinion，不讓它們真的並行 owning task。
「單押 Claude Code 就夠」的人忽略了什麼
「Claude Code 一個工具就夠」這個立場有它的道理——cognitive overhead 確實是真實成本，單押一個工具能避免。
但這個立場忽略了：單押一個工具 = 接受那個工具所有的盲點。
如果 Claude Code 在某類任務踩雷你又沒 second opinion，那個雷會直接進你 codebase。多工具 stack 的本質是「我願意付 cognitive overhead 來換更廣的盲點覆蓋」——這是一個 trade-off，不是無腦的「更多工具更好」。
每個人的 trade-off 點不一樣。如果你日常 task 大多是 Claude Code 擅長的領域、且踩雷成本你接得住，單押是合理的。但只要你開始碰陌生 framework / 高複雜度系統 / 長期維護的 code，多工具 stack 的 second opinion 價值會浮現。
真正最難的地方
寫到這裡其實有個比工具選型更難的問題。
我能用 Claude Code 寫、用 Codex review、用 Gemini 處理長 context——前提是我已經懂這些工具產出的東西。我看得懂 Codex 的 review 是不是有道理、看得出 Gemini 的長 context 結論有沒有偏、判斷得出 Claude Code 的方案要不要採。
但怎麼用這種多工具 stack 去學會我不會的東西？這個我還在摸。
具體 case：我要寫一個我完全不熟的 framework 的 code，三個工具都能寫出來——但因為我不熟，我看不出哪個寫得對。這時候多工具 stack 不能幫我，因為「互相 review」需要我自己有最低判斷力，工具回的東西我看不懂的話，互相 review 變成三個盲人摸象。
這個問題沒有 elegant 解法。我目前的做法是：先靠工具產出 + 跑起來驗證 + 寫 test 確認行為 + 慢慢回頭學原理——但效率比「先學原理再用工具」差。
如果你解決過這個問題，我很想聽。
反思一句話
多工具 stack 不是「各自擅長」，是「互相 review 補盲點」。
但這個架構建立在你有足夠判斷力分辨工具回的東西對不對這個前提上。判斷力不夠的話，多工具 stack 不是平衡，是迷宮。
這個 trade-off 沒有正確答案——只有「你願意付多少 cognitive overhead 換多廣的盲點覆蓋」這個個人 calibration。