第 32 章 多模型与成本策略
第 12 章讲了"控本靠精确上下文 + 选对模型与档位",那是战术层;本章是战略层——当你的使用规模从个人编码扩展到团队 CI、从单模型扩展到多模型(含第三方)、从订阅扩展到 API 时,如何做选型决策。核心一句话:按场景选模型、按复杂度选档位、按规模选定费方式。
32.1 结论:三条决策轴
多模型与成本策略不是"哪个模型最便宜"的单点优化,而是三条轴的正交决策:
| 决策轴 | 选项 | 决策依据 |
|---|---|---|
| 模型 | sonnet / opus / haiku / fable / 第三方 | 任务场景:日常、复杂、轻量、长程、成本敏感 |
| 档位 | low → ultracode | 任务复杂度:越复杂越高档 |
| 定费 | Max 订阅 / API 按量 | 使用规模:重度交互 vs 规模化/CI |
三条轴的组合不是自由的——第三方模型往往不支持完整档位语义、Fast Mode 只覆盖 Opus 4.8/4.7、订阅额度不能给 CI 用。本章逐轴展开,最后给出组合拳与失败边界。
一条贯穿全章的判断标准:把贵的资源留给真正需要它的任务。Opus + ultracode + 订阅额度留给架构决策与疑难 Bug;Haiku + low + API 留给批量格式化;Fast Mode 留给迭代快的原型探索。错配是最大的浪费,不是单点单价。
32.2 模型选型:四档原生模型
/model:切换模型
/model进入选择器,或直接指定别名:
/model opus
/model sonnet
/model haiku
/model fable2026-07-08 核对(v2.1.202+)的原生模型基线:
| 别名 | 模型 | 定位 | 适用场景 | 成本量级 |
|---|---|---|---|---|
opus | Opus 4.8 | 旗舰推理 | 架构决策、跨文件重构、疑难 Bug | 高 |
fable | Fable 5 | 长程推理 | 长上下文研究、多步骤规划、代码考古 | 中高 |
sonnet | Sonnet 5 | 均衡主力 | 日常编码、Bug 修复、代码审查 | 中 |
haiku | Haiku 4.5 | 轻量快速 | 格式化、重命名、批量小任务 | 低 |
选型原则是"能力下限匹配":选能完成任务的能力下限模型,而不是无脑用最强。Sonnet 是 90% 日常任务的默认;只有当 Sonnet 在具体任务上明显力不从心(跨文件一致性丢失、推理链断裂)时才升 Opus。
选型决策树
任务进入
├─ 格式化/重命名/简单替换 → Haiku 4.5
├─ 日常 Bug 修复/功能实现/代码审查 → Sonnet 5
├─ 长上下文研究/多步骤规划 → Fable 5
└─ 架构决策/跨模块重构/疑难 Bug → Opus 4.8验证
/model或 /status,确认当前模型已切换。跑一个已知任务对比 /cost 输出与完成质量——同一任务用 Haiku 应比 Sonnet 省 60-80% token,用 Opus 应比 Sonnet 贵 3-5 倍。
失败边界
- 默认全程 Opus 是最贵的错误。Opus 单价高,日常任务用 Opus 既浪费配额(订阅)又浪费钱(API),且速度更慢。
- Haiku 不擅长多步推理。让它"重命名这三个函数"可以,让它"分析这个并发 Bug"会翻车——它会给出看似合理但经不起验证的结论。
- Fable 不是 Opus 的廉价替代。Fable 的强项是长程规划与长上下文,不是单点推理深度;复杂逻辑题 Fable 不一定比 Sonnet 强。
- 模型切换不跨会话记忆。切模型后,之前会话的上下文仍在,但新模型对新约束的遵循度可能不同,关键约束要写进 CLAUDE.md 而非依赖对话。
32.3 推理档位:/effort 六档
/effort:切换推理深度
/effort或直接指定:
/effort low
/effort medium
/effort high
/effort xhigh
/effort max
/effort ultracode档位语义(2026-07-08 核对):
| 档位 | 适用 | token 量级 | 注意 |
|---|---|---|---|
low | 简单替换、格式化 | 1x | 复杂逻辑会出错 |
medium | 日常编码默认档 | 1.5-2x | 大多数任务用这个 |
high | 跨文件改动、Bug 排查 | 3-4x | 略贵 |
xhigh | 架构设计、Plan Mode | 5-7x | 仅复杂任务 |
max | 疑难 Bug、极限推理 | 8-12x | 很贵 |
ultracode | 极限推理(research preview) | 最高 | 最贵,留给硬骨头 |
档位与模型是正交的:Opus + low 比 Opus + max 便宜一个数量级,Sonnet + max 比 Sonnet + medium 贵 5-7 倍。两轴组合才有完整的成本图景。
档位与模型的搭配矩阵
| 任务类型 | 模型 | 档位 | 备注 |
|---|---|---|---|
| 格式化、重命名 | Haiku 4.5 | low | 最便宜组合 |
| 日常 Bug 修复 | Sonnet 5 | medium | 默认 |
| 代码审查(主审) | Sonnet 5 | high | 平衡深度与成本 |
| 架构设计、Plan Mode | Opus 4.8 | xhigh | 关键决策 |
| 疑难 Bug、跨模块重构 | Opus 4.8 | max | 硬骨头 |
| 极限推理(无替代) | Opus 4.8 | ultracode | research preview |
验证
/effort
/status确认档位已生效。跑同一任务对比 /cost:Sonnet medium vs Sonnet high 的 token 差应约 2 倍;Opus max vs Opus low 应差 8-12 倍。若差距明显小于预期,可能档位未真正切换或任务过简单未触发深度推理。
失败边界
- 默认常驻 ultracode 是最快的烧钱方式。ultracode 是 research preview(2026-07-08 核对),行为可能随版本调整,不要写进不可变的生产流水线。
- 档位越高不是越准。简单任务用高档,模型可能在简单问题上"想太多"反而引入过度设计。
low/medium对日常任务的成功率通常与high持平,但成本低数倍。 - 档位对第三方模型语义可能不完整。第三方模型可能只部分支持 effort 语义,实际推理深度由对方后端决定,
/effort的切换不一定生效——见 32.6。 - 完成任务后忘降档。临时升到 max 处理硬骨头后,下一轮日常任务仍在 max,持续烧钱。养成"升档→完成→降档"的肌肉记忆。
32.4 Fast Mode:同模型 2.5x 速度、1/3 成本
/fast:切换 Fast Mode
/fastFast Mode 基于 Opus 4.8/4.7,在同一模型下提供约 2.5 倍速度、约 1/3 成本。定价 $10 / $50 per M tokens(输入/输出,2026-07-08 核对)。
适用场景
Fast Mode 的本质是用"轻微质量让渡"换"速度+成本"。适合:
- 迭代快的原型探索——多轮试错,每轮都要等结果,速度比单轮质量重要
- 批量小改——重命名、格式化、简单重构,容错高
- 跑验证——
/code-review的快速初筛,深度审查再走完整 Opus - 成本敏感的 API 场景——同模型 1/3 成本,长期能省可观费用
不适用场景
- 最终交付——关键代码、安全审查仍用完整 Opus,Fast 的质量让渡在交付物上不可接受
- 架构决策——需要最深推理,用 Opus + xhigh/max
- 疑难 Bug——细节决定成败,Fast 的速度优势在此无用武之地
- 订阅额度场景——Fast Mode 消耗 API 侧额度,订阅用户用 Fast 可能额外计费,以
/status显示为准
验证
/fast
/status确认 Fast Mode 已启用。跑一个原型任务对比:完整 Opus 与 Fast Opus 的耗时比应约 2.5:1,API 成本比应约 3:1。质量上,对简单任务两者结果应接近;对复杂任务 Fast 可能漏掉细节或给出更表面的方案。
失败边界
- Fast 不是"免费提速"。它在某些复杂推理上质量略降,关键代码、安全审查、最终交付不要用 Fast。
- Fast 不等于低档位。Fast 是模型层面的加速,
/effort是推理深度,两者正交。Fast Opus + max 仍是高档推理,只是更快更省;Fast Opus + low 是最便宜的 Opus 组合。 - Fast 的计费归属需核对。Fast Mode 消耗 API 侧额度,与订阅额度的关系以官方当前说明为准——不要假设订阅用户用 Fast 免费。
- Fast 不覆盖所有模型。仅 Opus 4.8/4.7,其他模型无 Fast 模式。
/fast在非 Opus 模型上可能无效或自动切到 Opus。
32.5 第三方模型接入:GLM / DeepSeek / Kimi via API provider
Claude Code 的工具链不限于 Anthropic 原生模型。通过 API provider 配置,可以接入兼容 Anthropic API 协议的第三方模型——典型的有智谱 GLM(z.ai 的 GLM Coding Plan)、DeepSeek、Kimi、MiniMax 等。
接入方式:环境变量重定向
Claude Code 通过两个环境变量重定向到兼容端点:
export ANTHROPIC_BASE_URL="https://open.z.ai/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="<你的 z.ai API Key>"或写入 shell 配置(~/.zshrc)持久化。重启 claude 后,所有请求走第三方端点,/model 选择器中可能显示该 provider 暴露的模型列表(具体以 provider 实现为准)。
部分 provider(如 z.ai GLM Coding Plan)提供包月套餐,适合成本敏感场景;另一些按 token 计费,适合区域合规(数据不出境)或特定模型能力需求。
配置验证
claude进入会话后:
/status预期输出(示例,非真实转录):
Provider: z.ai (GLM Coding Plan)
Model: glm-5.2
Base URL: https://open.z.ai/api/anthropic验证:Provider 与 Base URL 显示为第三方端点,模型为该 provider 暴露的模型。跑一个简单任务(读文件、写文件)确认工具链路完整。
适用场景
- 成本敏感——国产模型单价显著低于 Opus,批量任务能省可观费用
- 区域合规——部分场景要求数据不出境或走国内合规链路
- 特定能力——某些中文场景下国产模型的中文表达更自然
- 包月套餐——z.ai GLM Coding Plan 等套餐适合重度使用且预算可控
失败边界
- 不要混用环境变量与 API Key。同时设了
ANTHROPIC_API_KEY(原生)和ANTHROPIC_BASE_URL(第三方)会冲突,请求可能走错端点导致 401。同一时间只用一套认证。 - 第三方端点的工具协议可能不完整。Claude Code 的工具调用、流式输出、prompt caching 都依赖 Anthropic API 的特定行为,第三方实现可能有差异——表现为工具调用格式错、流式断流、缓存不命中。接入后必须跑 32.2 的验证三步。
/model列表由 provider 决定。第三方 provider 暴露哪些模型、是否支持别名切换,取决于 provider 实现,不要假设与原生一致。- Key 泄露风险。第三方 Key 同样不能进仓库或日志,写入
~/.zshrc后确保该文件不提交。详见 32.9 边界四。
32.6 第三方模型的能力边界:Skills 触发率与 Agent 稳定性
第三方模型"能用"不等于"等价于原生"。最关键的差异在高级特性。
Skills 触发率差异
Claude Code 的 Skills 系统(第 16 章)依赖模型对 skill 描述的理解与触发判断。原生 Claude 模型经过对齐训练,Skills 触发率约 98%(经验值,非官方承诺);第三方模型明显较低——它们没有经过相同的 skill 触发对齐,可能漏触发或误触发。
| 特性 | 原生 Claude | 第三方模型 |
|---|---|---|
| Skills 触发率 | ~98%(经验值) | 明显较低,因模型而异 |
| Agent 子代理 | 稳定 | 可能不稳,工具协议差异 |
| Plan Mode | 完整支持 | 部分支持,行为可能偏差 |
| 命令真实性 | 遵循 system prompt 约束 | 可能不严格遵守,存在编造命令风险 |
| prompt caching | 命中率高 | 取决于 provider 实现,可能不命中 |
实际影响
- Skills 不触发——
/code-review、/security-review、/deep-research等 bundled skills 在第三方模型上可能不自动激活,需要显式调用或自然语言触发,且行为可能不稳定。 - Agent 特性不稳——子代理(第 19 章)、Workflows(第 21 章)依赖工具调用协议的精确性,第三方模型的工具调用格式差异可能导致子代理无法正常启动或中途失败。
- 命令真实性受影响——原生 Claude 的 system prompt 包含严格的命令真实性约束(不把自定义伪装成内置);第三方模型可能不严格遵守,存在把自定义命令说成内置、或编造不存在的命令的风险。这与第 06 章的命令真实性纪律直接冲突。
应对策略
- 第三方模型用于简单编码任务,不用于依赖 Skills/Agent 的高级工作流。
- 关键任务回到原生模型。架构决策、安全审查、复杂重构仍用 Opus/Sonnet,确保 Skills 与 Agent 稳定。
- 显式调用 Skills。在第三方模型上,不要依赖自动触发,显式写
/code-review或在 prompt 中明确"调用 code-review skill"。 - 验证命令真实性。第三方模型给出的命令,对照第 06 章命令真实性总表与附录 A 核实,不接受凭模型记忆的命令陈述。
验证
在第三方模型会话中:
/code-review --effort high若 skill 未触发(模型直接用自然语言回答而非走 skill 流程),说明该模型对 skill 触发支持不佳。对比原生模型上同一命令的行为差异。
失败边界
- 不要把第三方模型当作 Opus 的廉价全替代。它在 Skills/Agent 上的不稳定性意味着高级工作流可能静默失败——任务"完成了"但实际没走应有的流程。
- 第三方模型的质量波动更大。原生模型的版本更新经过完整对齐;第三方模型的版本更新可能引入行为回归,生产流水线用第三方模型时要锁版本。
- 中文优势不等于推理优势。国产模型中文表达自然,但复杂推理(并发、架构、跨文件一致性)未必强于 Sonnet,不要因中文顺滑就高估其推理能力。
32.7 API vs 订阅:盈亏平衡点
第 12 章预告了本章会给出订阅 vs API 的盈亏平衡分析。核心结论:重度交互用 Max 订阅,规模化/CI 用 API 按量,但"重度"与"规模化"的量化门槛需要算。
成本模型对比
| 维度 | Max 订阅($100/$200 月) | API(按 token) |
|---|---|---|
| 成本可预测性 | 固定月费,上限已知 | 按量,高吞吐下可能更贵 |
| 适合工作模式 | 交互式、探索性、多轮迭代 | 脚本、CI、批处理、结构化输出 |
| 额度限制 | 5h 滚动窗口 + 周上限 | 无(只要余额足够) |
| 控费粒度 | 粗(撞上限就降速) | 细(--max-budget-usd、--max-turns) |
| 模型/功能 | 全部,含订阅专属特性 | 全部,按 token 计费 |
| Fast Mode | 消耗 API 侧额度,关系以官方说明为准 | 直接按 Fast 单价计费 |
盈亏平衡点估算
订阅的盈亏平衡点取决于"你每月实际消耗的 token 量"与"订阅固定月费"的比值。以 Max 5x($100/月)为例:
- 假设 Max 5x 每月可用的有效 token 量(扣除 5h 窗口与周上限限制)约等价于 API 侧 $150-200 的 Opus 用量,则订阅划算。
- 若你的实际消耗低于 $100/月的 API 等价成本,API 更划算(且无额度限制)。
- 若你的实际消耗高于 $200/月的 API 等价成本但被订阅上限卡住,需要升 Max 20x 或补 API。
实操判断:连续两周触顶订阅上限 → 升档或补 API;连续一个月没触顶且消耗稳定 → 降档省固定成本。
决策矩阵
| 使用模式 | 推荐 | 理由 |
|---|---|---|
| 个人日常编码(每天 2-4 小时交互) | Pro $20 | 轻度,固定成本低 |
| 重度 Agent 编码(每天 6+ 小时) | Max 5x $100 | 交互为主,撞上限可接受 |
| 全天候 Agent 驱动 | Max 20x $200 | 上限最高,仍以交互为主 |
| CI/CD 流水线(每 PR 跑审查) | API | 按量计费,可设预算上限 |
| 批处理(夜间批量重构) | API | 避免撞订阅 5h 窗口 |
| 突发高峰(临时大任务) | API 补订阅 | 订阅撞上限时切 API Key |
| 团队协作 | Team premium seat | 统一计费,组织管理 |
| 企业合规 | Enterprise | SSO、审计、数据驻留 |
组合策略:订阅 + API 双轨
最常见的成熟组合是订阅用于交互、API 用于自动化:
- 日常在 IDE 里交互式编码 → Max 订阅(额度与 claude.ai 聊天共享,注意别在网页聊天里高强度对话挤占 CC 额度)
- CI 里每 PR 跑
/code-review→ API Key,设--max-budget-usd 1.00--max-turns 5 - 夜间批量重构 → API Key,worktree 隔离 + 子代理并行
- 订阅撞上限时的应急 → 临时切 API Key 继续
切换方式:
# 默认订阅
claude
# 临时用 API
ANTHROPIC_API_KEY="sk-ant-..." claude -p "审查 diff" --max-budget-usd 1.00验证
- 订阅用户用
/status看当前 5h 窗口与周用量,判断是否接近上限。 - API 用户用
/cost看真金白银消耗,与计费面板对账。 - 双轨用户定期对账:订阅月费 + API 月消耗的总成本,与"全 API"或"全订阅"的假设成本对比,验证组合是否仍最优。
失败边界
- 订阅额度与 claude.ai 聊天共享。在网页聊天里高强度对话会挤占 CC 可用额度,反之亦然。这是常见误区,不要假设 CC 有独立配额。
- Team $25/座默认不含 CC。需要升级 premium seat 才解锁,只买基础座位会发现 CLI 无法用订阅登录。
- API 与订阅额度不互通。同一账号同时有 Max 订阅和 API Key,两者计费分开,不能互相补充。
- API 没有上限不等于可以无限花。CI 里不设
--max-budget-usd的 Agent 循环探索可能在一夜烧掉数百美元。硬上限是必须的。
32.8 成本优化组合拳
单点优化天花板低,组合优化才能把成本压到合理区间。四个抓手叠加:
抓手一:精确上下文(第 12 章)
精确投喂(@文件 而非 @.)+ 排除清单写进 CLAUDE.md + 两阶段探索。这是控本的基础,直接减少输入 token 30-60%。没有这一步,后面的模型/档位优化都在漏水的池子上做。
抓手二:合适档位
任务进入时按 32.3 的决策树选模型与档位,完成后降回默认。关键纪律:升档是临时的,默认是 Sonnet medium。不要让 max/ultracode 常驻。
抓手三:子代理隔离(第 19 章)
大规模重构用子代理并行,每个子代理有独立上下文、独立模型/档位选择。主上下文只收结论,不收探索过程。这比单代理长会话省 token——长会话有累积噪音成本,短会话没有。
用 3 个子代理并行:
- Agent A:重构 src/auth/(Sonnet medium,独立 worktree)
- Agent B:重构 src/api/(Sonnet medium,独立 worktree)
- Agent C:更新测试(Haiku low,独立 worktree)
各自完成后回主上下文合并。注意:子代理的模型/档位可以不同——测试更新用 Haiku,核心重构用 Sonnet,架构决策回主上下文用 Opus。这是组合优化的精髓。
抓手四:Fast Mode
迭代快的原型探索用 Fast Opus,同模型 1/3 成本。与抓手二正交:Fast Opus + medium 是原型探索的便宜组合,Fast Opus + low 是最便宜的 Opus 组合。
组合示例
| 任务 | 上下文 | 模型 | 档位 | Fast | 子代理 |
|---|---|---|---|---|---|
| 原型探索 | 精确投喂 | Opus 4.8 | medium | 是 | 否 |
| 日常 Bug 修复 | 精确投喂 | Sonnet 5 | medium | 否 | 否 |
| 批量重命名 | 排除清单 | Haiku 4.5 | low | 否 | 可并行 |
| 架构设计 | Plan Mode | Opus 4.8 | xhigh | 否 | 否 |
| 大规模重构 | 精确投喂 | Sonnet/Opus 混合 | 按子任务 | 按需 | 是 |
| CI 代码审查 | diff only | Sonnet 5 | high | 否 | 否 |
验证
- 每周用
/cost(API)或/status(订阅)复盘消耗趋势。若某类任务消耗异常高,检查是否模型/档位错配。 - 对比"优化前"与"优化后"的同类任务 token 量。合理的组合优化应降 40-70%;若降幅小于 20%,说明上下文管理仍有漏水点。
失败边界
- 组合优化不是越省越好。省到牺牲验证质量(跳过测试、跳过 code review)是反模式——第 12 章边界一已警告,返工成本是验证成本的 10 倍。
- 子代理并行有协调成本。3 个独立任务适合,1 个耦合任务硬拆成 3 份会更慢更错。判断标准:任务之间能否独立验证。
- Fast Mode 在组合中要谨慎。原型探索用 Fast 合理,但子代理里用 Fast 可能放大质量波动——子代理本身上下文短,Fast 的质量让渡更明显。
32.9 失败边界汇总
本章的策略,反向看就是失败边界。五条最致命的:
边界一:第三方模型上 Skills 不触发
最隐蔽的失败。任务"完成了"但 /code-review、/security-review 等 skill 根本没激活,模型用自然语言糊弄了一个"审查结果"。你以为走了流程,实际没走。
正确做法:第三方模型用于简单编码,关键任务回到原生模型;在第三方模型上显式调用 skill 并验证 skill 确实触发(看是否走 skill 流程而非自然语言回答)。
边界二:成本失控
三种典型失控:(1) 默认全程 Opus + ultracode,订阅额度快速耗尽或 API 账单爆炸;(2) CI 里 Agent 循环探索不设上限,一夜烧掉数百美元;(3) 第三方端点计费模式不清,以为包月实则按量。
正确做法:升档是临时的,完成即降;CI 必须设 --max-budget-usd 与 --max-turns;第三方 provider 的计费模式接入前核实清楚。
边界三:档位过高浪费
简单任务用高档,模型"想太多"引入过度设计,既贵又降低质量。常见于"我习惯了 max 档就不再降"的惰性。
正确做法:low/medium 是日常默认,high/xhigh/max/ultracode 是临时升级。完成任务后显式降回,养成肌肉记忆。用 /effort 确认当前档位。
边界四:API Key 泄露
第三方 provider Key、Anthropic API Key、ANTHROPIC_BASE_URL 配置都可能通过 shell 历史、git 提交、日志输出泄露。这是 CLAUDE.md 红线边界。
正确做法:Key 写入 ~/.zshrc 或独立的 .env 文件(加入 .gitignore);不要在命令行直接 export ANTHROPIC_API_KEY="sk-..."(会进 shell 历史);CI 里用 secret 管理系统注入,不硬编码;定期在 ~/.zshrc 与 git 历史里 grep 检查 Key 是否泄露。
边界五:把第三方模型当 Opus 全替代
第三方模型"能用"且便宜,容易让人误以为可以全替代 Opus。但 Skills 触发率、Agent 稳定性、命令真实性约束都存在差异——在简单任务上无感,在高级工作流上静默失败。
正确做法:明确第三方模型的定位——成本敏感的简单编码、区域合规场景、中文表达需求。架构决策、安全审查、复杂重构、依赖 Skills/Agent 的工作流仍用原生 Opus/Sonnet。双轨并行,按任务类型选模型。
多模型与成本策略是产品化的最后一道经济关。守住这条线,Claude Code 才能从个人工具扩展到团队 CI 与规模化场景;守不住,要么被配额卡停、要么被账单拖垮、要么被第三方模型的静默失败坑掉关键交付。本书到此结束,后续附录提供速查手册与版本时间线。
上一章:第 31 章 一人公司产品化路径
下一章:附录 A 速查手册