没有"最强"AI 模型：一套在编辑器里就能跑的选型框架

文章封面

模型月月出新品，榜单每周都在变。所以这篇文章不会告诉你“哪个模型最强”——任何此刻印出来的名字，一个月后就过时了，而且“对的模型”永远取决于你在做什么、愿意为“答对”付多少钱。

我们想给你的是一套可复用的选型框架，以及怎么不离开编辑器就把它跑完。OpenRouter 的 MCP 服务器能把你的助手连上实时用量榜、第三方基准测试、各家供应商的真实定价，还能直接给候选模型发测试提示词。

太长不看版：

“最好”= 你的任务 + 你的每任务成本 + 你的延迟预算。排行榜名次不在这三个里面。

用基准测试筛候选，用你自己的提示词定胜负。Ori Eval 能替你写并跑这套对比。

通过 MCP 在编辑器里查实时排名和价格，再用 get-generation 量出每次测试调用到底花了多少。

如果没有哪个模型明显胜出，与其死选一个，不如用 openrouter/auto-beta 按请求做路由。

一、别再问“哪个模型最强”，这个问题本身就有毒

不存在“唯一最强的 AI 模型”，只有“在某个任务、某个预算、某个时间点下最合适的模型”。

不同任务对模型的要求天差地别：摘要和写代码是两种完全不同的需求；抽取要的是“每次调用都吐出合法 JSON”，而不是文笔好；聊天功能取决于“第一个 token 多快蹦出来”，这跟答案整体质量压根不是一回事；一个在编程榜排第一的模型，处理长文档可能稀烂，做日常抽取又贵得离谱。

更有用的问法是把具体工作写进去。与其问“最好的 AI 模型是什么”，不如问“从扫描发票里抽出行项目，最好的模型是哪个”“审一篇 TypeScript 的 PR，最好的模型是哪个”“总结一场 90 分钟的电话记录，最好的模型是哪个”。先把自己的版本写出来，再用当前的数据去回答，而不是抱着一张过时的排行榜。

我们的流量数据能说明差异有多大。我们把一批请求归成 29 种任务类型并公布了市场份额。光“写代码”就占了其中九类：代码生成、调试、代码评审、仓库扫描、SQL、DevOps 配置……这九类没有一个共同的领头羊。在截至 2026 年 7 月 25 日的七天窗口里，有一个模型领跑了其中八类，而代码评审和安全类却是另一个模型领跑。“写代码用什么模型最好”——这个问题即使在“写代码”内部都已经太宽泛了。

二、基准测试是“过滤器”，不是“答案”

基准测试的价值，是把几百个选项收窄到几个你能认真测的候选。我们这边会把 Artificial Analysis 和 Design Arena 的第三方分数，跟我们自己的用量数据放在一起呈现。

但排行榜替你做不了最终决定。分数有噪声、热门榜单容易招来定向调优，而且没有一张榜跑过你的提示词。用榜来筛短名单，用你自己的测试来拍板。

不同任务要的不同能力，得看清楚：

写代码要推理质量和可靠的工具调用；
摘要要大上下文窗口和便宜的输入价；
抽取要的是稳定贴着 schema 走，而不是流利；
聊天要低延迟；
视觉要的是“模型得能接图片”这个前提——在拼质量之前，这一条先把候选砍掉一大半。

没有哪个模型在所有类目都第一。给所有事都用同一个模型，结果就是一个“演示很好看、你真正跑的业务上很差、而且还很贵”的默认选项。

三、先把 OpenRouter MCP 服务器接上

下面每一步都通过 MCP 服务器跑，所以先连上它。

OpenRouter MCP 服务器由官方托管，本地无需安装，任何 MCP 客户端都能连。下面覆盖 Claude Code、Cursor 和 Codex CLI，文档里还包含 OpenCode 和 Claude Desktop。你连一次，助手就能在编辑器里拉取实时模型、定价、额度、排名、基准和文档，还能发测试提示词，全程不离开编辑器。选型阶段用它；上线时照常调 API。

Claude Code：

claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp
claude mcp login openrouter

也可以在会话里跑 /mcp，选 openrouter，点 Authenticate 完成认证。

