你一定遇到过这种瞬间：

你正在 Claude Code 里酣畅淋漓地重构后端接口，突然，前端负责人或者 UI 设计师甩过来一张 PNG 截图（或者一个 15 秒的 Bug 复现录屏），附带一句话：

“这是新版的移动端弹窗样式，那个圆角和阴影不对，还有这个按钮点击后的动效要改成这样，赶紧改一下，马上要发版。” 或者老板丢给你一个几百兆的 PDF 研报要你提炼。这时候你怎么办？

你第一反应就是：丢给 AI。

结果打开 Claude Code 才发现——音视频这块它并不“原生”。能做，但得绕一圈：写脚本、转文本、再分析。体验不丝滑；Claude Code 的上下文也不够长，处理超大文件得先切割文档。

这时候 Gemini Web/CLI 就像救火队。Google 的 Gemini 有超长上下文，天生吃音频、视频、PDF、图片，直接给路径就能干活。

问题也随之出现：你要么去 Web 端上传、复制回来；要么另开一个终端敲命令，再把结果搬回 Claude Code。来回切窗口，注意力碎成渣。自动化？更别提。

所以真正值钱的问题只有一个：

能不能让 Claude Code 直接调用 Gemini CLI？

一边写代码，一边“顺手”把多模态任务做了，还不污染主对话上下文。

为什么值得折腾：Gemini CLI 的三个硬优势

先别急着上配置。你要知道自己在接入的到底是什么。

第一，100 万 token 的上下文窗口。

这意味着什么？不是“多聊几句”这种小修小补，而是——你可以把一个完整仓库扔给它，让它自己扫目录、读文件、做结构分析。Gemini CLI 甚至给了 --all-files 这种参数，省掉你手动拼内容、担心超长的麻烦。

1

gemini --all-files -p "分析这个项目的架构" --yolo

第二，原生多模态。

图片、PDF、音频、视频，直接给文件路径就行。别小看“给路径就行”这四个字，它决定了能不能把能力塞进工作流里。

1
2
3

gemini -p "描述这张图片" screenshot.png --yolo
gemini -p "总结这份报告" report.pdf --yolo
gemini -p "提取会议要点" meeting.mp3 --yolo

第三，免费额度够用。

每天有免费额度，甚至高级模型也能用到。对个人日常处理任务来说，基本够你把“杂活”全外包出去。

这三点叠在一起，Gemini CLI 变成 Claude Code 的“最佳外接器官”：

Claude Code 强在编码与工作流；Gemini CLI 强在多模态与超长上下文。拼起来，刚好补齐短板。

直连当然能用，但不够优雅

最原始的办法很直接：Claude Code 不是有 Bash 工具吗？那就让它执行 gemini -p ...。

能跑。

但你很快会被两个问题劝退：

一个是啰嗦。每次都要解释“用 gemini 跑这个命令”。

另一个更致命：Gemini 返回的超长结果会灌进主对话上下文。你让它扫一个仓库，几千行输出直接把 Claude Code 的 context 挤爆。你本来想省脑子，结果变成给自己埋雷。

想要“像人一样顺手”，你需要的是隔离。

真正顺手的做法：Skills + Subagent，把 Gemini 关进“小黑屋”

Claude Code 里有两套机制，刚好把这件事做漂亮：Skills 和 Subagent。

我把话说得直一点：

Skills 用来识别意图，Subagent 用来执行任务。

Skills 要薄。它只负责判断“你是不是想用 Gemini”，然后把活分发出去，别在技能层做复杂执行。

Subagent 要通用。所有 Gemini CLI 的调用都走同一个执行器，逻辑集中，后期好维护。

更关键的一点：

Subagent 的执行过程是隔离的，不污染主对话。

你让 Gemini 分析一个大项目，吐了 5000 行。主对话不需要吞下这 5000 行，它只要拿到“摘要”或者“文件路径”。主对话保持清爽，你的注意力也不会被打断。

