跳到主要内容

Haiku 的便宜是“重新定义分工”，不是“把整场演出交给它”

· 阅读需 10 分钟
Isaac Zhao
AI编程俱乐部创建者

如果你最近才看到 Haiku 5.5，可能已经被两个数字晃了神：输入 $0.10/百万 token、输出 $0.50/百万 token（仅限 prompt ≤ 100,000 token 时；超过该阈值会切换为更高价档）。
再对比一下 Haiku 4.5——输入 $1、输出 $5——直觉上，把一切交给它，成本当然会“暴跌”。

但现实是：当你用 Coding Agent 真正干活时，最贵的往往不是某一段 Haiku 生成的代码，而是“主模型反复跑同一件事”的时间损耗。
Anthropic 2026 年 10 月 7 日的发布稿已经说得清楚：复杂 agentic coding 任务仍然更适合 Opus 5.5、Sonnet 5.5；Haiku 的定位是更窄的压缩、摘要、子 Agent 工作，以及高频、成本敏感的场景。
这不是我跑出来的跑分，这是官方给出的“使用边界”。
把这句话当成前提，你会发现：Haiku 5.5 真正带来的不是“更便宜的模型”，而是“重新分配任务的机会”。

为什么“看起来便宜”经常变成“更麻烦”​

我们先抛开价格表，看看一个典型的 Coding Agent 流程：

  1. 主模型理解需求，拆解任务
  2. 调用多个小任务：查接口、写片段、改配置、跑测试
  3. 合并结果、自我修正、再验证
  4. 人工验收或再返回人类决策

在这条链路上，有两类成本最容易被低估：

  • 模糊任务的返工成本
    你扔给 Haiku 一段“帮我优化这段逻辑”的指令，它可能生成合理但不够精准的改动。主模型接着发现不对，又要重新分析、重新设计——Haiku 省的钱被这轮额外的“理解—修正”循环吃掉。

  • 交付物不可检查的成本
    如果一个小任务没有清晰的输入约定与输出形状，主模型就必须在每次调用后重新“猜它做了什么”。这种隐性验证开销，在高频调用时会迅速放大。

所以，低价带来的价值不在“单次调用更便宜”，而在于：哪些子任务可以安全地标准化、可检验、批量跑？
只有满足这三点，Haiku 的便宜才会变成真正的杠杆。

用三个具体子任务来说明分工​

为了把抽象边界落地，我们拿一个真实可感的场景：
一个 Node.js + TypeScript 服务，最近要加一套新的权限校验中间件，并迁移一部分旧 API 到 v2 路径。
你手上已经有一个 Coding Agent（主模型），现在要在它周围配 Haiku 5.5。

1. 查清“精确的定义”：适合交给 Haiku​

任务描述：

“为以下接口表生成一份‘变更影响清单’，输出格式为 JSON。字段包括：旧路径、新路径、签名变化、是否破坏向后兼容。”

为什么适合 Haiku：

  • 输入高度结构化（你给出的路由列表），没有模糊的“感觉像”或“应该大概”。
  • 输出可被结构校验：主模型拿到 JSON，用脚本跑一遍正则/JSON schema，格式错误立刻暴露。但这只是形式正确，远不等于模型归纳的源码或业务事实正确。
  • 不需要跨文件、跨层级的创造性设计，更多是检索+比对+格式化。

价格直觉上的收益：
哪怕这个清单要生成上百次（每次不同服务、不同模块），Haiku 的低价在大批量调用上会迅速体现出来。关键是：你可以把“影响清单”做成一个可重复调用的标准子任务，而不是每次都让主模型重新理解一遍需求。

2. 总结“限定范围的 diff”：适合交给 Haiku​

任务描述：

“对给定的 Git diff（或 patch），输出：修改的文件列表、涉及的核心模块、是否触及类型定义、是否有疑似遗漏的副作用（如关闭了某个日志调用）。”

为什么适合 Haiku：

  • 输入是明确边界内的文本：就是那一块 diff。
  • 输出是“观察 + 归类”，不是“重新设计架构”。
  • 可核验性强：你应通过原始 diff、文件路径对照与源码级语义测试来验证它总结的模块是否匹配；覆盖率本身只能说明“接触过”，不能证明归类或摘要语义正确。

这里要注意一个细节：
Haiku 支持 effort 调节（它是首个可调 effort 的 Haiku 级模型）。在这种场景下，你可以：

  • 对常规 diff 用小 effort：快速扫描、覆盖核心字段；
  • 对关键文件路径、涉及 schema 变更的 diff，临时切换到更稳重一点的配置。
    同一框架内的弹性，比硬邦邦地“全部用 Opus”或“全部用 Haiku”更有实际价值。

3. 跨文件的架构判断：主模型（Opus/Sonnet）的事​

任务描述：

