Codex CLI vs Gemini CLI：省 Token 的 AI 輔助開發流程實測

Claude token 2 天燒完一週額度，是很多重度使用者的共同痛點。本文記錄一個解法：把「寫 code」這件事外包給 Codex CLI 或 Gemini CLI，Claude 只負責出架構與 review，大幅降低消耗。

工作流程設計

Claude（省著用）   →  出 spec + 介面定義 + edge cases
        ↓
Codex / Gemini CLI  →  實作（消耗 OpenAI / Google token）
        ↓
Claude              →  review git diff
        ↓
Codex / Gemini CLI  →  修正（resume 同一個 session）
        ↓
        loop...

Claude 最耗 token 的動作是讀大量程式碼、來回 debug。把這些移給其他 CLI 執行，Claude 只看 diff，理論上可將消耗壓到原本的 20~30%。

測試題目設計

為了公平比較，三語言各出一題，同樣的 prompt 分別餵給 Codex 和 Gemini：

• Python：實作 analyze_text(text) -> dict，回傳 word_count、char_count、sentence_count、most_common_word、avg_word_length，並寫 pytest 測試
• Rust：實作 merge_sorted<T: Ord> 雙指針合併，與 find_kth_largest min-heap，含 #[cfg(test)]
• Go：實作泛型 MergeSorted[T constraints.Ordered] 與 GroupBy[T any, K comparable]，搭配 table-driven tests

Codex CLI（gpt-5.4）實測結果

使用 codex exec --sandbox workspace-write 非互動模式執行。

Python — 一次通過

WORD_RE = re.compile(r"\b[\w']+\b")
SENTENCE_RE = re.compile(r"[.!?]+")

def analyze_text(text: str) -> dict:
    words = WORD_RE.findall(text.lower())
    ...
    avg_word_length = round(sum(len(w) for w in words) / word_count, 2)

3 個測試全部通過（3 passed in 0.02s），測試案例自行計算預期值寫進 assert，而非用 assert result is not None 敷衍。

Rust — 語法正確，用現代特性

pub fn merge_sorted<T: Ord + Clone>(a: &[T], b: &[T]) -> Vec<T>

亮點：使用 Rust 1.88+ 的 let-chains 語法：

if let Some(&Reverse(smallest)) = min_heap.peek() && num > smallest {
    min_heap.pop();
    min_heap.push(Reverse(num));
}

知道最新穩定特性，不只是寫能動的 code。

Go — 正確，自動提醒 import 路徑

使用 golang.org/x/exp/constraints，並主動提醒：

如果你想要 Go 1.21+ stdlib-only 版本，可以改用 cmp.Ordered。

Gemini CLI（2.5 Flash）實測結果

Python — 比 Codex 多一個 edge case

Gemini 多寫了第 4 個測試：純標點符號輸入（"!!!???..."），Codex 沒有測這個。

另一個差異：empty 時 most_common_word 回傳 None 而非 ""，語意更正確。

4 passed in 0.03s ✅

Rust — 更簡潔的 trait bound，測試更完整

pub fn merge_sorted<T: Ord>(a: &[T], b: &[T]) -> Vec<T>

Codex 加了 T: Clone，Gemini 直接用 T: Ord，對 Copy 型別（如 i32）完全正確，簽名更簡潔。

測試數量：11 個（vs Codex 的 5 個），還附上完整的 /// doc comments。

Go — 有一個邏輯 bug

// Gemini 的版本
if a[i] < b[j] {   // ← 應該是 <=

// Codex 的版本（正確）
if a[i] <= b[j] {

這個 bug 用 < 而非 <=，遇到重複元素時排序不穩定（stable sort 破壞）。編譯器不會報錯，只有 semantic review 才會發現——這正是 Claude review diff 環節存在的意義。

Codex vs Gemini 完整對比

Gemini CLI 速度問題排查

預設設定下，Gemini CLI 寫個程式會卡 60 秒以上。原因是：

1. selectedAuthType: "oauth-personal" — 走 Code Assist 端點
2. gemini-2.5-pro 免費配額極低，耗盡後 retry 4 次加 backoff

修法：

# 1. 取得免費 API Key
# https://aistudio.google.com/apikey

# 2. 加入 ~/.zshrc
export GEMINI_API_KEY="AIza..."

# 3. 改 ~/.gemini/settings.json
# "selectedAuthType": "oauth-personal"
# 改成
# "selectedAuthType": "gemini-api-key"

切換後 Flash 從 16 秒降到 7 秒，且不再遇到 429。

實務建議

首選組合（省錢優先）：

Claude  →  spec + review diff
Gemini 2.5 Flash  →  主要 coding（免費 1500 req/day）

首選組合（正確性優先）：

Claude  →  spec + review diff
Codex gpt-5.4  →  主要 coding（付費但 bug 率低）

無論選哪個，Claude review diff 這步不能省。Gemini 的 Go bug 就是典型案例——語法正確但邏輯錯誤，只有人工 review 才能抓到。這個工作流程的設計初衷，剛好讓 Claude 做它最擅長的事：高層次的正確性判斷，而非低層次的逐行寫 code。