九月初,我点开Claude的账单详情页时,手指是发颤的。上个月AI编程相关的API开销:12746元人民币,折算下来差不多1800美元。作为一个单枪匹马的独立开发者,一个人维护一个项目,这笔钱已经不是"咬咬牙还能扛",而是"再不动刀就得砍掉功能模块"的境地了。
但真正让人难受的是,钱花得凶,产出却没跟着涨。很多活儿其实DeepSeek一遍就能搞定,我却总是顺手让Claude Opus去死磕,一个中等规模的需求一口气烧掉200万token,拿到的代码还得我自己返工三成。那一瞬间我算是想明白了:症结不在于模型能力不足,而在于我把高配模型当成了万能工具,好比拿宰牛刀去切水果。
于是我用了两周时间,干了两件事:第一,把同一份真实需求分别投喂给四套模型做对照实验,拿到第一手数据;第二,根据数据重新搭建了一套"模型调度"工作流。接下来这篇文章就是完整的过程复盘,每一个数字都是从我自己账单里扒出来的。
动手之前我先做了归因分析,把上个月12746元的账单按任务类型逐项拆开:
看出问题了吗?真正需要顶级模型能力的部分,可能只占前两类的一半,甚至更少。 测试生成、文档撰写、格式化、简单CRUD,这些活儿对模型来说难度只是"及格线"级别的,我却一直拿顶配模型在干。
更让人哭笑不得的是,我还挖出了一个隐性浪费源:上下文反复重传。我每次新开会话就把整个仓库README、关键文件全部贴一遍,Claude Code一次会话光上下文输入就吃掉40-60万token。Anthropic有prompt caching功能,缓存命中部分能便宜90%,但我之前压根没启用,等于每次都按全价付费。就这一项,一个月白白扔掉接近2000元。
先说结论:成本优化的空间不在于"换个便宜模型",而在于任务分级 + 缓存 + 减少无效上下文这三件事上。
我挑了三个真实任务做基准测试,难度依次递增:
参与测试的:Claude Opus 4.6(顶配)、Claude Sonnet 4.6、GPT-6(Codex CLI)、DeepSeek V4、Kimi K3。每个任务跑3次取均值,统一使用相同的system prompt和仓库上下文,用脚本统计token消耗,人工盲评代码质量(评的时候不知道是谁写的)。
直接上数据:
| 模型 | T1耗时 | T2耗时 | T2输入token | T2输出token | T2成本(¥) | 代码一次通过率 |
|---|---|---|---|---|---|---|
| Opus 4.6 | 3分10秒 | 11分40秒 | 18.2万 | 5.6万 | 21.3 | 83% |
| Sonnet 4.6 | 2分50秒 | 9分20秒 | 17.8万 | 5.2万 | 8.9 | 75% |
| GPT-6 / Codex | 3分30秒 | 10分10秒 | 19.5万 | 6.1万 | 11.7 | 72% |
| DeepSeek V4 | 2分20秒 | 8分40秒 | 16.9万 | 5.8万 | 1.6 | 61% |
| Kimi K3 | 2分40秒 | 9分50秒 | 18.0万 | 5.9万 | 2.1 | 64% |
几个反直觉的结论:
第一,顶配模型的优势并没有价格差距那么夸张。 Opus 4.6的一次通过率比DeepSeek高22个百分点,但成本高出13倍。换算成"通过一次测试的总花费":Opus约25.7元/次通过,DeepSeek约2.6元/次通过。就算DeepSeek多失败两次需要重跑,仍然便宜一个数量级。当然,返工的成本不只是token,还有我的时间和心情——这就是后文路由策略要解决的张力。
第二,T1这种简单任务,五个模型通过率差距不足8%,耗时差距不到1分钟。 用Opus写单元测试,纯属行为艺术。这类任务我测下来DeepSeek最划算,Kimi K3在长上下文仓库理解上反而有惊喜(它的上下文窗口利用率是几个里最实在的),但写代码的"听话程度"略逊。
第三,T3架构任务,Opus是真的断层领先。 依赖分析准确率Opus约92%,Sonnet 81%,GPT-6 78%,DeepSeek只有63%——它漏掉了两个循环依赖,给出的迁移顺序会直接编译失败。这个任务上我认账:该花的钱得花。"省成本"不是"用最便宜的",是"最贵的只用在刀刃上"。
踩过的坑也记录一下:
context_compaction调激进一点pip install验证,失败自动重试基于实测数据,我把工作流拆成了三层路由:
核心思想一句话:按任务难度和失败代价分派模型,而不是按心情。 具体规则(可以直接抄):
任务分级规则(写入项目的 AGENTS.md):
L1 机械任务:测试补全、格式化、rename、commit信息、文档
→ DeepSeek V4(成本0.02-0.05元/次)
L2 常规编码:CRUD、接口实现、小功能、bug修复
→ Kimi K3 或 Sonnet 4.6(成本0.5-3元/次)
L3 架构任务:模块拆分、并发设计、技术选型、复杂重构
→ Opus 4.6(成本5-25元/次),Sonnet做初稿、Opus做评审可省40%
兜底规则:L2/L3任务失败后自动升级模型重试一次,再失败才转人工
工程实现上,我没有自己造轮子,是组合现成工具:
.claude/settings.json里配了subagent分流,让Sonnet子agent干L1/L2,主agent(Opus)只处理被升级上来的任务另外一个大杀器是减少上下文投喂。以前我是"整个仓库塞进去",现在是:先跑一遍repomix生成结构化仓库摘要(只带关键文件全文,其余只留签名),一次会话的输入token从45万降到12万左右,降幅73%。信息密度反而更高了,因为模型不用在一堆无关文件里大海捞针。
9月17日我拉了新账单,改造上线满30天:
关于什么值得折腾、什么是智商税,我态度很明确:
值得折腾的:prompt caching(配置一次永久受益,这是纯捡钱)、任务分级路由(两周搭建成本,一个月回本)、上下文瘦身(repomix这类工具十分钟上手)。这三个组合拳占了我降本的90%。
智商税/别碰的:所谓的"万能Agent编排平台",卖你几百刀一个月,底层就是帮你调几个API,规则还不透明——路由逻辑写成markdown规则文件,免费且你自己可控;某些"自动评估模型质量"的付费服务,自己拿20个真实任务做基准,一小时搞定,数据还更贴合你的场景;以及盲目囤各家订阅会员,实测下来按需API + 两个订阅(Claude Pro + 一家便宜的)是最优组合,全订等于给五家公司同时交月租但只用其中两家。
清单时间,直接抄:
repomix或类似工具给仓库瘦身,把单次会话输入token压到15万以内说明:文中成本、token消耗、耗时及通过率等数据来源于本人项目API账单统计与个人基准测试记录,结合公开行业报告综合整理,部分数值为估算仅供参考。