google-gemini/gemini-cli

想象一下这个场景：你正在调试一个棘手的 API 响应，终端里全是 JSON 和错误日志。你想知道某个字段为什么是 null，或者想快速写个脚本把数据清洗一下。你现在的做法是什么？复制一段日志，打开浏览器，登录 ChatGPT 或 Gemini 网页，粘贴进去，等它分析，再把结果复制回终端。如果分析结果里建议你改代码，你又得切回编辑器，改完再跑一遍，发现新错误，再复制、再粘贴。一个简单的排查，硬生生被切成四五个窗口，每次切换都在打断你的思路。你甚至可能因为懒得切窗口，就硬着头皮自己读那坨 JSON，花上十分钟。

gemini-cli 就是来解决这个撕裂感的。它是一个跑在你终端里的 AI 代理，你不需要离开命令行。安装很简单，一条 npm 命令就行。装完之后，你在终端里直接敲 `gemini` 开头的问题，比如 `gemini "解释一下这个错误日志"`，然后把日志贴进去。系统会调用 Google 的 Gemini 模型，把结果直接打印回你的终端。但它的能力远不止聊天。因为它跑在你的电脑上，它能直接操作你的文件系统、执行命令、读写代码。你可以说 `gemini "帮我写一个脚本，把当前目录下所有 .log 文件里的时间戳提取出来，按小时统计数量"`，它就会生成一个 Python 或 Shell 脚本，甚至直接帮你运行。它还能通过 MCP（Model Context Protocol）连接外部服务，比如你的数据库、你的 GitHub 仓库。你问它“上周的 bug 修复记录有哪些”，它能直接去查你的 Git 日志，然后总结给你。

它的核心机制，你可以把它想象成一个坐在你肩膀上的实习生。这个实习生懂代码、会写脚本、能查文档，但他没有自己的电脑，只能用你的终端。你告诉他“帮我把这个文件夹里的图片压缩一下”，他就开始翻你的文件，找图片，写压缩命令，然后问你“用 80% 质量可以吗？”你点头，他就执行。整个过程你不需要给他开浏览器，不需要给他解释什么是终端，因为他本来就住在里面。

跟市面上其他 AI 编程助手比，比如 GitHub Copilot 或者 Cursor，gemini-cli 走了一条完全不同的路。Copilot 和 Cursor 的核心是“补全”——你写代码，它猜你接下来要写什么，帮你自动补全。它们更像一个打字员，擅长在你已有的思路上加速。而 gemini-cli 的核心是“执行”——你给它一个任务，它自己规划步骤，自己写代码，自己跑，自己看结果，然后告诉你搞定了。Copilot 适合你在写代码时，它帮你省掉敲键盘的时间。gemini-cli 适合你不想写代码时，直接让它帮你把活干了。比如你想批量重命名 200 个文件，用 Copilot 你还是要自己写个循环，用 gemini-cli 你直接说“把文件名里的日期格式从 YYYYMMDD 改成 YYYY-MM-DD”，它就帮你搞定了。

当然，这种能力是有代价的。因为它能直接操作你的文件系统和执行命令，安全风险是明摆着的。你让它“删除所有临时文件”，它可能真的会删，而且如果它理解错了，删错了东西，你很难追责。虽然 gemini-cli 在每次执行危险操作前会跟你确认，但如果你习惯性地一路回车，风险就来了。另外，它依赖网络调用 Gemini API，如果你在离线环境或者网络不稳定，它就废了。还有，它目前有 1360 个 open issues，说明还在快速迭代中，有些边界情况可能处理得不好。如果你是一个对安全极度敏感、所有操作都需要审计日志的团队，或者你经常在完全没有网络的服务器上工作，那 gemini-cli 目前可能不适合你。

我有个朋友，后端工程师，负责维护一个老旧的微服务。上周他遇到一个 bug，某个接口偶尔返回 500，但日志里没有明显错误。他以前的做法是：先 grep 日志，找到异常时间点，然后手动 curl 那个接口，对比正常和异常的返回体，再翻代码找可能的原因。整个过程大概要四十分钟。这次他试了 gemini-cli。他直接在终端里敲：`gemini "帮我分析一下这个服务最近的 500 错误，日志在 /var/log/app/error.log，代码在 ./src，看看是什么原因"`。几秒钟后，gemini-cli 返回了一段分析，指出是某个第三方 SDK 在特定条件下抛出了空指针，还给出了修复建议。他照着改了，重新部署，问题解决。整个过程不到十分钟。他跟我说，那种感觉就像身边突然多了一个不用发工资的同事，而且这个同事从来不抱怨你代码写得烂。