企业官网建设流程全解析

1. 这次调价到底动了谁的蛋糕

Haiku 5.5 这轮降价幅度直接拉到 90%，这个数字放在任何一家大模型厂商的定价史上都算得上地震级。我第一时间看到这个消息时的反应不是兴奋，而是赶紧翻出上个月刚做完的那份模型选型方案——因为里面有一大半的结论，现在全部作废了。

先把这个模型在整条产品线里的位置说清楚。Claude 系列目前大致分三档：Opus 是旗舰，能力最强但单价最高，适合复杂推理、长链路 Agent、高难度代码生成这类任务；Sonnet 是中间档，综合性价比一直是主力；Haiku 是最轻量的一档，主打低延迟、高并发、低成本，过去大家用它主要是做分类、抽取、意图识别、简单问答这类"脏活累活"。问题在于，Haiku 以前虽然便宜，但便宜得不够彻底——当你的日调用量上到千万级 Token 的时候，哪怕单价只差一点点，月度账单的差距也是肉眼可见的。

这次降价 90% 之后，Haiku 5.5 的定位发生了本质变化。它不再只是"能省则省"的备选项，而是变成了很多场景下的默认首选。我重新算了一遍账，发现过去那些"因为成本太高所以不敢用大模型做"的需求，现在突然都变得可行了。比如全量日志的语义打标、用户评论的逐条情感细分、电商商品标题的批量结构化，这些任务以前要么用规则硬扛，要么抽样处理，现在可以放开手脚全量跑。

但这里有个坑必须先说：降价不等于无脑迁移。Haiku 5.5 再便宜，它的能力边界依然存在。我见过太多团队一看到降价就把所有任务往最便宜的模型上堆，结果准确率掉了一大截，最后返工的成本比省下来的钱还多。所以这篇文章的核心不是告诉你"赶紧换 Haiku"，而是把模型选型这件事重新拆一遍——什么任务该留在 Sonnet，什么任务可以放心下沉到 Haiku，什么任务反而应该往上走用 Opus，以及每一步背后的 Token 成本到底怎么核算。

如果你正在维护一个已经上线的 LLM 应用，或者正在做新产品的技术选型，这篇内容应该能帮你省下不少试错时间。我会把核算表格、迁移判断标准、以及实际压测中踩到的坑都摊开讲。

2. 把三档模型的单价换算成"每千次任务成本"

2.1 为什么不能只看每百万 Token 单价

大部分人看模型定价，第一反应是看"每百万输入 Token 多少钱、每百万输出 Token 多少钱"。这个数字当然重要，但它有个致命问题：不同模型完成同一个任务，消耗的 Token 数量是不一样的。一个能力弱的模型可能需要更长的提示词、更多的示例、更啰嗦的思维链才能达到同样的效果，甚至根本达不到，需要重试。所以真正该比较的指标是"每千次任务成本"，也就是完成一千次同样的业务请求，总共花多少钱。

我拿三个典型任务做了实测对比，分别是：短文本分类（判断一条用户反馈属于哪个品类）、结构化抽取（从一段商品描述里抽出品牌、规格、材质）、以及多轮意图识别（客服场景下判断用户当前想干什么）。这三个任务都是 Haiku 的传统强项，但实测下来差异依然明显。

2.2 实测数据与成本对照表

下面这张表是我用同一批测试集（每个任务 2000 条样本）跑出来的结果，价格按调价后的公开单价折算，Token 消耗取平均值：

注意最后一列的"相对值"，我把 Haiku 5.5 的成本归一化为 1.0，这样对比更直观。可以看到，在短文本分类和结构化抽取这两个任务上，Haiku 5.5 的准确率只比 Sonnet 低 2 到 4 个百分点，但成本只有后者的十二分之一左右。这个差距在调价前大概是三到四倍，现在直接拉开了一个数量级。

但多轮意图识别这个任务就不一样了。Haiku 5.5 的准确率掉到了 88.7%，比 Sonnet 低了将近 6 个百分点。在客服场景里，6 个百分点的意图误判意味着大量用户被路由到错误的处理流程，后续的人工兜底成本远超省下来的模型费用。所以这个任务我最终没有迁移。

2.3 成本核算里最容易被忽略的三个变量

第一个变量是重试率。Haiku 5.5 在结构化抽取任务上有大约 3% 的输出格式不合规，需要重新请求。这 3% 的重试会额外增加约 6% 的 Token 消耗（因为重试时通常要带上原始上下文）。核算成本时如果不把重试算进去，实际账单会比预期高出一截。

第二个变量是提示词长度差异。为了让 Haiku 5.5 达到接近 Sonnet 的抽取效果，我在提示词里多加了两个 few-shot 示例，输入 Token 从 480 涨到了 540。虽然单价降了 90%，但 Token 量涨了 12.5%，这部分抵消掉了一小部分降本效果。

