Jenny Met

Posted on Jul 30 • Originally published at crazyrouter.com

Claude Opus 5 vs GPT-5.6-SOL：10 道智能正确率实测，核心答案打平

#ai #api #llm #benchmark

Claude Opus 5 vs GPT-5.6-SOL：10 道智能正确率实测，核心答案打平

Claude Opus 5 和 GPT-5.6-SOL，谁更聪明？

如果用一次响应时间回答这个问题，结论很可能测到的是线路、路由和上游负载，而不是模型能力。因此这轮对比主动放弃“谁更快”的叙事，只保留可以独立验收的内容：数学答案是否正确、物理建模是否完整、代码能否通过隐藏测试、错误前提能否被识别，以及题目要求是否全部完成。

我们通过 Crazyrouter 的同一个 OpenAI-compatible endpoint，对两个模型执行了 10 道智能题，并把严格 JSON 作为单独的指令遵守测试。结果比“谁碾压谁”更值得参考：

核心答案正确率：Opus 5 为 10/10，GPT-5.6-SOL 为 10/10；
完整完成全部子要求：Opus 5 为 9/10，GPT-5.6-SOL 为 10/10；
两道 Python 算法题隐藏测试：双方均为 2/2；
严格 JSON 首次交付：Opus 5 为 0/1，GPT-5.6-SOL 为 1/1；Opus 后续两次复测仍附加了额外文字。

所以，本轮可以说“核心正确率打平”，但不能说两者的交付行为完全相同。

创建 API Key，用自己的真实题库复测

快速结论

问题	本轮结果
谁的核心智能答案更正确？	打平：双方 10/10
谁完整完成了更多题目要求？	GPT-5.6-SOL：10/10；Opus 5：9/10
谁的代码更可靠？	本轮打平，两道算法题均通过隐藏测试
Opus 的概率题算错了吗？	没有，核心答案正确；只是输出被 `max_tokens=3200` 截断，遗漏最后一个解释要求
谁更遵守严格 JSON？	本轮 GPT-5.6-SOL 更稳；Opus 连续 3 次添加了额外文本或代码围栏
能据此宣布 GPT 更聪明吗？	不能。格式遵守和核心推理正确率应分开统计

如果你的业务以数学、物理或算法正确性为主，这组样本没有拉开明显差距。如果业务要求响应必须是可直接解析的 JSON，或者每个子要求都不能缺失，那么 GPT-5.6-SOL 在本轮表现得更完整。

为什么这次不比较速度

模型 API 的端到端耗时会受到多个变量影响：

网关到不同上游的网络路径；
当时渠道负载与账户限流；
是否命中缓存；
路由到哪个实际服务实例；
上游如何统计或隐藏 reasoning token。

一次请求快几秒，并不能证明模型推理更强。除非固定上游、重复足够多次并报告置信区间，否则延迟更适合做运维观测，不适合当作“智能分数”。

这也是为什么本文没有把任何响应耗时指标放进胜负表。如果你关心可用模型和接入范围，可以先查看 Crazyrouter 模型列表；成本规划则应单独参考 Crazyrouter pricing。

测试环境与评分方式

测试前调用模型列表接口，确认两个精确模型 ID 均可见：

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
gpt-5.6-sol

正式请求统一使用：

POST https://cn.crazyrouter.com/v1/chat/completions

每个测试批次内，两款模型使用相同的 system prompt、user prompt、temperature 和 max_tokens。测试不启用外部工具，也不把 HTTP 200 自动当成任务通过。

评分拆成三层：

核心答案正确率：关键数值、结论和算法行为是否正确；
完整任务通过率：是否完成题目列出的全部子要求；
机器可验收性：代码是否通过隐藏测试，JSON 是否可直接解析。

自动字符串评分之后又做了人工复核。原因很简单：LaTeX 写法、大小写、精确分数与小数舍入都可能造成假阴性。比如 GPT-5.6-SOL 的概率题没有照抄参考分数，但给出了等价公式和正确小数；Opus 的物理题把 0.302 m 写成两位有效数字 0.30 m，也不能因此算错。

10 道智能题结果

任务	验收要点	Claude Opus 5	GPT-5.6-SOL
精确马尔可夫链	`E[τ]=5`、`E[τ²]=43`、`Var(τ)=18`	正确	正确
二自由度振子	两个固有频率、两个振幅、两个相位	正确	正确
约束搜索	唯一顺序 `A,C,E,B,D`	正确	正确
Cantelli 纠错	概率不可识别，上界为 `0.2`	正确	正确
Python 环检测审查	bug、DAG 反例、最小修复	正确	正确
实验设计	同题配对、难度控制、置信区间	正确	正确
偏置硬币等待 `HHTH`	期望约 `12.6547` 与正确状态转移	核心正确，最后一项解释因截断缺失	正确且完整
日志聚合算法	时间窗口、失败事件、缓存率、Top 用户	隐藏测试通过	隐藏测试通过
非弹性碰撞与弹簧	`v1≈6.10`、`v2≈2.44`、`x≈0.302`	正确	正确
稳定路由算法	cost、latency、reliability 与字典序规则	隐藏测试通过	隐藏测试通过

