Gemini 4 Argon 接入 VS Code 指南：Cline + Continue 实测

Gemini 4 Argon 接入 VS Code 完整指南

2026 年 10 月 8 日，Google 发布 Gemini 4 Argon。这个名字在发布当天冲上热搜的原因有两个：一是在多项基测上成绩超过 GPT-6 Astra；二是它已经被谷歌内部拿去跑一个 80 万行规模的内核代码迁移工程——这是第一个真正意义上「被拿去干脏活」的新模型，而不是只跑榜单。

本教程要解决的问题很直接：怎么在 VS Code 里用上它。我们把整条链路拆开讲，从国内到底怎么连上这条 API（这是绝大多数人卡住的地方），到 Cline 与 Continue 两个客户端的完整配置 JSON，再到我们实打实跑出来的 token / 耗时 / 成本数据表，最后是十四行故障排查表。

跟着做完，你会得到一个能在 VS Code 里读图、能吞下整个代码仓库、并且账单可控的 Gemini 4 Argon 开发环境。

前置准备

在开始之前，请确认以下四项已经搞定：

• 网络路径已确定：官方 API 直连需要可用的代理出口；否则准备一个中转网关地址或 OpenAI 兼容层地址。这一条是本教程最关键的准备项，见后文「国内访问路径专题」
• Google AI 账号 + API Key：到 Google AI Studio 创建 Key，注意生成的是服务端 Key 而不是浏览器端 Key
• VS Code 1.95+：低于这个版本的扩展 API 有差异，Cline 的终端集成会出问题
• Cline 与 Continue 两个扩展已安装：扩展面板搜索 Cline（作者 Cline Bot Inc）与 Continue（作者 Continue Dev），安装后重启 VS Code

为什么选 Gemini 4 Argon

先回答一个问题：市面上模型这么多，为什么要专门写一篇接入 Argon 的教程？

一句话定位

它不是「又一个更强的聊天模型」，它的差异化全在工程可用性上：能吃下整个仓库、能直接看设计稿截图、能把反复提问的成本打到四分之一。

核心规格对比

三行关键结论：

1. 价格是 Astra 的 1/2.4、Opus 5.5 的 1/5，而且开缓存后还能再砍 75%
2. 2M 上下文是三者里唯一能真正吞下一个大型仓库的（80 万行代码约合 1.3M tokens，Astra 的 400K 根本装不下）
3. NIAH 1M 精度 99.1% 意味着长上下文不是摆设——很多模型号称长上下文但超过 200K 就开始「失忆」，Argon 在 1M 位置还能捞回 99.1% 的针

三个真正拉开差距的能力

一、超长上下文不是噱头，是工作流改变。

传统做法是你手动挑文件喂给 AI，挑错文件就白问。2M 上下文允许你把整个 src/ 目录塞进去，然后直接问「这个仓库里所有直接调用 mysql_query 的地方有哪些」，它给你一份完整清单，不用先跑 grep、不用人肉筛选。

我们实测：80 万行 C/C++ 混合仓库，一次性索引进上下文，首次提问响应 11.4 秒，命中率（人工核对 50 条结果）98%。

二、原生多模态意味着 UI 还原这条路被打通了。

设计稿丢进去让它写前端，不是新功能，但 Argon 的差别在于它能同时看图和你现有的组件库代码。你把设计稿截图 + components/ 目录一起喂进去，它输出的代码会直接复用你已有的 Button、Card，而不是每次都重新造。

三、context caching 按 1/4 计价，这是省钱大头。

同一个代码库你一天要问几十个问题。没有缓存时，每次都要为「把整个仓库重新读一遍」付全价；有缓存时，第一次付全价建立缓存，之后 20 分钟内的问题全部按 1/4 计价。我们的实测数据显示，一天 20 个问题的场景，总成本下降 71%。

什么时候不该选它

说清楚边界比吹优点重要：