第三个变量是缓存命中率。如果你的系统提示词是固定的，很多厂商会对重复的输入前缀做缓存计费，缓存命中的部分单价更低。Haiku 5.5 的缓存单价同样降了，但降幅和标准单价不完全一样，需要单独确认。我实测下来，在系统提示词占输入 60% 的场景下，缓存能把实际输入成本再压下去三成左右。

提示：做成本核算时，一定要用真实流量的采样数据，而不是拍脑袋估的 Token 数。我建议至少采样一周的真实请求，统计 P50 和 P95 的 Token 分布，因为长尾请求往往才是账单的大头。

3. 哪些任务可以放心下沉，哪些必须留在原地

3.1 可以下沉到 Haiku 5.5 的任务特征

经过这轮重新评估，我总结出四个可以放心迁移的信号。第一，任务有明确的输出格式约束，比如分类标签固定、抽取字段固定，模型不需要自由发挥。第二，错误可以被下游环节兜住，比如分类错了还有人工复核，抽取漏了还有规则补。第三，单次请求的上下文不长，通常在 1000 Token 以内，Haiku 在长上下文下的注意力衰减比 Sonnet 明显。第四，对延迟敏感但对准确率容忍度较高，比如实时打标、预筛选这类场景。

符合这四条的任务，我基本都迁到了 Haiku 5.5。迁移之后最直观的感受是，以前因为成本压力做的各种"抽样处理""批量合并请求"的优化，现在可以适当放松了。比如日志打标，以前是每 100 条抽 10 条跑模型，现在可以全量跑，数据完整度上了一个台阶。

3.2 必须留在 Sonnet 或更高档位的场景

有三类任务我坚决没有迁移。第一类是多步推理链，比如需要先理解用户问题、再检索知识、再综合判断的问答场景。Haiku 5.5 在单步任务上表现不错，但一旦涉及多步串联，错误会累积放大。第二类是长文档理解，超过 4000 Token 的输入，Haiku 5.5 的信息召回率下降比较明显，实测在 8000 Token 的合同文本里找特定条款，召回率比 Sonnet 低了十几个百分点。第三类是对格式极度敏感的输出，比如直接生成可执行的代码或结构化配置文件，Haiku 5.5 的格式错误率还是偏高，重试成本划不来。

这里有个判断技巧：你可以先在小流量上把任务迁到 Haiku 5.5，跑一周，重点看两个指标——下游报错率和人工干预率。如果这两个指标没有明显上升，就可以放心扩大流量；如果上升了，就说明这个任务对模型能力有隐性依赖，老老实实留在 Sonnet。

3.3 一个反直觉的发现：有些任务反而该往上走

调价之后我重新审视了整个任务矩阵，发现有一类任务以前因为"Sonnet 太贵、Haiku 不够用"被硬塞在中间档，现在反而应该直接上 Opus。这类任务的特点是：调用量不大，但单次错误代价极高。比如合同关键条款的风险提示、财务数据的异常检测。以前为了省钱用 Sonnet 凑合，现在 Haiku 便宜了，可以把省下来的预算挪给这些高价值任务，用 Opus 把准确率再往上顶一顶。整体账单可能没变，但关键环节的质量提升了。

4. 迁移实操：从灰度到全量的完整链路

4.1 灰度方案的设计要点

迁移最忌讳一刀切。我的做法是先在请求入口加一个分流开关，按用户 ID 或请求 ID 的哈希值把流量分成三组：对照组继续走原模型，实验组走 Haiku 5.5，还有一个观察组走 Haiku 5.5 但开启详细日志。分流比例从 5% 起步，观察 48 小时，没有异常再逐步放大到 20%、50%、100%。

分流开关的实现很简单，在调用模型之前加一层路由逻辑就行。关键是要保证同一个用户的请求始终落在同一组，否则用户体验会不一致。我用的是用户 ID 取模的方式，稳定且实现成本低。

4.2 效果对比该看哪些指标

不要只看准确率。准确率是离线指标，线上真正重要的是这几个：端到端延迟的 P95、下游服务的错误率、用户主动重试率、人工客服的介入率。我实测发现，Haiku 5.5 的 P50 延迟比 Sonnet 低了约 40%，但 P95 延迟差距没那么大，因为长尾请求的排队时间受并发影响更大。所以如果你的系统对 P95 敏感，迁移后要重新压测并发上限。

4.3 回滚预案必须提前准备好

灰度期间一定要保留一键回滚的能力。我的做法是把模型选择做成配置项，存在配置中心里，改配置秒级生效，不需要重新发版。同时监控系统里设好告警阈值，比如下游错误率超过基线 1.5 倍就自动触发告警，人工确认后回滚。这套机制在迁移过程中救过我一次——某个批处理任务迁移后错误率突然飙升，后来发现是那个任务的提示词里有个特殊字符，Haiku 5.5 的解析行为和 Sonnet 不一致，回滚后改了提示词才重新上线。