“基于影响清单与 diff 总结，给出一个迁移方案：哪些路由先改、中间件如何插桩、是否要临时兼容层，以及测试集如何分组。”

为什么不适合直接丢给 Haiku：

  • 需要把多个子任务的结论“串起来”，形成连贯的策略；
  • 要考虑前后依赖、异常路径、灰度发布策略等宏观问题；
  • 输出不是单一 JSON 或列表，而是带权衡的决策。

这就是 Anthropic 公告里强调的 Opus/Sonnet 的价值区间：
它们擅长在模糊空间里“设计”，而 Haiku 擅长在明确空间里“执行”。
让主模型负责架构判断，把细节扫描交给 Haiku，这本身就是“用低价重新分配任务”的正确姿势。

什么时候你可以放心地把子任务交出去？​

如果要用最直白的方式讲，只有一条验收标准：

你能否在调用之后，通过返回结果与输入源码/diff及可验证的预期对照，就判断它做对了没有？

如果可以，那它就是一个合格的 Haiku 子任务。
可以进一步拆成三条更落地的检查清单：

  • 输入可结构化
    不是“帮我看看这块代码”或“你觉得这里会不会有问题”，而是“针对以下路由/文件/配置，输出 X 字段”。

  • 输出有明确形状
    JSON、固定字段列表、带类型标记的 YAML……主模型可以用正则、schema 校验甚至自动化测试来验证格式；而内容是否正确，仍需对照输入提示（prompt）、源码变化与语义测试证据。

  • 失败可快速发现
    如果错了，能在几秒内通过对比或运行一个小脚本看出来；否则你迟早会把它当成“差不多就行”的结果收下去。

主模型的“新工作”：从“全能写手”变成“任务协调者”​

Haiku 5.5 让主模型从“什么都要自己干”的角色，转向“任务编排 + 验收”的角色：

  • 把模糊大需求拆解成若干可标准化子任务
  • 给每个子任务设定清晰的输入/输出约定
  • 对 Haiku 返回的结果做批量校验，而不是逐行人工审核
  • 只在真正出现歧义或架构冲突时，再切到更重的模型

这种转变的本质是：
你把“单次调用的便宜”换成了“整体流程的可控性与稳定性”。
这正是 Anthropic 在发布页里暗示的方向：Haiku 更适合做子 Agent、压缩与摘要等“高频、可裁剪”的工作，而不是替代主模型去解决模糊的复杂问题。

实操：现在你可以立刻试的一项具体子任务​

别等“完美场景”，从一个小点开始：

  • 场景：接下来一周你要维护一个服务，需要频繁查看多个 PR 的变更。
  • Haiku 子任务：
    “对每一个给定的 Git diff，输出：涉及文件列表、核心模块（如 auth/routing/config）、是否触及类型定义、是否可能影响测试覆盖率。”
  • 验收方式：
    写一个简单脚本，读取 Haiku 输出的 JSON，核对是否包含所有出现过的文件名，并用你的静态分析工具跑一遍关键变更，验证“是否触及类型定义”这条结论。

如果一周下来，这个子任务在准确率、延迟与成本上都是正的，你就已经跑通了一个微型的“主模型 + 小模型分工”闭环。
等到这种模式成熟，再把它从“临时脚本”变成你项目里固定的 CI/CD 或开发流程的一部分。

最后的提醒：别把“单价比例”当成整项任务的省钱比例​

价格表上的数字很诱人：输入从 $1 到 $0.10、输出从 $5 到 $0.50。
但真实世界里有三个干扰项，且模型不同、档位不同：

  • 分词器与 token 计量在不同版本间并不完全一致；
  • 两档定价（prompt ≤ 100,000 / > 100,000）会显著改变单价感知；
  • 缓存读取价仅在特定调用模式生效：

(USD per ONE MILLION tokens)

型号提示词长度输入输出缓存读取
Haiku 5.5≤100,0000.100.500.01
Haiku 5.5>100,0000.502.500.05
Haiku 4.5—1.005.000.10
Sonnet 5.5———0.10
Opus 5.5———0.20

所以，别简单用“单价比例”来算“整项任务能省多少”。
更可靠的方式是：固定一个真实子任务（比如上面的 diff 总结或影响清单生成），在 Haiku、Sonnet、Opus 上各跑一次，记录 token 用量与耗时，再结合你的调用频率做对比。
你会发现：真正能省钱的，往往是“把原本由主模型完成的重复性子任务标准化之后”，而不是单纯地“把全部工作改用小模型”。

回到 Anthropic 的定位：Haiku 5.5 不是把编码流程中最难的部分变简单，而是让那些高频、可检验的小任务变得足够便宜与稳定。
你的角色，不是继续一个人扛所有活，而是学会：哪些事可以精确描述并验收？哪些事仍需要重量级模型的模糊推理？
当你开始这样分，Haiku 的低价才会真正变成生产力，而不是账单上的一串数字。

参考资料：