Vol 46.

Gemini CLI 一夜極限測評

以及我用 Claude Code 修復了 Gemini Cli

作者：南川·2025-06-28

#開源#Claude-Code##Gemini-Cli##Vibe-Coding

如果說 Claude Code 是 AI 程式設計助手界的 iPhone——精緻、閉源、定義標準，那麼 Gemini CLI 就是 Android——開源、普惠、後發制人。

歷史告訴我們，這兩種模式都有其存在的價值，而最終的贏家是整個生態和使用者。

緣起：從群內訊息到深夜折騰

下午 4 點半，我們 Claude Code 交流群裡突然有人扔出一個連結："兄弟們，Google 剛開源了 Gemini CLI！"

當時我正在忙別的專案，只是瞄了一眼就繼續幹活了。直到晚上 10 點多，朋友圈和各種 AI 自媒體開始瘋狂刷屏，我才意識到——這事兒可能真的大了。

作為一個重度 Claude Code 使用者，我當時就來了精神——woc，Google 終於下場了？晚上 10 點半，關掉手頭的工作，開始了這場馬拉松式的測評。

二話不說，直接 npm install -g @google-gemini/cli，開始了我這五小時的魔幻之旅。

第一印象：這也太拉了吧？

22:30 – UI 都能做錯的 Google？

剛裝好興沖沖地執行 gemini，結果差點把我眼睛閃瞎——在我的暗色主題下，選了 ansi light、google code light 這些主題，文字內容根本看不清！

啊這… Google 的產品團隊是不是都不用暗色模式的？這種低階錯誤，像極了我第一次做前端時忘記測試深色模式的樣子。

22:45 – 它… 它不幹活？

更離譜的來了。我輸入一個簡單的指令，期待它像 Claude Code 一樣開始 planning、執行… 結果呢？

$ gemini "help me analyze this project structure"[等待中...][70秒後][程序退出]

我：？？？

這就像你滿懷期待地啟動了一輛法拉利，結果它在原地熄火了。

當時我的第一反應：這 TM 是 alpha 版本吧？不對，這連 alpha 都算不上，頂多算個 proof of concept。

劇情反轉：等等，這程式碼怎麼這麼眼熟？

23:01 – 社群的質疑聲

就在我準備放棄的時候，群裡有人說："這個 gemini-cli 怎麼跟 cc (Claude CLI) 這麼像？"

我心想，像就像唄，大家都是 CLI 工具，功能相似很正常… 直到我打開了原始碼。

23:06 – 震驚！核心 Prompt 幾乎一模一樣

當我開啟 https://github.com/google-gemini/gemini-cli/blob/main/packages/core/src/core/prompts.ts 這個檔案時，我整個人都傻了。

這… 這不就是 Claude CLI 的 prompt 嗎？連措辭都沒怎麼改！

23:13 – 程式碼結構分析：IIFE 包裝的痕跡

作為一個寫了多年程式碼的人，我一眼就看出了問題。整個程式碼充斥著 IIFE（立即執行函式表示式）的寫法。

這種模式，通常只有在你想"包裝"或"改造"別人程式碼的時候才會大量使用。如果是從零開始寫，誰會給自己加這麼多層包裝？

Tip