Cursor： 把下面这段加进 ~/.cursor/mcp.json，再用 cursor-agent mcp list 验证。

{
  "mcpServers": {
    "openrouter": { "url": "https://mcp.openrouter.ai/mcp" }
  }
}

Codex CLI：

codex mcp add openrouter --url https://mcp.openrouter.ai/mcp
codex mcp login openrouter

认证都是一步浏览器操作，三个编辑器一样。Cursor 里是在你第一次请求时才触发，而不是走登录命令。未认证的请求会返回 401 并启动我们的 OAuth 流程，同意前屏幕上会写清楚你授权了什么。

我们会签发一把标注 OpenRouter MCP: <应用名> 的密钥，作用域限定该客户端，默认七天有效、封顶 $10 额度（这个界面上可改，见 MCP 发布说明）。密钥短命且默认封顶，随时可断开，也能在你的密钥面板里撤销。

流程会重定向到 localhost——对 Claude Code、Cursor 这类桌面客户端是正常现象，但也意味着我们无法验证是哪个本地应用在接收密钥。只有你刚刚自己发起连接时才点同意。

你会用到的工具

多数工具是对实时数据的只读查询。例外是 send-message、generate-image、transcribe-audio、generate-speech——这几个会产生计费推理调用；还有 send-feedback，会就你自己的某次生成写反馈（见 MCP 文档）。

工具	返回什么
`list-task-classifications`	按任务类型的流量占比，以及每类的领头模型
`list-benchmarks`	Artificial Analysis 与 Design Arena 的第三方分数，可按任务类型筛选
`list-daily-model-rankings`	前 50 名模型每天的 token 总量，看趋势而非任务契合度
`list-models` / `get-model`	搜实时目录；查看单个模型完整详情
`list-model-endpoints`	某个模型的所有供应商，含价格、延迟、吞吐、数据策略
`search-docs`	从我们当前文档里直接取答案
`send-message` (计费)	用你的提示词跑候选模型。支持 `:online`、`:nitro`、`:floor`、`:free`
`get-generation`	一次调用的精确成本、token 数、供应商与延迟

助手调用 list-task-classifications，按 code:general_impl 标签返回领头模型及其用量与 token 占比，再继续拉各供应商定价——整个过程不需要开浏览器。

四、六步选型框架：按顺序跑

第 2 到第 5 步，每一步都对应助手对实时数据的一个具体调用；第 1 和第 6 步是你的判断：你定义需要什么，再拍板上线什么。

步骤 1：按“上线形态”定义任务

从活儿出发，别从模型名出发。写清楚：输入是什么、你期望的输出是什么、什么算“好”、你的延迟目标是多少，以及当成本和质量冲突时你倒向哪边。

最后这条影响后面每一步。给客户看的摘要，值得多花钱；一夜之间扫一百万条记录的抽取任务，即使牺牲一点质量也该压低价，因为量主导了账单。先说清楚你做的是哪一种。

步骤 2：从实时数据筛短名单

短名单来自两个问题：大家拿这个活儿用什么，以及这件事上谁分数高？

第一个，调 list-task-classifications。它返回我们 29 个任务标签、回溯七天的窗口，每个都带用量占比和服务的模型排名榜——数据来自真实流量。第二个，带 task_type（coding / intelligence / agentic）调 list-benchmarks，返回 Artificial Analysis 和 Design Arena 的分数，附带价格。这三个类目故意比 29 个流量标签粗，两个调用要搭配用：基准过滤先在 broad 类目里砍掉低分模型，流量标签再显示在你的具体细分里大家实际用什么。

list-daily-model-rankings 看趋势好用。默认返回前 50 名模型每天的 token 总量，外加一行聚合的 other。你可以按 programming、roleplay 这类用例、按模态、按工具调用活动收窄，但这些类目切片来自每周聚合的采样数据，当估算看。它告诉你什么在涨，不告诉你在你的活儿上表现好。同样视图在 openrouter.ai/rankings。

步骤 3：对比成本、供应商与延迟

对每个入围者，调 list-model-endpoints。你会拿到所有服务该模型的供应商，及其价格、上下文长度、近三十分钟的吞吐与延迟、在线率、量化方式、支持的参数。同一个模型在不同供应商之间，价格、速度、可靠性都可能不一样——这些差异最好在这儿发现，而不是在生产里。

