前一篇 講「為什麼押多工具 stack 不押單一」——立場層的東西。這篇接著講具體分配：三個工具我各自拿來做什麼。
很多多工具 stack 的文章寫得很抽象——「Claude Code 擅長 X、Gemini 擅長 Y」這種泛泛比較，看完不知道實際工作流是什麼樣。我這篇直接給我自己的分配：實際 task、實際情境。
Claude Code：日常 dev 主力
90% 的 coding work 在 Claude Code。
典型 task：
- 部落格架構調整（這個 quartz-blog 的目錄結構、Wave 規劃、ROADMAP 整理都是 Claude Code 跑的）
- 舊專案重構（OpenClaw 那邊 skill / subagent / MCP server 的維護）
- 從零寫新 feature
- 跨多檔的重構
為什麼是主力：
- Multi-agent / sub-agent 機制成熟，複雜 task 能拆
- 對 codebase context 抓得準，不用每次重新給
- 「one-shot」品質高——好的 prompt 一次到位，不太需要反覆 iterate
- CLI 環境住進工作目錄，看得到我的 git history、能跑 test、能改檔
不會用 Claude Code 的時刻：圖片相關的東西。即使 Claude 有 vision，產圖不是它的強項。
Gemini：產圖主力
Gemini 在我的 stack 裡角色很單純——圖。
典型 task：
- Blog 文章的 cover image / OG image 生成
- 配圖類視覺素材
- （偶爾）長 context 的批次處理，但這個用得不多
為什麼是 Gemini 不是 Claude / OpenAI：
我用 Gemini 主要是因為它產圖品質跟成本對我這種低頻使用 case 比較合。Claude 的 image gen 還沒到我滿意的程度，OpenAI DALL-E 我有用過但 workflow 比較笨重。Gemini 在「給個 prompt 拿一張圖」這個粒度做得乾淨。
不會用 Gemini 寫 code 的原因：可以但沒必要——主力工具用熟了，臨時切過去 cognitive overhead 比 leverage 高。
Codex：跨 model review 用
Codex 在我的 stack 裡角色最特殊——它是給我看「別的 model 做的東西」用的。
典型 task：
- 我自己的 ClawdBot（OpenClaw 子專案）後端用的是 ChatGPT 系列 model，當這個 model 寫的東西要 review 時，用 Codex 比較順手——因為它跟 ChatGPT 是同一家，比較知道對方的盲點
- 偶爾用 Codex 做 second-opinion review（Claude Code 寫完 → Codex 看一遍）
這個用法的本質：
不是「Codex 比較強」——是「不同 model 看到的問題不一樣」。當我已經有 model A 的輸出，想要 model B 的觀點來補盲點，Codex 是比較好的 second opinion 來源。
跟 #03 multi-tool stack 講的「互相 review」是同一條邏輯，但 Codex 在我這套 stack 裡的位置就是這個 reviewer 角色，不是主要產出者。
三個工具的不可替代時刻
| 任務 | 主力 | 替代成本 |
|---|---|---|
| 寫 code（任何專案） | Claude Code | 切到別的工具會慢、會踩 rate limit / context loss |
| 生成 cover / OG image | Gemini | Claude / OpenAI 可以但 workflow 變笨 |
| Review ChatGPT 系 model 的輸出 | Codex | Claude review 也行但少了「同家 model 視角」的盲點掃描 |
每個工具在我的 stack 裡都有它「不能被簡單替代」的時刻。如果我硬要單押一個，會付出意外的成本——例如 Claude Code 產圖體驗變差、ChatGPT 系 model 的 review 視角缺一塊。
Cognitive overhead 怎麼處理
多工具最大的成本不是訂閱費，是每次切換要 mental switch。我的處理方式：
主力 / 副位 mental model
- Claude Code 是「住在那邊」的工具——預設打開、預設用它
- Gemini 跟 Codex 是「需要時叫出來」的工具——有特定 trigger 才開（產圖 trigger / review trigger）
這樣切換的場合都是有意識的——不會在「該用 Claude Code 寫 code」時手滑切到 Gemini，也不會在「該產圖」時硬要 Claude Code 處理。
避免「無限循環」
#03 提過——多工具最容易掉的坑是 Claude 說 A、Codex 說 B、Gemini 說 C 三個都不算錯但你在原地打轉。
我處理這個的辦法：Codex 的 review 意見當「參考」不當「指令」。我不會因為 Codex 說「這裡該抽 helper」就無腦改——我會評估「Claude Code 原本的判斷 vs Codex 的意見」，自己選一個，不來回擺盪。
反思一句話
多工具 stack 的價值不在「工具種類多」，在「每個工具被用在最 fit 的地方」。
如果你的 stack 是「三個工具我每天輪流問同樣的問題看誰回得最好」——那不是 multi-tool stack，是 cognitive overhead disaster。
我的 stack 之所以能 work，是因為每個工具的角色明確：Claude Code 是 dev、Gemini 是圖、Codex 是 reviewer。這三個角色不衝突、不重疊太多——這才是讓多工具能持續 sustain 的關鍵。