顯示具有 Codex 標籤的文章。 顯示所有文章
顯示具有 Codex 標籤的文章。 顯示所有文章

為什麼 Gemini 寫程式總被嫌?拆開來看,問題根本不在模型

先講一個讓我卡很久的矛盾。

如果你只看 benchmark,Gemini 3.1 Pro 在 SWE-bench Verified 上一度衝到 80.6%、登上榜首,把同期的 Claude 和 Codex 壓在下面,而且還是這群前沿模型裡最便宜的。照理說,這應該是個寫程式的猛獸。

但你只要打開 Reddit 的 r/ClaudeCode、r/GeminiCLI,或者 gemini-cli 的 GitHub issue 列表,畫風完全相反:「Gemini CLI is a joke」「hot garbage and slow」「把我的 repo 搞得一團亂」。同一個模型,數字漂亮到不行,口碑卻被踩在地上摩擦。

這個落差本身才是真正的故事。我花了幾輪搜尋、把社群論據跟官方工程文件交叉比對之後,結論很清楚:大家罵的「Gemini 寫程式爛」,九成歸因歸錯地方了。 問題幾乎不在模型腦力,而在三層完全不同的東西。這篇就把它一層一層拆開。

三個 AI 模型並列,原始算力強卻缺乏整合

先別急著罵模型:benchmark 上 Gemini 根本沒落後

我們很習慣把「寫程式強不強」濃縮成一個 SWE-bench 分數。那就先看分數。

模型SWE-bench Verified備註
Gemini 3.1 Pro80.6%首個破 80%,曾居榜首;sparse MoE + Deep Think
Claude Opus 4.5 / 4.676.2% ~ 80.8%多次與 Gemini 互換第一
GPT-5.2 / 5.3 Codex71.8% ~ 80%Codex 路線
Claude Opus 4.7(較後期)87.6%這時才真正拉開差距

(數字跨來源略有出入,因為 SWE-bench 受 scaffold、抽樣影響很大,這裡看趨勢就好。來源:Vals.ai SWE-bench 榜 、Vellum 、Composio 。)

看出問題了嗎?除了 Claude 後期的 Opus 4.7 真的甩開一截,其餘時間這三家根本是貼著打。更尷尬的是,多份 2026 的排行榜——像 Morph 、Medium 的年度排名 ——都把 Gemini 3.1 Pro 封為「frontier 上的性價比之王」,還酸 Opus 的溢價是「為了 0.2 分 SWE-bench 多付你 2.5 倍」。

連 Real Python 在 比較 Gemini CLI 和 Claude Code 時都點出一個很刺的事實:Gemini 用免費層級的模型,在 SWE-bench 上硬撼 Claude 的付費旗艦,還撐得住。

所以「Gemini 模型不會寫程式」這句話,數據根本不支持。可是體感落差又真實存在——那它到底落在哪?

真正的災難在終端:Gemini CLI 的可靠度崩壞

落差在工具。準確說,是在那個包住模型、幫它讀檔、改檔、跑指令的東西——agentic CLI。社群罵的幾乎全部集中在這一層,而不是「模型懂不懂程式」。

終端陷入無限迴圈的災難場景

最致命、也最一致的抱怨是無限迴圈。這不是零星個案,是系統性的。你去翻 google-gemini/gemini-cli 的 GitHub issue,loop 相關的 bug 一整排,很多都被標成 p1:

  • #2201 :編輯檔案時,反覆讀同一個檔、套用同一個會失敗的 replace,無限重試、沒有退出條件。
  • #8237 :「偵測到潛在迴圈」的硬性中斷反而誤殺合法的重複性任務,整個 session 卡死。
  • #22141 :處理一個小改動花了一小時以上;光回答「你用哪個模型」就要 13~14 分鐘。

最有畫面的是 acusti.ca 紀錄的那次:Gemini CLI 到最後卡在輸出「I'm done.」「I'll stop.」「Done.」,同一句變體重複了 42 次 ,直到 CLI 自己跳出「A potential loop was detected」才強制停下。夭壽,連「我做完了」都能講 42 遍還停不下來。

這裡有個很關鍵的細節:Google 的解法是事後加一個「偵測到迴圈」的硬煞車。這恰恰暴露了問題——它沒辦法讓 agent 從根本上自己收斂,只能在外面裝個攔截器硬擋。issue #8237 的抱怨就是這個煞車太粗暴,連正常的批次編輯都被當成迴圈砍掉。

第二類災難是檔案編輯不可靠。#6443 裡開發者紀錄了完整的崩壞鏈:「我反覆用 replace 工具但 old_string 不對,工具失敗後我又對檔案狀態做了錯誤假設」,最後 Gemini 連自己跟使用者的改動一起刪掉。r/ClaudeAI 那串「Gemini CLI is a joke 」裡有人講得很傳神:「就算用很強的 2.5 Pro,它還是把我的 repo 搞得一團亂。」

對照 Claude Code 並排測試的評價(r/ClaudeCode ):「Claude 安靜地在 reasoning 重的任務上勝出——更乾淨的 refactor、更敏銳的 edge-case、更好的 repo 級理解。」差別不在誰比較聰明,在誰做事比較可靠、會收尾。一個是資深工程師,一個是有時候會發瘋、把介面越改越爛的實習生。

為什麼會這樣?因為「Harness 即產品」

這才是整件事最核心的解釋,而且它有官方文件、學術論文、業界大佬部落格一起背書。

引擎與完美咬合的傳動系統,象徵模型與工具共生

過去一年業界冒出一個共識:前沿 coding 模型,是「針對自己的 harness 共同後訓練」出來的。 Harness 就是那層包在模型外面、定義它能做哪些動作(讀檔、bash、規劃、派 subagent)的執行框架。業界普遍推測,Claude 的 agentic 後訓練是繞著 Claude Code 在調、GPT-5 Codex 是繞著 Codex 在調——模型和工具綁在一起、共生演化(這點各家沒有完整公開細節,但從行為與多位研究者的分析高度一致)。Addy Osmani 和 HumanLayer 都把這點講得很直白:模型會針對 harness 設計者認為它該擅長的動作變強 。

這個共生關係有多重要?有人量化過:Claude Opus 4.7 從原生的 Claude Code harness 換到 Cursor 的 harness,functionality 就從 87.2% 跳到 91.1%——模型沒變,只換了外面那層工具(MindStudio )。SWE-agent 的研究也顯示,光是把 tool-schema 設計好,固定模型也能大幅拉高 benchmark。換句話說——工具層的權重,在 agentic 場景下不輸給模型本身。

Anthropic 自己的工程文章 〈Effective harnesses for long-running agents〉 講得更白:即使是 Opus 4.5 這種前沿模型,丟進 Agent SDK 裡跑迴圈,如果只給它一句高階 prompt,它照樣蓋不出 production 級的 web app——你需要 compaction、context reset、handoff artifact 一大堆 harness 工程把它撐住。

模型 ──跑在──▶ Harness 工具層 ──真實使用──▶ 海量 agentic telemetry
▲────────── 回頭訓練 ──────────┘
(模型與工具層之間還有一條「共同後訓練」的虛線:兩者一起演化)

這就是 Anthropic 和 OpenAI 的飛輪:模型↔工具共同訓練,再用真實使用的 telemetry 回頭餵下一代。Google 呢?它的模型是「從頭為多模態打造」的通才——r/GeminiCLI 上最高讚的解釋一針見血:「因為它們的造法不同,Gemini 是樣樣通、樣樣鬆 (jack of all trades, master of none)。」agentic tool-use 那條 loop 的後訓練與工具成熟度,Google 起步就晚,飛輪也轉不起來。

Google 的組織病:一手好牌打成碎片

技術解釋之外,還有一層是組織的。這部分連主流媒體都看不下去了。

碎片化的工具拼圖散落,對比一道聚焦的光束

Google 最大的毛病是產品碎片化。Anthropic 就一個 Claude Code,OpenAI 就一個 Codex,目標明確、火力集中。Google 呢?同時養了 Gemini CLI、Gemini Code Assist、AI Studio、Firebase Studio、Jules、Antigravity——一桌子菜,每個都做一點點不一樣的事。獨立顧問 Martin Alderson 在 〈What's going on with Gemini?〉 直接用 smorgasbord(大雜燴)形容,還補了一刀:「我幾乎遇不到任何開發者日常在用 Google 的 SWE 工具。」

洛杉磯時報 的標題更不留情面:「Google 的內部鬥爭,正把 AI coding 競賽拱手讓給 Anthropic 和 OpenAI。」報導點名 Google 用 24 億美元的授權費與薪酬,從 Windsurf 取得核心人才與技術(典型的 acquihire 結構),結果 Jules 的負責人 Kathy Korevec 沒多久就跳槽去了 OpenAI。

