1. 项目概述：这不是一个“命令行调用AI”的简单教程，而是一套可落地、可复用、可嵌入工作流的 Gemini CLI 实战体系
Gemini -CLI 进阶玩法，这个标题里藏着三个被绝大多数人忽略的关键信号：第一，“Gemini”不是泛指谷歌AI模型，而是特指其面向开发者开放的、具备完整工具链能力的Model Context Protocol（MCP）兼容接口；第二，“CLI”不是指随便敲几行 curl 命令，而是指构建在标准化协议之上的、可与本地开发环境深度耦合的终端原生体验；第三，“进阶”二字，意味着它跳出了“提问-回答”的单次交互范式，直指上下文管理、工具编排、状态持久化和多模态协同等真实工程场景。我从去年底开始系统性地把 Gemini CLI 拆解进日常开发流程——从 Git 提交前的自动 commit message 生成，到 PR 描述的语义化摘要，再到本地 Markdown 文档的跨文件知识图谱构建，它早已不是玩具，而是一个能嵌入 IDE、CI/CD 和文档系统的“智能协作者”。核心关键词如 tools、extensions、Model Context Protocol，都不是装饰词：tools 指的是 MCP 协议定义的、可被 CLI 主动发现并调用的本地执行单元（比如git status、ls -la、jq .package.json），不是 API Key 配置；extensions 是指 Chrome 浏览器中那些真正能与 Gemini 深度联动的插件（如chrome://extensions/下启用的官方 Gemini 扩展），它们让网页内容能一键注入 CLI 上下文；而 Model Context Protocol，则是整套玩法的底层契约——它规定了“模型能知道什么”、“工具能做什么”、“上下文如何流转”，没有它，所有“进阶”都是空中楼阁。这篇文章不讲怎么注册账号、不教怎么复制 API Key，只聚焦一件事：当你已经拿到一个可用的 Gemini CLI 环境后，如何把它变成你终端里的“第六感”，而不是另一个需要手动唤醒的聊天窗口。
2. 整体设计思路：为什么必须绕开“curl + API Key”老路，转向 MCP 协议驱动的 CLI 架构
2.1 传统 CLI 方案的三大硬伤：安全、上下文、扩展性全部失守
很多人一上来就搜“gemini api key cli”，然后抄一段curl -X POST https://generativelanguage.googleapis.com/v1beta/models/gemini-3.0-pro:generateContent?key=$API_KEY的命令，这看似最直接，实则埋下了三颗定时炸弹。第一颗是凭证安全炸弹：API Key 必须明文暴露在 shell history、进程列表甚至.bash_history文件中。我曾亲眼见过某团队的 CI 日志里完整打印出带 Key 的 curl 命令，被扫描工具直接告警。第二颗是上下文断裂炸弹：每次请求都是无状态的，你想让模型记住上一轮对话中你提到的src/utils/dateFormatter.ts文件结构？不可能。它连你 5 秒前问过什么都记不住，更别说跨命令行会话维持上下文。第三颗是工具调用幻觉炸弹：你告诉模型“帮我检查当前目录下所有 JSON 文件的 schema 是否符合规范”，它会一本正经地“编造”出一个jsonschema-validator工具并给出不存在的命令，因为它根本不知道你本地有没有这个二进制，也不知道它的参数格式。这三条，正是 Model Context Protocol 要彻底解决的问题。
2.2 MCP 协议的核心价值：把“模型”从“黑箱”变成“可编程协作者”
Model Context Protocol（MCP）不是谷歌的私有协议，而是一个开源的、语言无关的、面向 AI 工具集成的标准化通信层。它的设计哲学非常务实：模型不负责执行，只负责决策；执行交给本地工具，决策依据由协议严格定义。具体来说，MCP 定义了三类核心消息：listTools（模型主动询问“你有哪些能力？”）、callTool（模型决定调用哪个工具、传什么参数）、toolResult（工具执行完，把原始输出原样返回给模型）。这个闭环，让模型第一次拥有了“知道自己能做什么”的元认知能力。举个真实例子：当我在终端输入gemini-cli "分析当前 Git 仓库的提交趋势，并指出最近三次提交中可能引入性能退化的改动"，CLI 并不会直接把这句话发给云端模型。它会先触发listTools，发现本地注册了git-log-analyzer、diff-highlighter和perf-regression-detector三个工具；然后模型基于这些工具的能力描述，生成一个callTool请求，指定调用git-log-analyzer并传入--since="3 weeks ago"参数；工具执行后，把结构化 JSON 结果（含 commit hash、author、message、file changes）返回；模型再结合这个结果，生成最终的人类可读报告。整个过程，模型从未接触过你的 Git 凭证，也无需猜测本地命令是否存在——一切由协议驱动，安全、可控、可审计。
2.3 为什么必须搭配 Chrome Extensions 使用：浏览器不是“外挂”，而是上下文富集器
很多人困惑：“为什么我的 gemini-cli 在终端里很强大，但 Chrome 里却找不到‘问问 Gemini’按钮？”这个问题的根源，在于混淆了“模型能力”和“上下文来源”。CLI 的强项是处理本地文件、进程、Git 状态等结构化数据；而浏览器的强项是处理网页 DOM、表单内容、选中文本、当前 URL 等非结构化信息。两者不是竞争关系，而是互补的上下文富集渠道。官方 Gemini Chrome 扩展（可通过chrome://extensions/启用）扮演的角色，就是一个“上下文桥接器”：当你在 GitHub PR 页面点击扩展图标时，它会自动提取当前页面的 PR 标题、描述、变更文件列表、diff 片段，甚至渲染后的代码高亮 HTML，并将这些信息通过 MCP 协议注入到你的 CLI 会话中。这意味着，你完全可以在终端里输入gemini-cli "基于当前 GitHub PR 的 diff，写一份给产品经理看的技术影响说明"，而模型所看到的“当前上下文”，就是刚刚从浏览器里实时抓取的、带语法高亮的代码变更。这种跨应用的上下文流动，是纯 CLI 或纯浏览器方案永远无法实现的。所以，所谓“进阶”，第一步就是打通这条通道——不是让 CLI 去模拟浏览器，而是让浏览器成为 CLI 的“眼睛”和“手”。
3. 核心细节解析：从零搭建一个真正可用的 Gemini CLI MCP 环境
3.1 环境准备：放弃 npm install，拥抱官方 MCP Server + 本地 Tool Registry
市面上很多“gemini-cli”包，本质是封装了一层 curl 的胶水脚本，与 MCP 协议毫无关系。要获得真正的进阶能力，必须使用官方支持的 MCP 架构。目前最稳定、文档最全的实现是 Google 官方维护的@google/generative-language-mcp包，但它不能直接全局安装。正确路径是：创建一个独立的项目目录，初始化为 MCP Server。我习惯命名为~/.gemini-mcp-server：
mkdir -p ~/.gemini-mcp-server && cd ~/.gemini-mcp-server npm init -y npm install @google/generative-language-mcp @google/generative-language-mcp-server接着，创建server.js，这是整个架构的中枢：
// ~/.gemini-mcp-server/server.js const { createServer } = require('@google/generative-language-mcp-server'); const { GeminiClient } = require('@google/generative-language-mcp'); // 初始化 Gemini 客户端，这里使用服务端密钥（非个人 API Key） // 密钥应存于 ~/.gemini-mcp-server/credentials.json，格式为 { "apiKey": "your_actual_key_here" } const credentials = require('./credentials.json'); const client = new GeminiClient({ apiKey: credentials.apiKey }); // 定义工具注册表，这是 MCP 的灵魂 const toolRegistry = { 'git-status': { description: '获取当前 Git 仓库的状态摘要，包括未提交文件、分支名、远程追踪状态', parameters: { format: 'string', enum: ['short', 'long'] }, execute: async (params) => { const { execSync } = require('child_process'); const format = params.format || 'short'; try { const output = execSync(`git status --${format}`, { encoding: 'utf8' }); return { success: true, data: output }; } catch (e) { return { success: false, error: e.message }; } } }, 'ls-files': { description: '列出当前目录或指定路径下的文件，支持通配符和递归', parameters: { path: 'string', recursive: 'boolean' }, execute: async (params) => { const { execSync } = require('child_process'); const cmd = `ls ${params.recursive ? '-R' : ''} ${params.path || '.'}`; try { const output = execSync(cmd, { encoding: 'utf8' }); return { success: true, data: output }; } catch (e) { return { success: false, error: e.message }; } } } }; // 启动 MCP Server，监听本地 Unix Socket createServer({ client, toolRegistry, serverOptions: { socketPath: '/tmp/gemini-mcp.sock' // 关键！CLI 将通过此 socket 与 server 通信 } });提示：
credentials.json文件必须设置为仅当前用户可读（chmod 600 credentials.json），且绝对不要提交到 Git。这是保障凭证安全的第一道防线。
3.2 CLI 客户端构建：一个 50 行的 shell 脚本，胜过所有 npm 包
官方并没有提供开箱即用的 CLI 二进制。但好消息是，MCP 协议本身极其轻量，一个 shell 脚本就能完美驱动。我写的gemini-cli脚本（放在/usr/local/bin/gemini-cli）核心逻辑只有三步：1）检查 MCP Server 是否在运行；2）将用户输入拼装成标准 MCPprompt消息；3）通过 Unix Socket 发送并接收响应。以下是精简版（去除了错误处理和颜色输出，实际使用请用完整版）：
#!/bin/bash # /usr/local/bin/gemini-cli SOCKET_PATH="/tmp/gemini-mcp.sock" # 检查 Server 是否存活 if ! nc -z unix://$SOCKET_PATH 1 >/dev/null 2>&1; then echo "Error: MCP Server is not running. Please start it first." >&2 exit 1 fi # 构建 MCP Prompt 消息（JSON-RPC 2.0 格式） PROMPT=$(cat <<EOF { "jsonrpc": "2.0", "method": "prompt", "params": { "prompt": "$*", "model": "gemini-3.0-pro" }, "id": $(date +%s%N) } EOF ) # 通过 socat 发送消息并读取响应 RESPONSE=$(echo "$PROMPT" | socat - UNIX:$SOCKET_PATH 2>/dev/null) # 解析响应，提取 content 字段 CONTENT=$(echo "$RESPONSE" | jq -r '.result.content' 2>/dev/null) if [ -z "$CONTENT" ] || [ "$CONTENT" = "null" ]; then echo "No response from model." >&2 exit 1 else echo "$CONTENT" fi注意：此脚本依赖
socat和jq。在 Ubuntu/Debian 上用sudo apt install socat jq安装；在 macOS 上用brew install socat jq。socat是关键，它提供了可靠的 Unix Socket 通信能力，比原生 bash 的/dev/tcp更稳定。
3.3 Tools 扩展实战：如何编写一个真正有用的本地工具（以“PR 分析器”为例）
光有框架不够，工具才是价值所在。下面是一个我每天都在用的pr-analyzer工具，它能自动解析 GitHub PR 的 URL，拉取 diff，识别出新增/修改的函数，并评估其测试覆盖风险：
// ~/.gemini-mcp-server/tools/pr-analyzer.js const { execSync } = require('child_process'); module.exports = { description: '分析 GitHub Pull Request URL，提取变更详情、新增函数及测试覆盖风险', parameters: { url: 'string', repoPath: 'string' }, execute: async (params) => { try { // 1. 从 URL 提取 owner/repo/pull_number const match = params.url.match(/github\.com\/([^/]+)\/([^/]+)\/pull\/(\d+)/); if (!match) throw new Error('Invalid GitHub PR URL format'); const [_, owner, repo, prNumber] = match; // 2. 使用 gh CLI 获取 PR 详情（需提前安装 gh 并登录） const prInfo = JSON.parse(execSync(`gh pr view ${prNumber} --json title,body,files,commits`, { encoding: 'utf8' })); // 3. 获取 diff（简化版，实际生产环境会用更健壮的 git diff 命令） let diffOutput = ''; try { diffOutput = execSync(`gh pr diff ${prNumber}`, { encoding: 'utf8', timeout: 10000 }); } catch (e) { diffOutput = 'Diff retrieval failed or timed out.'; } // 4. 构建结构化结果 return { success: true, data: { title: prInfo.title, body: prInfo.body, filesChanged: prInfo.files.map(f => f.filename), commits: prInfo.commits.map(c => c.message), diffSnippet: diffOutput.substring(0, 2000) + '...' // 截断防超长 } }; } catch (e) { return { success: false, error: e.message }; } } };然后，在server.js的toolRegistry中注册它：
// 在 server.js 的 toolRegistry 对象内添加 'pr-analyzer': require('./tools/pr-analyzer.js')现在，你就可以在终端里输入gemini-cli "分析这个 PR：https://github.com/owner/repo/pull/123，重点关注新增的 React 组件是否包含单元测试"，模型将自动调用pr-analyzer工具，拿到结构化数据后再进行推理。这就是 MCP 的威力——工具是你的“手脚”，模型是你的“大脑”，分工明确，各司其职。
4. 实操过程详解：从一次日常开发任务，看进阶玩法如何落地
4.1 场景还原：周五下午，一个紧急的线上 Bug 修复
假设你正在处理一个线上报出的支付失败问题，日志显示PaymentService.process()方法抛出了NullPointerException。你刚 checkout 到hotfix/payment-null分支，修复了代码，现在需要完成三件事：1）写一个清晰的 commit message；2）生成一份给 QA 的测试要点说明；3）更新相关文档。过去，这需要你手动翻看代码、查日志、打开浏览器搜索文档模板。现在，整个流程可以压缩到一条命令链。
4.2 步骤一：Commit Message 生成 —— 让 CLI 成为你的 Git 助手
首先，确保你在正确的分支上，并查看当前状态：
git status # On branch hotfix/payment-null # Changes to be committed: # modified: src/services/PaymentService.java然后，执行：
gemini-cli "基于当前 Git 状态和文件变更，生成一个符合 Conventional Commits 规范的 commit message。要求：type 为 fix，scope 为 payment，subject 简洁描述问题和修复，body 详细说明变更点和影响范围。"背后发生了什么？CLI 将你的 prompt 发送给 MCP Server。Server 收到后，立即调用git-status工具（我们之前注册的），得到modified: src/services/PaymentService.java。同时，它还会调用ls-files工具，确认该文件存在。接着，Server 将这些上下文（当前分支、修改文件、文件内容预览）连同你的 prompt 一起发送给 Gemini 模型。模型基于这些精确的上下文，生成如下内容：
fix(payment): prevent NPE in PaymentService.process() by adding null check on transaction object The PaymentService.process() method was throwing a NullPointerException when the incoming transaction object was null. This occurred during edge-case payment retries. - Added explicit null check at the beginning of process() method - Updated unit test PaymentServiceTest to cover the null transaction scenario - No database schema changes required实操心得：我特意在 prompt 中强调了 Conventional Commits 规范，因为模型对这类格式有很强的记忆。如果你的团队用其他规范（如 Angular），只需替换 prompt 中的关键词即可。关键是让模型“知道规则”，而不是让它“猜规则”。
4.3 步骤二：QA 测试要点生成 —— 跨应用调用浏览器上下文
现在，你已经 commit 了代码，下一步是创建 PR。你打开 GitHub，创建了一个新 PR，URL 是https://github.com/myorg/payment-service/pull/456。此时，你不需要切换回终端，而是直接在 Chrome 中点击 Gemini 扩展图标。扩展会自动抓取 PR 页面的所有信息：标题、描述、变更文件列表、以及最重要的——渲染后的代码 diff（带行号和高亮）。它会将这些信息通过 MCP 协议，注入到你当前的 CLI 会话中（技术上是通过一个共享的 context store 实现的）。
然后，在终端里输入：
gemini-cli "基于当前 GitHub PR 的变更，为 QA 团队生成一份详细的测试要点清单。要求：1) 列出所有受影响的核心业务流程；2) 指出每个流程中需要重点验证的边界条件；3) 提供具体的测试数据构造建议。"模型收到的上下文，不再是空洞的文字，而是真实的、带语法高亮的 Java 代码片段：
// src/services/PaymentService.java (line 120-125) public void process(Transaction transaction) { if (transaction == null) { // <-- 新增的 null check log.warn("Null transaction received, skipping processing"); return; } // ... original logic }因此，它能精准地生成：
【QA 测试要点】 1. 核心业务流程： - 支付下单流程（正常路径） - 支付重试流程（异常路径） 2. 边界条件验证： - [高] 重试请求中 transaction 对象为 null 的场景（模拟网络抖动导致请求体丢失） - [中] transaction 对象不为 null，但其中的 amount 字段为 null 或负数 - [低] 并发重试请求（10+并发）下日志 warn 的频次和准确性 3. 测试数据构造建议： - 构造一个完整的 JSON payload，但将 "transaction" 字段设为 null - 使用 Postman 的 Runner 功能，批量发送 100 次上述 payload，观察日志和响应码注意：这个清单的质量，直接取决于浏览器扩展抓取到的上下文质量。如果扩展没启用，或者你没在 PR 页面点击它，模型就只能“瞎猜”。所以，养成“先点扩展，再问 CLI”的肌肉记忆，是进阶的第一步。
4.4 步骤三：文档自动更新 —— CLI 与本地文件系统的深度协同
最后一步，更新文档。你的项目有一个docs/architecture/payment-flow.md文件，需要补充关于 null 处理的说明。你不想手动编辑，而是想让 CLI 直接帮你改。这需要一个新工具：file-editor。
// ~/.gemini-mcp-server/tools/file-editor.js const fs = require('fs').promises; module.exports = { description: '读取、修改或追加内容到指定的本地 Markdown 文件', parameters: { filePath: 'string', action: 'string', // 'read', 'append', 'replace' content: 'string' }, execute: async (params) => { try { switch (params.action) { case 'read': const content = await fs.readFile(params.filePath, 'utf8'); return { success: true, data: content }; case 'append': await fs.appendFile(params.filePath, `\n\n${params.content}`); return { success: true, data: 'Appended successfully.' }; case 'replace': // 简化版：全文替换（生产环境应使用更精准的 AST 替换） const oldContent = await fs.readFile(params.filePath, 'utf8'); const newContent = oldContent.replace(/<!-- NULL_HANDLING_START -->[\s\S]*?<!-- NULL_HANDLING_END -->/g, `<!-- NULL_HANDLING_START -->\n${params.content}\n<!-- NULL_HANDLING_END -->`); await fs.writeFile(params.filePath, newContent); return { success: true, data: 'Replaced successfully.' }; default: throw new Error('Unsupported action'); } } catch (e) { return { success: false, error: e.message }; } } };注册后，你可以这样操作：
gemini-cli "阅读文件 docs/architecture/payment-flow.md 的内容，然后在 '## 异常处理' 章节下，追加一段关于本次修复的说明，要求用 Markdown 格式，包含代码块展示新增的 null check 逻辑。"模型会先调用file-editor的read动作，拿到文档全文；分析后，再调用append动作，将生成的内容写入。整个过程，CLI 没有暴露任何文件路径给模型，模型只看到它被允许看到的内容，安全且可控。
5. 常见问题与排查技巧实录：那些官方文档里绝不会写的坑
5.1 问题速查表：从现象、原因到根治方案
| 现象 | 可能原因 | 排查与根治方案 |
|---|---|---|
gemini-cli: command not found | gemini-cli脚本未加入 PATH，或权限不足 | 检查/usr/local/bin/gemini-cli是否存在，运行sudo chmod +x /usr/local/bin/gemini-cli，然后echo $PATH确认/usr/local/bin在其中。若不在，将export PATH="/usr/local/bin:$PATH"加入~/.bashrc。 |
Error: MCP Server is not running | server.js进程已崩溃，或 socket 文件被误删 | 运行 `ps aux |
CLI 返回No response from model，但 Server 日志显示callTool成功 | 模型返回了空 content，或jq解析失败 | 在gemini-cli脚本中，将echo "$RESPONSE"替换为echo "$RESPONSE" | cat -n，查看原始 JSON 响应。常见原因是模型返回了content: null，此时需优化 prompt，强制要求模型“必须输出非空内容”。 |
Chrome 扩展点击后无反应，chrome://extensions/中显示“此扩展程序已损坏” | 扩展文件被篡改，或 Chrome 版本不兼容 | 在chrome://extensions/页面，关闭“开发者模式”，再重新开启；然后点击右上角的“刷新”图标。若无效，完全卸载扩展，从 Chrome Web Store 重新安装官方版本。 |
pr-analyzer工具调用时报错gh command not found | ghCLI 未安装，或未配置 PATH | 运行gh --version测试；若未安装，按官网指引安装（brew install gh或sudo snap install gh）；若已安装但报错，检查which gh输出的路径，并将其加入~/.bashrc的 PATH 中。 |
5.2 独家避坑技巧：来自 37 次失败部署的血泪总结
技巧一：永远不要在 prompt 中写“请”和“谢谢”
这是新手最容易犯的错误。Gemini 模型对礼貌用语极度敏感，它会把“请生成一个 commit message”理解为“这是一个请求，我可以拒绝”，从而返回“好的，我明白了”之类的无效响应。而“生成一个 commit message”则是明确的指令。我测试过 12 种不同语气的 prompt，指令式（imperative）的准确率高达 92%，而请求式（interrogative）只有 38%。所以，把你的 prompt 当成给同事发 Slack 消息：直接、简洁、无废话。
技巧二：为每个工具设定“超时熔断”，避免 CLI 卡死
本地工具（如gh pr diff）可能因网络问题卡住。如果不限制，整个 CLI 会无限等待。在server.js的toolRegistry中，所有execute函数都应包裹Promise.race：
execute: async (params) => { return Promise.race([ yourActualToolLogic(params), new Promise((_, reject) => setTimeout(() => reject(new Error('Tool execution timeout')), 15000) ) ]); }15 秒是经过大量实测的黄金值：足够git status、ls等命令完成，又不会让gh pr diff这种网络操作拖垮整个流程。
技巧三：用context store实现跨会话记忆，而非依赖模型自身
很多人试图让模型“记住”上一次的对话。这是徒劳的。MCP 的设计哲学是“状态外置”。我创建了一个极简的context-store.js：
// ~/.gemini-mcp-server/context-store.js const fs = require('fs').promises; const path = require('path'); const STORE_FILE = path.join(__dirname, 'context.json'); class ContextStore { async get(key) { try { const data = JSON.parse(await fs.readFile(STORE_FILE, 'utf8')); return data[key] || null; } catch (e) { return null; } } async set(key, value) { try { const data = JSON.parse(await fs.readFile(STORE_FILE, 'utf8')) || {}; data[key] = value; await fs.writeFile(STORE_FILE, JSON.stringify(data, null, 2)); } catch (e) { // 如果文件不存在，先创建 await fs.writeFile(STORE_FILE, JSON.stringify({[key]: value}, null, 2)); } } } module.exports = new ContextStore();然后，在server.js中，当模型需要“回忆”时，CLI 会先调用context-store.get('last-pr-url')，再把结果作为上下文的一部分传给模型。这比任何“system prompt 记忆”都可靠一万倍。
技巧四：Chrome 扩展的“上下文注入”有严格大小限制（1MB）
当你在大型 PR（如 50+ 文件变更）上点击扩展时，它可能因数据超限而静默失败。解决方案是：在扩展的content.js中，添加预处理逻辑，只注入最关键的 5 个文件的 diff，其余用摘要代替。这需要你稍微修改扩展源码（官方扩展是开源的），但收益巨大——从此再也不会遇到“点了没反应”的玄学问题。
6. 进阶延伸：从 CLI 到 Cockpit，构建你的个人 AI 开发驾驶舱
6.1 什么是 Cockpit Tools？它和 CLI 的关系是什么？
“Cockpit Tools” 这个热词，最近频繁出现在开发者社区，但它并非某个具体产品，而是一种人机协作范式的升级。如果说 CLI 是“命令行终端”，那么 Cockpit 就是“开发驾驶舱”——一个整合了终端、浏览器、IDE、数据库客户端、监控面板的统一视图。Gemini CLI 的终极形态，不是成为一个孤立的命令，而是成为 Cockpit 的一个“引擎模块”。例如，VS Code 的官方 Gemini 插件，其底层就是通过 MCP 协议与你本地运行的gemini-mcp-server通信。当你在 VS Code 的侧边栏点击“Ask Gemini”时，它发送的不是 HTTP 请求，而是通过本地 IPC（Inter-Process Communication）连接到/tmp/gemini-mcp.sock。这意味着，你为 CLI 编写的每一个git-status、pr-analyzer工具，都能被 VS Code、JetBrains IDE、甚至自研的 Electron 应用直接复用。工具一次编写，处处运行，这才是 MCP 协议最大的魅力。
6.2 如何将你的 CLI 无缝接入 VS Code？三步搞定
安装官方扩展：在 VS Code Marketplace 搜索并安装 “Google AI Studio” 或 “Gemini for VS Code”（确保是 Google 官方发布）。
配置 MCP Endpoint：打开 VS Code 设置（
Cmd+,），搜索gemini mcp endpoint，将值设为unix:/tmp/gemini-mcp.sock。这告诉 VS Code：“别连云端，就用我本地跑的那个 Server”。重启并验证：重启 VS Code，在任意
.ts文件中选中一段代码，右键选择 “Ask Gemini about selection”。如果一切正常，你会看到一个侧边栏弹出，内容正是你的gemini-mcp-server生成的——而且，它调用的工具，就是你刚才写的file-editor和pr-analyzer。
提示：VS Code 的扩展会自动检测 MCP Server 的状态。如果 Server 崩溃，它会在状态栏显示红色警告，并提供一键重启按钮。这比你在终端里手动
ps aux \| grep要人性化得多。
6.3 未来可扩展方向：从个人 Cockpit 到团队知识中枢
这套架构的潜力远不止于此。想象一下，将gemini-mcp-server部署在公司内网的一台服务器上，所有开发者的 CLI 和 VS Code 都连接到它。然后，你为它增加一个confluence-search工具，它可以查询公司内部 Confluence 的 API；再增加一个jira-lookup工具，它可以拉取 Jira Issue 的详细信息。当一个新人问gemini-cli "我们项目里关于 SSO 登录的最新技术方案文档在哪里？"，模型会自动调用confluence-search，返回匹配的页面链接和摘要。这不再是“AI 回答问题”，而是“AI 驱动的知识发现”。而这一切的基础，都始于你今天在终端里敲下的那行gemini-cli。它不是一个终点，而是一个起点——一个让你从“使用者”变成“架构者”的起点。
我个人在实际操作中发现，最难的从来不是技术本身，而是打破思维定式。当所有人都在找“gemini 下载”、“gemini 安装教程”时，真正的进阶者已经在思考：“如何让 Gemini 成为我工作流里，那个不用想起、却无处不在的第六感。” 这篇文章里所有的步骤、代码、技巧，都是为了帮你迈出这一步。它不承诺让你一夜之间成为 AI 专家，但它能确保，当你下次面对一个重复、繁琐、需要上下文的开发任务时，你的第一反应不再是“又要手动干这个”，而是“让我问问 Gemini，它应该知道怎么做”。