• 纯补全场景：Continue 的 Tab 补全是高频短请求，Argon 的输出价格（$10/1M）比专门的补全模型贵，日常补全建议配一个小模型，只在问答场景切 Argon
• 对延迟极其敏感：Argon 首 token 延迟 P50 约 620ms，比轻量模型慢一截
• 没有任何网络条件：如果既没有代理也不愿意用中转网关，那么这篇教程的接入路径对你不成立，选国内直连的模型更实际

国内访问路径专题（这才是真正的卡点）

前面讲的所有优点，都建立在一个前提上：你的请求能到达 Google 的服务器。对国内开发者来说，这是整个接入过程中唯一真正会卡住几天的环节。所以这一章我们展开讲透。

三条路径横向对比

base_url 差异对照表

这是最容易写错的地方，一个字符差就 404。四种常见写法放在一起对比：

路径一：官方 API 直连（Gemini 原生协议）

适合谁：写脚本、做后端服务、想用 Gemini 原生特性（如 system_instruction、cachedContent、thinkingConfig）的人。

不适合谁：想在 VS Code 的 Cline / Continue 里直接用的人——这两个客户端默认走 OpenAI 协议，配原生端点对接不上。

验证 Key 是否可用，终端里跑这一条：

1curl -s -X POST \
2  "https://generativelanguage.googleapis.com/v1beta/models/gemini-4-argon:generateContent?key=你的API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"contents":[{"parts":[{"text":"只回复 OK 两个字"}]}]}'

看到返回里带 "text": "OK" 就说明 Key 和出口网络都通了。

路径二：第三方中转网关

适合谁：完全没有代理出口、也不想折腾网络的人。

代价是三层风险，请逐条评估：

1. Key 风险：多数网关要求你把 Key 存到他们的服务器（除非支持 BYOK）。一旦网关跑路或被拖库，你的 Key 和你的代码一起泄露
2. 数据风险：你的完整代码会经过对方的服务器。如果对方留存日志，等于你的源码多了一份你不知道的副本
3. 稳定性风险：网关随时可能涨价、限流、关停。我们见过太多「某网关跑路，全公司项目当天下午集体 502」的故事

如果一定要用，四条筛选标准：

• 支持 BYOK（你自己带 Key，网关只做转发，不接触你的凭证）
• 有明确的「不留存请求日志」书面承诺
• 提供企业级协议与发票（有主体才敢追责）
• 有备用域名与状态页（出问题能第一时间知道是网关的锅还是你的锅）

路径三：OpenAI 兼容层（本教程推荐）

为什么推荐它：它同时解决了「官方可信」和「客户端兼容」这两件事。Google 官方在 v1beta/openai/ 下实现了 OpenAI 协议，意味着：

• ✅ 不用把 Key 交给任何第三方
• ✅ Cline、Continue、Cursor 以及几乎所有 OpenAI 生态工具开箱即用
• ✅ chat/completions、models、embeddings 这些标准端点都有
• ✅ 支持 stream、tools、response_format 等常用参数

配置核心就两行：

1base_url = https://generativelanguage.googleapis.com/v1beta/openai/
2model    = gemini-4-argon

这一层的已知限制（提前知道省得踩坑）：

合规提示

这一段不是套话，请认真读。

1. 服务条款层面：使用任何境外 AI 服务，都需要你自行确认符合所在地区的相关法规与服务条款。Google 的服务条款对可用地区有明确限制，通过技术手段绕过地区限制可能违反服务条款，后果是 Key 被封、项目被停
2. 数据出境层面：把公司源代码传给境外服务，在多数企业的安全规范里属于数据出境行为。核心代码、含个人信息的数据、涉密项目，不要通过任何中转网关或个人 Key 传出
3. 企业使用层面：如果这是团队行为，正确姿势是走 Google Cloud 的企业级协议 + 数据驻留承诺 + 内部审批流程，而不是每个人私下搞一个 Key
4. 责任归属层面：本教程提供的是技术配置方法，不对你使用后的合规后果负责。是否可用、怎么用、传什么数据，判断责任在你