而這個碎片化會自我惡化,Martin Alderson 點出最致命的一環——訓練資料飛輪。Claude Code 和 Codex 每天產生海量的真實 agentic 編碼 telemetry,回頭餵養下一代模型;Google 因為沒人用它的工具,就拿不到這桶燃料。沒人用 → 拿不到 telemetry → 下一代 agent 行為改不好 → 更沒人用,這是會複利的劣勢。

他還補了一個很犀利的觀察:Google 內部用的是一套極度客製的源碼控制、build、測試、部署系統,「當你習慣用 Google-scale 的方式想事情,就很難理解業界其他人到底怎麼寫程式」——所以它難以為「一般開發者」設計出順手的 agentic 工具。

如果你想要一句總結,r/google_antigravity 上那串「Anthropic 和 OpenAI 怎麼把 Google 打這麼慘 」的神比喻最到位:

如果 AI 智能是引擎、工具整合是傳動系統:Google 造了更好的引擎,Anthropic 造了更好的車,OpenAI 造了更好的賽車變速箱。 Gemini 有極強的原始大腦,卻完全缺乏可靠驅動工具、讀檔案系統、在 IDE 裡執行程式的「傳動系統」……你是在用法拉利引擎犁田。

最能說明這團混亂的,是一個正在發生的事件。2026 年 5 月的 Google I/O 上,Google 宣布 Gemini CLI 和 Code Assist IDE 擴充將在 6 月 18 日停止對 Pro/Ultra/免費用戶服務 ,全部要遷到新的 Antigravity CLI——一個閉源、用 Go 重寫、發布時還沒有 feature parity 的東西。用開源換閉源、功能還沒齊就逼遷移,AI Builder Club 的遷移指南 乾脆直接建議:個人開發者終端工作流就用 Claude Code,要全開源就用 Aider。自家工具的遷移指南把用戶推給對手,這畫面有夠尷尬。

等等,先別把 Gemini 寫死

罵了這麼多,得講句公道話——Gemini 完全不是沒救,而且把它寫死的人很可能會踩到自己的臉。

矽晶片在日出時發亮,象徵翻盤本錢

第一,便宜、快、context 大這幾張牌是真的硬。Gemini 是前沿模型裡的性價比之王、支援 1M context、多模態,前端/UI 生成出來的東西常常漂亮到不行,Web 版體驗也很順。r/GeminiCLI 有句話很實在:「Gemini 免費,你贏不了免費。」

第二,口碑正在回升。前面那些迴圈災難很多是 2.5 Pro 時代的事。到了 Gemini 3 Pro,Shipyard 在 2026 年 4 月的比較 反而觀察到:「很多用戶覺得 Gemini 3 Pro 比 Claude 更少卡住,更能自己跳出無效迴圈。」注意,這跟前面的舊抱怨剛好相反——這代表 Google 確實在補洞,落差在縮小。而且要公平地說,loop 不是 Gemini 的專利,r/Anthropic 上也有人抱怨 「Claude Code 一碰到複雜邏輯錯誤或 race condition 也會 loop」,只是程度差異。

第三,Google 手裡握著一張別人沒有的牌:自研 TPU。Martin Alderson 的分析很有意思——Gemini 3.5 Flash 跑到 206 tokens/sec,比同期的 Opus 4.8、GPT-5.5 快了大約 4 倍,單位推論成本極低,因為模型和 TPU 是 Google 內部一起設計的。從這個角度看,Gemini 與其說是輸給對手的開發者工具,不如說它根本是「在玩另一場遊戲」:模型很大程度是為 Google 自家海量內部 token 消耗(AI mode、Gmail)而調的。如果哪天它把 agent 那條故事理順,底層的矽晶+研究+整合會讓它非常難纏——「但那是個大大的 if」。

所以真要落到「我現在該用哪個」,我會這樣切:

你的需求建議
要可靠的終端 agent 工作流、多檔 refactorClaude Code / Codex CLI(現階段首選)
預算敏感、大量批次、超長 context、前端 UI、多模態Gemini 3.x(性價比最佳)
想兩邊通吃Claude 規劃+code review,Gemini 大量實作;或 Gemini 分析產報告 → Claude 執行
你還在用 Gemini CLI注意 6/18 停服,評估遷 Antigravity CLI 或改用 Claude Code / Aider

結語:罵之前,先分清楚你在罵哪一層

回到開頭那個矛盾。Gemini 的分數和口碑為什麼差這麼多?因為大家把「模型腦力」「工具可靠度」「組織策略」三件事揉成一句「Gemini 寫程式爛」。

拆開來看其實很清楚:模型那層 Gemini 沒輸,甚至更便宜;真正崩的是 agentic CLI 的可靠度,而它的根因是「模型沒跟工具共生後訓練」這個結構性差距,再被 Google 自己的產品碎片化雪上加霜。

這對我們最大的啟發其實是:在 agentic 時代,harness 跟模型一樣是產品的一半。 下次你覺得某個 AI 工具「很笨」,先停一下——你罵的到底是那顆腦,還是包在外面那層手腳?這兩件事,修起來完全不一樣。

如果你手上同時開著 Claude Code 和 Gemini,不妨拿同一個任務並排跑一次,你會很快親身體會「分數接近、體感天差地遠」是什麼意思——而那個差,正是 harness 的差。至於 6/18 之後 Antigravity 能不能把這層手腳補起來,會是接下來半年最值得盯的指標:Google 的引擎從來不是問題,問題一直是它願不願意專心把車造好。

參考資料

延伸閱讀

Codex vs Claude Code:用了大半年,我把這兩個 AI coding agent 的「個性」摸透了

兩個 AI coding agent 在賽博機房裡對峙,一藍一綠

有件事我一直覺得很妙。

某次我把 Claude Code 寫好、自己看過覺得沒問題的一段程式碼,丟給 Codex 做 review。結果 Codex 一口氣抓出一堆我跟 Claude 都沒注意到的問題——race condition、漏掉的 edge case、一個會在高併發下爆掉的鎖。我心想好吧那反過來呢?把 Codex 寫的程式碼丟給 Claude Code 看。Claude 看了半天,給我一句客客氣氣的「這段寫得很完整,沒有發現明顯問題」。

這個不對稱的現象,在 Hacker News 的討論串 跟一堆 Reddit 貼文裡反覆出現,不是只有我遇到。它其實濃縮了一件事:Codex 跟 Claude Code 不是「誰比較強」的問題,而是它們根本是兩種不同性格的生物。 你拿 benchmark 分數去比,會發現兩邊幾乎打平;但真正決定你每天用起來爽不爽的,是它們的「脾氣」。

這篇就來聊聊我用了大半年下來,對這兩個工具最真實的使用體感——不是比規格表,是比那種「跟它共事久了才會懂」的細節。


它們根本不是同一種生物

先把最容易搞混的東西講清楚。雖然大家都叫它們「終端 AI coding agent」,但這兩個工具從骨子裡的設計哲學就分岔了。

Claude Code 是 Anthropic 的終端原生工具 ,預設跑在你自己的機器上,邊做邊跟你報告每一步、動到危險的東西會先問你。它的整個互動模型是「developer-in-the-loop」——你跟它並肩坐著,隨時可以打斷、可以導正。

Codex 則是 OpenAI 從雲端優先(cloud-first)出發 設計的,預設把任務丟進一個隔離的雲端 sandbox 裡跑。它的模型是「委派」——你描述任務、走開、回來看結果(通常是一個 PR)。它在 macOS app、CLI、IDE 擴充、ChatGPT 網頁、甚至 Slack 裡 @Codex 都能用。

左邊本地終端發綠光,右邊雲端 sandbox 容器發藍光,光束相連

把規格攤開來看會更清楚:

維度Claude CodeCodex
主力模型(2026-05)Opus 4.7、Sonnet 4.6GPT-5.4、GPT-5.5、GPT-5.3-Codex
預設執行環境本地終端(你的機器)雲端 sandbox + 本地 CLI
互動風格逐步敘述、要你批准丟出去自己跑、回來看 PR
開源否是(Apache 2.0、Rust binary)
沙箱安全應用層(26 種可程式化 hook)OS kernel 層(Seatbelt / Landlock / seccomp)
設定檔CLAUDE.md(專有)AGENTS.md(開放標準)
Context window1M tokens(Max/Team 標準定價)272–400K,GPT-5.4 實驗性 1.05M