注意：迁移前一定要把提示词里的边界情况测一遍，特别是空输入、超长输入、特殊字符、多语言混排这几种。不同模型对这些边界的处理差异，往往比正常样本的差异大得多。

5. 压测中暴露的四个真实问题

5.1 并发限流策略需要重新调

Haiku 5.5 单价降了，很多团队的第一反应是把并发调高，把以前因为成本压着的量放出来。但这里有个陷阱：单价降了不代表配额限制也放宽了。我实测发现，同一账号下的 RPM（每分钟请求数）和 TPM（每分钟 Token 数）限制并没有随降价同步调整。如果你按成本下降的比例去放大并发，很容易撞到限流，导致大量请求被拒。

我的做法是先做一次限流压测，摸清楚当前账号的实际配额上限，然后按配额的 80% 设定并发上限，留出缓冲。同时把请求队列做成带优先级的，重要任务优先消费配额，非关键任务排队等待。

5.2 输出格式的稳定性差异

前面提到过，Haiku 5.5 在结构化输出上的格式错误率比 Sonnet 高。压测时我具体统计了一下，在要求输出 JSON 的任务里，Haiku 5.5 的首次格式合规率大约是 96%，Sonnet 是 99.2%。这 3 个多百分点的差距，在日调用量百万级的时候就是每天几万次重试。

解决办法有两个：一是用厂商提供的结构化输出功能（如果支持的话），让模型在解码层面就约束格式；二是在提示词里把格式要求写得更死，给出完整的示例，并且明确说"只输出 JSON，不要任何解释文字"。我两个都用了，格式合规率提到了 98.5% 左右，剩下的 1.5% 用重试兜底。

5.3 长上下文下的表现衰减

这个坑比较隐蔽。Haiku 5.5 在短上下文下表现很好，但当输入超过 3000 Token 之后，它对中间位置信息的召回率下降明显。我做了个测试，把关键信息分别放在输入的开头、中间、结尾，Haiku 5.5 在中间位置的召回率比开头低了将近 20 个百分点，而 Sonnet 的衰减只有 8 个百分点左右。

应对方法是在提示词结构上做优化，把最关键的信息放在开头或结尾，中间放次要内容。如果任务本身要求处理长文档，那就别硬用 Haiku，该上 Sonnet 就上 Sonnet。

5.4 成本监控的粒度要细化到任务级

降价之后，账单结构变了，以前粗粒度的成本监控不够用了。我把成本统计细化到了每个任务类型、每个模型档位，每天出一份成本日报。这样能及时发现异常——比如某个任务的成本突然涨了，可能是提示词被改长了，或者重试率上升了。没有这个粒度，你只能看到总账单，根本定位不到问题出在哪。

6. 重新算一遍账：我的最终选型结论

6.1 三类任务的最终归属

经过这轮完整的评估和压测，我把手上的任务重新分了三类。第一类全量下沉 Haiku 5.5：短文本分类、简单抽取、日志打标、实时预筛选，这些任务占了总调用量的七成左右，迁移后这部分成本降到了原来的十分之一出头。第二类保留 Sonnet：多轮意图识别、长文档理解、多步推理问答，这些任务对能力有硬要求，省不得。第三类升级到 Opus：合同风险提示、财务异常检测这类高价值低频率任务，用 Haiku 省下来的预算补贴到这里，整体质量反而提升了。

6.2 整体账单的变化

把这三类任务按调用量加权算下来，我的整体模型成本下降了大约 62%。注意不是 90%，因为还有三成任务留在 Sonnet 和 Opus，而且 Haiku 那边因为放开了全量处理，总 Token 量其实涨了不少。但即便 Token 量涨了，总成本还是大幅下降，这就是单价降 90% 的威力。

6.3 给不同规模团队的建议

如果你是小团队，日调用量在百万 Token 以内，这次降价对你的账单影响其实有限，重点应该放在"把以前不敢做的功能做起来"，而不是抠成本。如果你是中型团队，日调用量在千万级，那这次降价值得你花一周时间重新做一遍选型，迁移带来的降本效果会非常明显。如果你是大团队，日调用量上亿，那除了迁移，还要重新审视你的配额策略、缓存策略和成本监控体系，因为规模越大，这些基础设施层面的优化空间越大。

我个人在实际操作中的体会是，模型降价这件事，表面上是省钱，实际上是给了你一次重新思考产品边界的机会。以前因为成本被砍掉的功能、被抽样处理的数据、被降级的需求，现在都可以重新捡起来。省下来的钱是次要的，把产品做得更完整才是主要的。最后分享一个小技巧：每次模型调价后，别急着改代码，先花半天时间把成本核算表更新一遍，把新单价代进去重新算，很多时候你会发现，最优解和你第一直觉想的完全不一样。