你大概遇到过这种场面：写代码的那条链路想换成 Claude，但面对几档模型不知道从哪下手——全用最强的那档怕成本撑不住，换便宜的又怕质量掉下来返工。这篇不给你一个「最好」的答案，而是给一套按任务分工的挑法：先认清各档差在哪、再按你的活对号入座、最后留一个能验证和回退的流程。
写代码的链路想换成 Claude，第一步通常不是去比哪个模型名字更响，而是先问自己：这条链路上跑的到底是什么活。补全、改 bug、写迁移脚本、审合同，这几件事对模型的要求完全不同，用同一档去套，要么浪费钱，要么返工。这篇给一套按任务分工的挑法，不替你下结论。
思路分三步：先认清档位之间到底差在哪三个维度，再拿自己的任务清单去对号入座，最后留一个能量化验证、能一键回退的流程。中间涉及规格和单价的地方，一律去站内页面看当时的数字，别用记忆里的旧值做预算。
先接受一件事：没有「最好」，只有「这活谁干」
同一个模型在不同任务上的相对表现经常翻转：代码类、长文整合、结构化抽取、对话风格，各自的赢家可能不是同一档。所以任何单一榜单只能当参考，不能当结论。真正该看的不是绝对强弱，而是三个可量化的量：单次任务通过率、单次耗时、每次成功任务的综合花费。
- 单次任务通过率：同一条需求跑若干次，几次不用人改就能用。
- 单次耗时：包含重试在内的端到端时间，不只是首字延迟。
- 每次成功任务花费：把失败和重试的调用都摊进成功的那一次里算。
- 判断口径统一之后，再比模型才有意义，否则只是各说各话。
各档到底差在哪：别背参数，记住三个轴
规格表上参数很多，记不住也没关系，抓住三个轴就够用了：能力、上下文、速度与成本。这三个轴决定了某一档适不适合某类活，参数名字叫什么反而次要。
- 能力轴
- 能不能一次处理多步复杂任务，比如重构整个模块、跨文件追一个 bug。弱档通常需要人先把步骤拆好再喂。
- 上下文轴
- 一次能塞多少材料。长文档问答、整库检索拼上下文这类活，它是硬约束，装不下就是装不下，能力再强也没用。
- 速度与成本轴
- 这两条一般绑在一起。快而便宜的档适合高频、可容忍重试的活；慢而稳的档适合低频、错了代价大的活。
具体哪一档当前对应哪档能力、上下文多长、单价多少，各家口径都会变。与其记旧数字，不如到 /official-api/providers/anthropic 看当时的规格与价格，再做预算。
按任务对号入座：一张自查清单
把手上要交给 Claude 的活先列出来，按下面的类别分组，再套档位。分不清类型的活，先归到「高价值低频」那一类做保守处理，跑一段时间有数据了再往下调。
| 任务类型 | 典型场景 | 选档倾向 | 注意事项 |
|---|---|---|---|
| 高频轻量 | 改写、分类、打标签、格式转换、简单摘要 | 便宜快速的那档 | 批量调用摊平成本，出错就重试 |
| 代码常规 | 补全、单测生成、小函数实现 | 中档 | 先跑基线，看返工率决定要不要升档 |
| 代码复杂 | 跨文件重构、读整库定位问题、迁移脚本 | 强档 | 一次返工的成本远高于调用差价 |
| 长文与资料整合 | 长文档问答、多份资料归纳 | 够用且装得下的那档 | 先量材料长度，装不下走分段或检索 |
| 高价值低频 | 合同条款比对、关键代码评审、对外内容终审 | 强档 | 强制加人工复核节点 |
- 先列任务清单把打算交给 Claude 的活写成一句话一条，标上日均调用量和能不能容忍重试。
- 归到上面的类别归不进任何一类的，先按高价值低频处理，别一上来就压成本。
- 跑二十条真实样本拿任意一档在你自己的真实样本上跑一遍，记录通过率和返工点，比看任何对比文章都准。
- 定档并记录每类任务对应哪一档写下来，顺手记下选它的理由，后面换档时这就是依据。
什么情况下不适用：如果你还没跑过任何基线，先别急着挑模型，也先别急着做混合路由，二十条真实样本跑完再说。
上下文和预算怎么一起算
只比每百万 token 的单价会误判，因为真实的单任务成本至少要三个数相乘：单次输入 token、单次输出 token、平均重试次数。这三个数只有拿你自己的任务测才准，用工具估算只能当起点。
- 用 /tools/token-price-calculator 或 /tools/model-cost-calculator 把材料长度和预估成本先换成数字。
- 把历史对话每轮都在重复计费这件事算进去，能靠检索只取相关片段就别整篇灌。
- 预留一份降级预算：假设强档调用量超预期，你打算把哪几类任务切到弱档，这个决定提前做。
- 当前定价口径和是否有缓存折扣，去 /official-api/providers/anthropic 与 /price-watch 看当时的数字，变化比你想象的频繁。
预算这件事最怕事后才发现超了。更稳的做法是给每类任务设一个调用量上限，超了就自动降级或者排队，而不是等账单出来再想办法。
上下文装不下时的三条路
材料塞不进去是最常见也最容易被忽视的问题。这时候有三条路，各有代价，别默认第一条就是对的。
| 做法 | 适合的任务 | 主要代价 |
|---|---|---|
| 按语义分段处理 | 抽取类任务，各段之间没有依赖 | 跨片推理会丢，汇总环节要单独设计 |
| 检索前置只取相关段 | 知识库问答，答案集中在少数段落 | 召回率决定上限，漏召就直接答错 |
| 换更长的上下文档 | 材料不可切分，比如完整合同、跨文件依赖链 | 最省心也最贵，成本要提前算 |
换档前后要做的事：别拍脑袋切
换档不是改一行配置那么简单，没有基线就没有比较，没有回退就是拿线上做实验。下面几件事按顺序做，出问题的概率会低很多。
- 留基线在现有档位上跑固定的一小批真实样本，记录通过率和耗时，这是后面比较的锚点。
- 灰度切先让一小部分流量走新档，观察一段时间，别一次性全量切。
- 留回退配置里能一键切回旧档，旧档的调用凭证和限流额度别急着清掉。
- 配指标换档一定要配一个可观测的成功率指标，没有指标就等于没验证。
- 换档后的对比要用同一批样本，不要中途换题。
- 样本量太小容易得出反直觉结论，至少覆盖日常几类主要任务。
- 回退演练一次，确认真的能切回去，别等出事才发现配置没生效。
- 迁移和回退的通用清单可以参考 model-upgrade-migration-checklist 的写法，这里只强调可观测这一条。
不用二选一：混合着用往往最划算
很多人纠结「到底用哪一档」，其实答案可以是不止一档。按任务把流量分开走，是常见做法，但它有前提：调用量得撑得起这套逻辑的维护成本。
- 路由分派：先用便宜那档判断任务难度或类型，简单活自己做完，复杂的转给强档。
- 草稿加审校：弱档出草稿、强档检查或重写，适合文案和代码场景。
- 按用户分层：内部试用走弱档，对外交付走强档，成本和质量各归其位。
- 别过度设计：日调用量很小的时候，分派逻辑的维护成本可能超过省下的钱，老实只用一档反而划算。
判断要不要做混合，可以看一个信号：如果分派规则写了两版还调不准，或者调试分派逻辑的时间已经超过跑任务本身，那就先退回单档。等调用量上来了再重新考虑。
下单前最后过一遍这份清单
动手前把下面几条对着过一遍，能省掉相当一部分返工和事后补丁。清单不长，但每一条都对应一个真实的坑。
- 任务清单分好类了吗，每类对应哪一档写下来了吗。
- 单任务真实成本算过了吗，用的是当前口径的单价吗。
- 长材料能不能装下，装不下走哪条路定了吗。
- 有没有基线样本、有没有灰度方案、有没有一键回退。
- 调用凭证、限流和额度够不够，去 /official-api/providers/anthropic 和 /ai-nav/category/ai-api 核对一遍。
- 每类任务有没有一个可观测的成功率指标，没有的话补上。
别问哪个模型最好，先问这活该谁干；档位是分工问题，不是排名问题。下一步拿你手上的任务去核对当前的档位规格和价格口径，再用自己的二十条真实样本跑一遍基线，比看任何对比文章都准。→
常见问题
我想省事直接用最强的那档，可以吗？
可以，只要你接受两件事：一是高频任务的成本会明显上去，二是你放弃了用便宜档跑简单活的路子。判断标准很简单——如果省下的调用费还不够你花时间去调路由，那就别省，直接上强档，把精力放在任务本身。
怎么判断我该换档了？
看两个信号：一是同一批任务里人工返工的比例明显偏高，说明当前档位撑不住复杂度；二是大量任务其实很简单却一直在走强档，说明你在为不需要的能力付钱。两个信号方向相反，一个往上换一个往下切。换之前记得先跑一批固定样本做基线。
上下文装不下怎么办，是不是只能换长上下文档？
不一定。如果任务只需要局部信息，切片或先检索再拼进去更便宜；只有当任务必须看到全局才做得对时，换长上下文档才是对的解法。判断方法：把材料切一半问自己，模型只看这一半能不能给出正确答案，能就切，不能就换档。
不同档之间的输出风格差很多吗，会不会换了之后要重调提示词？
通常需要微调。强档对模糊指令的容忍度一般更高，弱档更依赖你把格式和步骤写死。换档时把提示词里的「要求」改成「例子加要求」往往更稳，改完用同一批样本比一次通过率，别凭感觉判断。
预算有限的话，最该把钱花在哪类任务上？
花在错了代价高、并且人很难提前发现错误的活上，比如关键代码评审、对外发布内容的终审、合同条款比对。这类任务量小但对结果敏感，单价贵一点无所谓；反过来，高频、错了立刻能看出来的活，用便宜档加重试最划算。
