Gemini CLI 一夜极限测评，谷歌掀翻了 Vibe Cod

互联网 0 65

硅星人 互联网资讯 发布于 6月27日 14:15

本条新闻为单纯事实消息的时事新闻，转载自硅星人，版权归源站所有，如有侵权，烦请联系我们。

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: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... 可能一晚上就干之前半个月的工作量了！"

复盘：这一夜教会了我什么

Summary

### 三个核心洞察

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 革命的胜利！！！

而这，仅仅是第一枪。