claude haiku 4.5避坑，把要注意的地方一条条讲清楚

搜「claude haiku 4.5避坑」的人，多半已经在用或者准备接入了，卡的地方也很像：便宜档的模型被拿去干重活，跑出来效果不行；或者账单比预估高出不少，回头查发现是上下文和缓存没算进去。这篇不堆概念，给一套能照做的判断标准和排查顺序，让你在选型、接入、对账三个节点上少走弯路。

搜「claude haiku 4.5避坑」的人，处境其实挺像：要么手已经放到了接入代码上，要么账单已经出过一次血。卡住的地方也集中在三处——活派错了、账算错了、上线前没核对。这篇按这三个节点拆，每处给能照做的判断标准和排查顺序。

先摆个前提：便宜档的模型不是不能用，是它的强项和弱项差得比较明显。你不把任务边界划清楚，省下来的单价会被返工和时间吃掉。下面从选型开始讲。

先分清哪些活不该派给它

最容易踩的第一坑，是把重活塞给轻量档。长链路推理、多步工具调用、要求严格格式输出（比如固定 JSON 结构）这几类任务，交给便宜档之后的返工率会明显抬头。返工一次的代价，往往比一开始就用高一档更高——你不光是多跑一遍，还要多写一层容错逻辑。

它擅长的是什么？输入短、判断简单、量大、错了也能兜住。分类打标、短文本改写、做初步筛选、把一堆脏数据先过一遍，这些活它接得住。判断标准给一个可操作的：同一个提示词连着跑两遍，结果差得离谱，说明这活对稳定性要求高，别硬压给它。选型前先去 /models 看同类模型的定位和推荐场景，别凭感觉拍板。

• 长链路多步推理、多轮工具调用：返工率高，不建议用它扛
• 严格格式输出：结构一旦飘了要写额外校验，省的钱搭进去
• 分类打标、短文本改写、初筛：输入短、容错高，适合它
• 同一个提示词两次结果差异大：说明稳定性要求高，换档

计费口径对不上，账一定算错

第二个坑更隐蔽：按输入输出两行单价心算，算出来的数跟账单永远对不上。实际口径至少有四项——输入、输出、缓存写入、缓存读取，每一档单价都不是一个数。你把系统消息和几个示例塞进提示词，每一轮对话都会重复计费，这部分在大用量下才是大头。

所以单价这事儿别背，背了就过期。当期规则到 /official-api/providers/anthropic 核对，再把一次真实调用丢进 /tools/model-cost-calculator 折成具体金额，心里才有底。

缓存能不能命中，是有技巧的：命中率取决于前缀稳不稳定。把会变的内容（用户输入、时间戳、随机 ID）放到提示词末尾，固定部分放前面，命中率才上得去。反过来放，缓存写了也用不上，等于白付写入的钱。

上线前该做的三次核对

接入跑通不等于可以上线。我建议在上线前固定做三次核对，顺序别乱，因为后一次依赖前一次的结果。

1. 核口径拉一条真实请求的日志，把输入、输出、缓存写入、缓存读取四项各自的量抄下来，别用估算值。四项对不上，说明你还没搞清自己实际在为什么付费。
2. 核单价模型档位、区域、渠道不同，单价都不同；走中转的还要看倍率。到 /price-watch 看当期变动，别用三个月前的截图做预算。
3. 核余量按峰值并发估一遍每分钟请求数。限速卡住之后的重发也会产生消耗，这部分最容易被漏算。

这三步做完，你手上会有一份「一次调用实际花多少」的账，而不是一个单价数字。预算也好，对账也好，都从这份账出发。

账单不对劲时的排查顺序

账超了别急着怀疑单价。先看总量再拆结构：是调用次数变多了，还是单次 token 变多了？这两种原因的修法完全不同，方向搞反了会白折腾。

交叉验证的工具还是那个：/tools/token-price-calculator。数字对不上时，先怀疑口径，再怀疑单价。实际用下来，十次里八九次是口径问题——要么缓存那两项没算，要么系统消息被重复计入。

什么情况下这套判断不适用

上面这套逻辑有个前提：按量计费。如果你已经签了包量或订阅套餐，边际成本和按量不是一回事，要换成套餐口径重算，硬套会得出错误结论。

还有一种：对延迟敏感的场景。便宜档在高峰期可能排队和限速，成本不是唯一变量，体验掉下来用户流失的代价更贵。一次性任务、小体量试用也别反复调，省下来的绝对金额有限，优先保证效果。说白了，避坑是帮你别踩大坑，不是逼你在每一分钱上抠。