這張表你不用背,只要記住一句話:Claude Code 從「本地、敘述、要你批准」長出來,Codex 從「雲端、自主、給你成品」長出來。 後面所有體感差異,都是從這個分岔點延伸出來的。

順帶一提,Codex 的桌面 app 在 2026 年 2 月推出時是 macOS only ,Windows/Linux 用戶當時只能用 CLI——這對一些跨平台團隊來說是個 dealbreaker,要留意。


真正的差異,是它們的「個性」

規格表看完你大概無感,因為兩邊看起來都很能打。但用久了你會發現,最有感的差異 benchmark 永遠測不出來——是它們的講話方式跟做事節奏。

onevcat 那篇用了一個半月的深度心得 把這件事講得超精準,跟我的體感幾乎一模一樣:

Claude 相對啰嗦但細緻。 它喜歡把每個決策的前因後果、自己正在做什麼,都解釋給你聽,偶爾還會附贈一句「You're absolutely right」的情緒價值。這種個性在「理解專案、做簡單測試、邊探索邊調整」的時候超好用——你看得到它在想什麼,走錯方向馬上喊停。但處理困難任務時,它有時會顯得效率不高,而且很容易被你帶偏:你一句「會不會是這裡的問題?」它可能就真的順著你那個錯誤方向一路跑下去。

Codex 則是人狠話不多,直達要害。 它幾乎不解釋為什麼這麼做,往往就自己悶頭苦幹個十來分鐘,然後直接甩給你一個簡潔有效的解法。onevcat 那個比喻我超愛——「就彷彿在跟一個掃地僧對話,一個眼神勝過千言萬語」。但這種含蓄也有代價:碰到架構設計或需要研究的任務,除非你明確要求它解釋,否則那種「沉默是金」會讓你完全摸不透它的思路。

左邊話多的綠機器人被一堆對話框包圍,右邊像掃地僧一樣安靜的藍機器人

這裡有個很多人會踩的坑:話多不等於比較好。 我以前也以為 Claude 解釋得多就是比較聰明,後來才想通——這只是「適不適合當下這個任務」的問題。需要對齊需求、邊做邊釐清的活,Claude 的啰嗦是優點;目標明確、規格寫死的活,Codex 的沉默高效反而更省心。

還有一個實務上的雷:Codex 很常用 Python 腳本去改檔案,產出的 diff 不是那種一行一行清楚的修改,而是一坨腳本執行結果,review 起來很痛苦 。所以你基本上只能等它跑完、看最後結果,沒辦法像 Claude 那樣盯著過程即時介入。這也是為什麼——

Claude Code 適合 pair programming,Codex 不適合。 Claude 那種快速迭代、approve 每個 edit、走偏就打斷的節奏,就是結對編程的精髓。Codex 太慢了,它的正確用法是「丟出去,十分鐘後回來收貨」。HN 上一個資深開發者的配比我覺得很有代表性:Claude Code 用 80%、Codex 用 20%,但 Codex 當 PR reviewer 是所有工具裡最強的。


Benchmark?早就打平了

如果你還在用 SWE-bench 分數來決定要用哪個,我勸你省點力。2026 上半年這兩邊的數字已經咬得超緊,而且每次有新模型就翻盤一次。

Benchmark(2026 上半年)Codex(GPT-5.x)Claude Code(Opus 4.x)
SWE-bench VerifiedGPT-5.5 88.7%(5 月反超)Opus 4.7 87.6%
Terminal-Bench 2.0GPT-5.3-Codex 77.3%Opus 4.7 69.4%
OSWorld-Verified(電腦操作)較低72.7%(領先)
Token 效率省 2–4×吃 token 較凶

SWE-bench Verified 上,GPT-5.5 在 5 月以 88.7% 微幅反超了 Opus 4.7 的 87.6% ——差距只有 1.1 分,根本是測量誤差等級。但你換個 benchmark 結論就變:Terminal-Bench 2.0 上 Codex 把 Claude 拉開一截(GPT-5.3-Codex 77.3%、GPT-5.4 75.1% vs Opus 4.7 69.4%,不同評測機構數字略有出入),終端/debug 類任務它是真的強。

所以與其問「誰分數高」,不如問「它們各自擅長哪條軸線」。這個結論反而很穩定:

  • Codex 擅長:terminal 操作、debug、抓 race condition 跟 edge case、PR review。Composio 的實測 裡,Codex 持續抓出 Claude 漏掉的邏輯錯誤。
  • Claude 擅長:大型 codebase 推理、跨檔重構、前端設計保真。同一份 Figma 設計克隆測試 裡,Claude 保留了排版結構跟原始設計的圖片,Codex 給的版本功能正常但視覺有出入。

一個我覺得最該記住的數字是 token 效率:Codex 完成同樣的任務通常省得多,各家評測落在 2–3 倍 到 約 4 倍 之間,依任務型態而定。這件事看起來不起眼,但它直接連到下一個——也是會真正讓你崩潰的——問題。


會讓你崩潰的,其實是額度

能量油表快見底、亮起紅色警示燈

講真的,benchmark、個性那些都還好,rate limit 才是會讓你當場想砸鍵盤的東西。 這也是 Reddit 上最高頻、而且方向超一致的抱怨。

Claude Code 這邊,Opus 吃 token 的速度快到誇張。5 小時額度、每週額度動不動就撞牆,一堆重度用戶被迫只能拿 Claude Code 來「規劃」 ,或是中途降級去用 Sonnet 才不會超限。onevcat 甚至算過,他以 API 計價的方式,一個半月燒掉了價值三千多美金的 token——後來 Anthropic 推出 weekly limit,他自嘲「大概就是針對我這種重度用戶吧」。

Codex 這邊就寬鬆很多。同樣 $20 的 Plus 方案,一個 Reddit 用戶說他「狂刷 GPT-5.4 xhigh 都還碰不到 5 小時限制」 ,auto-compact 也很平順、長 session 不太掉 context。這就是大量人從 Claude Code 跳去 Codex 的頭號原因——不是模型比較強,是同樣的錢能做更多事。前面講的 token 效率 2–4×,到這裡就直接兌現成「更不容易撞額度」。

不過這裡要踩個煞車,講兩個反面訊號,免得你以為 Codex 是萬靈丹:

第一,Codex 也有週期性「變笨」的抱怨 。每隔一陣子就會冒出一波「Codex 失去魔力了」「最近在複雜問題上越來越笨、自主性下降」的貼文,通常是 OpenAI 默默調整模型導致的。這種事 Claude 也會發生,兩邊都不能免疫。

第二,Codex 雖然額度寬鬆,但它很 verbose,話多會吃掉額度優勢。有用戶就吐槽「Codex 很囉嗦,考慮到它的 limit 這點滿煩的」。所以省不省,還是要看你的任務型態。


我的混合工作流(也是業界主流)

繞了一圈,結論其實很無聊但很實在:能同時用就同時用。 這不是和稀泥,是 2026 年絕大多數資深開發者收斂出來的共識。它們的強項剛好互補,硬要二選一反而虧。

綠機器人畫架構藍圖、藍機器人拿放大鏡檢查程式碼,協作工作流

我自己是做硬體/韌體的,BLE、儀器、各種工具鏈一大堆,分享一下我的配法:

工作流程: 需求/任務 → 判斷類型 →(規劃/重構/理解 codebase)走 Claude Code 主力;(規格明確/可無人值守)丟 Codex 外包執行 → 兩者寫完、commit 前 → 交給 Codex 當 PR reviewer → 合併。

拆開講:

Claude Code 當主力,負責規劃、跨檔重構、理解既有 codebase、以及那些需要邊做邊對齊的活。對我來說最關鍵的是——它的 MCP 生態超成熟 ,我那一堆串接硬體、BLE 抓包、邏輯分析儀的 MCP server 接上去就能用,這是 Claude Code 的主場。

Codex 當 reviewer 兼執行外包。寫完、commit 之前,固定丟給 Codex 做一輪 PR review(前面說過,它是公認最強的 reviewer)。另外那些規格寫死、可以無人值守的任務——批次腳本、CI、DevOps、純粹的 debug——直接丟給它在雲端 sandbox 跑,我去做別的事。

還有個進階玩法:兩者都能當對方的 MCP server,互相呼叫。不少 power user 就靠這個做自動化的交叉 code review,讓 Claude 寫的東西自動過一遍 Codex 的法眼。

如果你真的預算有限只能挑一個,我的建議是:

  • 主要做韌體 debug、terminal 操作、規格清楚的活,而且很在意每月帳單 → 選 Codex。
  • 主要做大型重構、需要深度推理跟互動、重度依賴 MCP 工具鏈,或公司幫你出錢 → 選 Claude Code(搭 Max 方案解額度焦慮)。

