10 月大模型怎么选：GPT-6、Opus 5.5 与五个模型系列的能力对比

写代码、读合同、整理表格，打开模型列表却不知道选谁。GPT、Claude 和几个国产模型都在更新，切换了一圈，还是很难判断哪一个值得长期用。

选模型可以从手头的工作开始。写一个能自动检查的函数，通常更在意完成速度和费用；整理一份合同，则要看结论能否回到原文找到依据。同一个模型，在这两类工作中的吸引力可能相差很大。

围绕 GPT-6、Gemini 3.8、GLM-5.3、Claude Opus 5.5、DeepSeek、Kimi 和豆包，近期测评呈现出一些值得拿来试用的方向。

目录

• 01｜模型的优势，会随着任务变化
• 02｜短代码与批量任务：轻量模型值得先试
• 03｜读文档与做表格：能回查的答案更有用
• 04｜按你的工作，建立候选清单

01｜模型的优势，会随着任务变化

图 1｜综合能力与输出量对照。横轴越靠右，输出量越大；同一模型的推理档位也会改变位置。

这张图把综合能力与输出量放在了一起。同样达到接近的综合表现，不同模型消耗的输出量可能相差明显，推理档位也会改变它们的位置。日常选型可以同时看完成质量和资源投入：多花的时间与费用，是否换来了更好用的结果。

❝

这些数值来自文章列示的模型与推理设置，不是百分制正确率，也不等于它们在写作、编程和办公上的逐项排名。

图 2｜综合能力指数。Opus 5.5 与 Astra 位于前列，比较时同时看模型全名和括号中的推理设置。

综合能力图中，Opus 5.5 与 GPT-6 Astra 处在较高的位置；GLM-5.3 与 Kimi K3 比较接近，Gemini 3.8 Flash 和 GPT-6 Luna 则处在更靠后的位置。结合上一张图的输出量，可以先按工作难度缩小范围，再到具体任务里比较结果和费用。

GPT-6 内部就可以这样分工：Luna 放进短任务的首轮候选，Sol 与 Astra 拿材料依据要求较高的工作比较。GLM 的主模型、Flash、FlashX 和 Prime 也要分别试，选定实际适合你的版本。

选择时，把完整版本和推理设置记下来。遇到同类任务，再看模型是否稳定交付、是否需要重试。这样更容易判断一次表现能不能延续到日常工作中。

02｜短代码与批量任务：轻量模型值得先试

解析文本、合并区间、处理一段表格数据，这些任务要求明确，也比较容易自动检查。

图 3｜同样通过全部短代码题，调用费用仍有差距；图中使用对数刻度，重点看 Luna、Sol 和 Opus 的相对位置。

这组短代码测试中，GPT-6 Luna、GPT-6.1 Sol、GPT-6 Sol 和 Claude Opus 5.5 都通过了全部题目，Luna 的调用费用明显更低。Sol 6.1 与 Sol 的完成结果相同，前者的实际费用也更低。对能自动验收的小函数，模型大小带来的差别，更多体现在成本和等待时间上。

图 4｜全部通过模型的结果表。对照 FlashX 与 Sol 6.1 的费用、等待时间，可看到两种不同取舍。

GLM-5.3 FlashX 也在全部通过的模型名单里。结果表显示，它的实测费用低于 GPT-6.1 Sol，但平均等待时间更长。因此，选型时还要看你更在意单次调用费用，还是交付速度。

因此，批量处理文本解析、小函数和数据清洗时，可以先试 Luna；偏好 GLM 系列的，可以先把 FlashX 放进候选。让它们跑一遍你常用的任务，比较能否直接运行，以及每批任务需要修改几次。

Opus 的额外成本，交给真实任务判断

图 5｜Claude 结果表。重点比较同日的 Opus 5.5 与 Sonnet 5.5：通过数相同，费用和响应时间不同。

结果表中，同日测试的 Claude Opus 5.5 与 Sonnet 5.5 都通过了全部短代码题，Sonnet 的费用更低、平均响应也更快。单看这组任务，Opus 的额外投入没有换来更多通过的题目。普通短代码可以先交给 Sonnet 或 Luna。

我的建议是先让较低成本的模型完成初稿。当它反复通不过检查时，再让 Opus 处理同一份材料，比较错误是否减少、修改时间是否缩短。这样才容易判断额外投入是否划算。

推理投入增加，效果未必同步提高

图 6｜四种推理设置的完整结果。每格依次列出通过数、推理用量和费用，可逐行比较 Luna、Gemini 与 DeepSeek。

GPT-6 Luna 在默认设置下漏过了一题，切到 low 后全部通过，费用还更低。Gemini 3.8 Flash 在 low 档也全部通过，但 medium 和 high 都出现了答错的题目；增加推理投入，没有让这组短任务更稳。

DeepSeek V4.1 Flash 的情况又有不同：四种设置都全部通过，其中 medium 的实测用量和费用最低。low 并不总是最省钱的选项。

做短脚本时，Luna 和 Gemini 可以先从 low 试起；使用 DeepSeek 时，也值得把 medium 一起比较。保持题目和验收方式一致，再看哪种设置更少出错、费用更合适。

图 7｜DeepSeek 新旧版本的原始对照表。通过数相同，费用不同；末行同时列出各自的测试批次。