需要跟人分享时，对比页在浏览器里展示同样的数据。

步骤 4：用你自己的数据测短名单

基准给了短名单，你自己的提示词做最终选择。

拿你真实的活儿跑 send-message：真实的工单、真实的文档、真实的 schema，包括那些平时最容易翻车的。一套“干净”的评测集会让每个模型都显得很能干——正因如此它分不出高下。

测试时有三个变体很有用：

:floor 路由到服务该模型最便宜的供应商，压低评测成本；
:nitro 路由到最快的，用来卡延迟预算；
:online 在任务需要当前上下文时附带联网搜索。

online 的花费要盯紧。同一个简单提示词跑三种方式：:floor 是 $0.0000030，:nitro 是 $0.0000024，而 :online 是 $0.0052576——单次提示词大约是普通调用的两千倍，所以要有意识地去用，别让它一直开着。

用 Ori Eval 把对比变成“可复跑”

零散的测试调用只能回答一次。Ori Eval 让这一步可复跑。你用大白话问一句，比如“我的客服 agent 用什么模型最好”，你的编程 agent 会在项目里找测试素材、把评测写成 *.eval.ts 文件、跑候选模型，并附上分数、耗时、成本给出推荐。在编辑器里启动，给你的编程 agent 这条指令：

run curl -fsSL https://openrouter.ai/skills/spawn-ori-eval and follow the instructions in its output to get started

Ori 一次运行锁定一个测试框架和一个模型，整轮测试都复用，所以同一份评测文件两次跑用的是同一套配置。它经 OpenRouter 发请求，于是一次对比能包含多家供应商的模型。上面这条指令在临时目录里跑。如果你改走手动步骤，评测文件就作为普通代码留在你项目里，新模型发布时可重跑、用 --baseline 跟上次对比、还能排进 CI 定时跑。

步骤 5：算“每任务成本”

每次测试调用后，把 generation ID 传给 get-generation。你会拿到精确成本、提示词与补全的 token 数、服务的供应商、以及延迟。在一组有代表性的提示词上取平均，按任务成功概率校正，把这个数写进决策文档。

两点注意：生成记录在调用一返回的瞬间还查不到，紧接着查会返回 404，几秒后才就绪——重试，别把第一次 404 当失败。另外，补全响应本身已带 usage.cost，如果你只关心这次调用的价格，跳过这趟额外往返即可；想顺带拿供应商、延迟、原生 token 计数时，再用 get-generation。

步骤 6：选定，或按请求路由

如果某个模型在你跑的业务上明显胜出，就用它。

如果结果很接近、你的流量混了好几种活儿、或者你不想每次有更好的模型发布就重做决定，就指向自动路由器（Auto Router），模型串用 openrouter/auto-beta。旧的 openrouter/auto 还能解析但已标废弃，用新的那个。

路由器不是乱选。它把每个请求归到约 30 个细粒度任务类型，按回溯七天的真实花费占比给候选排名，套用你的成本和质量偏好，并带兜底路由（见 Auto Router 文档）。这就是上面的框架，按请求粒度在跑，用的正是你在步骤 2 查的那套任务分类数据。

五、用“每任务成本”算账，别用“每 token 价格”

对比模型经济性，正确的计价单位是“每任务成本”，不是“每 token 价格”。

人们按每 token 比价，是因为好比是好比是真方便，也因为过去“全口径成本”很难量。现在 get-generation 每次调用都返回真实数字，这个难点没了。

一个单价低的模型，一旦开始重试、吐出比你 token 预算更长的补全、或者需要背后垫一个更强模型来兜底它的失误，就不再便宜了。一个更贵、但一次就做对的模型，总成本常常更低。

2026 年一项关于推理模型定价的研究量化了这点：在 32% 的模型两两对比里，标价更低的那个反而总花费更高，极端情况下反转达到 28 倍（Chen et al., “The Price Reversal Phenomenon”）。作者把原因归于模型在“思考”上花 token 的方式差异巨大：同一道查询，一个模型可能比另一个多用 900% 的 token，而同一道查询重复跑，波动能到 9.7 倍。标价一个字都没反映这些。

