别再迷信最强模型了，真正省钱的是模型路由

如果你最近用 AI 写过代码，大概率遇到过这种情况。

让它设计一个模块，用的是同一个模型；让它改一个变量名，用的还是同一个模型；让它读日志、跑测试、修报错、再跑测试，整个 Agent 循环里，依然是同一个模型从头干到尾。

看起来很省心。

账单也会很诚实。

很多 AI 编程成本变高，并不只是因为模型贵，也不只是因为你用得太多。

更常见的原因是：任务没有分流。

一个成熟的工程团队，不会让架构师去做所有格式化，也不会把安全审查交给刚入门的人。

但很多人一到 AI 工作流里，就把这个常识忘了。

复杂架构、日常实现、单行修改、代码补全，全都扔给同一个模型。

问题就出在这里：简单任务花了不该花的钱，复杂任务又未必拿到足够强的判断。

所以《AI成本账》这一篇，我想讲一个很朴素但很重要的动作：

给你的 AI 工作流加一套路由规则。

Token 是账单，路由是结构。

账单只能告诉你钱花出去了，路由才能决定下一次钱该花在哪。

这篇文章不打算做模型排名。读完你能拿走三件更实用的东西：

• 一张判断任务该交给哪层模型的路由表；
• 一个 30 分钟就能搭起来的最小路由器；
• 一套避免长 Agent 循环烧钱的检查方法。

不要再问“哪个模型最强”。

先问“这件事到底需要哪一层能力”。

模型路由，本质是给工作分层

所谓模型路由，听起来像一个技术系统。其实最小版本只是一张判断表：每次把任务交给 AI 之前，先判断它属于哪一类。

我建议先分成四层。

第一层，决策层。

这层处理的是少数关键判断：系统架构、技术选型、安全审查、跨模块重构方案、复杂线上问题定位。这里最贵的是决策错误。一旦方向判断错了，后面几十次对话、几十个文件修改、几轮测试都会跟着走偏。

所以这部分任务值得用高级模型。

第二层，主力层。

这是日常编码的主体：实现功能、调试、重构、补测试、读代码、修失败用例、跑中等复杂度的 Agent 循环。

它需要可靠，但不需要每一步都动用最贵的模型。如果你的 AI 使用量很高，真正决定长期账单的往往就是这一层。

第三层，执行层。

这层处理目标明确的小任务：格式化、变量命名、单行修改、小段样板代码、JSON 转换、注释补全。

这类任务需要快、便宜、少打扰，复杂推理在这里反而浪费。

第四层，本地层。

自动补全、通用存根、代码片段、脚手架、简单语法修复，很多时候可以交给本地模型、IDE 补全或脚本。

这一层的价值是低摩擦。它不需要很聪明，只需要随手可用。

一旦你把任务分成这四层，AI 成本就开始变清楚：省钱的关键，是让每一类任务使用匹配的智能密度。

最烧钱的地方，通常是长 Agent 循环

很多人盯着单次调用成本。

但在真实编码里，更值得盯的是长循环。

比如让 Agent 修一个 bug。

它先读文件，再搜索引用，再改代码，再跑测试，再看报错，再读另一个文件，再改一次。

这个过程可能跑十几轮，甚至几十轮。

如果每一步都走高端模型，单步看着还好，循环一长就很贵。

更关键的是，循环里的很多动作并不需要顶级判断。

搜索文件、读取日志、格式化代码，这些都属于执行动作。根据一个明确的测试失败改小分支，也未必需要顶级判断。

真正值得升级到高级模型的，往往是几个关键节点。

• 开始前，判断任务怎么拆。
• 中途卡住时，判断是不是路线错了。
• 合并前，检查有没有架构、安全和边界风险。

高级模型更适合做总工。让它负责每一步流水线操作，账单自然会难看。

一张可以直接用的路由决策树

你可以从这 5 个问题开始。

1. 这是架构、规划或高风险判断吗？

走决策层。

比如系统设计、安全审查、关键技术选型、跨模块重构方案。

这类任务数量不多，但影响很大。

如果做错，后面会产生连锁返工。

2. 这是正常实现、调试、重构、补测试或代码审查吗？

走主力层。

这里可以放你当前最信任的日常编码模型。

它不一定是最贵的模型，但要能稳定完成中等复杂度任务，能读懂上下文，能跑多轮修改。

3. 这是包含多次迭代的 Agent 循环吗？

默认走主力层，中间关键节点再升级。