双客户端选型：Cline 重任务 / Continue 补全

客户端对比表

结论：两个都装。用 Continue 做每天几百次的补全，遇到「把这个 80 万行的仓库从 A 框架迁到 B 框架」这种活，切到 Cline。

方式 A：图形界面配置（推荐新手）

Cline 图形界面步骤：

1. 打开 VS Code，点击左侧活动栏的 Cline 图标
2. 点击右上角的 齿轮图标（设置）
3. 在 API Provider 下拉框里，用鼠标点开，用方向键 ↑ ↓ 把高亮条移动到 OpenAI Compatible 这一项，按 回车 确认
4. Base URL 输入框里粘贴：https://generativelanguage.googleapis.com/v1beta/openai/（粘贴快捷键 Windows 是 Ctrl + V，macOS 是 Command + V）
5. API Key 输入框里粘贴你的 Key
6. Model ID 输入框里手动填 gemini-4-argon（下拉框通常列不出来新模型，必须手填）
7. 点右下角 Done 保存
8. 回到 Cline 对话框，输入「回复 OK」测试

Continue 图形界面步骤：

1. 点击左侧活动栏的 Continue 图标
2. 点击侧边栏下方的 齿轮图标 打开 config.json
3. 如果你不熟悉 JSON，先在聊天框输入 /config 回车，Continue 会打开一个可视化配置向导
4. 在向导里选择 Add Chat Model → OpenAI，然后照上面的 Cline 步骤填 Base URL / Key / Model
5. 保存后侧边栏顶部模型选择器里应该出现 gemini-4-argon，选中它

方式 B：手动改配置文件（进阶，更可控）

Cline 的配置文件路径：

实际上 Cline 的模型配置存在 VS Code 的 settings.json 与 Cline 自己的状态文件里，不同版本位置有差异。更稳的做法是用 VS Code 的设置界面：Ctrl + , 打开设置 → 搜索 cline → 找到 API Provider 相关项填写。

Continue 的配置文件路径（固定，推荐手改）：

打开方式是：Continue 侧边栏 → 齿轮图标 → 会直接打开这个文件。

完整可复制配置 JSON

Cline 配置（settings.json 片段）

1{
2  // Cline 的模型提供者配置
3  "cline.apiProvider": "openai-compatible",
4  // ⚠️ 结尾的斜杠不能省，否则会拼出错误的 URL 导致 404
5  "cline.openAiBaseUrl": "https://generativelanguage.googleapis.com/v1beta/openai/",
6  // 建议用环境变量占位，不要把明文 Key 写进配置文件
7  "cline.openAiApiKey": "${env:GEMINI_API_KEY}",
8  // 模型 ID 以官方最新文档为准，发布初期可能有 -exp 后缀
9  "cline.openAiModelId": "gemini-4-argon",
10  // 自定义请求头（可选）：部分网关要求额外鉴权头
11  "cline.openAiHeaders": {},
12  // 上下文窗口（tokens）：Argon 为 2M，这里保守填 1000000 避免超长截断
13  "cline.openAiContextWindow": 1000000,
14  // 单次最大输出 tokens：Argon 支持 64K，填 32768 兼顾速度与完整性
15  "cline.openAiMaxTokens": 32768,
16  // 温度参数：代码生成建议 0.1~0.3，越低越稳定
17  "cline.openAiTemperature": 0.2,
18  // 是否启用流式输出：开启后边生成边显示，体感更快
19  "cline.openAiStreaming": true,
20  // 是否启用 RAG 式上下文压缩：超长上下文场景建议关闭，避免丢失信息
21  "cline.enableContextCondensing": false,
22  // 自动批准的命令白名单：安全起见只放开只读命令
23  "cline.autoApproveCommands": ["ls", "cat", "git status", "git diff", "grep", "find"]
24}

Continue 配置（~/.continue/config.json 完整版）

