先定任务，再选模型
这篇记录一套经验性的选型方法。目前没有附上各型号的版本、原始输出和费用记录，因此不提供实测排名，也不把某个系列的名称当作质量保证。
可以从下面的候选组合开始，随后用自己的数据验证：
| 任务 | 起步时比较的候选 | 重点检查 |
|---|---|---|
| 分类、抽取、简单路由 | Haiku、Sonnet | 字段正确率、失败处理、单次费用 |
| 日常代码、文档与对话 | Sonnet，并选另一候选作对照 | 测试通过率、修改量、响应时间 |
| 复杂规划、多步骤工作 | Sonnet、Opus | 任务完成率、约束遗漏、总调用成本 |
表里的系列名称只用于组织候选。测试时要记录完整模型 ID、测试日期、提示词和参数，不同版本的结果不能直接混用。
把“好用”写成验收条件
先列出业务真正需要的结果。例如订单分类可以要求：只输出规定的枚举值、空输入返回 other、退款意图优先于物流查询。
长输入不等于简单任务。合同抽取、财务分析等场景，还需要检查遗漏、证据引用和人工复核成本；升级模型并不能自动消除这些问题。
质量、延迟和费用应分别记录。一次回答便宜，但需要多次重试，整条工作流未必便宜；只记录成功请求也会漏掉失败成本。
用同一份样例开始比较
下面是一个小型分类例子，参考答案由规则确定，不是某个模型的实测输出。它适合检查评测流程能否运行，不能代表真实业务的完整分布。
给每个候选相同的指令：
将用户请求分类为 order、refund、other。
refund：明确申请退款或退货；同时出现物流问题时，退款意图优先。
order：查询订单状态或物流，且没有退款或退货意图。
other：其他请求或空输入。
只返回一个标签，不添加说明。| 输入 | 参考答案 |
|---|---|
| 我的订单到哪了？ | order |
| 包裹迟迟没到，我要退款。 | refund |
| 我要取消邮件订阅。 | other |
至少加入空输入、容易混淆的词、多个意图和真实失败样例。把用于调整提示词的样例与最后验收的样例分开，避免只对熟悉的题目表现好。
留下可以复核的记录
每次调用保存 case_id、完整模型 ID、输入、原始输出、开始与结束时间、用量、错误和重试次数。费用按照测试当天的平台价格计算，并保存价格来源。
对分类任务，可以先做下面这个最小检查。results.jsonl 的每行是你实际收集的 {"id":"order-status","output":"order"}；缺失结果也计入总样本数。
import json
def read_jsonl(path):
with open(path, encoding="utf-8") as file:
return [json.loads(line) for line in file if line.strip()]
cases = read_jsonl("model-selection-cases.jsonl")
results = {row["id"]: row["output"] for row in read_jsonl("results.jsonl")}
correct = sum(results.get(row["id"], "").strip() == row["expected"] for row in cases)
missing = sum(row["id"] not in results for row in cases)
print({"correct": correct, "total": len(cases), "missing": missing})这个检查只验证标签一致性。代码任务应运行测试；开放式任务需要预先确定评分维度与人工复核方法。重复运行时也要保留波动，不能只挑一次最好结果。
什么时候升级或重新验证
先选能满足验收条件的候选，再决定是否值得为质量提升支付额外延迟和费用。只有测到某类失败能被另一模型稳定改善，才值得为那类任务增加升级路线。
模型版本、提示词、工具、数据分布或验收标准变化后，应重跑相关样例。复测由变化触发；没有一张选型表能只靠发布日期保证持续有效。