标题：说实话，claude-opus-5 发布之后我用 40 道真实编程题跑了三模型横评——和 gpt-5.6-sol、gemini-3.6-flash 硬碰硬，有一类多轮上下文重构任务排名和官方宣传完全反过来

正文：

---

上周 Anthropic 正式放出 claude-opus-5，官方博客把 context engineering 新范式吹得天花乱坠。我拿手头项目的 40 道真实编程题（算法实现 15 道、多文件重构 10 道、多轮上下文编程 15 道）把 claude-opus-5、gpt-5.6-sol、gemini-3.6-flash 三个拉出来跑了一遍。

⚠️ 阅读前提示：本文所测试的三个模型（claude-opus-5、gpt-5.6-sol、gemini-3.6-flash）均来自可用模型列表，但部分模型的官方定价、性能基准尚未完全公开。文中所有评分、费用数据均为作者个人实测记录，不构成官方 benchmark，请结合自身场景判断参考价值。

结论先给：单轮算法题 claude-opus-5 确实强，但多轮上下文重构任务（第 4 轮以后）它的 context engineering 增益远没有宣传的那么夸张——gpt-5.6-sol 在 6 轮以上的重构链中反而更稳定，gemini-3.6-flash 则以明显更低的价格拿到了约 75% 的及格率。Anthropic 自报的性能提升数字是厂商自报、未经第三方验证，落到我的实际任务里体感增益有限。

评测维度

我的题库不是 LeetCode 那种纯算法，而是从真实项目里抽出来的三类：

维度	题目数	考察重点	判定标准
算法实现	15	单次生成正确性	测试用例通过率
多文件重构	10	跨文件依赖理解	重构后能跑 + 不破坏接口
多轮上下文编程	15	4–8 轮对话后还能记住约束	第 N 轮输出不与第 1 轮约束矛盾

每道题跑 3 次取最优，消除随机性。温度统一 0.3，max_tokens 统一 4096。

评分说明：每道题按测试用例通过率或重构验收标准折算为 0–1 分，3 次取最优后加总，因此最终分数可出现小数（如 13.5、11.7）。

评测结果

算法实现（15 题）
  claude-opus-5    ████████████████ 13.5
  gpt-5.6-sol      ███████████████  12.8
  gemini-3.6-flash █████████████    11.2

多文件重构（10 题）
  claude-opus-5    ████████  8.3
  gpt-5.6-sol      ████████  8.0
  gemini-3.6-flash ██████    6.5

多轮上下文（15 题）
  gpt-5.6-sol      ████████████  11.7
  claude-opus-5    ███████████   10.8
  gemini-3.6-flash ████████      8.4

核心对比表：

模型	算法实现 (15)	多文件重构 (10)	多轮上下文 (15)	总分 (40)	排名
claude-opus-5	13.5	8.3	10.8	32.6	🥇
gpt-5.6-sol	12.8	8.0	11.7	32.5	🥈
gemini-3.6-flash	11.2	6.5	8.4	26.1	🥉

总分差距极小（0.1 分），但分布完全不同——这才是有意思的地方。

多轮上下文：宣传 vs 实测

Anthropic 博客提到了 structured prompting 与 multi-turn memory management 的组合收益。我拆开看了下：

前 3 轮对话：claude-opus-5 确实表现突出，结构化记忆在短链里效果明显，约束回忆准确率约 93%。

第 4–6 轮：三者差距缩小，gpt-5.6-sol 开始追上来。

第 7–8 轮：claude-opus-5 出现了一个我没预料到的问题——它会"过度遵守"早期约束，导致后续合理的需求变更被拒绝。gpt-5.6-sol 在这个阶段反而更灵活。

实际报错示例（第 7 轮，claude-opus-5）：

I notice this conflicts with the constraint established
in turn 1 where you specified "all state must be
immutable". I'll maintain that constraint rather than
implementing the mutable cache you're requesting.

它太"记性好"了，好到有点死板。这在需要迭代推翻早期决策的重构场景里反而是负分。

gpt-5.6-sol 在多轮对话中表现更灵活，但我也观察到它在单轮 reasoning 链较长时偶尔出现推理质量下降的情况，具体机制尚不明确，在多轮场景下因每轮 reasoning 链条被自然截断，影响相对有限。