最後,講點掃興的真話

用了這麼久,我反而對「選哪個工具」這件事越來越無所謂了。

onevcat 那句話 我很認同:「當代 LLM 用戶的忠誠度接近於零,新模型吊打舊模型是業界常態,於是用戶也像候鳥一樣來回遷移。」廠商想用應用層那些 commands、subagent 配置來綁住你,但說真的——換工具的時候,那些精心設計的設定檔,幾分鐘複製貼上就能在新工具上重建。真正留得住人的,從來不是 lock-in,是模型本身的能力跟性價比。

所以與其糾結「Codex 還是 Claude Code」,不如把力氣花在一個更值得練的技能上:把需求講清楚。模糊的需求產生模糊的程式碼,清晰的需求才能逼出高品質的輸出。這個能力不管你用哪個工具、不管明年又冒出什麼新模型,都不會過期。

工具會一直換,候鳥年年遷徙。你的判斷力跟表達力,才是那個不會被 deprecated 的東西。

你現在主力是哪一個?有沒有什麼任務是某一邊特別頂、另一邊怎麼調都不行的?歡迎留言聊聊你的配方,我很想知道別人都怎麼搭。


參考資料

延伸閱讀

AI Agent三國大亂鬥:Google Jules、OpenAI Codex、Claude Code 功能深度評比

FA077962-6BFE-4059-8D37-9556465D909E

前言

AI 程式助理的發展進入白熱化階段,Google、OpenAI、Anthropic 各自推出了 Jules、Codex、Claude Code,形成三國鼎立局面。這些工具不僅提升開發效率,也改變了程式設計的工作型態。本文將針對三者的功能、整合性、應用場景與優缺點進行詳細評比,協助開發者選擇最適合自己的 AI 助理。

產品簡介

Google Jules

Jules 是 Google 推出的 AI 程式助理,主打與 Google 生態系(如 Docs、Sheets、Google Cloud)深度整合,適合習慣 Google 工具的開發者。

OpenAI Codex

Codex 是 OpenAI 旗下的旗艦級 AI 編程助手,支援多種程式語言,API 完善,與 VS Code、GitHub Copilot 等工具整合度高,適合需要雲端協作與多語言開發的團隊。

Claude Code

Claude Code 由 Anthropic 推出,強調本地端、終端機操作與隱私保護,特別適合需要在本地環境下進行大型專案維護或理解舊有程式碼的開發者。

功能比較表

功能/產品 Google Jules OpenAI Codex Claude Code
IDE/編輯器整合 Google 工具、VS Code VS Code、GitHub VS Code、終端機
終端機/本地支援 部分支援 雲端為主 強調本地、終端機
雲端API/生態系 Google Cloud、Docs OpenAI API、GitHub 無(本地優先)
語言支援 多語言 多語言 多語言
程式碼理解能力 強 極強 強,適合舊有專案
隱私與安全 Google 標準 OpenAI 標準 高度本地、隱私優先
價格與授權 Google 訂閱/雲端計價 OpenAI 訂閱/API 計價 可能為本地授權/訂閱

實際應用場景

  • Google Jules:適合深度依賴 Google 生態系、需要與 Docs、Sheets、Cloud 整合的開發者。
  • OpenAI Codex:適合多語言開發、雲端協作、API 驅動專案,或已經使用 GitHub Copilot 的團隊。
  • Claude Code:適合重視隱私、需在本地端維護大型或舊有程式碼庫的開發者,或偏好終端機操作者。

優缺點分析

Google Jules

優點:

  • 與 Google 生態系整合深,適合 Google 用戶
  • 支援多語言與雲端協作 缺點:
  • 本地端與終端機支援較弱
  • 需依賴 Google 帳號與雲端服務

OpenAI Codex

優點:

  • API 完善,支援多種 IDE
  • 雲端協作與多語言能力強
  • 文件與程式碼理解能力極佳 缺點:
  • 隱私性不如本地端方案
  • 需訂閱或按量付費

Claude Code

優點:

  • 強調本地端與終端機整合,隱私性高
  • 適合維護大型、舊有程式碼庫
  • 與 VS Code 整合佳 缺點:
  • 雲端協作與 API 能力較弱
  • 生態系資源較少

2025 最新深度比較

技術架構與定位

  • Google Jules:以 Gemini 2.5 Pro 為基礎,強調「計畫先行」與 Google 生態深度整合,適合企業級、重視安全與流程可控的團隊。
  • OpenAI Codex:以 GPT-4o/5 為核心,支援多語言、API、IDE、CLI,開源 CLI 彈性高,適合多語言、API 驅動與雲端協作。
  • Claude Code:以 Claude 3.7/4 Sonnet/Opus 為基礎,主打本地端、終端機、隱私優先,適合維護大型/舊有程式碼庫。

進階功能比較

維度/產品 Google Jules OpenAI Codex Claude Code
整合性 Google Cloud、GitHub VS Code、API、CLI VS Code、Git、CLI
本地/雲端 雲端為主,異步執行 本地/雲端皆可 本地優先,終端機
語言支援 8-12 種主流語言 12+ 種語言 多語言,強於 Python/JS
上下文理解 256K token 128K token 200K token(企業更高)
自動化能力 多步驟計畫、需審核 多任務並行、可自訂 高度自主、可全自動
測試/CI/CD 產生測試計畫 自動產生/執行測試 可執行測試、產生 PR
隱私/安全 雲端執行,嚴格控管 本地執行、開源 本地優先、不訓練資料
價格 Beta 免費/未來訂閱 API 計價/開源 CLI Pro/Max 訂閱/按量計價
用戶體驗 計畫審核、雲端慢 快速、彈性高 CLI 操作、解釋詳盡

真實用戶體驗摘要

  • Jules:適合需要嚴格審核、流程可控的團隊,計畫透明但速度慢,適合企業級專案。
  • Codex:原型開發、跨語言、API 驅動專案首選,開源 CLI 彈性高,適合技術型團隊。
  • Claude Code:維護大型/舊有程式碼庫、重視隱私與自動化的開發者首選,解釋與 commit message 極佳,適合終端機愛好者。

適用建議

  • 企業/大型團隊:Google Jules(安全、流程可控)、Claude Code(自動化維護)
  • 個人/小型團隊:OpenAI Codex(彈性高、API 多)、Claude Code(本地端、隱私)
  • 原型/多語言/快速開發:OpenAI Codex
  • 維護舊有/大型專案、重視隱私:Claude Code
  • Google 生態用戶:Jules

價格與授權

  • Jules:Beta 免費,未來訂閱制
  • Codex:API 按量計價,CLI 開源免費
  • Claude Code:Pro/Max 訂閱($20$200/月),API 按量計價

最新趨勢

  • 2025 年 AI 助理已從「自動補全」進化為「自主代理人」,能理解專案、規劃任務、產生測試、提交 PR,甚至語音註解。
  • Copilot++、Cursor、Windsurf 等新競爭者快速崛起,VS Code 內建 AI 支援多模型,生態系更開放。
  • 多數專業開發者建議「多工具並用」:如 Codex 負責演算法、Claude Code 處理 legacy code、Aider/VS Code AI 負責日常協作。

參考來源

Ithy、Luseratech、Kingy AI、Medium、SourceForge、Jon Atkinson Blog、Kasra Blog、Rumjahn、Bind AI 等 2025 年 5 月最新評測與用戶回饋。

三款 AI 助理各有千秋,選擇時可依據開發需求:

  • 偏好 Google 生態、雲端協作選 Jules
  • 需要多語言、API 與雲端整合選 Codex
  • 重視本地端、隱私與終端機操作選 Claude Code

未來 AI 助理將持續進化,建議開發者可多方嘗試,選擇最適合自身工作流程的工具。

執行摘要

2025年,AI程式助理的發展已進入白熱化階段,市場從基礎的程式碼補全工具,迅速演進為能夠理解開發者意圖、規劃多步驟任務並自主執行複雜開發流程的智慧代理人。這場變革正深刻地重塑軟體開發的工作模式。在眾多競爭者中,Google Jules、OpenAI Codex和Claude Code脫穎而出,形成三足鼎立之勢,各自代表著不同的策略方向與目標客群。

Google Jules以其與Google生態系的深度整合及企業級的安全與流程控制能力為核心優勢,特別適合已深度依賴Google工具的大型團隊。OpenAI Codex則憑藉其強大的API介面、雲端原生架構以及與GitHub等工具的高度協作能力,成為多語言開發和雲端協作專案的理想選擇。而Anthropic的Claude Code則強調本地端操作與終端機整合,並將隱私保護置於首位,對於重視資料安全或需維護大型、老舊程式碼庫的開發者而言,具有獨特的吸引力。

