寫 Code 的話就別聽信人退訂 ChatGPT 換 Gemini

最近網路上充斥著許多聲音，鼓吹大家「退訂 ChatGPT，轉投 Gemini 的懷抱」。如果你是一般使用者，這或許是個好建議；但如果你是依賴 LLM 寫程式的開發者，請務必三思。對於認真寫 Code 的人來說，盲目跟風轉用 Gemini 可能會讓你後悔莫及。

平心而論，Gemini 3 Pro 並非一無是處。如果你只是需要它幫忙寫一些簡單的腳本、製作單一功能的小工具，它的表現確實可以一用。

然而，一旦專案進入中後期，系統架構變得複雜，Gemini 的穩定性就會面臨巨大考驗。在處理複雜上下文時，它往往會出現「暴走」的情況，不僅邏輯混亂，甚至會開始胡亂瞎編。前期節省的時間，後期可能都要花在修補它產生的混亂上。

如果你將 LLM 視為生產力工具，用來處理嚴肅的開發工作，目前的「最低標準」依然是OpenAI Codex與Claude Code。

不過根據近期的實測體驗：

舉個實際發生的例子：面對同一個 Bug，Opus 4.5 耗費了 60% 的 Session Usage，來回對話卻始終無法修正錯誤；轉手交給 GPT 5.2 Codex (Extra High)，它卻能一擊即中，瞬間解決問題。這在趕專案進度時，效率差距是巨大的。

當然，沒有任何一款 LLM 是完美的，每一款模型都有其「輸出不穩」的時刻。為了不讓自己被單一模型氣死，以下提供三個實用的建議：

1. 保持「雙持」狀態

建議長期最少手握兩款主流 LLM。當主力模型突然「失常」或變笨時，你可以馬上切換到備用模型繼續工作，確保開發流程不中斷。一位超聰明但有時會亂來的員工，一位聰明又重穩定的員工。

2. 資源許可下的「雙開」測試

對於 Token 額度充足，或是快到重置日（Reset Date）的朋友，遇到難題時不妨直接「雙開」。將同一個問題同時丟給兩款模型，看誰能最快給出正確解答。這往往是解決疑難雜症最高效的方法。

3. 工作前先查看 AI「狀態」

養成一個好習慣，每次開工前先去 aistupidlevel.info 查看各大 LLM 的即時穩定性。如果你發現今天慣用的模型狀態顯示「不在狀態」或智商掉線，請馬上切換另一個模型。

別為了省一點訂閱費或跟隨潮流，就輕易放棄目前寫 Code 最穩定的工具。在模型能力尚未全面超越之前，OpenAI Codex 體系依然是開發者最可靠的夥伴，而多準備一個後備方案，才是專業開發者的明智之舉。

科技