烧掉2亿Token之后，我不再让模型干所有活

来源 | 至顶AI实验室

"我得停止用Claude Opus了，这条路走不通。"
说这句话的时候，Heitor Lessa 刚做完一次重构，烧掉了2亿Token。
他不是那种拿AI 玩票的人，在AWS干了11年，换过8 个岗位，他主导的开源工具库Lambda Powertools，现在每周被调用2300亿次。
这样一个人，在自己最熟悉的工作上，被Token账单打了个措手不及。
说实话，两亿token这个数字本身没什么稀奇的，现在只要认真用过一段时间Claude Code ，多少都有这种体会：一个功能改到一半，进度没动多少，额度先见底了。
区别在于，大部分人的反应是骂一句，然后静等5个小时的额度重置；而Heitor Lessa 把整套工作流推倒重做了一遍，现在这套东西，每天有1400 名工程师在用。
他把完整重构流程录了下来，放到了YouTube上，113 分钟，从最初的需求讨论一路讲到代码合并前的最后一道检查，全程开屏演示。
看完我发现了一件有意思的事：标题里"不再让模型干所有活"这件事，在视频第56 分钟才出现。前面将近一小时，他一个模型都没提。

他先动的不是模型，是顺序

烧掉2 亿Token 之后，一个正常人的第一反应是去比价，Heitor Lessa 没有，他先回头看的是，这2 亿Token 到底花在了哪。
这些token大部分不是花在写代码上，而是花在反复解释自己想要什么。AI 跑偏了，拉回来；理解错了，再说一遍；改到一半发现方向不对，推翻重来。
而每一轮重来，都得把相关的代码、文件、之前的对话重新喂给模型一遍，这部分是账单里的大头。真正产出有效代码的那点开销，在总账里占比小得可怜。
所以他重建工作流的时候，第一刀砍在了顺序上。
Heitor Lessa演示了一整套前置流程：一个需求进来，先花时间搞清楚"到底要解决什么问题"，再把白板上那些零散想法整理成一份正式的开发计划、存进代码仓库里，然后才轮到AI 动手。
这两步他各配了一个固定的流程入口，前一步叫Discovery，后一步是一条自己写的命令 “/roadmap”，名字不重要，重要的是他把"想清楚"这件事变成了一道必经的关卡，绕不过去。
人先规划，AI后执行，顺序反了，后面全是返工。
规划阶段是人在思考，成本几乎为零；执行阶段AI 是在烧Token 想，一轮几毛钱。把想不清楚的问题丢给AI，等于用最贵的方式做最不确定的事。2亿Token 里那些冤枉钱，说到底都是意图不清晰的价格。
他在32 个不同的模型上验证过，看同一套预设指令能不能稳定跑出同样的结果，从而可以决定哪些模型干哪些活性价比最高。
一个真正在做模型调度的人，工作量首先花在的地方不是选型，而是兼容性，同样一句话，换个模型执行，会不会跑出完全不同的东西。想让便宜模型接活，前提是你的指令足够明确到换个人也能照做。做不到这一点，换模型不是省钱，是给自己找返工。

怎么让Agent 不骗你

流程理顺之后，遇到了第二个问题：Agent 会说谎。
它跟你说测试通过了，你信了，代码合并了，第二天线上出问题，回头一查，测试根本没跑通。
Heitor Lessa的应对办法是给每一份测试计划都配了一个专门唱反调的角色，任务就是挑刺，这个方案哪里会崩，边界情况想了吗，这个假设凭什么成立。紧接着是一串刨根问底的追问，不给答案，只反复问为什么，逼着测试计划自己暴露漏洞。
他演示了一个叫 “new-work”的命令，专门处理开发过程中冒出来的新需求，这是很多团队用Agent 时的隐形出血点：做着做着发现还得顺手改个别的，于是任务范围一点点膨胀，要喂给模型的东西越滚越多，最后一次会话烧掉的Token 是原计划的好几倍。“new-work” 干的事很简单，把新冒出来的活记下来、挪出去，不让它污染当前这条线。
他把最需要判断力的部分牢牢留在了人这边，把可以被明确描述的部分才交出去。这不是对AI 不信任，是分工清楚。

