使用场景指南

最适合编程助手的 LLM API

编程助手通常需要较大的上下文窗口(以容纳周边文件或整个仓库)以及均衡或旗舰级模型。此列表同时按这两个条件筛选 — 我们不对代码质量做基准测试,请结合自己的测试综合判断。

编程助手往往需要发送很大的提示词——文件内容、diff、周边上下文——因此需要足够大的上下文窗口,才能在一次调用里放下代码库中有意义的一部分。这份榜单筛选公布上下文窗口至少 20 万 token 的均衡型和旗舰型模型,按输入价格排序,因为编程类负载通常以输入为主。

ℹ️该列表的筛选方式: 筛选均衡或旗舰档位、且公开上下文 ≥20万 tokens 的模型,按输入价格升序排列。
10 个模型
模型 服务商 输入 /百万 输出 /百万 上下文
xAI $1.25 $2.50 100万 tokens
Anthropic $2.00 $10.00 100万 tokens
OpenAI $2.00 $12.00 约105万 tokens
xAI $2.00 $6.00 50万 tokens
Alibaba $2.00 $6.00 100万 tokens
Cohere $2.50 $10.00 25.6万 tokens
OpenAI $4.00 $20.00 约105万 tokens
Anthropic $5.00 $25.00 100万 tokens
Anthropic $10.00 $50.00 100万 tokens
OpenAI $10.00 $50.00 约105万 tokens

我们不针对特定任务的质量做基准测试 — 此列表仅基于核实价格和公开上下文窗口构建。用它按成本筛选候选模型,再自行评估输出质量。

查看所有使用场景 →

常见问题

我们不直接测试编程准确率,但厂商通常把经济型模型定位为更简单的高并发任务,而不是代码生成。如果你的编程任务范围小、重复性高,经济型模型仍然值得一试。

这个量级大致能在一次调用中放下几千行代码,加上周边文件和指令——对于需要同时理解多个文件的助手来说,是一个比较实用的下限。

通常不需要,即使上下文窗口很大——大多数编程助手在只收到相关文件和 diff 而不是整个仓库时,表现更好、成本也更低,因为计费是按发送的 token 数,不管模型是否真的用得上全部内容。