把 Haiku 4.5 当 Router 用，我给 API 账单砍了七成

上个月我给一个做跨境电商的朋友做了个客服 bot，接 WhatsApp 和独立站两个入口，每天大概 3000-4000 轮对话。刚上线的时候我图省事，全部走 Sonnet 4.6——毕竟他们家客户问的问题挺杂，有退换货有物流追踪有产品咨询，我怕 Haiku 扛不住。

结果第一个月账单出来，$430。朋友当时没说什么，但我自己看着这个数字挺刷新的——一个小电商客服，一个月光 AI 费用就快赶上一个兼职客服工资了。这东西如果要商用化，成本必须砍下来。

我花了差不多一周时间重构，最后的方案就是标题这个：前面塞一个 Haiku 4.5 当 Router，先判断问题类型，简单的直接 Haiku 回，复杂的才转给 Sonnet。上线跑了一个月，账单掉到 $128，砍了大概 70%。这篇把整个思路和踩过的坑都讲清楚。

一、为什么是路由，不是降级

很多人第一反应是”那我直接全部换成 Haiku 不就行了”。我试过，不行。

Haiku 4.5 处理简单问题确实够用，但它有几个明显的短板：

多轮对话容易丢线索。用户上一轮说了订单号，下一轮问”那个能退吗”，Haiku 有概率接不住
复杂意图识别差。用户一句话里塞了三个问题（”我想退货，但我找不到订单，而且我换了邮箱”），Haiku 经常只回第一个
专业术语翻车。电商行业的”FBA””海外仓””清关”这些词，Haiku 的理解深度明显比 Sonnet 浅一层
指代消解能力弱。用户说”刚才那个”、”上面说的”，Haiku 有时候会在历史里找错引用对象

所以纯 Haiku 走不通。但反过来，大量的问题其实根本用不到 Sonnet 的智能——“你们几点上班””怎么联系人工””订单多久发货”，这类 FAQ 类问题，Haiku 一句话就能搞定，上 Sonnet 纯粹是杀鸡用牛刀。

路由的核心思想：让便宜的模型做选择，让贵的模型做事。

这里其实还隐含一个很多人不重视的点——路由本身也要算账。你不能为了路由加一层 GPT-4 级别的分类器，那就本末倒置了。Router 必须用成本可以忽略的模型，Haiku 4.5 的定价刚好够得着这条线。

二、Router 的 Prompt 到底怎么写

这里是整个方案最关键的地方。Router 的 prompt 写得好不好，直接决定误判率。

我最终跑通的版本大概长这样（简化过）：

<role>你是一个客服问题路由器。只做一件事：判断用户问题类型。</role>

<categories>
  <simple>
    打招呼、问营业时间、问联系方式、问退换货政策、
    问物流时效、问支付方式、问发票、简单的产品参数查询
  </simple>
  <complex>
    具体订单查询（带订单号）、投诉、多意图（一句话多个问题）、
    需要查询历史订单、涉及金额纠纷、需要调用工具
  </complex>
</categories>

<examples>
  <example>
    <input>你们周末上班吗</input>
    <output>simple</output>
  </example>
  <example>
    <input>我订单 #A2389 到现在还没发，怎么回事</input>
    <output>complex</output>
  </example>
  <example>
    <input>我想退货，但是我找不到当时的订单号</input>
    <output>complex</output>
  </example>
  <example>
    <input>运费怎么算</input>
    <output>simple</output>
  </example>
</examples>

<rules>
- 只输出 simple 或 complex，不要解释
- 拿不准的时候输出 complex
- 带数字订单号、金额的一律 complex
</rules>

用户问题：{user_input}

几个经验点：

1. Few-shot 4-6 个例子就够了。我一开始堆了 20 个例子，发现 Haiku 反而开始”过度思考”，准确率还下降了。后来砍到 6 个有代表性的，每个类别各 3 个，反而更稳。这个现象有点反直觉，但在很多分类任务里都能看到——例子太多会让小模型陷入”模式匹配”而不是”理解规则”。

2. 最后那条”拿不准的时候输出 complex”是救命稻草。这是一个不对称代价的场景——把简单题误判成 complex 只是多花点钱，但把 complex 误判成 simple 可能会让用户炸毛。所以默认倾向于保守。这个思路在任何业务路由里都通用——先想清楚误判的两类代价谁更高，然后让 prompt 倾斜向代价低的那一边。

3. XML 比 Markdown 好用。这点我另一篇《为什么 Claude 只吃 XML 不吃 Markdown》专门写了，这里就不展开，反正实测 XML 的路由准确率高 8-10 个百分点。

4. 强制单 token 输出能再快一截。如果你 Router 只需要 simple / complex 两个输出，可以把 max_tokens 设成 5，并且在 prompt 末尾加一句”直接输出标签，不要换行不要解释”。这样单次 Router 延迟能压到 200ms 以内。

三、命中率和误判率：真实数字

跑了一个月，我拉了一下日志做了统计。总调用量 98000 次左右：

被路由到 simple（Haiku 回复）：72%
被路由到 complex（Sonnet 回复）：28%
Router 自己的误判率：约 3.2%

误判里面又分两种：

simple 误判成 complex（花了冤枉钱）：约 2.1%
complex 误判成 simple（用户可能不爽）：约 1.1%

第二种是真正需要关注的。我翻了这 1.1% 的日志，大部分是用户表述特别隐晦的情况——比如”前两天那个东西一直没到”，没说订单号，没说产品名，Haiku 就判成 simple 了。