最难的概率题：答案正确不等于任务完整

目标模式为 HHTH，偏置硬币满足 P(H)=0.62、P(T)=0.38。题目要求用最长前后缀匹配状态建立方程，并特别解释两个容易出错的地方：

状态 HH 后再次出现 H，为什么仍然停留在 HH；
为什么期望等待时间不能直接写成 1/P(HHTH)。

两款模型都得到了正确期望：

E[N] ≈ 12.6547

GPT-5.6-SOL 完成了全部推导，并指出模式存在重叠，因此：

E[N] = 1 / P(HHTH) + 1 / P(H)

Opus 5 也给出了正确状态、方程、精确分数和小数结果，但响应最终为 finish_reason=length。输出停在附加状态期望值处，没有完成最后一项“为什么不能直接使用倒数概率”的解释。

这道题提醒我们：

最终数值正确，可以计入核心答案正确率；没有完成全部问题，则不能计入完整任务通过率。

这和此前的 max_tokens 截断复测是同一个方法论问题：必须同时保存答案、finish_reason 和输出预算，不能看到半段正确内容就宣布任务完成。

两道代码题：必须真正运行，而不是看起来像代码

代码生成对比最容易被“写得很长”“注释很多”“结构优雅”误导。我们没有人工挑喜欢的实现，而是把两款模型输出保存成 .py 文件，在隔离模式下执行统一测试。

日志聚合器

函数需要处理：

半开时间窗口；
成功与失败请求的不同计数规则；
缺失用户和模型；
cache hit rate；
cost 相同情况下的用户字典序排序；
不修改输入对象。

两款模型的实现都通过了隐藏测试。

带可靠性约束的稳定路由

函数需要在路径搜索中同时处理：

总成本最低；
成本相同时延迟最低；
再相同时可靠性最高；
最后按路径字典序选择；
banned nodes、最大 hops、最小可靠性和非法边。

两款模型同样全部通过。因此本轮代码能力结论是打平，而不是根据代码长度猜测赢家。

如果你希望看 GPT-5.6-SOL 在另一组复杂物理与依赖算法中的表现，可以参考 GPT-5.6-SOL vs GPT-5.5 高难物理与代码实测。

严格 JSON：这是指令遵守测试，不是数学智力题

严格 JSON 题要求把事故数据压缩为一个对象，并明确写了：

exactly one JSON object and no Markdown

两款模型都算对了失败率、渠道归属和重试后未恢复数量。差异出现在输出外壳：

GPT-5.6-SOL 首次只返回 JSON，可直接交给 json.loads；
Opus 5 首次添加代码围栏和 Verification；
Opus 第一次复测输出紧凑 JSON，但后面继续添加 Verification；
Opus 第二次复测再次添加代码围栏和解释。

因此 Opus 是“数据正确、格式失败”，不是“不会计算”。把这一项混入智能正确率，会把两个不同问题混成一个模糊总分。

生产中可以做最基本的本地验收：

import json

REQUIRED_KEYS = [
    "window",
    "total_requests",
    "failed_requests",
    "failure_rate_pct",
    "provider_owned_failures",
    "customer_owned_failures",
    "recovered_by_retry",
    "unrecovered_failures",
    "root_cause",
    "action",
]


def parse_incident_json(raw: str) -> dict:
    payload = json.loads(raw)
    if list(payload) != REQUIRED_KEYS:
        raise ValueError("unexpected schema or key order")
    if payload["failed_requests"] != 84:
        raise ValueError("failed request count mismatch")
    return payload

只靠 system prompt 不能保证结构化输出。更稳妥的方式是：使用供应方支持的结构化输出参数、执行本地 schema 校验，并在解析失败时重试或切换模型。

如何通过同一个 API 复测

下面的最小示例使用 OpenAI-compatible chat completions endpoint。API endpoint 本身不添加 UTM 参数。

import os
import requests

BASE_URL = "https://cn.crazyrouter.com/v1"
API_KEY = os.environ["CRAZYROUTER_API_KEY"]


def ask(model: str, prompt: str, max_tokens: int = 4000) -> dict:
    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": model,
            "messages": [
                {"role": "system", "content": "Answer accurately and follow every requested constraint."},
                {"role": "user", "content": prompt},
            ],
            "temperature": 0.2,
            "max_tokens": max_tokens,
        },
        timeout=600,
    )
    response.raise_for_status()
    return response.json()