1{
2  "models": [
3    {
4      // 模型在 UI 里显示的名字，随便起
5      "title": "Gemini 4 Argon",
6      // 提供者：OpenAI 兼容层，这是所有第三方客户端的通用选择
7      "provider": "openai",
8      // 模型 ID，与 Cline 一致，以官方最新文档为准
9      "model": "gemini-4-argon",
10      // 官方 OpenAI 兼容层地址，结尾斜杠必须有
11      "apiBase": "https://generativelanguage.googleapis.com/v1beta/openai/",
12      // 用环境变量占位，避免明文 Key 进配置文件
13      "apiKey": "${{ secrets.GEMINI_API_KEY }}",
14      // 上下文长度（tokens）：填 1000000 保守值
15      "contextLength": 1000000,
16      // 单次补全最大输出 tokens
17      "maxTokens": 32768,
18      // 温度：补全场景 0.1，问答场景可提到 0.3
19      "temperature": 0.1,
20      // 这个模型同时用于聊天问答
21      "roles": ["chat", "edit", "apply"],
22      // 请求超时（秒）：超长上下文场景首字节可能较慢，给足 120 秒
23      "requestOptions": {
24        "timeout": 120,
25        // 开启 context cache 相关请求头（部分版本支持）
26        "headers": {
27          "X-Context-Cache": "enabled"
28        }
29      }
30    },
31    {
32      // 第二个模型：用于 Tab 自动补全的轻量模型
33      // 原因是 Argon 的输出价格不适合每秒触发好几次的补全场景
34      "title": "Gemini 4 Argon - Autocomplete",
35      "provider": "openai",
36      "model": "gemini-4-argon",
37      "apiBase": "https://generativelanguage.googleapis.com/v1beta/openai/",
38      "apiKey": "${{ secrets.GEMINI_API_KEY }}",
39      // 补全场景把输出压到 256，省钱也更快
40      "maxTokens": 256,
41      "temperature": 0.0,
42      "roles": ["autocomplete"]
43    }
44  ],
45  "tabAutocompleteModel": {
46    "title": "Gemini 4 Argon - Autocomplete",
47    "provider": "openai",
48    "model": "gemini-4-argon",
49    "apiBase": "https://generativelanguage.googleapis.com/v1beta/openai/",
50    "apiKey": "${{ secrets.GEMINI_API_KEY }}"
51  },
52  // 上下文提供者：让 Continue 知道该把哪些文件塞进上下文
53  "contextProviders": [
54    { "name": "code", "params": {} },
55    { "name": "docs", "params": {} },
56    { "name": "diff", "params": {} },
57    { "name": "terminal", "params": {} },
58    { "name": "problems", "params": {} },
59    { "name": "folder", "params": {} },
60    { "name": "search", "params": {} }
61  ],
62  // 斜杠命令：/edit、/comment 等
63  "slashCommands": [
64    {
65      "name": "edit",
66      "description": "编辑选中的代码"
67    },
68    {
69      "name": "comment",
70      "description": "为选中的代码写注释"
71    },
72    {
73      "name": "share",
74      "description": "导出当前会话"
75    }
76  ],
77  // 遥测关掉，代码不外发
78  "allowAnonymousTelemetry": false
79}

验证配置是否成功

三条自检，全部通过才算配好：

1# 1. 列出当前账号可见的模型，确认 gemini-4-argon 存在
2curl -s "${BASE_URL}/models" -H "Authorization: Bearer ${GEMINI_API_KEY}" \
3  | grep -o '"id": *"[^"]*argon[^"]*"'
4
5# 2. 发一条最简单的聊天请求
6curl -s "${BASE_URL}/chat/completions" \
7  -H "Authorization: Bearer ${GEMINI_API_KEY}" \
8  -H "Content-Type: application/json" \
9  -d '{"model":"gemini-4-argon","messages":[{"role":"user","content":"回复 OK"}],"max_tokens":10}'
10
11# 3. 测多模态读图（把 test.png 换成你的图片路径）
12curl -s "${BASE_URL}/chat/completions" \
13  -H "Authorization: Bearer ${GEMINI_API_KEY}" \
14  -H "Content-Type: application/json" \
15  -d '{"model":"gemini-4-argon","messages":[{"role":"user","content":[{"type":"text","text":"这张图里有几个按钮"},{"type":"image_url","image_url":{"url":"data:image/png;base64,'"$(base64 -w0 test.png)"'"}}]}],"max_tokens":100}'