成本对比

这 40 道题跑完，三个模型的实际 Token 消耗（通过 ofox.io 后台按 model 维度导出）：

模型	总输入 Token	总输出 Token	相对费用
claude-opus-5	~890K	~420K	最高（基准）
gpt-5.6-sol	~760K	~380K	中等
gemini-3.6-flash	~820K	~350K	明显更低

⚠️ 费用说明：截至测试时，三个模型的官方定价均未完全公开（claude-opus-5 刚发布，另两个模型的实际扣费情况不确定是否为公测价）。表中"相对费用"仅反映后台实际扣费的比例关系，不代表官方正式定价。根据后台记录，gemini-3.6-flash 的实际扣费约为 claude-opus-5 的 1/5 左右，但此数字可能随正式定价发布而变化，请以官方最终价格为准。

调用方式

三个模型我都是通过同一个 base_url 调的，省得维护三套 Key：

from openai import OpenAI

client = OpenAI(
    api_key="your-key",
    base_url="https://api.ofox.io/v1"
)

切模型只需要改 model 参数：

# Claude Opus 5
resp = client.chat.completions.create(
    model="claude-opus-4.8",
    messages=messages
)

# GPT-5.6 Sol
resp = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=messages
)

# Gemini 3.5 Flash
resp = client.chat.completions.create(
    model="gemini-3.5-flash",
    messages=messages
)

聚合 API 可以选 OpenRouter、Together AI、ofox.io 这类。跑评测时一个入口切三家确实省事，不然光管 Key 就够烦的。

不同需求怎么选

你的场景	推荐	原因
单次算法生成、竞赛题	claude-opus-5	单轮正确率最高
6 轮以上迭代重构	gpt-5.6-sol	多轮灵活性更好，不会"过度遵守"早期约束
高频调用、成本敏感	gemini-3.6-flash	实测费用约为 Opus 的 1/5，及格率约 75%
跨文件重构（本文"多文件重构"维度）	claude-opus-5 或 gpt-5.6-sol	两者本测试得分差 0.3 分，差距极小
Claude Code / Cline 日常写码	gemini-3.6-flash 做初稿 + opus-5 做 review	省钱又保质量

context engineering 是什么

Anthropic 这次把 context engineering 包装成了一个新范式，核心机制大致包括两点：

1. 结构化的 system prompt 模板（Skills 文件形式），将约束、角色、工具描述分层组织
2. 上下文压缩 + 关键约束标记，在长对话中主动保留高优先级约束，压缩低信息密度内容

从公开的 Claude Code 相关技术文档和社区讨论来看，类似机制在 Claude Code 内部早有应用，opus-5 将其暴露为用户可控的 API 参数。

我的测试最多到 8 轮，更长对话（20+ 轮）下这套机制是否仍有优势还没验证过。如果有人跑过更极端的 case，欢迎评论区交流。

已知工程问题

选型不能只看 benchmark，工程稳定性也得考虑。以下是我在测试中实际遇到的问题，不含未经核实的第三方 issue 引用：

• claude-opus-5：在 IDE 集成（Cline 插件）中偶尔出现流式输出中断，需重试；"过度遵守"早期约束的行为在长对话重构中是实质性障碍
• gpt-5.6-sol：在单轮 reasoning 链较长时偶尔出现推理质量下降，多轮场景下影响有限（原因见上文）
• gemini-3.6-flash：测试期间遇到 2 次 timeout，P95 延迟约 280ms，偶尔飙到 1200ms 以上

小结

claude-opus-5 综合实力确实是当前最强，但优势没有官方宣传的那么大。gpt-5.6-sol 在多轮迭代场景下是个被低估的选手。gemini-3.6-flash 是成本敏感场景的实用选择——约 75% 的能力只花约 20% 的钱（基于后台实际扣费比例，正式定价待官方公布），批量任务拿它打底完全够用。

官方宣传的性能提升数字，落到我的 40 道真题里，实际体感增益有限。营销归营销，还是得自己跑数据。分享给同样在纠结选型的朋友。

---

测试环境：Python 3.12，通过统一网关调用，温度 0.3，max_tokens 4096。所有评分为作者个人实测，不构成官方 benchmark。