Vol 46.
Gemini CLI 一夜极限测评
以及我用 Claude Code 修复了 Gemini Cli
如果说 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（立即执行函数表达式）的写法。
这种模式，通常只有在你想”包装”或”改造”别人代码的时候才会大量使用。如果是从零开始写，谁会给自己加这么多层包装？
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 确实把一个原本闭源的商业产品，变成了开源项目。从结果来看，这对整个社区是有益的。
– 任何人都可以免费使用
– 可以修改并再分发
– 可以用于商业项目
– 唯一要求是保留原始版权声明
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:42
2. 网络超时太短: HTTPS 请求使用 Node.js 默认的 5 秒超时，但没有显式配置更长的超时时间
3. 未处理的 Promise 拒绝: 当网络请求超时失败时，触发全局未处理 Promise 拒绝处理器 packages/cli/src/gemini.tsx:218-231，直接调用 process.exit(1) 退出程序
具体流程
4. 程序运行约 60 秒后，Clearcut 遥测系统尝试发送批量数据到 play.googleapis.com/log
5. 由于网络连接问题（如你的错误日志显示的 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 服务时超时退出 - 遥测请求没有通过你的代理。最后基于 claude code 的分析以及我的经验与推断，得出了最终的答案，是 telemetry 通信的问题！
我立即提交 Issue：https://github.com/google-gemini/gemini-cli/issues/1425#issuecomment-3005831312
**结果发现一小时前已经有人捷足先登了！**这也太火爆了！！！
但还是把自己的方案提了上去，侧重我们是使用 claude code 完成的，而且结果一致！
这真地太令我欣慰了，而且我相信 gemini cli 也能做到这点！
见证历史：Star 增长曲线与社区狂欢
就在我提交 Bug 修复后的几个小时，我亲眼见证了开源社区的疯狂：
-
2 小时内 5k star -
8 小时内 10k star -
……
一位技术产品经理朋友的评价一针见血：
“这是人类 Vibe Coding 的大型社会实验！原先可能 1 个月才能迭代成熟的项目，现在一堆程序员 + Claude Code|Cursor|Windsurf 这些 Coding Agent… 可能一晚上就干之前半个月的工作量了！”
复盘：这一夜教会了我什么
### 三个核心洞察
1.Vibe Coding 不是未来，而是现在
– 我用 Claude Code 修复 Gemini CLI 的经历证明：AI 辅助开发已经可以处理复杂的 debug 任务
– 社区 + AI 的组合拳，让开发效率提升了不止 10 倍
2.开源的力量超乎想象
– 即使是”套壳”产品，一旦开源，社区的创造力会让它焕发新生
– Apache 2.0 协议降低了参与门槛，让每个人都能贡献
3.先入为主的判断要不得
– 我在没有充分调查的情况下，就断言 Google “抄袭”，这是非常不负责任的
– 技术相似不等于抄袭，可能只是大家都在解决同样的问题
– 这次经历提醒我：做技术评论要严谨，不能凭感觉就恶意揣测大厂的动机
行动指南：你也可以参与这场革命
如果你看到这里，心痒痒想要尝试，这里是我的建议：
1. 立即体验 Gemini CLI
# 安装
npm install -g @google-gemini/cli
# 开始使用
gemini --telemetry false --prompt "help me build a todo app"2. 加入社区贡献
-
GitHub: https://github.com/google-gemini/gemini-cli -
提 Issue、交 PR、参与讨论 -
用你擅长的 AI 工具来改进它（是的，用 AI 改进 AI！）
3. 探索 Multi-Agent 开发
基于 gemini-cli 的开放性，尝试构建：
-
代码生成 Agent -
Code Review Agent -
文档编写 Agent -
测试用例 Agent
让它们协同工作，这就是未来的开发模式！
结语：一夜见证历史
5 个小时前，我还在吐槽 Google 的不要脸。5 个小时后，我成了这场 Vibe Coding 革命的参与者和见证者。
从晚上 10 点半到凌晨 3 点，这个不眠之夜让我明白：技术变革往往以我们意想不到的方式到来。它可能不完美，甚至有点”脏”，但只要方向是对的，社区的力量会让它变得伟大。
正如我那晚发的朋友圈：
这是 Vibe Coding 革命的胜利！！！
而这，仅仅是第一枪。
相关参考资料：
（文：硅星人Pro）