IIFE （Immediately Invoked Function Expression，立即呼叫執行函式）是一種 [JavaScript](https://developer.mozilla.org/zh-CN/docs/Glossary/JavaScript) [函式](https://developer.mozilla.org/zh-CN/docs/Glossary/Function)在定義後就會立即執行的習慣用法。它也被稱為_自執行匿名函式_。IIFE 這個名字是由 Ben Alman 在[他的部落格](https://web.archive.org/web/20171201033208/http://benalman.com/news/2010/11/immediately-invoked-function-expression/#iife)中提出的。

23:24 – 實錘了：這就是逆向 Claude CLI！

經過仔細比對，我可以 100% 確認：Gemini CLI 就是逆向 Claude CLI 後的套殼產品。

儘管 gemini cli 與 claude reverse 的程式碼並不完全一致，但互動方式一致、prompt 風格一樣，所以完全有理由只是用 AI 改寫了一遍。

當時我的心情… 怎麼說呢，就像你發現你崇拜的大廚，其實是在用預製菜。Google 啊 Google，你可是擁有世界頂級 AI 模型的公司，怎麼能幹出這種事？

我在朋友圈直接開噴："這是徹徹底底的抄襲與擠兌！"

冷靜之後的思考：但這可能是好事？

23:30 – Apache 2.0 的意義

罵完之後，我冷靜下來看了看 LICENSE 檔案——Apache 2.0。

這讓我陷入了沉思。雖然方式不太光彩，但 Google 確實把一個原本閉源的商業產品，變成了開源專案。從結果來看，這對整個社群是有益的。

Apache 2.0 是最商業友好的開源協議之一，意味著：

– 任何人都可以免費使用– 可以修改並再分發– 可以用於商業專案– 唯一要求是保留原始版權宣告

23:34 – 新的可能性

既然 Google 開了這個頭，那我們是不是可以基於它做更多事情？比如：

基於 gemini-cli 做一個 multi-agent 前端
讓不同的 agent 分別負責寫程式碼、code review、處理 PR
整合更多模型，不只是 Gemini
🤔

想到這裡，我又燃起了鬥志。

凌晨的突破：修復 Bug 的高光時刻

00:00 – 終於找到了問題所在！

折騰了一個多小時，各種 debug、查日誌、翻文件… 終於在午夜時分發現了問題的根源——API Key 配置有問題！

原來我一開始用的是一個測試專案的 key，許可權不對。gemini-cli 支援兩種認證方式：

使用 Google 賬號登入（訪問 /auth）
使用 API Key（從 https://aistudio.google.com/app/apikey 生成）

換了正確的 key 之後，它終於活了！

03:00 – 發現大陸使用者的特殊問題

就在我以為一切搞定，準備寫測評的時候，又出么蛾子了——程式每隔一分鐘就會自動退出。

凌晨 3 點，困得不行的我突然靈光一閃：這 TM 不會是 telemetry（遙測）的問題吧？

果然！經過一番除錯，發現是因為大陸網路環境下，gemini-cli 的遙測通訊會超時，導致程式異常退出。

03:13 – 用 Claude Code 修復 Gemini CLI 的 Bug！

這時候，戲劇性的一幕發生了——我開啟 Claude Code，讓它幫我分析和修復這個問題。

在合適的 prompt 下，Claude Code 很快就定位到了問題：

⏺ 根據分析，程式在接近一分鐘時退出的原因是：問題根源1. 遙測資料批次傳送: Clearcut 遙測日誌每 60 秒批次傳送一次資料 packages/core/src/telemetry/clearcut-logger/clearcut-logger.ts:422. 網路超時太短: HTTPS 請求使用 Node.js 預設的 5 秒超時，但沒有顯式配置更長的超時時間3. 未處理的 Promise 拒絕: 當網路請求超時失敗時，觸發全域性未處理 Promise 拒絕處理器 packages/cli/src/gemini.tsx:218-231，直接呼叫 process.exit(1) 退出程式具體流程4. 程式執行約 60 秒後，Clearcut 遙測系統嘗試傳送批次資料到 play.googleapis.com/log5. 由於網路連線問題（如你的錯誤日誌顯示的 ETIMEDOUT），請求在 5 秒後超時6. 超時錯誤變成未處理的 Promise 拒絕7. 全域性錯誤處理器捕獲到這個拒絕，列印"CRITICAL: Unhandled Promise Rejection!"訊息8. 程式呼叫 process.exit(1) 主動退出解決方案需要修改遙測系統的錯誤處理，使其在網路失敗時不導致整個程式退出，或者增加網路請求的超時時間和重試機制。

claude code 中途也產生了幻覺，但方向依舊是正確的：

> 為什麼我的網路會失敗，我配置了 vpn 代理呀~⏺ 讓我檢查一下 gemini-cli 是否正確使用了系統代理配置：⏺ Task(Check proxy configuration support)⎿  Done (19 tool uses · 64.7k tokens · 2m 33.2s)⏺ 找到問題了！你的 VPN 代理配置沒有生效是因為：問題原因Clearcut 遙測系統不使用代理設定 - 這是一個已知的缺陷。雖然 gemini-cli 對 API 請求有很好的代理支援：- 讀取 HTTP_PROXY, HTTPS_PROXY 環境變數- 使用 undici 的 ProxyAgent 處理所有 API 請求但是 Clearcut 遙測日誌器直接傳送 HTTPS 請求到 play.googleapis.com，完全繞過了代理配置。具體位置packages/core/src/telemetry/clearcut-logger/clearcut-logger.ts:108 - 直接使用 https.request() 而不是配置代理的請求方式。臨時解決方案你可以透過設定環境變數停用遙測來避免這個問題：export GEMINI_DISABLE_TELEMETRY=true長期解決方案需要修改 Clearcut 遙測系統，讓它也使用全域性配置的代理設定，或者提供在代理環境下停用遙測的選項。這解釋了為什麼即使你配置了 VPN 代理，程式仍然在嘗試連線 Google 服務時超時退出 - 遙測請求沒有透過你的代理。