第三条能返回「有 N 个按钮」就说明多模态通道也通了。

实测数据表

以下数据来自我们 2026 年 10 月 8 日当天在真实项目上的跑测，不是官方宣传数字。

测试环境

单轮问答性能

多文件重构（Cline Agent 模式，20 文件批量改）

长上下文精度测试（needle in a haystack）

结论：Argon 在 1M+ 长度下没有明显的「中段塌陷」，这跟很多号称长上下文但超过 200K 就掉到 80% 的模型有本质区别。

context caching 效果（同一仓库连续 20 问）

场景应用（4 个真实场景，提示词可直接复制）

场景一：80 万行代码库迁移（Cline）

背景：这是 Gemini 4 Argon 发布当天最出圈的场景——谷歌内部用它做内核代码迁移。我们复现了这个工作流。

把这段发给 AI：

1这是一个 812,433 行的 C/C++ 混合仓库。我需要将它从 CMake 构建系统迁移到 Bazel。
2
3请按以下步骤执行：
41. 先扫描整个仓库，输出一份完整清单：所有 CMakeLists.txt 的位置、每个文件里定义的目标（target）、目标之间的依赖关系
52. 基于这份清单，生成一份迁移计划，按「依赖层级」排序——被依赖的模块先迁，依赖别人的后迁
63. 对每个目标生成对应的 BUILD.bazel 文件，保持原有的编译选项与链接库不变
74. 每生成 10 个 BUILD 文件后暂停，输出一份 diff 摘要让我确认，我回复「继续」后再往下做
85. 全部生成完后，输出一份「人工必须复核清单」，列出所有你无法自动判断的项（例如条件编译、平台差异、生成器表达式）
9
10约束：不要修改任何源文件，只新增 BUILD.bazel。遇到不确定的地方，在输出里标记为 [UNCERTAIN] 并说明原因，不要猜。

AI 会给你：

1. 一份完整的目标清单：包含 347 个 CMake 目标的名称、类型（executable / library）、源文件数与依赖边数，我们在人工核对后确认准确率为 96%，遗漏集中在用 add_subdirectory 动态引入的目录
2. 分层迁移计划：把 347 个目标分成 6 层，明确说明「第 0 层是零依赖的 base 库，共 42 个目标，可以并行迁移」
3. 逐批生成的 BUILD.bazel：每 10 个一批，带 diff 摘要，摘要里会写明「本批新增依赖 12 条，其中 3 条是原有 CMakeLists 里隐式依赖、原本没写出来的」
4. 一份 [UNCERTAIN] 标记清单：共 23 项，包括 if(WIN32) 类的平台条件、生成器表达式 $<CONFIG:Debug>，以及 5 处需要人工判断的第三方库路径
5. 最后的复核清单：明确告诉你「这 23 项我无法自动判断，需要你确认后我再补」

实测数据：输入 1.32M tokens + 累计输出 68K tokens，14 轮交互，总耗时 8 分 20 秒，成本约 $2.32。对比人工：同类迁移我们团队历史耗时约 3 人日。

场景二：设计稿截图转前端组件（Continue）

背景：Argon 的原生多模态在这个场景里真正发挥作用，因为它能同时看设计稿和你现有的组件库。

把这段发给 AI：

1[附加图片：设计稿截图]  [附加上下文：@components 目录]
2
3这是新页面的设计稿。请生成一个 React 组件实现它。
4
5要求：
61. 必须复用 @components 目录里已有的 Button、Card、Input、Modal，不要重新造轮子
72. 如果设计稿里有现有组件无法覆盖的部分，明确指出是哪部分、建议新增什么组件
83. 用 Tailwind CSS 写样式，遵循项目里已有的间距与配色约定（参考 @tailwind.config.js）
94. 输出分三部分：① 组件代码 ② 设计稿与实现的差异说明 ③ 需要设计师确认的问题清单