DeepSeek V4.1 Flash 与旧版 V4 Flash 在各自的测试中都全部通过，新版的实测费用更高。两版来自不同批次，旧版没有保留具体运行日期，但至少提供了一个迁移时该问的问题：新版本有没有解决旧版在你手头的具体错误？如果完成情况和返工量差不多，批量流程可以继续保留旧版，再用难题比较新版是否值得切换。

豆包代码接口，要先检查是否完整交付

图 8｜Seed Code 运行记录。已完成题目全部通过，token_bucket 正文为空，因此整轮被标为未完成。

Seed 2.0 Code 在这轮接口测试中，已经完成的八道题都通过了检查；最后的 token_bucket 任务却耗尽预算，正文为空，没有交出函数。因此，这轮测试留下的是一次未完成的运行。接进自动化流程后，这类中断会让后面的步骤停下来。

准备接入 Seed Code 时，可以先检查输出是否完整、预算是否够用，以及未完成时怎样重试。豆包聊天应用、TRAE 和代码接口各有自己的使用流程，日常助手的选择仍要在实际入口里体验。

03｜读文档与做表格：能回查的答案更有用

把合同整理成风险表，要求每条结论都有材料依据。模型可能把表格排得很好，却写错日期、金额或责任主体。验收时，需要逐条回到原文核对。

近期法律任务测评把实质性幻觉加入评价后，模型之间的表现发生了变化。下面两张图使用同一组模型，可以先看加入检查前的交付表现，再看排除实质性幻觉后的结果。

图 9｜法律任务加入幻觉检查前的结果。先记下 Astra、Sol 6.1、Kimi 与 Opus 的位置，再与下一图比较。

图 10｜法律任务加入幻觉检查后的结果。Astra 与 Sol 6.1 下降较少，Kimi 在这项指标下仍高于 Opus。

在这组法律任务中，加入实质性幻觉检查后，GPT-6 Astra 保留了大部分原先合格的交付，Sol 6.1 的成绩下降也较少。Kimi K3 在这项严格指标下的表现高于 Opus 5.5，值得加入材料分析的对比。

需要整理合同、提取依据时，可以优先比较 Astra、Sol 6.1 和 Kimi：让它们为每条结论附上原文位置，再核对日期、金额和责任主体。Opus 在短代码里全部通过，并不意味着它也会在这类法律材料任务中领先；按工作类型分别选择默认模型，会更实用。

字段规则写清楚，抽取结果可能更可靠

JSON 是程序容易读取的结构化文本，schema 则规定字段及其类型。格式符合要求之后，仍要核对填入的内容。

图 11｜字段规则调整前后的困难样本结果。蓝色为重设后的严格规则，五个模型都完成了全部样本。

图中每个模型都有三组结果：原始严格字段规则、普通 JSON 输出，以及重新设计的严格字段规则。Gemini 3.8 Flash 在原始规则下仍有题目答错，重新设计后全部通过；3.5 Flash Lite、3.1 Pro Preview 和 2.5 Flash 的改善也很明显。到最后，五个受测版本都通过了这组困难样本。

图 12｜缺失日期的实际输出。左列是严格字符串规则，右列是普通 JSON 输出；空字符串、补出的日期与 null 一目了然。

缺失日期的结果表更直观：严格要求日期为字符串时，Gemini 3.8 Flash 和 3.7 Flash 写了空字符串，另外三个版本填出了材料中没有的日期；换成普通 JSON 输出后，五个版本都填了 null。这个例子说明，字段规则会影响模型怎样处理缺失信息。

因此，Gemini 3.8 Flash 可以先用于文本字段抽取。出现错填时，先检查规则是否容得下原始信息，明确允许缺失值填 null，再核对提取内容。图中 3.1 Pro Preview 和 2.5 Flash 在规则重设后同样全部通过，先把规则写对，很可能比急着换模型更有用。

下面的提示词可以用于比较不同模型的返工量：

请仅依据我提供的发票文本提取：
供应商、开票日期、币种、总金额、已付金额、待付金额。

原文没有的信息填写 null，不要推测。
每个非空字段附一段支持它的原文。
若金额不能相互核对，保留原值并列出冲突。

接口返回成功，还要检查回答是否可用

图 13｜接口参数结果表。重点看 max_tokens 5 一列：empty 表示请求成功但无正文；其余参数列也显示了不同模型的处理差异。

看结果表的 max_tokens 5 一列，Kimi K3、GLM-5.3、DeepSeek V4.1 Flash 和 Gemini 3.8 Flash 都被标为 empty，表示请求返回成功，却没有正文。同一列里，Claude Opus 5.5 与 Sonnet 5.5 被标为 applied。这反映了不同模型在极小输出预算下的处理差异。

批量接入时，先给思考和正文留够预算，再检查输出是否为空、字段能否读取，以及结束原因是否正常。对需要程序直接读取的结果，把格式检查和失败重试接进流程，才能知道模型是否真正完成了交付。

04｜按你的工作，建立候选清单

可以用下面的方向安排首轮试用，记录每个候选在真实任务中的完成情况。

挑几项最近真实做过的工作，让候选模型使用相同材料和要求作答。代码保留运行结果，文档回查引文；写作任务可以隐藏模型名称后比较，提前写清字数、事实和语气要求。

遇到决定选型的关键错误，重复运行，看看它是否容易再次出现。最后把调用费用与核对、修改占用的时间放在一起算，选出返工较少的默认模型，再留一个处理失败任务的备选。

扫码关注卡洛研究所