烧掉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 省下钱，不是因为找到了更便宜的模型，他花了将近一个小时讲流程、只用不到二十分钟讲模型怎么分档，这个时间分配本身就是答案。