AI大土豆
@suanwan
一条被热议的案例（阿拉伯语长文转述）：Spotify 把 Claude Code 的账单砍掉了 90%，事后把它用的那套工具作为开源项目放了出来（插件链接在发帖人的评论里）。
它先把问题拆开：coding agent 的日常大头其实是读写文件——回答一个文件的问题要读五个文件、写测试时把已有二十个文件的逻辑再抄一遍——而这些活儿全都在用远高于需求的模型干粗活。按他们的观察，token 消耗的很大一块流向例程工作：读文件、重复性测试、config 准备、文档更新，它们并不需要解复杂代码题的那层思考。
解法是按任务把活派给合适的模型：例程活交给便宜模型（他们用的是 Gemini 2.5 Flash），强模型只负责真正需要判断力的部分。为此他们做了两种模式——一个模式专门读文件、返回要点摘要；另一个模式直接把例程代码写进文件。
Claude 从此不必接收文件全文，要处理的 token 自然就下来了。两种模式的分工也有讲究：读的那侧负责把"文件里有什么"压缩成结论，写的那侧负责把重复性改动落盘，真正需要连贯推理的主模型只拿结论、只看差异——它省下的不只是输入量，还有被无关细节反复挤占的注意力。
这套做法里最值钱的教训是第三条：光写分配规则没用。第一版把规则写进 config 文件，模型读完之后照样忽略——纸面规则对模型来说只是又一段可选的上下文，任务一急就会被绕过去；真正跑通的版本是插件 + hook——在那次昂贵的读发生之前直接把它拦住。
规则写在纸面会被无视，闸门装在通路上才会生效。这个顺序很关键：先有拦截机制，再谈优化目标，否则所有的"以后记得省着点"都会在下一轮对话里蒸发。
边界也要说清楚：例程与关键任务的分界必须小心。他们的实测里，便宜模型会漏掉一个与线程安全相关的细微问题，强模型几秒就抓了出来——这不是偶然：并发类缺陷往往藏在"看起来读得懂"的细节里，便宜模型能复述代码，却未必会主动怀疑不变量；改代码、调试、架构决策这类活儿，路由必须保守；派错了地方，省下的钱会连本带利赔进返工里。
个人用户也有可以直接抄的部分：先给自己的工作流做一次 token 审计——如果你的账单大头也在读文件、写测试、补 config，那么给"读"这一步接一个便宜模型的摘要模式，收益立竿见影；没有插件能力的工具，至少可以在提示里把"读文件前先说明为什么要读"变成硬要求，虽然不如 hook，但总比默默全读强。
我的看法是三个点可以直接迁移：其一，先审计再优化——如果你不知道自己的 token 大头花在哪，先去看一眼是不是也全砸在读文件和写测试上；其二，约束要用机制、不要用嘱咐——这与"给 Agent 的规矩必须可执行"是同一个道理，写在提示里的规则会被上下文冲掉，hook 这种硬闸门才拦得住（今天的多个项目里都能看到同一种设计取向）；其三，选模型的粒度是任务、不是项目——同一个工作流里，读文件、写例程和诊断 bug、设计系统要的是完全不同的模型，按任务分而不是按项目锁死，成本结构立刻就不一样了。
账单降九成的配方其实很朴素：把粗活分出去、把规矩做成开关、把好钢用在刀刃上。他们把工具开源这一步同样关键——九成的降幅至少有了仓库可以对照复核，这比只发一篇成功学总结可信得多。插件的思路倒不用等仓库：你现在就可以给自己的 agent 加一道"读之前先想清楚"的闸门。
