我把月账单从1400刀压到310刀：一次AI编程工具链的“去肥增肌”实录

上个月底，我盯着信用卡账单愣了三分钟——1400多刀，全是AI编程工具和API的订阅费。

更气人的是，钱花了，活没干完。我手里那个内部工具项目，原计划两周收尾，结果拖到第四周还在调bug。问题出在哪？我复盘了一下：Claude Code开着Max套餐当主力，Codex当备胎，Kimi和DeepSeek的API挂在脚本里做批量处理，本地还跑着一个自建的Agent框架。工具多到我自己都记不清哪个任务该派给谁。

这就像厨房里摆了八口锅，结果炒个蛋炒饭手忙脚乱。

我决定做一次彻底的“去肥增肌”——不是少用AI，而是让每分钱都花在刀刃上。下面是这两周折腾的完整记录，翻车的地方我都标出来了。

先搞清楚钱到底烧在哪：一次让Agent自己查账的实验

我做的第一件事，是写了个脚本，把过去30天所有API调用日志扒出来，按工具、模型、任务类型三个维度做归因。

结果挺反直觉的。

我原以为大头是Claude Code的200刀月费。实际上，Claude Code的固定订阅只占14%，真正烧钱的是三块：

• Codex的按次调用：我习惯性用它做代码审查，每次review大概消耗1.2万token，一天跑20次，一个月就是720万token，按当时的价格折合约380刀。
• Kimi的长文本分析：我拿它读技术文档和论文，平均每次输入8万token，一个月跑了90次，约260刀。
• 自建Agent框架的“空转” ：这个最坑。我那个框架设计得过于“智能”，每次任务开始前会做一轮规划、一轮反思、一轮总结，三步下来光元认知开销就吃掉总token的35%。一个月下来，这部分“思考税”花了将近190刀。

这张图是我归因后的成本分布。注意那个“Agent元认知开销”，它不产出任何代码，纯粹是框架自己在那儿“想”。

踩坑记录一：我一开始想用GPT-4o做这个归因分析，把日志喂进去让它给建议。结果它洋洋洒洒写了2000字，建议我“优化prompt结构”“考虑使用更高效的模型”——全是废话。后来换成DeepSeek-V3，同样的输入，它直接给我列了个表格，指出Codex的调用频次和任务复杂度不匹配，建议把简单review下沉到本地模型。成本从0.8刀降到0.03刀。

观点：让AI做数据分析，别用最贵的模型。DeepSeek和Kimi在结构化归因上完全够用，GPT-4o适合做最后的“人话翻译”，但不是必须。

重构工作流：把“一个全能Agent”拆成“三条专线”

搞清楚钱去哪之后，我开始动刀。

原来的架构是一个“全能Agent”扛所有活：规划、写代码、审查、测试、部署。听起来很酷，实际上每个环节都在互相污染上下文，而且一旦某步出错，整个链路重来，token全白烧。

我把它拆成了三条独立流水线：

第一条：代码生成线（Claude Code + 本地Qwen3-Coder）

Claude Code保留，但只做一件事：从需求描述生成第一版代码。我给它写了一个极简的CLAUDE.md，核心就三句话：

你只负责生成代码，不解释、不审查、不测试。
输出格式：代码块 + 一行依赖说明。
如果需求模糊，只问一个最关键的问题。

这个改动直接把Claude Code的单次输出token从平均4500降到1800。省下来的不是钱，是时间——我不再需要从一堆解释里扒代码。

本地Qwen3-Coder跑在M2 Max上，用Ollama托管，负责处理那些“改个变量名”“加个日志”的小活。这些任务原来也走Claude Code，现在本地跑，零边际成本。一天大概能拦截30-40次小请求。

第二条：审查与测试线（Codex + DeepSeek-V3）

Codex不再做全量review。我给它设了一个门槛：只有diff超过50行的PR才触发Codex审查。小改动走DeepSeek-V3的API，用同样的prompt模板，成本差了多少？Codex一次review约0.12刀，DeepSeek-V3约0.004刀。30倍。

但这里有个坑：DeepSeek的review质量在复杂逻辑上确实不如Codex。我的做法是，DeepSeek先跑一遍，标记出“疑似问题”，只有被标记的才升级到Codex。这样Codex的调用量从一天20次降到3-4次。

第三条：文档与知识线（Kimi + 本地RAG）

Kimi的长文本能力没得说，但我之前用得太粗放——每次都是全文喂进去。现在改成：先用本地RAG（我用的是LlamaIndex + BGE-M3嵌入）做一轮检索，只把最相关的3-5个片段喂给Kimi。平均输入从8万token降到1.2万token，成本降了85%，而且回答更聚焦。

这张图是重构后的工作流。三条线独立运行，只在最后的“集成测试”环节汇合。

踩坑记录二：拆流水线的时候，我犯了一个经典错误——让三条线共享一个“全局状态”。结果Claude Code生成的代码风格和DeepSeek的审查标准打架，DeepSeek把Claude Code的命名规范全标成“建议修改”。后来我加了一个“风格锚点”文件，三条线都读同一个配置，问题才解决。

观点：多Agent协作，最怕的不是Agent不聪明，而是它们太聪明且各执己见。给它们一个共同的“宪法”，比让它们自由协商高效十倍。

省钱的核心不是换模型，是控制“元认知开销”

拆完流水线，账单降到了大概600刀。但我觉得还不够。

我回头去看那个“Agent元认知开销”的190刀，发现问题的根源不在模型，而在我的框架设计。

我那个自建框架，每个任务都会走一个“规划-执行-反思-总结”的循环。设计的时候觉得这是“智能”的体现，实际上：

• 规划阶段：Agent会生成一个任务分解，但80%的情况下，这个分解和上一步的分解几乎一样。
• 反思阶段：Agent会检查自己的输出，但检查标准模糊，经常陷入“我觉得可以了”“但也许还能更好”的循环。
• 总结阶段：生成一段人类根本不看的总结。

这三个阶段，我全部砍掉。

替换方案很简单：用结构化输出代替“自由思考”。我给每个任务定义一个JSON schema，Agent只需要填充字段，不需要生成自然语言解释。

比如代码生成任务，schema就四个字段：