进阶技巧
日常使用中，成本、速度和稳定性通常会一起出现。基础接入已经稳定后，再按下面这些思路继续优化更合适。
什么时候该看这页
- 基础接入已经完成
- 你开始在意成本、速度和稳定性
- 你准备把多工具、多设备配置管理起来
常见思路
Key 分层
按设备、按工具、按项目拆开建 Key，比一把通用 Key 更好管。
这样做不只是为了“看着整齐”，而是为了三个实际效果：
- 日志里能一眼看出到底是谁在消耗
- 某一台设备泄露时，只需要停掉对应 Key
- 你给团队成员或远端服务开权限时，不会牵连自己本机的所有工具
第一次从“一把全能 Key”拆分出去时，最稳的顺序通常是：
- 先保留一把主力 Key
- 再单独拆一把桌面客户端 Key
- 再单独拆一把 CLI 或服务器 Key
不要一口气拆十几把。
先拆出最常用、最容易混用的两三把，日志和排障效果就会明显好很多。
模型分工
- 轻量模型跑日常对话
- 强模型留给复杂分析和大任务
- 桌面端和 CLI 分开配置更清楚
不少工具本身就支持“主模型 + 轻量模型”双配置，例如 OpenCode 的 model 和 small_model。把轻任务交给轻量模型，通常比一把强模型从头跑到尾更省，也更稳。
第一次做模型分工时，可以直接按用途拆：
| 用途 | 更合适的模型 |
|---|---|
| 发一句“你好”测试链路 | 轻量模型 |
| 日常问答、翻译、总结 | 轻量模型或中档模型 |
| 代码重构、长文分析、大仓库阅读 | 强模型 |
| 自动化脚本、批量调用 | 轻量模型或低成本模型 |
上下文控制
模型变慢、费用变高，很多时候不是接口问题，而是上下文太大。
一旦你开始怀疑“是不是网关慢”，先回想最近是不是把整个仓库、超长日志或大量截图一起丢给了模型。很多所谓的慢，其实是任务规模已经远超当前问题本身。
一个简单判断方式：
- 问题只和 1-2 个文件有关，就不要把整个仓库一起塞进去
- 只是确认配置有没有生效，就不要附带几十屏运行日志
- 只是定位模型能不能返回，就先发最短测试消息
留一把备用 Key
主用 Key 出问题时，可以立刻切换，少中断。 备用 Key 平时不要写入公开脚本，也不要和主力 Key 共用同一份配置文件。
备用 Key 更适合做这些事：
- 主力 Key 临时被禁用时快速切换
- 先交叉验证“问题是不是出在这把 Key 上”
- 紧急联调时短时替代主力环境
不适合：
- 长期和主力 Key 混用
- 写进共享脚本或群文件
- 不设额度就长期闲置
固定一套最小测试
每次怀疑工具配置时，先跑最小 curl：
先把 MODEL 换成模型广场里复制的轻量模型名：
bash
MODEL="替换成模型广场里的轻量模型名"
curl -X POST https://xiaolan.ainb.plus/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 你的Key" \
-d "{\"model\":\"$MODEL\",\"messages\":[{\"role\":\"user\",\"content\":\"ping\"}]}"curl 正常，问题就在本地工具。curl 不正常，再看 Key、余额、模型和网络。
只要 curl 正常，后续就别继续盲改充值、分组或模型权限，而应该回到你正在使用的具体工具页面查配置。
固定一套最小测试的意义在于：
以后每次换模型、换工具、换网络，都能先用同一组最小请求判断“基础链路是不是还活着”。
控制上下文
AI 编程工具很容易把整个仓库塞给模型。上下文越大：
- 响应越慢
- 消耗越高
- 失败概率越高
优先提供相关文件。大型改造拆成多个小任务。 CLI 工具处理大仓库时，先让模型读取目录结构，再逐步提供相关文件。
配置文件比临时命令更稳
当你开始同时使用多个工具时，尽量把长期配置写回各自的正式位置：
- Claude Code：环境变量或对应配置文件
- Codex：
config.toml/小蓝中转站_API_KEY - OpenCode：
opencode.json/opencode.jsonc - OpenClaw：
openclaw.yaml - Gemini CLI：
~/.gemini/settings.json或项目内.gemini/settings.json
临时导出一两个变量适合排障，但不适合长期维护。正式配置写回去以后，换终端、重启机器或切项目时更不容易丢。
改了环境变量却总觉得“不稳定”“怎么有时生效有时不生效”时，优先检查是不是：
- 旧终端窗口还没关
- 当前项目目录里还有一份项目级配置覆盖默认值
- 桌面客户端当前会话还停留在旧服务商或旧模型
先固定一条主工作流
很多“越配越乱”的问题，不是工具不够，而是同时装太多、同时改太多。
更稳的做法通常是：
- 先选一个主力客户端
- 先固定一把主力 Key
- 先固定一个轻量模型和一个主力模型
- 这条链路稳定以后，再扩展第二个工具
这样做的好处是，出了问题时你知道自己最近只改了哪一层。
什么时候适合开始扩展第二个工具：
- 第一条主链路已经连续几天稳定可用
- 你已经知道当前主力模型、主力 Key 和主力配置放在哪里
- 你已经能独立判断问题大概卡在安装层、配置层还是模型层
如果这些还没稳，就先不要急着装第五个工具。
目前建议
先把最常用的那一条工作流跑顺：
- 一把主力 Key
- 一个主力工具
- 一套稳定模型
稳定后，再扩展到多工具和多设备。
还处在“今天能用、明天又乱”的状态时，先不要继续优化成本、切模型或折腾多人模板。
先把最常用的一条链路压到稳定，再谈进阶，收益会更大。
多工具配置建议
| 工具 | Key 命名 | 模型建议 |
|---|---|---|
| Cherry Studio | Desktop-Cherry | 聊天模型 + 轻量模型 |
| Claude Code | CLI-Claude | 代码能力强的模型 |
| Codex | CLI-Codex | Responses 兼容模型 |
| Gemini CLI | CLI-Gemini | Gemini / 长上下文模型 |
命名一致后，日志里能直接看出是谁在消耗。