长循环最怕每一步都贵。

更合理的做法是：开头规划和结尾审查用强模型，中间执行用主力模型。

4. 这是代码检查、格式化、重命名、单行修改吗？

走执行层。

用轻量模型、IDE 能力或脚本。

这类任务目标明确，错误成本低，不值得占用高级模型。

5. 这是自动补全、样板代码、通用存根吗？

能本地就本地。

本地模型、代码片段、脚手架工具，很多时候比在线大模型更合适。

这套规则不复杂，难的是你要愿意把它写进自己的工作流里。

Kimi K2.6 适合放在哪一层？

如果按这套路由来看，Kimi K2.6 更适合作为“主力层候选”。

也就是用于日常实现、调试、重构、多轮 Agent 循环。

它不需要被神化成“唯一答案”。更实际的价值在于：它让日常编码主力层多了一个成本更友好的选择。

对高频编码用户来说，这个变化很重要。

真正持续消耗账单的，往往是每天反复发生的实现、调试、重构和 Agent 迭代。

高级模型仍然有自己的位置。关键架构、安全审查、复杂边界判断，依然值得交给更强的模型。

但日常主力层要追求的是另一种平衡：足够强、上下文够用、成本能承受、长循环跑得起。

所以，与其争论谁是最强模型，不如拿自己的真实项目做三组测试。

第一组，同一个 bug，让不同模型各修一次，看谁能一次通过测试。

第二组，同一个重构任务，看谁改动更稳、返工更少。

第三组，同一个 Agent 循环，看完整跑下来花了多少钱、用了多久、最后质量如何。

测试完，你自然会知道谁适合做你的主力层。

别用别人的榜单替代自己的账单。

30 分钟搭一个最小路由器

你不需要一开始就做复杂系统。

先做一个 30 分钟版本。

先列出你最近一周最常见的 AI 任务。

不要写“写代码”这种大词，要写具体动作。

• 读一个陌生模块。
• 修一个测试失败。
• 生成接口样板。
• 重构一个函数。
• 查线上报错。
• 做方案评审。
• 写 PR 描述。
• 批量改命名。

然后把它们分到四层：决策层、主力层、执行层、本地层。

再给每层指定默认工具。

例如：

• 决策层：高级模型，用于架构、安全和最终审查。
• 主力层：日常编码模型，用于实现、调试、重构和 Agent 循环。
• 执行层：轻量模型或 IDE 能力，用于格式化、小修、转换。
• 本地层：本地模型、脚本、代码片段，用于补全和样板。

接着，把规则写进项目文档。

可以是 AGENTS.md，也可以是你自己的 AI_ROUTING.md。

重点不在写得多漂亮，重点是每次启动任务前都能看到。

最后，每周复盘一次。

只看三个问题。

哪类任务最贵？

哪类任务返工最多？

哪类任务其实可以下放到更便宜的一层？

跑一周，你就会比大多数人更清楚自己的 AI 账单。

别把路由做成新负担

这里有一个容易翻车的地方。

有些人一听模型路由，就开始配一堆模型、网关、脚本、自动规则。

最后省下来的 Token，还不够他折腾配置消耗的时间。

开始阶段，三层就够了。

高级模型，负责少数关键判断。

主力模型，负责大多数日常编码。

便宜模型、本地工具或脚本，负责清理和样板。

等你真的有稳定用量，再考虑自动路由、成本看板、日志统计。

不要为了省钱，先把系统搞复杂。

AI 成本管理最重要的原则很简单：先找大头，再改一个最影响账单的动作。

最值得复制的一张表

你可以直接把下面这张表放进项目规则里。

这张表提醒的是一件很基础的事：任务不同，值得支付的智能密度也不同。

最后，把路由变成结构

如果第一篇讲的是“别让 Token 白白烧掉”，第二篇讲的是“Token 账单到底由什么组成”，第三篇讲的是“先做一次成本体检”，那这一篇要解决的是：

体检之后，怎么改工作流。

模型路由就是最直接的一步。

它会逼你区分：

哪些任务需要判断。

哪些任务只是执行。

哪些任务可以自动化。

哪些任务应该沉淀成模板、脚本或本地能力。

表面上看，这是在少花几块钱。

更深一层，这是在训练自己重新组织 AI 能力。

你开始把 AI 从一个随手打开的聊天框，变成一套更清楚的个人工作系统。

Token 是账单，流程才是资产。

模型路由，就是把这句话落到每天写代码的第一步。