for model in ("claude-opus-5", "gpt-5.6-sol"):
    result = ask(model, "Your benchmark prompt here")
    choice = result["choices"][0]
    print(model, choice.get("finish_reason"), choice["message"].get("content", ""))

正式测试时还应保存 response ID、returned model、原始答案和本地验收结果。你可以在 Crazyrouter 模型列表确认当前模型可见性，再用自己的业务 prompt 做小批量回归。

生产选型建议

两款模型都适合的场景

有明确参考答案的数学与物理求解；
可以运行单元测试的 Python 算法；
需要识别错误前提或不充分统计结论；
能通过本地验证器判断任务是否成功的工作流。

本轮更适合优先 GPT-5.6-SOL 的场景

每一个子要求都必须在一次响应中完成；
原始正文必须是纯 JSON；
希望减少从解释文本中提取结构化数据的工作。

使用 Opus 5 时应增加的保护

长推导设置更充足的 max_tokens；
必须检查 finish_reason；
JSON 先解析再进入下游；
对额外 Markdown 或解释文字做明确回退处理。

这不意味着 Opus 5 的推理较弱。本轮它的 10 道核心答案全部正确，且两份代码都通过隐藏测试。差别主要体现在“是否把所有要求完整装进最终响应”。

如果你还在比较 Claude 系列内部的交付行为，可以阅读 Claude Opus 5 vs Claude Fable 5 真实 API 测试。

FAQ

Claude Opus 5 和 GPT-5.6-SOL 谁更聪明？

本轮 10 道可客观验收的智能题中，双方核心答案都是 10/10，因此没有证据支持“其中一款全面更聪明”。

为什么完整任务通过率不是平局？

Opus 的高难概率题输出被 max_tokens=3200 截断，虽然期望值和状态方程正确，但遗漏了最后一项解释。GPT 完成了全部子要求。

JSON 失败应该算智能错误吗？

不应直接算作数学或推理错误。更准确的分类是格式与指令遵守失败，因为 Opus 计算出的所有 JSON 字段和值都正确。

两道代码题如何评分？

模型输出被保存为 Python 文件，然后运行相同的隐藏测试，覆盖边界条件、排序规则、非法输入和输入不可变性。两款模型都通过。

为什么不公布速度赢家？

端到端速度会受到线路、渠道、缓存、上游负载和路由影响。在没有固定上游和足够重复次数时，它不能代表智能正确率。

10 道题足够决定长期选型吗？

不够。这是一次小样本、可复现的能力切片。上线前应把真实业务题库重复 20–50 次，分别统计核心正确率、完整任务通过率、代码测试通过率和格式违规率。

我应该怎样开始自己的模型对比？

先选择 10–30 个真实业务 prompt，为每题定义机器可执行的通过标准，再通过统一 API 发送相同输入。不要先决定赢家，再挑支持结论的案例。

最终结论

这轮测试最重要的结果不是“GPT 赢”或“Opus 赢”，而是一个更可操作的判断：

Claude Opus 5 与 GPT-5.6-SOL 在 10 道智能题上的核心答案正确率均为 10/10；GPT-5.6-SOL 在完整子要求和严格 JSON 交付上更稳定，Opus 5 则需要更严格的输出预算与格式验收。

如果你的任务有参考答案或隐藏测试，两款模型都值得进入候选集。如果下游系统直接消费 JSON，则应把格式验证、重试和模型回退视为必要组件，而不是可选优化。

创建 Crazyrouter 账户并运行自己的 Opus 5 / GPT-5.6-SOL 测试

Top comments (1)

Luis Cruz • Jul 30

我对 Claude Opus 5 和 GPT-5.6-SOL 在 10 道智能题中的表现特别感兴趣，尤其是它们在数学和物理建模方面的能力。很值得注意的是，两者在核心答案正确率方面打平，均为 10/10，这表明它们在处理复杂问题时有着相似的能力。然而，GPT-5.6-SOL 在完成全部子要求方面略占优势，取得了 10/10 的成绩，而 Opus 5 只有 9/10。这可能是由于 GPT-5.6-SOL 更好地理解并遵循了问题的所有要求。关于严格 JSON 首次交付的测试结果，GPT-5.6-SOL 也表现出更好的稳定性和遵守性。这些结果为我们提供了对这些模型在不同任务中的优劣的一个很好的参考，特别是在严格遵守问题要求和格式方面的差异。考虑到这些结果，你是否认为在特定类型的任务中，一个模型相对于另一个模型的优势会更加明显，或者它们的差异主要体现在输出格式和细节上？