三档模型，各司其职

Heitor Lessa在视频里铺垫了将近一个小时，真正的开发环节才开始，起手是把那份写好的规格文档摊开、让AI 先把相关代码摸一遍，然后把模型分成三档：最强的、中间的、最便宜的。
分档的标准，就一条：错了之后修正的难度。
架构决策、数据库改动、接口和数据结构的定义、涉及权限和安全的代码，这些要上最好的模型。不是因为它们复杂，是因为它们不可逆。一个字段类型定错了，三个月后要动的是十几处代码和一次数据迁移；一段权限逻辑写错了，代价可能是一次事故，这类地方省下的那点钱，跟返工成本比根本不成比例。
常规实现、代码整理、写测试这些活，中档模型足够，它们有明确的输入输出，做错了跑一遍测试就能发现，改起来也便宜。
样板代码、批量改名、写文档、整理日志、生成提交说明，这类活交给最便宜的档位，甚至可以考虑跑在本地的模型。它们的共同点是：不需要理解全局，只需要照着规则做完。
Heitor Lessa提到了一类容易被忽略的例外，要求模型严格按固定格式返回数据的场景，反而不适合降级。比如让它决定该调用哪个工具、按规定的字段结构回话，便宜模型在这种地方翻车的概率明显更高，而一旦格式错了，整条自动化流程就断在那儿，排查的时间成本比省下的那点API 费用贵得多。
YouTube上其他开发者也做过一次更直接的对照实验：同一个用Rails 写的网站功能，一边全程用最贵的模型做，一边拆开交给Opus、GLM、DeepSeek 分工完成，然后比费用、比耗时、比返工次数。
结论和Heitor Lessa 这套是一致的，省钱的关键不在于用了多便宜的模型，在于有没有把任务拆分清楚。

应该怎么用？

对国内开发者来说，这套方法论落地的条件其实比海外更好，因为模型要便宜得多。
DeepSeek V4目前的挂牌价，快速版输入，每百万Token只有约1元钱，高配版每百万token也就才3元。同一段内容被翻来覆去地读，命中缓存之后能降到2毛钱/百万，跟Claude差着不止一个数量级。
官方也已经给Claude Code、OpenCode、OpenClaw 这些工具提供了现成的接入方式，基本就是改个模型名的事。
国内学术界也验证过这条路。有论文在125 个真实的Claude Code 生产请求上做了模型路由，简单说，就是加一层调度，按任务难度自动决定这一次该派给哪个模型，结果相比全程直接用 Claude，API 成本降低了45.8%。
这从侧面验证了Heitor Lessa 的思路。
基于这套理论，那我们应该怎么用？
对于个人开发者，最省事的做法是主力用中低档模型，遇到架构决策、数据库改动这类活手动切到最好的。不用搞什么自动调度，你自己就是那个调度器。
小团队，重点不在模型，先把验收标准写好，测试必须真跑一遍而不是听AI 汇报、每一处代码改动人必须同步测试一遍。做不到就先别降，否则，省下的Token 会以线上事故的形式还回来。
而对于企业，除了成本还有三件事得先想清楚：代码传出去的合规边界、代理服务商的真伪（市面上转售的所谓"官方接口"不少经不起查）、以及换了模型之后行为不一致该怎么追溯。这些的优先级，都在省钱前面。
回到最开头那句话。
Heitor Lessa 省下钱，不是因为找到了更便宜的模型，他花了将近一个小时讲流程、只用不到二十分钟讲模型怎么分档，这个时间分配本身就是答案。

 

至顶AI实验室 作者：高书葆
vibe codingClaudeToken经济学