为生产环境选 AI 模型，不是一个“本周谁排在榜首”的问题。它是一个约束问题，而大部分答案你其实已经知道。先把六件事写下来——任务类型、上下文长度、输入模态、交互形态、可控性，以及对成本结构的敏感度——再用一小套取自你自己流量的自测收敛出选择。本指南讲为什么榜单做不了这个决定、六条模型选择标准、一个下午就能拼出来的最小黄金集，以及一张按任务族和模型类型组织的决策表。
为什么榜单做不了你的生产模型选择
基准测试衡量的是固定 prompt、固定条件下的一个平均任务。你的生产请求不是那个东西。它有自己的输入分布、自己的 prompt 结构，以及对失败特有的容忍度，而这些没有任何公开评测会共享。
这个差距在转译那一步就露出来了。一个公布的分数告诉你某些模型在别人的测试集上得了多少分；它没法告诉你你的任务是变好还是变差，因为你的任务从来不在那个测试里。读任何公布数字时有一个有用的习惯：问它量的是什么任务、用的是哪个 prompt 版本、什么时候跑的、谁控制了那套设置。这些问题答不上来，数字就是装饰，你还是得回到自己的约束和自己的测试。而且任何分数背后的条件都过期得很快：prompt 会变、版本会滚、各出版物之间的评测框架也不一样，一个看不到日期和方法的分数是故事，不是证据。这一切并不让评测变得无用，只是让它成为别人的评测——这也正是为什么任何模型选择流程的最后一步，都是你自己跑、用你自己的输入跑。
实际结论是：把榜单当作发现、初筛和建立词汇表的信号，把生产模型选择当作一个由你自己收尾的约束匹配问题。初筛阶段真正重要的能力，在源头就有文档，各家的模型页面就是这些规格所在的地方，OpenAI 的模型文档就在其中：模型接受什么、返回什么、为什么场景设计。
先写下来的六条模型选择标准
在打开任何对比页面之前，先回答这些。六条里有两条——上下文窗口和模态限制——淘汰候选最快，所以要早点用。漏掉任何一条，你会在一个季度内把整个选择重吵一遍，通常还发生在生产流量已经跑在你选的那个模型上的时候。
第一：任务类型。生成、抽取、分类、代码，还是多轮工具调用。怎么判断：分类真实的工作负载，而不是 demo。一个主要在抽取字段的聊天功能，就是穿着聊天外衣的抽取任务，它的标准要按抽取来。
第二：上下文长度。典型输入有多大，最坏情况又有多大？怎么判断：在真实请求上量，而不是手挑的样本。决定性的问题是：一整个工作负载能一次装下，还是必须切块；一旦切块进场，你就有了一个流水线问题，没有任何模型能悄悄吸收掉。
第三：输入模态。纯文本、有图片进来，还是要生成或编辑图片？怎么判断：审计实际到达的东西。大厂当前所有模型都能处理文本和图片输入，Anthropic 的模型概览就对其产品线说得很直白；但生成和编辑位于不同的端点、有不同的限制；如果你的产品会碰到它们，就先把模态当作硬性过滤条件。
第四：交互形态。离线批处理还是实时交互，随之而来的延迟敏感度有多高。怎么判断：找出谁在等输出，以及他们等更久时什么会坏。夜间流水线和实时自动补全面对的是同一个模型问题，但这条标准一旦写下来，答案就截然不同。
第五：可控性。结构化输出的稳定性、工具调用的可靠性，以及可复现性。怎么判断：往下游看。如果解析器、schema 或自动化要消费这个输出，那么稳定性就是硬要求而不是偏好，而且在大多数日子里它的优先级高于能力。
第六：成本结构敏感度。不是一个数字，而是一种形状：你的请求是输入重还是输出重，是否会重复，结果能不能缓存，工作负载是批处理还是交互式？怎么判断：读你自己的流量构成。两个团队做同一个功能，可能因为一个是把长文档送进去、另一个是把长文档拿出来，而落在不同结构上。
用最小黄金集收敛
六条标准写下来之后，初筛出两三个候选，然后用你处理其他所有生产决策的方式来定夺：用一小套取自真实数据的测试。
从真实流量里抽十到三十个有代表性的样本，并且刻意把那些别扭的也放进去：最长的输入、最奇怪的格式、让人提了 bug 的那个案例。对每个样本，对可接受的输出形状写一条断言：这个字段存在、这个结构合法、这种拒答不出现、这个引用格式被遵守。断言胜过感觉，因为它们可以显式地失败。
让每个候选跑同一套集合，然后比较两件事：有多少断言通过，以及更有用的——失败是如何分布的。一个模型在格式上失败、另一个在内容上失败，这告诉你你的产品能容忍哪一种失败。用完全相同的输入重跑一遍，以捕捉不稳定和格式漂移，因为一个只在隔周的周二才成立的选择不算选择。把黄金集控制到可维护的规模：几十个精心挑选的样本，只要有任何变化就重跑，胜过每个季度从头重建的宏大评测套件，因为真正抓到漂移的是重跑。这与我们兼容性清单里的“上线前先验证”是同一种纪律，只不过从端点行为换成了模型行为。
决策表：任务族与模型类型
下表把任务族映射到应当优先考虑哪一类模型。是类型而不是名字，因为名字会轮换、版本会退役，而工作的形状比任何具体模型都保持得更久。编码用哪个模型、长文档用哪个，也不是一个有唯一答案的问题；表里把它们分开，是因为它们的约束画像不同。
| Task family | Priority type | The constraint doing the deciding |
|---|---|---|
| Summarization and rewriting | Lightweight-efficient or long-context | Volume and input size; interactive if users wait |
| Long-document analysis | Long-context | One-pass coverage versus chunk-and-merge pipeline |
| Code generation and review | Reasoning-heavy with strong tooling | Structured output and edit correctness |
| Structured extraction | Controllable structured-output, multimodal when inputs include images | Schema stability is the product |
| Multi-turn tool calling | Reasoning-heavy with reliable tool use | Failure behavior across turns |
| Low-sensitivity batch (drafts, tagging) | Lightweight-efficient | Cost structure and throughput shape, no human in the loop |
当你从类型下沉到具体的模型名字时，用活的清单而不是记忆：你平台上的GET /v1/models会返回当前的阵容，平台文档解释了怎么读它。由提供商自己写的模型目录——Google 的平台模型页面就是一例——才是你在为某个条目投入一套黄金集之前，确认它接受什么的地方。
组合与替换，不必大动干戈
一个有韧性的安排，给每个任务族最多两个候选：一个主用、一个备用，两者都通过黄金集，两者都通过同一套集成可达。为每个任务族追一个唯一赢家，正是团队最后落得一打集成、却不知道哪一个在承载生产流量的原因。把结论写进团队已经在放决策的地方，并把黄金集结果附上；那份笔记才是资产，它决定了下一次替换是一个下午，还是一次事故。
替换遵循与选择相同的纪律。当某个版本退役，或某个候选不再通过它的断言时，用黄金集对着替代者重跑，而不是相信变更日志，然后再次让失败类型来做决定。保持工具侧配置可移植的机制，见我们关于一把 key 通用于多个编码工具的配置指南；完整生命周期视角——通知窗口、别名层与回滚——见模型迁移手册。
一页纸就能让这件事保持诚实：写下六条约束，抽样，写断言，跑候选，读失败类型，记录结论。六列笔记胜过任何分数表格，因为每一条都能映射回你真实拥有的某个需求。
有些替换不是可选的：退役日期一到，关停汇总就是确认哪个快照停止工作、由什么接替的地方。
接下来读什么
- 看看模型选择如何嵌入更完整的工作流。 把研究、写作和评审分派给不同模型，就是本指南的逻辑在整个流水线上的应用。
- 顺着产品这条线读下去。更多关于模型与平台选择的文章在产品指南里。
按约束选择，用测试收敛，并记录原因。榜单会继续变；下个季度你的约束还在那儿。