每任务成本 = ((输入 token × 输入价) + (输出 token × 输出价)) × 预期尝试次数

多数对比都漏了“预期尝试次数”这一项——而这一项往往决定结果。

下面用真实价格算一遍（核对于 2026 年 7 月 27 日）：GPT-5.4 mini 标价每百万输入 $0.75、每百万输出 $4.50；Claude Sonnet 5 标价 $2.00 / $10.00，约贵 2.4 倍。取一个 2000 输入 + 800 输出 token 的任务：

若 Sonnet 5 首次尝试成功率为 95%，每千次完成任务约花 $12.63；
要让 mini 追平，它首次尝试成功率得达到 40%；
低于 40%，那个“每 token 便宜 2.4 倍”的模型，反而成了更贵的干完这活儿的方式。

你对外汇报时，用“每千次完成任务成本”这个口径。token 最便宜的模型，往往不是干完活儿最便宜的方式。

下面的图不是只画一个点，而是画出整条曲线——这条曲线更值得留着，因为盈亏平衡率会随两个候选之间的价差移动：价差越大，便宜模型在“成功率更低”时仍能不输的空间就越大。

同一道例题，横扫每一个成功率画出的曲线（而非只取一个点）。Sonnet 5 固定按 95% 作参照，mini 的成功率变化。标价为 2026-07-27，任务为 2000 输入 + 800 输出 token，成功率是被扫的变量，非实测值。

六、分任务该优化什么：一张表说清

这是起点，不是排名。每一行告诉你优化什么、调哪个接口，名字由实时数据给。我们不印“赢家”，因为任何赢家名单下次发布就过时了。

任务	优化什么	怎么筛短名单
写代码	推理质量、工具调用可靠性，其次延迟	`list-benchmarks` 设 `task_type=coding`，再用 `list-task-classifications` 里的 `code:` 标签交叉核对
摘要与长上下文	上下文窗口和输入价（这俩主导账单）	`list-model-endpoints` 看上下文长度和提示词定价
结构化抽取	贴 schema、每次调用都合法 JSON	`list-model-endpoints` 看支持的参数，再用 `send-message` 跑你的真实 schema
聊天与助手	延迟优先，其次质量	`list-model-endpoints` 看供应商延迟与吞吐；用 `:nitro` 测
视觉与多模态	先能接图片，再谈领域契合	`list-models` 按输入模态筛选，再上你自己的图
智能体工具调用	多步之间的指令遵循	`list-benchmarks` 设 `task_type=agentic`，再做多步测试

写代码：先想清你说的是哪类写代码。我们的任务标签把代码生成、调试、评审、前端、仓库扫描拆开，领头模型各不相同。拿你 backlog 里一张真实工单测候选，别用玩具题。
摘要：输入价和上下文长度要一起看，单独看哪个都会骗你。一个窗口大但更便宜的模型，常能打赢一个更强但输入定价高的。
抽取：一个每次都还你合法 JSON 的小模型，胜过一天 corrupt 两次字段的更强模型。测难的输入：缺字段、模糊记录、格式乱掉的源文本。
视觉：多模态质量随领域波动极大，先按“能接图片”筛，再跑你自己的截图。一套库存 demo 集让每个候选都显得不错。

每种情况都是：跑查询、看本周的数字、从里面选。

七、为什么整套循环要跑在 OpenRouter 上

你根本不必锁定某一个模型。

一次接入，拿到跨供应商的整个模型目录。下个月出了更好的模型，你改一个模型串，而不是再集成一套 SDK、再测一遍接入路径。筛选和执行在同一平台，加上 MCP，筛选数据就在你本就在用的编辑器里。你还白拿供应商冗余和自动兜底，以及精确到“每请求”的成本数字——精确到足以让上面的“每任务成本”是算出来的而非估出来的。

如果你百分百确定就要某一家某一个、且永远不变，直连供应商也合理。但新模型一直在出，先掂量掂量你有多确定。

八、选型最常踩的五个坑

大多数糟糕的模型决策，要么量错了东西，要么量对了却太晚。这是我们看到最多的五个。

