我的 AI 编程工具链备份方案:别把工作流押在一个免费入口上

如果一个 AI 编程工具突然改登录、改额度、改入口，你的工作流会不会直接卡住？

我现在的答案是：不能。

Gemini CLI 要迁到 Antigravity CLI，Qwen Code 的 OAuth free tier 已经停用，DeepSeek-V4 又把 1M context 推到官方服务里。工具越来越强，但入口也越来越不稳定。

所以我现在更倾向于把 AI 编程工具链分成四层。

主力 Agent 只处理重任务。

比如：

• 读陌生仓库。
• 定位 bug。
• 跨文件修改。
• 补测试。
• 跑命令并根据报错继续修。

这一层可以放 Codex、Claude Code、Antigravity 这类工具。

它们适合做工程闭环，但不适合拿来回答所有小问题。解释一个函数、写一段小脚本、整理一段日志，都没必要上最贵、最重的入口。

主力 Agent 要省着用。

备用 CLI 不需要平替主力。

它只需要在主力入口卡住时，帮我继续处理轻任务。

比如 Qwen Code、OpenCode，或者任何支持自定义 base_url、api_key、model 的 CLI。

典型配置长这样：

1export OPENAI_API_KEY="sk-..."2export OPENAI_BASE_URL="https://example.com/v1"3export AI_MODEL="deepseek-v4-flash"

关键点不是某个模型名字，而是这套结构：

工具归工具，模型归模型，入口归入口。

只要这三件事能拆开，后面迁移就不会太痛。

长上下文模型不要神化。

DeepSeek-V4 官方文档写到，V4-Pro 是 1.6T total / 49B active params，V4-Flash 是 284B total / 13B active params，官方服务默认支持 1M context。

这很适合读材料：

• 长文档。
• 大日志。
• 技术报告。
• 多个 Issue。
• 大段历史对话。

但我不会一上来就让长上下文模型直接改代码。

更稳的流程是：

1长上下文模型读材料 -> 输出摘要 -> 主力 Agent 改代码 -> 本地测试

一个负责读，一个负责改，出问题也好定位。

省钱不是白嫖。

真正省钱，是不要把所有任务都交给最贵模型。

我的规则是：

• 小问题：便宜模型。
• 长材料：长上下文模型。
• 真改代码：主力 Agent。
• 高频任务：脚本和 Hooks。

如果需要统一管理入口，可以加 OpenRouter、LiteLLM、CLIProxyAPI、Sub2API 这类代理层。

它们的意义不是神秘，而是帮你把模型路由和成本控制从具体工具里拆出来。

今天不用折腾太复杂。

先建一个 ai-env.example：

1export OPENAI_API_KEY=""2export OPENAI_BASE_URL=""3export ANTHROPIC_API_KEY=""4export DEEPSEEK_API_KEY=""5export HTTPS_PROXY="http://127.0.0.1:7890"6export HTTP_PROXY="http://127.0.0.1:7890"

以后所有 AI CLI 尽量读这一套配置。

不要把 Key、代理、模型名散落在每个项目里。那样某个入口一变，你就要到处找配置。

我的最终原则就一句话：

主力 Agent 负责闭环，备用 CLI 负责不断工，长上下文负责读材料，代理层负责省钱和切换入口。

AI 编程工具肯定还会继续变，但配置和分工最好留在自己手里。

素材来源：

• Google Developers Blog: https://developers.googleblog.com/en/an-important-update-transitioning-gemini-cli-to-antigravity-cli/
• Qwen Code GitHub Issue: https://github.com/QwenLM/qwen-code/issues/3316
• DeepSeek API Docs: https://api-docs.deepseek.com/news/news260424

#AI编程 #Codex #QwenCode #DeepSeekV4 #工具链