我的兜底方案是在 Haiku 回答之后加一层 confidence 检查：如果 Haiku 自己也觉得回答不了，让它输出一个特殊 token <<ESCALATE>>，系统检测到这个 token 就重新路由到 Sonnet。这一层兜底把实际”用户可能不爽”的比例压到了 0.3% 以下。

这个兜底逻辑的实现也很简单，就是在 Haiku 的 system prompt 里加一句：

1 2	如果你不确定答案、或者用户问题需要查询订单/账户/实时数据，直接输出 <<ESCALATE>> 然后停止，不要编造答案。

Haiku 对这种 “知道自己不知道” 的指令还挺听话的。

四、账单的账算给你看

这是最实打实的部分。按 Anthropic 的定价（我用的是 2026 年 Q1 的价格）：

Sonnet 4.6：$3 / $15（input/output，per million tokens）
Haiku 4.5：$0.25 / $1.25

一轮平均对话大约 800 input + 300 output token。

纯 Sonnet 方案：每轮成本约 0.0069 美元，98000 次 = $676
（和我实际 $430 有差距是因为有 Prompt Caching 节省，这里只算理论上限）

Router 方案：

98000 次 Haiku 路由判断，每次约 200 token in / 5 token out，Haiku 成本 = 约 $5
72% 用 Haiku 回复，每次约 800/300 token，成本 = 约 $44
28% 用 Sonnet 回复，每次约 800/300，成本 = 约 $190
合计 $239

实际账单 $128 比这个还低，多出来的部分是 Prompt Caching 省的——因为 Router 的 prompt 是固定的，system prompt 命中 cache 之后 input token 成本降到 10%。这点不开 cache 你就白瞎了 Haiku 的便宜。

再补一笔：Haiku 4.5 本身也支持 Prompt Caching。我 Router 的 system prompt + few-shot 大概 400 token，每次请求这部分都能 cache 命中，理论上 98000 次 Router 调用光 cache 就能省下接近 $3——听起来不多，但这是在已经很便宜的基础上再打对折，积少成多。

五、边界判断的几个坑

踩过的具体坑：

1. 带数字不等于 complex。
我一开始粗暴地写了”带数字一律 complex”，结果”我买过 3 件”这种陈述也被扔给 Sonnet 了，浪费钱。后来改成”带订单号格式的数字（比如 #A 开头、纯 8 位数字、带连字符）”才稳定。

2. 多语言切换会让 Router 懵。
客户里有东南亚用户，一句话里中英文夹杂。Haiku 对混合语言的类目判断准确率会掉 10 多个百分点。解决办法是在 Router prompt 里加一条：<rule>输入可能是任意语言，只看意图不看语言</rule>，立竿见影。

3. 不要让 Router 兼职做别的事。
我中途想偷懒，让 Router 顺便输出一个”情绪标签”（positive/negative/neutral），结果路由本身的准确率掉了。模型一心二用容易出事。Router 就做路由，别的活交给下游模型。

4. Router 也要做 eval。
我每周会抽 200 条真实对话人工标注一遍，跑 eval 看准确率有没有飘。语料分布是会变的——最近有个产品出了点质量问题，投诉类问题突然变多，老的 few-shot 就不够用了，得补新例子。

5. 别忽视上下文污染。
Router 在判断当前用户输入的时候，有人会把之前的对话历史也塞进去。我试过，发现这样反而拉低准确率——因为 Router 开始综合历史做判断，变复杂了。Router 只看当前这一句，历史信息留给下游模型。

六、什么场景适合搞 Router？什么不适合

适合的：

流量大（每天过千轮），Router 的开发成本能分摊
请求类型差异大（FAQ 和深度分析混在一起）
大部分请求其实很简单（符合二八分布）
对成本敏感（比如 toC 业务、免费产品，用户量起来之后 token 成本会要命）

不适合的：

请求都很复杂（比如纯研发辅助、纯 Agent 编排），这种场景 Haiku 根本接不住，路由意义不大
流量很小（一天几十轮），你花一周开发 Router 的时间还不如直接烧钱
对延迟极度敏感（voice agent），多一次模型调用就是多 200-500ms
需要严格可解释（金融、医疗），Router 引入了额外的失败点，审计会更复杂

顺带说一下，如果你是做 Claude Code 辅助开发这种场景，claudecode.cocoloop.cn 已经帮你在工具层做好了模型选择策略，不用自己搞。Router 模式主要还是面向自研业务 API 调用的情况。

七、下一步：多级路由和动态 threshold

Router 不是什么新鲜东西，但大部分人没意识到这玩意儿能省到 70% 这个量级。关键在于：

Haiku 4.5 真的比你想象中聪明，做分类器绰绰有余
few-shot 要精而不要多
一定要开 Prompt Caching
不对称代价要体现在 prompt 的兜底规则里

再往下一步是做多级路由——Haiku 先判大类，Sonnet 再判子类，Opus 只负责最硬的 5%。这个方案我还在试，初步数据是能在 Router 方案基础上再省 15% 左右，但引入的复杂度也大幅提升，对 eval 和监控的要求更高。

另一个方向是动态 threshold——Router 不输出硬 label，而是输出一个置信度分数，根据分数决定走 Haiku 还是 Sonnet。比如 score > 0.9 走 Haiku，score < 0.5 走 Sonnet，中间段走 Haiku + escalate 兜底。这个方案理论上最省，但要调的参数也最多。

对了，如果想看更多 Claude 成本优化相关内容，可以翻翻站内的成本优化分类，有好几篇相关的。

想持续关注 AI 降本实战？

本站会持续更新 Claude 各种成本优化案例。想看更多 AI 行业一手新闻可以去 news.cocoloop.cn，看各类 AI 工具评测可以访问 www.cocoloop.cn。