每次大模型发布，厂商都会贴一张 benchmark 表：我们在 X 上得了多少分、在 Y 上赢了谁。Opus 4.6 的发布也不例外——Terminal-Bench 第一、Humanity’s Last Exam 第一、GDPval-AA 比 GPT-5.2 高 144 Elo、BrowseComp 第一。

数字很漂亮。但你真的该按这些数字做决策吗？

这篇不是要说 Anthropic 造假——他们大部分 benchmark 有第三方复现或独立机构跑的。要说的是：benchmark 的设计、运行条件、报告方式，都有值得注意的地方。

几个值得细看的注脚

Anthropic 的发布文章底部有一串注脚，大部分人不会看。但这些注脚里藏着关键信息。

Terminal-Bench 2.0：Anthropic 报告的分数包括"在我们基础设施上复现的分数"和"其他实验室公布的分数"。不同实验室用的 harness 配置不一样（Opus 用 Terminus-2 harness，OpenAI 的 Codex CLI 用了自己的 harness），资源分配也不同（1× 保证 / 3× 上限）。

同一个 benchmark，用不同的工具链跑，分数可能差 5-10 个百分点。当 Opus 4.6 和 GPT-5.2 的差距只有几个百分点时，这种方法论差异足以改变排名。

Humanity’s Last Exam：Anthropic 给 Claude 配了 web search、web fetch、code execution、programmatic tool calling、context compaction（50K 触发，最高 3M 总 token）、max reasoning effort、adaptive thinking。

也就是说，跑 HLE 时的 Claude 不是"裸模型"，而是一个全副武装的 Agent 系统。如果对手实验室用更少的工具跑，分数自然更低。这不一定是模型能力的差异，可能是工具链的差异。

SWE-bench Verified：Anthropic 的分数是 25 次试验的平均值，而且提到"用了一个 prompt modification 后分数可以到 81.42%"。报了 25 次平均值还是改过 prompt 的值？一般来说 25 次平均更公允，但"我还可以更高"这种暗示也在影响你的判断。

BrowseComp：加了多 Agent harness 后分数从基础分飙升到 86.8%。这说明 BrowseComp 的分数很大程度上取决于系统设计，不只是模型本身。

两个有意思的回退

The New Stack 的报道里提到了一个细节：Opus 4.6 在 SWE-bench Verified 和 MCP Atlas 上出现了小幅回退。

SWE-bench 是最广泛使用的代码生成 benchmark 之一，MCP Atlas 测的是工具调用能力。在这两个"最核心"的指标上反而退步了，Anthropic 没有给出解释。

可能的原因很多——benchmark 的具体 prompt 跟模型的训练分布不太匹配、adaptive thinking 在某些固定格式任务上不如手动 budget_tokens、或者模型的能力分配发生了偏移（在"更难的问题"上变强了，在"标准流程"上略弱了）。

但这恰恰说明了 benchmark 的局限性：一个模型不可能在所有评测上同时变好。如果一个发布只展示进步的数字、弱化退步的数字，你看到的就不是全貌。

GDPval-AA 的 Elo 差距意味着什么

Anthropic 在发布里重点强调 Opus 4.6 在 GDPval-AA 上比 GPT-5.2 高 144 Elo。这个 benchmark 由 Artificial Analysis 独立运营，测的是"经济上有价值的知识工作"——金融分析、法律推理等。

144 Elo 听起来很大。但 Elo 是一个相对评分系统，含义取决于基准分布。Anthropic 在注脚里翻译了一下：144 Elo 大约意味着 Opus 4.6 在 70% 的对比中胜出（50% 表示持平）。

也就是说，如果你随机抽 10 个 GDPval-AA 的任务，大概有 7 个 Opus 4.6 做得更好，3 个 GPT-5.2 做得更好（或持平）。不是碾压，是"大多数时候更好"。

对你的决策来说，这意味着：如果你的任务正好落在那 30% 里，Opus 4.6 反而不如 GPT-5.2。benchmark 只告诉你平均表现，不告诉你在你的具体任务上谁更好。

你应该怎么做自己的评估

与其纠结谁的 benchmark 更可信，不如花点时间建自己的评估。

1. 收集 20-50 个真实任务样本

从你的实际业务里选。如果你做代码审查，收集 20 个有代表性的 PR。如果你做客服，收集 50 个历史工单。

关键是"真实"——不是编造的测试用例，而是你的用户真正会遇到的输入。

2. 定义评分标准

不要用"好/坏"这种二元判断。定义几个维度，给每个维度打 1-5 分：

• 正确性：答案是否准确
• 完整性：是否遗漏关键信息
• 格式：输出结构是否符合要求
• 效率：token 消耗是否合理

3. 跑对比测试

同样的任务，同时喂给两三个模型。记录每个模型的得分和 token 消耗。

models = ["claude-opus-4-6", "claude-sonnet-4-5", "gpt-5.2"]
results = {}

for model in models:
    scores = []
    costs = []
    for task in test_tasks:
        response = call_model(model, task)
        score = evaluate(response, task.expected)
        cost = calculate_cost(response.usage, model)
        scores.append(score)
        costs.append(cost)
    results[model] = {
        "avg_score": sum(scores) / len(scores),
        "avg_cost": sum(costs) / len(costs),
        "score_per_dollar": sum(scores) / sum(costs)
    }

最后一个指标——每美元得分——通常是最有决策价值的。

4. 关注失败模式

平均分不够，还要看"什么时候会输"。

如果 Opus 4.6 在简单任务上跟 Sonnet 打平、但 Sonnet 只要三分之一的钱，你的最优策略可能是：简单任务用 Sonnet，复杂任务用 Opus。

这种分层策略在生产环境里很常见，但在 benchmark 表上看不出来。

一个务实的态度

Benchmark 的价值在于快速筛选：如果一个模型在你关心的任务类型上排名靠后，可以先不考虑。但排名靠前不等于"在你的场景里一定好"。

Opus 4.6 在 Terminal-Bench、ARC AGI 2 上的提升是实打实的（跟自己的 4.5 比）。但这些提升能不能转化成你的业务价值，只有你自己的测试说了算。

花半天时间建一套属于自己的小型 eval，远比在网上争论"谁的 benchmark 更可信"有用。