一位独立开发者的实验表明，通过使用三种 Claude 模型，每月 API 成本降低了 35%，任务中位延迟从 42 秒降至 27 秒。通过将简单、低模糊度的任务路由到廉价的 Haiku 模型，将常规工作交给 Sonnet，并将重量级的 Opus 留给高风险问题，作者证明了“万能模型”是一种昂贵的习惯。

为什么路由至关重要

作者运行着一个自主编程智能体，它会持续接收开发任务——包括 lint 修复、功能新增、安全审查和深度调试。几个月来，该智能体一直将所有请求发送给能力最强的 Claude 模型 Opus，认为高质量总是优于价格。由于 Opus 的每 token 价格较高，账单随之失控增长。

当作者引入分层路由方案后，支出降至原水平的 65%，Opus 的使用量降至总任务量的 11%。

三层系统如何运作

路由逻辑取决于模糊度，而非任务涉及的代码行数。作者定义了三个类别：

  • Haiku – 低模糊度、确定性任务。例如：修复 lint 警告、重命名变量、总结日志文件。正确答案通常只有一行代码或文本。
  • Sonnet – 默认主力。处理功能实现、常规 Bug 修复和标准重构，这些任务问题明确，但解决方案可能涉及多个步骤。
  • Opus – 高风险、高模糊度工作。架构决策、安全审计、复杂的调试会话，或任何正确路径不明且一步走错可能导致流水线崩溃的任务。

一个静态查找表根据这些规则将每个传入请求映射到相应的模型。作者曾尝试使用一种可以动态决定层级的“智能”模型，但额外的 token 使用量抵消了所有节省。简单的静态规则覆盖了约 80% 的工作量，并保持了系统的廉价与可预测性。

升级安全网

廉价模型仍会犯错。为了防止 Haiku 或 Sonnet 的错误响应导致构建失败，系统会在两次失败后升级请求，将其提升到下一层级。这种安全机制能及早发现错误，并在无需人工干预的情况下保持流水线顺畅运行。

数据说明一切

运行分层路由器四周后，作者记录了以下变化：

  • API 支出降至原成本的 65%（减少了 35%）。
  • 中位处理时间从 42 秒降至 27 秒。
  • Opus 使用量从处理所有请求缩减至仅占总任务量的 11%。

这些数据表明，大多数开发工作可以委派给更便宜的模型，而不会明显降低质量，同时最棘手的问题仍能受益于 Opus 更大的上下文窗口。

给其他开发者的启示

  1. 从低级开始，而非高级。 大多数日常编码琐事不需要最强大的模型。将 Sonnet 作为模糊任务的默认模型，比将所有任务都推给 Haiku 更省钱。
  2. 衡量难度，而非规模。 一个单行的竞态条件修复可能比重构整个文件更难。应根据解决方案的模糊程度进行路由，而不是根据修改的代码行数。
  3. 关注升级率。 升级次数增加意味着静态规则已不再匹配工作负载。在廉价模型开始导致更多流水线故障之前，及时调整类别划分。

将最昂贵的模型留给最棘手的问题，让廉价模型处理其余工作，可以保持 AI 辅助开发的快速与经济。真正的优势在于通过严谨的路由策略，将正确的工具匹配给正确的工作。