夜雨聆风
今日推荐：Gemini CLI
今天有个热搜很适合拿来聊 AI 工具：大模型收费合理吗？
这个问题表面上是在问价格，实际上是在问另一件事：AI 到底能不能进入普通人的真实工作流。
如果一个工具只是陪你聊几句，收费再便宜，你也会觉得它可有可无。可如果它能帮你读代码、改文件、跑命令、查资料、接自动化脚本，甚至在 GitHub 里帮你看 PR 和分流 issue，那它就不再是“聊天会员”，而更像一个新的工作入口。
所以今天想聊的项目是 Google 开源的 Gemini CLI。
截至 2026 年 6 月 21 日，这个项目在 GitHub 上已经超过 10.5 万星，使用 TypeScript 编写，Apache-2.0 协议开源。它的描述很直接：把 Gemini 的能力带进你的终端。
它不是网页版 Gemini 的命令行皮肤
很多人听到 CLI 工具，第一反应是：这不就是把网页聊天框搬到终端里吗？
如果只是这样，那确实没什么好写。
Gemini CLI 真正有意思的地方，是它把 AI 放进开发者已经每天使用的地方。不是让你打开一个新网页，然后手动复制代码、粘贴报错、再复制答案回来，而是让 AI 直接站在当前项目目录里，看文件、理解上下文、调用工具、执行命令。
这件事的体验差异很大。
网页聊天适合“问一个问题”。终端 Agent 更适合“处理一件事”。
比如你在一个陌生仓库里，想知道昨天改了哪些关键逻辑；或者你接手一个老项目，想先理解目录结构；再或者测试失败了，你希望有人先帮你定位是依赖问题、配置问题，还是代码本身的问题。
这些场景里，AI 如果不能接触项目现场，就只能靠你喂材料。材料喂少了，它猜；材料喂多了，你累。
Gemini CLI 的价值就在这里：它把模型、文件、命令和项目上下文放在同一个工作台上。
为什么它能火
Gemini CLI 的 README 里给出的几个卖点很清楚。
第一，它有比较慷慨的个人免费额度：个人 Google 账号登录后，README 写的是每分钟 60 次请求、每天 1000 次请求。对很多开发者来说，这已经足够日常试用。
第二，它能访问 Gemini 3 模型，并支持 100 万 token 上下文窗口。大白话说，就是它一次能看进去更多项目背景，不容易读两段代码就忘了前因后果。
第三，它内置了不少工具能力，包括 Google Search grounding、文件操作、Shell 命令、网页抓取。也就是说，它不只是“会回答”，还可以“会动手”。
第四，它支持 MCP。MCP 可以理解成给 AI 工具接外设的标准接口，你可以通过 MCP Server 把数据库、Slack、内部系统、媒体生成工具等能力接进来。
这些点合在一起，Gemini CLI 就不只是一个命令行玩具，而是 Google 在开发者工作流里放下的一颗钉子。
最值得关注的是非交互模式
如果你只把 Gemini CLI 当成一个终端聊天工具，它还不算特别新鲜。
我更在意的是它的非交互模式。
README 里有这样的用法：用 gemini -p 直接让它执行一段提示词，还能通过 --output-format json 或 stream-json 拿结构化结果。
这意味着它可以被脚本调用。
这一步很关键。
聊天框解决的是“人临时问 AI”。脚本解决的是“系统固定调用 AI”。前者是效率工具，后者才是自动化能力。
比如每天早上自动总结昨天的提交；每次发版前让 AI 先扫一遍变更风险；每个新 issue 进来先做分类；内部文档更新后自动生成摘要；一个长任务执行过程中，把状态以结构化日志吐出来。
这些事情单独看都不大，但加起来就是团队效率。
真正的 AI 工具，不应该只在你想起来时才出现。它应该能被放进流程里，在合适的节点自动出现。
GitHub 集成也很有想象空间
Gemini CLI 还提供了 GitHub Action 集成方向。
按照 README 的说明，它可以用于 Pull Request Review、Issue Triage、在 issue 和 PR 里通过提及 @gemini-cli 获取帮助，也可以做团队定制的自动化工作流。
这类能力会改变一部分团队协作习惯。
过去我们写代码，很多“轻量检查”都靠人肉：这个 PR 有没有明显风险？这个 issue 应该打什么标签？这个报错有没有重复问题？这个需求要不要先补信息？
AI 不一定能替你做最终判断，但它很适合做第一轮整理。
它把散乱信息先归类，把上下文先拉齐，把明显问题先标出来。人再接手时，脑子不用从一地碎片开始拼。
这也是我最近越来越相信的一点：AI 编程工具的竞争，不会只发生在模型参数上，而会发生在“谁离工作现场更近”。
它适合谁
第一类，是每天在终端里工作的开发者。
你本来就在命令行里查日志、跑测试、看 diff、改配置。Gemini CLI 的优势是不用切换太多场景，它直接在你工作的地方出现。
第二类，是小团队里的技术负责人。
小团队的问题通常不是没有工具，而是每个流程都差半口气：PR 没人先看、issue 没人分、脚本没人补、文档没人整理。Gemini CLI 这类工具能先把这些杂活接住一部分。
第三类，是正在做 AI 应用的人。
你可以把它当成一个很好的样本：AI 产品不一定非要做成聊天窗口。它也可以变成命令、脚本、Action、扩展协议，嵌进已有工作流。
需要冷静看的地方
当然，它也不是万能药。
第一，终端 Agent 的门槛天然比网页聊天高。它需要你理解文件权限、命令执行、项目目录、凭证配置这些东西。
第二，一旦工具能执行命令，就必须认真对待安全边界。AI 帮你动手很爽，但“能动手”也意味着要设置规则、确认危险操作、保护敏感信息。
第三，它更适合开发者和技术团队，不太适合完全不碰代码的人。普通用户如果只是写文案、做总结，网页端可能更省心。
所以我不会把 Gemini CLI 推荐给所有人。
但如果你已经习惯用命令行，它很值得试。
二万怎么看
Gemini CLI 真正厉害的地方，不是“Google 也做了一个 AI 编程助手”，而是它把模型放进终端、脚本和 GitHub 工作流里。优点是额度友好、上下文长、扩展性强；缺点是安全和上手门槛都要认真对待。推荐指数：★★★★☆。
一句话总结
Gemini CLI 代表的趋势很清楚：AI 正在从聊天框里走出来，进入命令行、仓库、脚本和团队流程。
如果你每天都在终端里工作，它不是一个“可以收藏一下”的项目，而是一个值得花半小时亲手跑一遍的工具。
项目地址：
https://github.com/google-gemini/gemini-cli
如果觉得有用，点个「在看」支持二万
每天分享一个好用的AI工具/思路
关注我，一起搞懂AI
The best interface is the one already inside your workflow.
别再只问 AI 一个问题了，把它放进你每天工作的地方。
—— 二万