把排行榜名次当生产决策：公开榜上的高排名，只够进你的短名单，不够进生产流量。先拿你的提示词把模型跑一遍。
按每 token 价格选购：低价掩盖了重试、超长补全和兜底。get-generation 告诉你每任务成本之前，你并不知道这模型到底多贵。
无视上下文形态：上下文长度和那个长度下你要付的价都得看。长上下文模型既强又贵。用“最小可靠的上下文策略”把活儿干完，考虑扩大窗口之前，先考虑检索（RAG）。
选一次就再不回头：一月对你任务最好的，七月未必。光截至 2026-07-27 的三十天我们就加了约 40 个模型——任何大类发布后都重跑这六步，在仓库里留一份 Ori 评测定时重跑，或者把问题丢给 Auto Router。
把延迟和可靠性留到上线才看：先看 list-model-endpoints 里的延迟、吞吐、在线率，再按生产的方式压一遍端点。上线后才发现供应商不稳，是场本可避免的事故。

九、结语：为任务选，再让选择保持“当下”

正确的问题不是“哪个模型最强”，而是“在我预算下、此刻、为我正在做的东西，哪个模型最合适”。

有了清晰的任务定义、实时数据、一组真实提示词，你一个下午就能答出来；等有什么变了，几分钟就能重答。

“最好”是任务相关、时间相关的。按每任务成本和延迟评判，别按排名。
基准建短名单，你自己的数据定胜负。send-message 和 get-generation 一锤定音。
MCP 服务器一连，整套循环就在你的编辑器里跑。

接上 OpenRouter MCP 服务器，让你助手替你把这周要上线的活儿筛候选、算价格。如果拿不定、或者任务混杂，就用 Auto Router 配 openrouter/auto-beta，让它按请求去挑。

附：常见问题（精简版）

Q：到底怎么选 AI 模型？ 精确定义任务，从实时用量和基准数据筛候选，对比各供应商的价格与延迟，再用你自己的提示词测入围者。按“每任务成本”而非“每 token 价格”拍板。在 OpenRouter 上，这些步骤全能在编辑器里经 MCP 跑完。

Q：写代码用什么模型最好？ 没有固定答案，而且“写代码”不是一件事。我们把写代码流量拆成九个独立标签（代码生成、调试、文件 I/O、shell 执行、代码评审与安全、前端 UI、仓库扫描、SQL 与数据库、DevOps 配置），领头模型各不相同。用 list-benchmarks 设 task_type=coding 建短名单，用 list-task-classifications 跟真实流量交叉核对，再拿你 backlog 里一张真实工单测候选。

Q：OpenRouter MCP 服务器是什么？ 官方托管的远程 MCP 服务器，本地免安装。连上后，你的 AI 助手能查实时模型数据、各供应商定价、用量排名、第三方基准和文档，还能给候选模型发测试消息，全程不离开编辑器。任何 MCP 客户端都能连，文档覆盖 Claude Code、Codex CLI、OpenCode、Cursor CLI、Claude Desktop。

Q：每 token 成本和每任务成本差在哪？ 每 token 是输入输出的广告单价；每任务是“拿到一个成功结果”的总花费，含重试、超长补全、以及兜底到更强模型的开销。标价更低的模型，每任务可能更贵。get-generation 返回每次调用的真实成本和 token 数，让你量出来而不是估出来。

Q：多久该重评一次？ 你任务大类有任何重大发布、或成本/延迟/失败率漂移时，就重跑框架。截至 2026-07-27 的三十天我们加了约 40 个模型——把模型选型当运营决策，而非一次性配置。不想跟这个节奏，就用 Auto Router 按请求路由。

Q：用一个模型，还是几个之间路由？ 任务窄、提示词稳、某个候选从容过关时用一个。请求复杂度参差、可靠性比“模型一致”更重要、或不想到每个发布周期都重做决定时，就路由。Auto Router 把每个请求归到约 30 个任务类型，用社区回溯七天的花费占比按请求挑。

本文译自 OpenRouter 官方博客 How to Choose the Best AI Model (Live, in Your Editor)（2026-08-25 发布）。技术细节、命令、价格与链接均按原文核对；文中模型名、价格、论文编号均为原文所述时点数据，落地时请以 OpenRouter 实时数据为准。