本報告將對這三款頂尖AI程式助理的功能、技術架構、整合性、隱私安全、價格模型及實際應用場景進行深入評估,旨在協助開發者和IT決策者根據自身需求,選擇最合適的AI助理,以最大化開發效率與專案品質。未來的軟體開發將日益走向人機協作,策略性地整合多種AI工具,將成為提升競爭力的關鍵。

1. 前言:軟體開發中自主AI的黎明

AI在軟體開發領域的應用,已從早期的程式碼自動補全或生成,躍升至具備「代理人」(agentic)能力的系統。這些AI代理人能夠自主理解程式碼、領會開發意圖、制定多步驟的執行計畫,並實際執行任務,甚至能自動提交拉取請求(pull requests)。這標誌著AI在軟體開發中角色從單純的輔助者轉變為積極的協作者,帶來了質的飛躍 1。

這種從「副駕駛」(co-pilot)到「代理人」的轉變,意味著AI工具不再僅僅是提升單行程式碼生產力的輔助,而是開始能夠管理整個開發工作流程。這項趨勢的出現,主要得益於大型語言模型(LLMs)在推理、規劃和多步驟執行方面的顯著進步。這種轉變對開發者角色產生了深遠的影響,例如,開發者將更多地從事監督工作而非繁瑣的底層任務,團隊效率也因任務的平行執行而提升,進而加速了軟體開發生命週期,透過自動化測試和重構提高了程式碼品質。這預示著一個AI成為真正「隊友」而非僅僅「工具」的未來。

在這一波AI浪潮中,Google Jules、OpenAI Codex和Claude Code成為了領先的「三國」,各自秉持著獨特的理念和目標市場,共同塑造了一個既競爭又充滿創新的AI程式助理格局。本報告旨在提供一份詳細且客觀的比較分析,以幫助開發者、工程經理及IT決策者在2025年選擇最符合其特定需求的AI助理。

2. Google Jules:企業級代理人

產品概述與核心功能

Google Jules是Google推出的一款自主AI程式碼代理人,於2025年5月進入公開測試階段。它被定位為一款全面的程式碼代理人,而非僅僅是程式碼補全工具或協作者 1。

Jules以非同步方式在安全的Google Cloud虛擬機器(VM)中運行,它會複製程式碼庫以全面理解專案上下文,並在後台執行任務,讓開發者能夠專注於其他工作 1。其核心任務包括:撰寫測試(單元測試、整合測試、端到端測試)、建構新功能(例如樣板程式碼、基礎功能實現、整合)、修復錯誤(分析錯誤報告並生成潛在修復方案),以及更新依賴版本 1。

Jules在執行變更前,會清晰地呈現其計畫、推理過程以及變更的差異(diff),供使用者審查和批准,確保使用者對程式碼擁有完全的控制權 1。其獨特的功能還包括提供近期提交的音訊變更日誌(audio changelogs),將專案歷史轉化為可聽取的上下文日誌 1。此外,Jules與GitHub工作流程深度整合,可直接在開發者慣用的環境中運作 1。

技術架構

Jules的核心是Google的Gemini 2.5 Pro模型,該模型被Google譽為「最先進的複雜任務模型」,為Jules提供了卓越的程式碼推理能力 1。它利用雲端VM系統實現平行執行,能夠高效處理複雜的多檔案變更和並行任務 1。

Gemini 2.5 Pro擁有高達100萬個token的上下文視窗,這使其能夠在單一提示中處理大量程式碼和文件,從而實現對大型程式碼庫的深度理解 16。Jules支援多種主流程式語言,包括Python、JavaScript、TypeScript、Go、Java和Rust 15。

優缺點分析

優點: Jules與Google生態系統(如Docs、Sheets、Google Cloud)深度整合,非常適合已習慣使用Google工具的開發者。它具備強大的代理人能力,能夠處理複雜任務並支援雲端協作。其非同步操作模式能有效釋放開發者的時間,而高度透明的計畫、推理和差異顯示,則確保了程式碼變更的可控性與可審計性。此外,Jules預設為私有,不使用私人程式碼進行模型訓練,且資料在執行環境中保持隔離,提供了穩固的隱私保護 1。

限制: Jules主要基於雲端運作,這可能不符合所有開發者的隱私偏好或本地開發需求。目前它仍處於公開測試階段,存在使用限制,且未來的定價模式尚未公布 1。

Google對Jules的策略定位明確:它旨在鎖定企業級客戶,特別是那些已在Google Cloud生態系統中投入大量資源,並高度重視控制、可審計性以及在結構化雲端原生環境中整合的組織。Jules的非同步操作特性和明確的計畫批准流程,正是為了滿足企業級專案對治理和審查的嚴格要求。這種設計與某些更「放手」或純本地的工具形成鮮明對比。公開測試階段的免費策略,也是一種常見的企業級產品推廣模式,旨在在全面商業化前吸引大量使用者。這項策略有望鞏固Google在企業AI開發工具市場的地位,因為它專注於受控、可審計的代理行為,這對大型團隊而言至關重要。

3. OpenAI Codex:API驅動的強大引擎

產品概述與核心功能

關於「Codex」的狀態,需要進行澄清:雖然最初的Codex API已於2023年3月被GPT-3.5 Turbo取代並終止支援 21,但「OpenAI Codex」本身在2025年5月以雲端AI程式碼代理人的形式重新推出,並深度嵌入ChatGPT,供Pro、Team和Enterprise使用者使用。同時,它也以開源CLI(Command Line Interface)工具的形式提供 6。

Codex被定位為「雲端AI軟體工程師」,能夠理解自然語言提示,將其轉化為程式碼,並獨立管理整個程式設計任務 6。它具備讀取、導航和編輯整個程式碼庫的能力,也能執行測試和調試程序,並提出附帶可驗證日誌和終端機輸出的拉取請求 6。

Codex支援廣泛的任務類型,包括:調試、錯誤修復、基礎設施即程式碼(例如使用Ansible或Terraform進行部署)、撰寫單元測試/整合測試/端到端測試、程式碼庫查詢、重構,以及微服務/API的快速原型開發 7。開發者還可以透過建立AGENTS.md檔案來定義Codex的作用範圍、偏好框架、程式碼風格和測試規則 6。Codex具備多任務處理能力,允許使用者同時向多個Codex代理人分配任務,每個任務都在獨立的微型虛擬機中平行執行 6。

技術架構

驅動Codex的核心模型是codex-1,這是OpenAI o3架構的專門版本,針對真實世界的開發工作流程進行了微調 6。所有任務都在安全的、與網路隔離的雲端沙盒環境中執行,這些沙盒預先載入了使用者的程式碼庫 6。

Codex CLI是開源的命令列工具,可在本地運行,確保原始碼在未經使用者明確共享的情況下不會離開本地環境。它預設使用o4-mini模型 24。此外,它支援多模態輸入,包括文字、螢幕截圖和圖表,以生成程式碼 25。作為GitHub Copilot的底層模型,OpenAI的Codex也利用GPT-4o、GPT-4.1、GPT-4.5、o1、o3、o3-mini和o4-mini等模型。其中,GPT-4o擁有128K token的上下文視窗 28。

優缺點分析

優點: OpenAI Codex功能高度多樣化,支援多種程式語言,並提供完善的API介面,便於與其他工具整合。它具備強大的代理人能力,可處理端到端任務,並支援平行執行以實現高吞吐量。透過GitHub Copilot,它與VS Code和GitHub深度整合。開源的CLI版本則提供了本地控制和更高的隱私性 6。

限制: 嵌入ChatGPT的版本主要基於雲端執行,其隱私保護依賴於OpenAI的政策(儘管預設情況下資料不用於訓練)。此外,基於使用量的定價模式可能導致大型任務的成本較高 6。

OpenAI將Codex(及其與Copilot的整合)定位為一個功能強大、靈活且可擴展的AI工程合作夥伴,可透過流行的聊天介面(ChatGPT)和本地CLI兩種方式存取。Codex的「重新登場」凸顯了OpenAI在產品策略上的靈活性,透過將強大的底層模型整合到更易於存取和整合的平台中,以適應市場需求。這項積極的整合和雙重產品策略(雲端代理人 + 本地CLI)使OpenAI能夠佔領廣闊的市場區隔。這表示AI公司正優先將先進的AI直接嵌入開發者工作流程和熱門平台,而非提供獨立的利基API。開源CLI的推出,也進一步促進了社群採用和創新,強化了其生態系統。

4. Claude Code:隱私優先的終端機夥伴

