主流大模型怎么选：我的场景对照表

每次有新模型发布，我都会看到同一类问题：「它和另一个比，谁更强？」但我自己早就不这么问了。原因很简单：模型能力不是一个标量，而是一张按任务类型铺开的表。 一个模型在代码重构上碾压对手，不代表它在中文润色上可用；一个模型能稳稳地做结构化抽取，也可能在读图时把表头认错。

这篇不比较跑分，只写我的选型方法。凡是涉及具体版本、参数与价格的部分，请以各家官方最新说明为准——这个领域变化太快，写死的数字几个月后就会变成误导。

一、先给任务分类，再谈选型

我现在的第一步不是打开模型列表，而是给手上的任务贴标签。落到日常，大概只有六类：

1. 长文理解：读一份几十页的规范、一堆日志、一整份合同。
2. 代码生成与重构：在既有代码库里改东西，而不是从零写一个算法题。
3. 结构化抽取：把非结构化文本转成字段固定的 JSON。
4. 中文写作与润色：写文档、写邮件、改语气。
5. 多模态读图：看报错截图、看设计稿、看表格图片。
6. 需要联网检索的事实性问题：涉及「最新」「这周」的问题。

这六类对模型的要求几乎不重叠。长文理解考的是定位与召回，不是「聪明」；代码任务考的是对既有约定的模仿能力和工具调用，不是背 API；结构化抽取考的是指令遵循与格式稳定性——这一点跟推理能力关系很小，用最贵的模型经常是浪费；中文写作考语感；读图考 OCR 与版面理解；联网检索考的是检索工具链，模型本身只负责最后一步归纳。

所以我的第一条判断是：不要问「哪个模型最好」，要问「我这类任务，能接受的最低配置是什么」。

二、长上下文 ≠ 有效上下文

这是我踩过最实在的一个坑。当时我把一份很长的接口文档整份贴进去，让它找某个字段的约束条件。它回得很快，也很自信，答案是错的——那段约束在文档中段。同样的内容，我改成「先让它输出章节目录，再指定章节精读」，答案立刻就对了。

塞得进去，不等于读得懂。我的经验规律有三条：

• 信息在开头和结尾时召回最好，落在中间时明显变差。
• 需要跨段推理（A 处定义、B 处引用）时，长上下文不如把两段显式拼在一起。
• 上下文越长，模型越容易顺着你给的前提往下编，而不是回头质疑你的前提。

对应的做法很朴素：

【分段精读模板】

第一步：先不要回答问题。把材料拆成章节清单，每项给出标题与大致内容。
第二步：我会指定其中 1-3 个章节，你只根据这些章节回答。
第三步：逐条标注依据来自哪个章节；找不到依据就写「材料中未提及」。

材料：
<<<
（粘贴全文）
>>>

那句「找不到依据就写未提及」是整个模板里最值钱的一行。它把「不许编」变成了一条可执行的指令，比在前面加十句「请准确」都有用。

另外记住：上下文长度是成本项，不是能力项。 塞进 5 万字，付的是 5 万字的钱和延迟，效果可能还不如先本地 grep 定位两段再问。

三、推理型模型与通用模型的取舍

「会先想一会儿再回答」的那类模型，在数学、多约束规划和隐蔽 bug 排查上确实更强，代价是慢和贵。我判断值不值得，用三条标准：

1. 中间步骤是否相互依赖？ 如果是「把这段话转成 JSON」「润色一下语气」，想久一点纯属浪费。
2. 答案是否可验证？ 有客观对错的问题，多花思考预算是划算的；纯主观的写作，思考再久也只是换一种说法。
3. 返工代价是否高于多花的钱和时间？ 线上故障排查、数据迁移脚本、架构评审，值得；生成一条提交信息，不值得。

我在这些任务上明确放弃了推理型模型：日常代码补全、文案润色、提交信息生成、写简单的正则和 SQL。它们慢得让人烦躁，质量差异却落在噪声区间。「更强的模型」用错了地方，唯一的确定收益就是账单变高。

四、本地模型与小模型的位置

我不建议拿本地小模型去对标云端强模型，那是必输的比较。它真正解决的问题是另外三类：

• 隐私敏感：不能出网的文本、内部合同、客户数据。质量差一点可以接受，合规不能谈。
• 批量且规则明确：给几千条数据打标、做分类、做脱敏预筛。这类任务里成本模型比能力上限重要得多。
• 离线与内网：网络不稳或不允许联外网的环境。

我试过用本地模型替代强模型做代码生成，结论是放弃了——它对项目里既有约定的模仿能力太弱，产出的代码风格像另一个人写的，评审成本反而更高。但用同一套本地模型做日志归类和敏感信息预筛，效果好到可以直接进流程。同一个模型，换个任务就从「不可用」变成「很好用」，这就是分类的意义。

五、我的两段式策略

大部分任务不需要最强模型，但需要最稳的流程。我固定用两段式：

{
  "stage_1": {
    "model": "便宜、快的那一档",
    "job": "分类、抽取、压缩、打标",
    "output": "结构化的中间结果",
    "note": "这一步允许出错，但必须可复核"
  },
  "stage_2": {
    "model": "最强的那一档",
    "job": "只处理第一段筛出来的难例和最终产出",
    "input": "已被压缩过的上下文",
    "note": "预算花在真正难的地方"
  }
}

举个具体例子：一批用户反馈要先分类再回复。第一段模型给每条打上类型标签和紧急度，并把长文本压成两三句摘要；只把「需要认真写回复」的那部分交给强模型。强模型的输入从几百字的长文变成几句话的摘要，成本下来了，质量反而更稳，因为它不用在无关内容里找重点。

六、任务类型对照表

任务类型	我的选型倾向	注意事项
长文理解	长上下文能力强的模型 + 分段精读	中间位置易丢；先出目录再精读
代码生成与重构	对代码库上下文理解好、能调工具的模型	让它先读周边代码，别直接下笔
结构化抽取	中等档位、指令遵循稳的模型	用 schema 约束输出，抽完要校验
中文写作与润色	中文语感好的模型	语义没变但语气跑偏很常见，要通读
多模态读图	视觉能力强的模型	表格与密集小字要人工核对
联网检索	检索工具链完善的产品	让它给出来源，逐条点开看

七、几个我试过大模型但收益不明显的地方

我不想把「用最强模型」说成无条件的正确答案，这几类任务上我的收益接近于零：

1. 大批量机械式重构。 几百个文件的同类替换，用脚本加一次抽样 review，比让模型逐个改更快也更一致。模型的价值在「判断哪里该改」，不在「改几百次」。
2. 需要精确记忆内部约定的任务。 比如内部某个字段的取值规则，模型不知道，猜出来的东西却很像真的。这类信息必须喂给它或者查文档，不能指望它「应该知道」。
3. 纯格式转换。 JSON 转 YAML、时间格式统一，写脚本是确定性的，模型每次都可能有细微差别。
4. 时效性极强的事实。 不联网的模型给出的版本号、发布时间，我一律当作不可信。

一句话小结：好的选型不是用最好的模型，而是用刚好够用的模型，加上明确的人来把关。 能稳定判断「这个任务属于哪一类、下限在哪里」，比记住任何一份榜单都更耐用。