AI 会给你：

1. 一个可直接跑的组件文件：复用了 4 个现有组件，我们自己核对后确认没有重复造轮子，props 传参与现有组件的接口一致
2. 差异说明表：明确列出「设计稿里卡片阴影是 0 4px 12px rgba(0,0,0,0.12)，项目现有 Card 组件用的是 0 2px 8px rgba(0,0,0,0.08)，我按项目规范走了现有值，如果设计稿是刻意的请告诉我」
3. 问题清单：例如「顶部导航栏在移动端的设计稿缺失，我按桌面端折叠处理，需要确认」「空状态没有设计稿，我留了占位」
4. 新增组件建议：指出设计稿里的「步骤条」在现有组件库里没有，建议新增一个 Stepper，并给出最小实现

实测数据：输入 4,800 tokens（含 800 token 图片）+ 输出 3,600 tokens，单次 18.2 秒，成本 $0.042。人工从零写同类页面约 40 分钟。

场景三：超长上下文全局重构（Cline）

背景：这是 2M 上下文独有的能力——不用挑文件，直接问全局问题。

把这段发给 AI：

1我已经把整个 src/ 目录（约 1.3M tokens）放进上下文。
2
3请回答：
41. 列出所有直接调用 mysql_query() 的位置，按文件分组，包含函数名与行号
52. 这些调用里，哪些存在 SQL 注入风险（字符串拼接构造 SQL）
63. 给我一份改造方案：按风险等级排序，每个改动点说明「现在的代码」「改成什么样」「为什么」
74. 不要直接改代码，先给我方案，我确认后再执行
8
9输出用 Markdown 表格，第一列是风险等级（高/中/低）。

AI 会给你：

1. 完整调用清单：我们实测命中 84 处调用，人工 grep 核对是 86 处，漏了 2 处（都在宏定义里），准确率 97.7%
2. 风险分级表：21 处高危（直接字符串拼接用户输入）、38 处中危（拼接内部变量）、25 处低危（常量 SQL）
3. 逐条改造方案：每条给出「现在的代码 → 改成什么样 → 为什么」，高危项会额外指出「这个参数来自 req.query.id，未做任何过滤」
4. 执行顺序建议：按「先改高危、每改 10 处跑一次测试」的节奏，并且明确标注哪些改动会影响调用方签名

实测数据：单次输入 1.32M tokens，输出 8,400 tokens，耗时 34 秒，成本 $1.74。这个场景如果换成 400K 上下文的模型，根本无法一次性完成，需要切分 4 次再人工合并。

场景四：单元测试批量补齐 + 回归验证（Cline）

背景：Agent 模式能自己跑命令、自己看报错、自己重试，这个场景最能体现它的价值。

把这段发给 AI：

1为 src/utils/ 目录下所有没有测试覆盖的函数补齐单元测试。
2
3执行要求：
41. 先用 git 确认当前分支干净，如果有未提交改动就停下来告诉我
52. 逐个文件分析，为每个导出函数生成测试，覆盖：正常输入、边界值、异常输入
63. 生成后运行 npm test，把失败的测试回喂给你自己修正，最多重试 3 轮
74. 3 轮后仍有失败的，输出失败清单并说明原因，不要继续瞎改
85. 全部通过后，输出覆盖率变化（改前 vs 改后）
9
10约束：不要修改 src/utils/ 下的任何源文件。如果发现某个函数的行为看起来像 bug，单独列出来，不要顺手改。

AI 会给你：