產品概述與核心功能

Claude Code是Anthropic推出的一款代理人程式碼工具,旨在直接在使用者終端機中運行,強調本地操作和隱私保護 3。它透過理解程式碼庫、執行例行任務、解釋複雜程式碼以及處理Git工作流程,幫助開發者更快地編寫程式碼,所有這些都透過自然語言命令完成 3。

其核心功能包括:編輯檔案、修復錯誤、回答有關程式碼架構和邏輯的問題、執行和修復測試、執行程式碼檢查(linting)、搜尋Git歷史紀錄、解決合併衝突以及建立提交和拉取請求 3。Claude Code採用「代理人搜尋」(agentic search)技術,無需手動選擇上下文,即可理解整個程式碼庫 4。

Claude Code的一項重要差異化優勢在於其對隱私的承諾:它在未經明確批准的情況下絕不修改檔案,並且Anthropic明確表示不會使用Claude Code的使用者回饋來訓練生成模型 3。它與VS Code和JetBrains IDEs深度整合,並可利用現有的測試套件和建構系統 4。

技術架構

Claude Code直接將Claude Opus 4(提供強大智慧)或Sonnet 4(平衡效能與成本)模型嵌入終端機 4。Anthropic聲稱Opus 4是「世界上最好的程式碼模型」,在複雜任務、大型程式碼庫重構和多步驟開發工作流程方面表現出色 10。

Opus 4擁有200K token的上下文視窗,雖然容量龐大,但仍小於Gemini 2.5 Pro的100萬token 35。它支援「擴展思考」(extended thinking)模式,以實現更深入的推理,允許模型在推理和工具使用(如網路搜尋)之間動態切換 10。Claude Code在本地終端機中運行,直接與模型API通訊,無需後端伺服器或遠端程式碼索引 4。它支援多種程式語言,包括Python、JavaScript、Java、C++、C#、Ruby、PHP、Go、Swift、Kotlin、SQL、HTML、CSS,尤其在Python和JavaScript方面表現強勁 37。

優缺點分析

優點: Claude Code因其本地執行和明確的非訓練政策,提供了高度的隱私和安全性。它在理解和維護大型/舊有程式碼庫方面表現出色,並與終端機深度整合。其強大的代理人功能適用於Git工作流程和複雜的程式碼編輯 3。

限制: 相較於Gemini 2.5 Pro,其上下文視窗較小,這可能影響處理極大型單一提示任務的能力。與Google或OpenAI的產品相比,其雲端協作功能較不突出 35。

Claude Code對本地執行和明確隱私保證的強調,使其成為對資料隱私有嚴格要求的開發者和組織的強大競爭者,特別是那些處理敏感智慧財產權或在高度受監管行業中運作的實體。其專注於舊有程式碼和終端機工作流程,也為其開闢了獨特的市場利基。這種強大的隱私立場,使得Claude Code能夠鎖定市場中對資料主權和控制有特殊需求的客戶群,這表示隱私正成為某些企業AI採用中不可或缺的特性。

5. 深度比較:三國爭霸

本節將對Google Jules、OpenAI Codex和Claude Code進行全面的頭對頭比較,涵蓋其技術能力、整合性、語言支援、效能、隱私、安全以及定價模型。

技術能力與代理人工作流程

AI程式助理正從單純的輔助工具轉變為能夠自主執行複雜任務的代理人。儘管三者皆具備代理人能力,但其在雲端與本地執行、自主程度、規劃與使用者可控性以及上下文理解深度方面存在顯著差異。

雲端與本地執行模式:

Google Jules: 主要基於雲端,在安全的Google Cloud虛擬機器中進行非同步執行。它需要與GitHub整合,將程式碼庫複製到雲端進行處理 1。

OpenAI Codex: 同時提供雲端執行(透過ChatGPT介面在安全沙盒中)和本地開源CLI工具 6。

Claude Code: 強調本地優先的終端機操作,直接透過API連線。它也可以與企業級雲端平台(如Amazon Bedrock、Google Cloud Vertex AI)整合以進行部署 3。

自主程度、規劃與使用者可控性:

Google Jules: 作為自主代理人,它能夠生成多步驟計畫,展示推理過程,並提供差異(diffs)供使用者批准。其設計理念是「計畫先行」並強調使用者可控性 1。

OpenAI Codex: 具備自主代理人功能,提供「豐富的批准工作流程」,包括「建議」(Suggest)、「自動編輯」(Auto Edit)和「完全自動」(Full Auto)三種模式,允許不同程度的人工監督。它還能平行執行多個任務 6。

Claude Code: 作為代理人工具,它在修改檔案前需要明確的使用者批准。它能執行多步驟任務並自動化Git操作,並提供「擴展思考」模式以進行更深入的分析 4。

上下文視窗與程式碼理解深度:

Google Jules: 由Gemini 2.5 Pro驅動,擁有100萬個token的上下文視窗,能夠深度理解大型程式碼庫和複雜任務 16。

OpenAI Codex: 底層模型如GPT-4o擁有128K token的上下文視窗,旨在理解完整的程式碼庫上下文 28。

Claude Code: Claude Opus 4擁有200K token的上下文視窗,並使用「代理人搜尋」技術實現完整的程式碼庫感知 4。

這些工具在自主性和控制方式上的差異,反映了不同的設計理念。Jules優先考慮透明度和明確批准,適合受監管的環境。Codex提供多樣的自主模式。Claude Code則強調對檔案變更的明確批准,強化了開發者的控制權。上下文視窗的大小則顯示了它們在單一提示中處理大型專案的能力,Google目前在原始token容量方面領先。上下文視窗的大小與模型在不喪失上下文的情況下處理大型、複雜、多檔案變更的能力直接相關,這對於重構整個程式碼庫等代理人任務至關重要。不同的批准機制則反映了人機協作和信任的不同設計理念。Google的「計畫先行」與企業可審計性相符,而Claude的檔案變更明確批准則為本地操作建立了信任。OpenAI的模式則為不同使用場景提供了靈活性。開發者和組織必須權衡大上下文視窗(用於複雜、整體性任務)與細粒度人工控制的需求。工具的選擇將取決於特定任務的複雜性、團隊的風險承受能力以及合規性要求。

整合性與生態系統相容性

IDE/編輯器整合:

Google Jules: 與GitHub工作流程整合。其相關產品Gemini Code Assist則與VS Code、JetBrains IDEs和Android Studio整合 1。

OpenAI Codex: 與VS Code和GitHub Copilot深度整合。Copilot本身支援VS Code、Visual Studio、JetBrains IDEs、Eclipse、Xcode和Azure Data Studio 29。

Claude Code: 與VS Code和JetBrains IDEs整合,並直接在終端機中運行 3。

雲端平台整合:

Google Jules: 與Google Cloud及其他Google生態系統工具(Docs、Sheets)深度整合 1。

OpenAI Codex: 可透過OpenAI API存取,並與ChatGPT Enterprise/Team整合。GitHub Copilot是Microsoft的產品 6。

Claude Code: 支援Amazon Bedrock和Google Cloud Vertex AI的企業部署 10。

版本控制系統整合:

Google Jules: 直接與GitHub整合,支援分支和拉取請求 1。

OpenAI Codex: 透過Copilot及其自身的代理人功能,與GitHub深度整合 27。

Claude Code: 直接從終端機處理Git工作流程(搜尋歷史、合併衝突、提交、拉取請求),並與GitHub、GitLab整合 3。

語言支援與效能

支援程式語言的廣度:

Google Jules: 語言中立,但最適合Python、JavaScript、TypeScript、Go、Java和Rust 15。

OpenAI Codex: 支援多種程式語言,底層模型如GPT-4o在Python方面表現出色 26。

Claude Code: 支援多種語言,包括Python、JavaScript、Java、C++、C#、Ruby、PHP、Go、Swift、Kotlin、SQL、HTML、CSS,尤其在Python/JS方面表現強勁 37。

效能基準與程式碼品質:

Google Jules: 建基於Gemini 2.5 Pro,該模型在數學和程式碼編輯基準測試中超越了OpenAI的o3-mini和Anthropic的Claude 3.7 Sonnet 2。

OpenAI Codex: GPT-4o在HumanEval基準測試中達到約90%的準確度,在SWE-bench中約為49%(針對o1模型)。以速度和即時自動補全能力著稱 28。

Claude Code: Claude 3.7 Sonnet在HumanEval中達到92%的準確度,而Claude 3.7/4 Sonnet/Opus在SWE-bench中創下了70.3%的紀錄。它強調「擴展思考」模式以解決複雜的程式碼錯誤 10。