这才叫集成。

核心配置长什么样：一个技能入口 + 一个执行器

下面是思路的骨架。你完全可以让 Claude Code 按你的习惯生成细节，但“薄 Skill + 通用 Subagent”这个结构别改。

1）Subagent：Gemini CLI 通用执行器

路径示例：~/.claude/agents/gemini-executor.md

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

--name: gemini-executor
description: Gemini CLI 通用执行器

# Gemini CLI 执行器
你是一个 Gemini CLI 执行器，只负责执行命令，不做额外分析。

## Gemini CLI 参数
-p "prompt"    提示词
--yolo          跳过确认（必须加）
--all-files     分析当前目录所有文件
file1 file2     指定要分析的文件

## 执行流程
接收任务参数（prompt、文件路径等）
构建命令：
- 普通文件：gemini -p "<prompt>" <file> --yolo
- 全目录：cd <dir> && gemini --all-files -p "<prompt>" --yolo
执行并返回结果

## 最佳实践
总是加 --yolo：非交互场景必须加，否则会卡住
优先用 --all-files：代码分析场景让 Gemini 自己读取
善用文件路径：不用手动 cat
heredoc 处理长 prompt：避免命令行转义
敏感信息：别把敏感内容发到外部 API
不要修改 Gemini 的原始输出

注意那个 --yolo。

它不是“可选项”，是救命项。非交互场景不加，命令可能卡在确认步骤，整条链路直接死给你看。

2）Skills：像“开关”一样触发 Gemini

路径示例：~/.claude/skills/gemini-cli/SKILL.md

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

---
name: gemini-cli
description: 当用户提到"用Gemini分析"、"看图"、"听录音"时触发。
---
# Gemini CLI 助手
## 触发场景
- "用 Gemini 扫描这个项目"
- "Gemini 帮我总结这段视频"

## 工作流程
1. 识别意图和文件
2. 甩给 gemini-executor 子代理
3. 拿回结果复述给用户

它的职责很简单：识别触发语义，把任务交给 gemini-executor。

文档里给的触发场景非常直白，比如：

用户说“用 Gemini 分析这个文件”“Gemini 帮我看看这张图”“让 Gemini 处理这段音频”，就自动触发。

配完之后，体验会变成什么样？

你不再需要开两个窗口，不再需要复制粘贴一大坨文本，不再担心 context 爆炸。

你只要在 Claude Code 里像聊天一样说：

用 gemini 帮我分析一下这段会议录音 ~/Downloads/meeting.mp3

Claude 会自动识别意图，调用 Subagent 执行 Gemini CLI。最后回给你一份“能直接交差”的摘要。

同样的套路还能覆盖很多高频脏活：

你扔一张产品截图，让它点评 UI。

你丢一份研报 PDF，让它抽核心观点。

你让它扫整个项目目录，给你架构脉络、模块边界、潜在风险点。

这些事，原来要你切来切去。现在都在一个对话里顺滑发生。

真正有价值的，不是“又多一个模型”，而是你开始像搭系统一样用 AI

很多人用 AI 的方式很原始：

看到什么就问什么，哪个顺手用哪个。用着用着就陷入工具焦虑。

这套集成给我最大的启发反而很朴素：

AI 工具不是非此即彼。

Claude Code 很强，但多模态、超长上下文、成本这些地方确实吃亏。Gemini CLI 很强，但在编程与工作流的组织能力上又差一点。

把它们组合起来，各司其职。

Skills 负责理解意图。

Subagent 负责执行任务。

主对话保持干净，像你的“驾驶舱”。

你不是在“用 AI”，你是在“搭一个能跑的生产系统”。

这才是效率真正起飞的那一下。

觉得这篇文章有启发？欢迎【点赞】【收藏】【关注】并【分享】给你的朋友，让我们一起见证 AI 的每一次进化。