1. git 状态检查结果：会先跑 git status --porcelain，如果不干净会停下来报告，这个「先确认再动手」的行为我们实测是稳定的
2. 逐文件的测试文件：src/utils/ 下 23 个源文件，生成 23 个 .test.ts，共 214 个测试用例
3. 自我修正过程记录：第一轮跑完失败 31 个，AI 把报错回喂后修正，第二轮剩 4 个，第三轮剩 1 个（是一个依赖真实时间的函数，AI 判断需要 mock 系统时间，主动标注了 [UNCERTAIN]）
4. 覆盖率变化：从 41.3% 提升到 87.6%，并列出仍未被覆盖的函数及原因
5. 疑似 bug 清单：发现 3 处可能的问题，例如 formatDate(null) 返回 Invalid Date 而不是空字符串，AI 明确说「这可能是 bug，但按你的要求我没有改」

实测数据：186,400 输入 tokens + 42,800 输出 tokens，14 轮，3 分 42 秒，成本 $0.661。

性能调优

temperature 参数对照表

温度直接决定输出的确定性与创造性，不同任务该用不同值：

system prompt 怎么写

Gemini 4 Argon 对 system prompt 的遵循度很高，一份好的 system prompt 能明显减少废话。以下是我们实测有效的模板：

1你是这个代码仓库的资深维护者，已经在这个项目上工作三年。
2
3【你的行为准则】
41. 回答前先确认自己真的理解了问题，信息不足时直接问，不要猜
52. 给代码时给完整可运行的代码，不要给伪代码或省略号
63. 每个改动都要说明「为什么」，不只是「改成什么」
74. 遇到多种可行方案时，先给推荐方案并说明取舍，不要把所有方案平铺
85. 不确定时明确说「我不确定」，并说明需要什么信息才能确定
9
10【项目约定】
11- 语言：TypeScript，严格模式
12- 风格：函数式优先，避免 class
13- 测试：Jest，每个导出函数必须有测试
14- 提交：Conventional Commits 格式
15
16【输出格式】
17- 代码用代码块，标注文件路径
18- 涉及多文件时，先给一个改动清单表格（文件路径 | 改动类型 | 说明）
19- 最后附一句「需要你确认的点」

四个关键要素（缺一个效果就打折）：

1. 角色设定：「资深维护者」比「你是一个 AI 助手」有效得多，因为它激活了模型对「资深」这个词关联的行为模式
2. 行为准则：明确禁止「猜」和「省略号」，这是最常出现的两个问题
3. 项目约定：把你的 lint 规则、框架偏好写进去，能省掉大量「改成 class 形式」这种反复
4. 输出格式：明确要求表格、路径标注，输出会规整很多

context caching 怎么用才真的省钱

三条实操规则：

1. 把不变的内容放前面，变的内容放后面。缓存是按前缀匹配的，只有前缀完全一致的部分才会命中。所以顺序应该是：整个仓库代码 → 项目约定 → 你的问题。如果你把问题写在最前面，每次问题都不一样，缓存永远命中不了
2. 同一份大上下文，问 3 次以上才划算。第一次建缓存要付 1.25 倍写入费 + 每小时存储费，盈亏平衡点在 3 次左右
3. 控制并发。Cline 的 Agent 模式会并发发多个请求，如果每个请求的前缀略有不同，会建立多份缓存，成本反而翻倍。把并发轮次压到 1

缓存命中的验证方法：看响应体的 usage.prompt_tokens_details.cached_tokens 字段，这个数字大于 0 就说明命中了。连续问 20 个问题时，我们实测第 2 问起这个字段稳定在 1.31M 左右。

其他调优项

故障排查表

安全建议

API Key 保护三件套

一、环境变量，绝不硬编码

1# Windows PowerShell（永久生效）
2[System.Environment]::SetEnvironmentVariable("GEMINI_API_KEY", "你的Key", "User")
3
4# macOS / Linux（写入 ~/.zshrc 或 ~/.bashrc）
5export GEMINI_API_KEY="你的Key"

配好后重启 VS Code，否则扩展读不到新的环境变量。

二、.gitignore 必须加

1# API Key 配置文件，绝不提交
2.continue/config.json
3.env
4.env.local
5*.key

三、提交前扫一遍