儘管所有工具都支援多種語言,但它們在基準測試中的表現各異,尤其是在複雜的實際軟體工程任務(SWE-bench)上。Claude在SWE-bench上的強勁表現及其「擴展思考」模式,表示它專注於深度、複雜的問題解決,這可能以犧牲即時速度為代價。高SWE-bench分數表明模型能夠處理真實世界的軟體問題,這些問題通常涉及多步驟推理和理解大型程式碼庫。Claude對此的專注,加上「擴展思考」功能,表示它在更具挑戰性、非例行性的程式碼任務中具備專業能力。這項能力使得Claude Code在需要深度分析、複雜錯誤修復或大規模重構的任務中,可能成為更優的選擇,儘管回應時間可能較慢。對於快速原型開發或更簡單的即時建議,其他模型可能更受青睞。這進一步強化了多工具協作的理念。

隱私、安全與合規性

資料使用政策(訓練、保留、選擇退出選項):

Google Jules: 預設為私有,不使用私人程式碼進行訓練,資料在執行環境中保持隔離 1。

OpenAI Codex: 預設情況下,發送至OpenAI API的資料不用於訓練或改進模型(自2023年3月起,除非明確選擇加入)。濫用監控日誌最多保留30天。符合條件的客戶可選擇「零資料保留」或「修改濫用監控」控制 30。

Claude Code: 不會使用Claude Code的回饋來訓練生成模型。使用者回饋的文字記錄保留30天。資料用於回饋/改進需要明確同意 3。

執行環境安全性(沙盒、本地資料處理):

Google Jules: 將程式碼庫複製到安全的Google Cloud VM中,進行隔離以確保安全 1。

OpenAI Codex: 任務在安全的、與網路隔離的雲端沙盒中執行。Codex CLI在本地運行,程式碼不會離開本地環境 6。

Claude Code: 直接在終端機中運行,本地執行。直接的API連線意味著查詢直接發送到Anthropic的API,無需中間伺服器 4。

主要安全認證與合規標準:

Google Jules: 受益於Google Cloud廣泛的合規性,包括ISO/IEC 27001、27017、27018、27701、SOC 2/3、FedRAMP等 44。

OpenAI Codex: OpenAI API和ChatGPT商業產品符合SOC 2 Type 2和CSA STAR Level 1標準。支援HIPAA商業夥伴協議(BAA) 46。

Claude Code: Anthropic已獲得ISO 27001:2022、ISO/IEC 42001:2023(AI管理系統)、SOC 2 Type I/II以及HIPAA可配置認證 48。

所有主要參與者都對安全和合規性做出了堅定承諾,這對企業採用至關重要。然而,Claude Code的本地優先方法為高度敏感的資料提供了固有的隱私優勢,而Google和OpenAI則依賴於強大的雲端安全和資料治理政策。儘管所有產品都符合行業標準,但它們在隱私處理方式上有所不同。Claude Code的本地優先設計提供了更直接和透明的隱私保證,因為程式碼本身在未經明確發送至API的情況下,不會離開使用者的本地機器。Google和OpenAI雖然擁有強大的雲端安全性,但仍涉及程式碼在其雲端環境中處理。這項差異為組織依據其風險承受能力和資料治理需求,在不同市場區隔中做出選擇提供了依據。

定價模型與可存取性

Google Jules: 在公開測試期間免費使用,但有使用限制。預計在測試期結束後會引入定價 1。底層Gemini API的定價可作為token成本的參考 50。

OpenAI Codex: codex-mini API的定價為每百萬輸入token 1.50美元,每百萬輸出token 6美元。透過ChatGPT Pro(每月20美元)、Team和Enterprise方案提供。GitHub Copilot(由Codex驅動)提供免費、Pro(每月10美元)、Pro+(每月39美元)、Business(每位使用者每月19美元)和Enterprise(每位使用者每月39美元)等多種層級 6。

Claude Code: 可透過Anthropic API(基於token的按量計費)或Max訂閱方案(每月100美元,提供5倍Pro使用量;每月200美元,提供20倍Pro使用量)存取。學生和教職員工可享折扣價 4。

市場正朝向分層、基於價值的定價模式發展,這反映了這些工具日益提升的複雜性和感知價值。「免費」通常是有限的試用或測試階段。具備進階代理人功能的AI程式碼輔助工具是付費服務,定價模式因供應商而異(訂閱制或基於token計費)。從免費/測試版轉向付費模式,表示這些AI助理不再是實驗性新奇事物,而是企業願意投入的不可或缺的工具。分層定價(例如Copilot Pro/Pro+、Claude Max 5x/20x)表明市場根據使用者需求和使用強度進行了細分,使供應商能夠從高用量使用者中獲取更多價值,同時仍提供可負擔的入門點。基於API的定價則允許靈活的大規模整合。組織需要仔細評估使用模式並相應地編列預算。成本的增加反映了AI代理人能夠執行任務的複雜性和價值日益提升,這表示對於有效整合這些工具的團隊而言,其投資回報率將會非常高。

表1:綜合功能比較

功能/產品 Google Jules OpenAI Codex Claude Code
底層模型 Gemini 2.5 Pro GPT-4o/o-系列/codex-1 Claude Opus 4/Sonnet 4
核心範式 雲端代理人 雲端代理人 (帶本地CLI) 本地終端機代理人
關鍵能力 自動測試、錯誤修復、功能建構、依賴管理、音訊變更日誌 自動測試、錯誤修復、基礎設施即程式碼、原型開發、程式碼查詢、重構、多任務處理 自動測試、錯誤修復、程式碼解釋、Git工作流程自動化、大型/舊有程式碼維護
IDE/編輯器整合 Google 工具、VS Code、JetBrains、Android Studio VS Code、Visual Studio、JetBrains、Eclipse、Xcode、Azure Data Studio VS Code、JetBrains、終端機
終端機/本地支援 雲端優先 本地CLI 終端機原生
雲端API/生態系 Google Cloud/API OpenAI API/ChatGPT、GitHub Copilot Anthropic API、AWS Bedrock/Google Vertex AI
語言支援 Python、JS、TS、Go、Java、Rust 多語言 (Python尤其強) Python、JS、Java、C++、C#、Ruby、PHP、Go、Swift、Kotlin、SQL、HTML、CSS (Python/JS尤其強)
使用者可控性 計畫審查與批准 建議/自動編輯/完全自動模式 明確批准檔案修改
音訊功能 音訊變更日誌 語音模式 (透過ChatGPT) 語音模式 (透過Claude手機應用程式)

表2:技術規格與效能基準

維度/產品 Google Jules OpenAI Codex Claude Code
主要底層模型 Gemini 2.5 Pro GPT-4o/o-系列 Claude Opus 4
上下文視窗 (Tokens) 100萬 128K 200K
HumanEval 分數 (準確度 %) >85% 90% 92%
SWE-bench 分數 (準確度 %) 未公開 ~49% 70.3% (最高紀錄)
代理人執行環境 Google Cloud VM 雲端沙盒 / 本地 (CLI) 本地終端機
特殊推理模式 深度思考 (Deep Think) 可調整推理努力 (Reasoning Effort) 擴展思考 (Extended Thinking)

表3:定價與授權概覽

產品 現況/可用性 定價模型 個人方案/成本 企業/團隊方案/成本 免費層級/存取 使用限制
Google Jules 公開測試 (Beta) 免費測試,未來訂閱制 免費 (測試期間) 待定 是 有使用限制 (測試期間)
OpenAI Codex GA (ChatGPT Pro/Team/Enterprise) API按量計費 / 訂閱制 ChatGPT Plus: $20/月;Copilot Pro: $10/月;Pro+: $39/月 Copilot Business: $19/使用者/月;Enterprise: $39/使用者/月 是 有高級請求限制
Claude Code GA (Max訂閱/API) 訂閱制 / API按量計費 Max 5x: $100/月;Max 20x: $200/月 API按量計費 是 有訊息/提示使用限制 (Max方案)

表4:隱私與安全合規矩陣

產品 資料是否用於模型訓練 (預設) 資料保留期限 (日誌/回饋) 執行環境 主要認證/合規 使用者資料控制
Google Jules 否 VM中隔離 安全雲端VM ISO 27001/27017/27018/27701, SOC 2/3, FedRAMP 使用者可控性
OpenAI Codex 否 (除非選擇加入) 30天 (濫用日誌) 雲端沙盒 / 本地 (CLI) SOC 2 Type 2, CSA STAR Level 1, HIPAA BAA支援 選擇退出選項
Claude Code 否 30天 (回饋文字記錄) 本地終端機 ISO 27001:2022, ISO/IEC 42001:2023, SOC 2 Type I/II, HIPAA可配置 明確同意使用回饋資料

6. 使用者體驗與理想應用場景

總結使用者回饋與實踐觀察

Google Jules: 適合需要嚴格審查和流程控制的團隊。其計畫透明度是一大優勢,但由於雲端處理和批准步驟,執行速度可能較慢。對於流程控制至關重要的企業級專案來說,Jules是理想選擇 12。

OpenAI Codex: 擅長快速原型開發、跨語言開發和API驅動的專案。其開源CLI為技術團隊提供了高度靈活性。使用者讚賞它能夠分擔例行且耗時的任務,以及其平行執行能力 6。

Claude Code: 在維護大型或舊有程式碼庫方面表現突出,尤其是在隱私是首要考量時。使用者重視其詳細的解釋、出色的提交訊息以及與終端機的深度整合。它非常適合偏好命令列介面和精確控制的開發者 3。

各AI助理的建議使用案例

Google Jules:

企業/大型團隊: 在安全性、流程可控以及與Google Cloud生態系統整合至關重要的場景下,Jules是理想選擇 2。

需要嚴格審計的專案: 由於其透明的計畫和推理過程,非常適合此類專案 1。

Google生態系統使用者: 深度依賴Google Docs、Sheets和Cloud的開發者 1。

OpenAI Codex:

快速原型開發與多語言開發: 其多功能性和API優先的特性使其非常適合快速迭代和多樣化的技術堆疊 26。

雲端原生專案與API驅動開發: 與雲端環境的無縫整合和強大的API能力 6。

使用GitHub Copilot的團隊: 可利用現有的Copilot基礎設施和使用者熟悉度 29。

小型團隊/自由工作者: 用於加速擴展、減少DevOps開銷以及自動化耗時任務 27。

Claude Code:

高隱私要求專案: 由於其本地優先執行和明確的資料政策 3。

維護大型/舊有程式碼庫: 其深度程式碼理解能力和在終端機中運作的能力極具優勢 3。

偏好終端機/CLI工作流程的開發者: 提供原生的命令列體驗 3。

自動化拉取請求生成與CI/CD整合: 能夠管理從問題追蹤到拉取請求的工作流程,包括測試和建構系統 4。

7. 新興趨勢與未來展望 (2025年及以後)

朝向完全自主AI代理人的持續轉變

AI助理正從「副駕駛」演變為「自主代理人」,能夠理解專案、規劃任務、生成測試並提交拉取請求 1。這包括音訊摘要/變更日誌(Jules 1)和視覺模型支援(GitHub Copilot代理人 40)等功能,以實現更直觀的互動。

開放生態系統與IDE中的多模型支援興起

VS Code現在支援「代理人模式」(Agent mode)和「模型上下文協定(MCP)伺服器」,允許AI模型與外部工具和資料來源互動 55。VS Code也讓使用者可以「攜帶自己的API金鑰」(BYOK)直接在聊天介面中存取來自不同供應商(Anthropic、Azure、Google Gemini、Ollama、OpenAI、OpenRouter)的模型 55。這項趨勢表示在IDE層面,互通性和使用者選擇性正在增加,這可能降低核心AI模型的供應商鎖定。

VS Code中「攜帶自己的API金鑰」功能是一項重大發展,它使多樣化AI模型的存取變得民主化,允許開發者根據特定任務選擇最佳模型,無論IDE的本地整合如何。這可能促進更具競爭力和創新性的AI模型市場。VS Code作為廣泛使用的IDE,引入了「代理人模式」、「MCP」和多個LLM供應商的「攜帶自己的金鑰」功能。這表示開發者不再受限於IDE中的單一AI模型,而是可以整合並在多個模型之間切換。這項發展將IDE與單一AI供應商解耦,改變了權力動態,允許開發者根據效能、成本或特定功能選擇模型,而非受限於IDE的預設AI。MCP進一步標準化了AI模型與外部工具的互動方式,促進了更整合和開放的生態系統。這種開放標準和BYOK的關係,導致了競爭的加劇和使用者靈活性的提升。這項趨勢挑戰了某些AI供應商的「圍牆花園」策略,並鼓勵模型開發者在原始效能和成本效益方面展開競爭。它還透過使不同AI優勢在單一開發環境中更容易結合,來支持「多工具採用」策略。

新競爭者與市場整合

市場正經歷快速增長,新興參與者如Copilot++、Cursor AI、Windsurf AI(由Codeium開發)、Tabnine、CodeGeeX等,正在挑戰現有工具的地位 43。其中一些新進入者,如Windsurf AI,因其代理人能力和在大規模重構方面的表現而迅速獲得關注 57。新競爭者的快速出現和現有競爭者的持續演進,表明這是一個高度動態和競爭激烈的市場。這種激烈的競爭正在推動AI程式碼助理的創新和專業化。眾多新競爭者(Copilot++、Cursor、Windsurf、Tabnine、Codeium等)在2025年崛起。這意味著市場競爭激烈且創新迅速。這種激烈的競爭迫使現有參與者不斷創新,並促使新參與者尋找利基優勢(例如,Windsurf在重構方面的代理人能力)。這導致了功能開發和專業化步伐的加快,為開發者帶來了更多量身定制且功能強大的工具。儘管目前市場參與者眾多,但最終的整合或明確的差異化對於長期生存至關重要。公司將需要提供卓越的通用代理人,或在特定利基領域(例如,隱私、舊有程式碼、特定語言支援)脫穎而出。

8. 對開發者和組織的建議

選擇最適合的AI助理的量身建議

對於Google生態系統使用者和企業團隊: Google Jules提供深度整合、強大安全性和透明、可審計的工作流程,非常適合已投入Google Cloud並要求嚴格控制的組織。

對於快速原型開發和雲端原生開發: OpenAI Codex(透過ChatGPT或CLI)提供強大、靈活且可擴展的代理人功能,特別有利於多語言專案和高度依賴API及雲端基礎設施的專案。

對於隱私敏感專案和舊有程式碼維護: Claude Code的本地優先方法和強大隱私保證使其成為處理高度敏感資料或大型、複雜舊有程式碼庫的首選,在這些場景下,本地控制和詳細解釋至關重要。

將AI整合到現有CI/CD管道和開發工作流程的最佳實踐

從小處著手並迭代: 從較不關鍵的任務開始(例如,測試生成、小型錯誤修復),以了解AI的能力和限制,然後再擴展到複雜功能。

保持人工監督: 始終審查AI生成的程式碼、計畫和差異。AI代理人雖然強大,但仍需要人工驗證以確保正確性、安全性和符合專案標準。

利用自訂指令: 使用AGENTS.md(Codex)或自訂規則(Claude Code、Gemini Code Assist)等功能,使AI行為與團隊特定的程式碼標準、風格指南和架構模式保持一致 6。

與CI/CD整合: 利用AI在現有CI/CD管道中生成/運行測試和提出拉取請求的能力,以自動化品質檢查並確保無縫整合 6。

採用多工具策略: 結合不同AI助理的優勢來執行各種任務(例如,Codex用於演算法,Claude Code用於舊有程式碼,VS Code AI用於日常協作),以最大化效率 43。

監控成本: 了解定價模型(基於token或訂閱層級)並監控使用情況,特別是對於大型或複雜任務,以有效管理成本 6。

9. 結論

Google Jules、OpenAI Codex和Claude Code這「AI三國」各自提供了獨特的優勢。Jules在企業整合和受控雲端執行方面表現出色。OpenAI Codex則是一個多功能、API優先的強大工具,適用於快速開發和雲端原生工作流程。Claude Code則以其隱私優先、本地終端機的方法脫穎而出,是處理敏感專案和舊有程式碼的理想選擇。

AI助理向自主AI代理人的演進正在從根本上重塑軟體開發。這些工具並非取代開發者,而是增強他們的能力,使他們能夠將重複性任務委派給AI,並專注於更高價值的設計、策略和創新工作。軟體工程的未來將日益涉及人機協作,AI代理人將成為開發生命週期中不可或缺的智慧夥伴。持續評估和策略性地採用這些不斷演進的工具,將是最大化生產力並保持競爭力的關鍵。


本文最初發布於 HackMD @BASHCAT。

8GB 的 RK3588 能跑多聰明的 LLM?ROCK 5C 用 NPU 實測 5 個模型

先講結論,省得你滑到最後: 在一片 8GB 的 RK3588 板子上,用 NPU 跑得最聰明的是 Qwen3-4B-Instruct-2507,我出的 7 題全對,但每秒只吐 3.7 個 token。 想要順一點的對話體驗,Qwen3.5-2B 的 8.4 tok/s 是比...