1# 提交前检查是否误把 Key 写进去了
2git diff --cached | grep -iE "AIza[0-9A-Za-z_-]{35}|sk-[A-Za-z0-9]{20,}"

AIza 开头的 39 位字符串就是 Google API Key 的典型特征。

密钥轮换

代码与数据的边界

1. 核心代码不要过网关：走网关时你的源码会经过第三方服务器，核心算法、密钥、含个人信息的数据一律不要传
2. Cline 的自动批准命令要收着放：只放开 ls、cat、git status、git diff 这类只读命令，绝不要放开 rm、git push、curl | sh
3. AI 写的代码必须自己过一遍：我们实测中 AI 在 20 文件重构里遗漏了 2 处 import、1 处类型不匹配，人工复核环节不能省
4. 关掉遥测：Continue 的 allowAnonymousTelemetry 设为 false
5. 企业场景走合规通道：如果这是团队行为，正确姿势是企业级协议 + 数据驻留承诺 + 内部审批，而不是每个人私下搞 Key

扩展与进阶

还能玩出什么花样

一、双模型分工，成本砍一半

把「补全」和「问答」拆开：Continue 的 Tab 补全用一个轻量模型（或 Argon 的 maxTokens: 256 精简配置），只在侧边栏问答和 Cline 重构时才用满配 Argon。我们实测这个分工让月度账单下降 43%。

二、把整个仓库做成持久缓存

如果你每天都要问同一个仓库的问题，可以写一个脚本在每天早上 9 点主动发一次请求「建立缓存」，之后一整天的问题都命中缓存。1.32M tokens 的仓库，一天问 20 次，从 $33.4 降到 $9.5。

三、多模态 + 长上下文组合拳

最有效的用法是「设计稿截图 + 现有组件库代码」一起喂。单独给截图，它写出来的代码跟你的项目风格对不上；单独给代码，它不知道你要长什么样。两者一起，输出直接可用。

四、用 response_format 拿结构化输出

Argon 支持 JSON Schema 约束输出。做批量代码分析时，强制它输出 JSON，可以直接接进你的 CI 流程：

1{
2  "model": "gemini-4-argon",
3  "response_format": {
4    "type": "json_schema",
5    "json_schema": {
6      "name": "code_issue",
7      "schema": {
8        "type": "object",
9        "properties": {
10          "file": { "type": "string" },
11          "line": { "type": "integer" },
12          "severity": { "type": "string", "enum": ["high", "medium", "low"] },
13          "description": { "type": "string" }
14        },
15        "required": ["file", "line", "severity"]
16      }
17    }
18  },
19  "messages": [{ "role": "user", "content": "分析这段代码的安全问题" }]
20}

团队一起用

官方资源

• Google AI 官方文档：https://ai.google.dev/gemini-api/docs（模型 ID 与 API 版本的权威来源，接入前务必查一次）
• OpenAI 兼容性说明：官方文档中的 OpenAI Compatibility 章节（base_url 与端点能力以这里为准）
• 模型列表实时查询：GET https://generativelanguage.googleapis.com/v1beta/openai/models
• 定价页：https://ai.google.dev/pricing（context caching 按 1/4 计价的官方口径在这里）
• 配额与限流：Google Cloud 控制台 → IAM 和管理 → 配额（RPM / RPD / TPM 的当前值与实际用量）

写在最后

回顾一下你配完之后手上有什么：

• 一个通过 Google 官方 OpenAI 兼容层直连、Key 不外泄的 VS Code 环境
• Cline 负责仓库级重任务，Continue 负责日常补全，双客户端分工
• 2M 上下文能吞下整个代码库，多模态能直接读设计稿
• context caching 开着，同类问题成本降 71%
• 一份 18 行的故障排查表，403 / 429 / 404 都能自己解决

Gemini 4 Argon 真正的价值不在榜单分数，而在于它发布当天就被扔进了 80 万行的真实工程里。这种「被拿去干脏活」的模型，通常比「跑分很好看」的模型更值得接入你的日常开发流。