GPT-5.5 vs GPT-5.4 vs Opus 4.7：56 个来自 2 个开源仓库的真实编码任务

Opus 4.7 写出的补丁更小。GPT-5.5 写出的补丁更常经得起代码审查。你想要哪一个，取决于在你的仓库里，“小”意味着有纪律，还是意味着不完整。

我在来自两个开源仓库的 56 个真实编码任务上运行了这两个模型，以及 GPT-5.4：27 个任务来自 Zod，29 个来自 graphql-go-tools（这些代码库是任意选择的，可能不代表你的体验——而这正是运行你自己的基准测试很重要的原因！）每个模型都在自己的原生 agent harness 中以默认设置运行：Anthropic 模型在 Claude Code 中，OpenAI 模型在 OpenAI Codex CLI 中。

结果并不是“一个模型赢下一切”。在这些运行中，GPT-5.5 是最好的发布默认选择。这里说的“发布”，指的是我最常会信任这个模型产出一个能够通过测试、匹配预期人类变更、并经得起代码审查的补丁。Opus 4.7 仍然在做一件有价值的事：它写出的补丁小得多。

在 Zod 上，这看起来像一个真实的取舍。在 graphql-go-tools 上，它更像是实现不足。

GPT-5.5 更常能发布。Opus 4.7 发布时更小。你的仓库里谁胜出，取决于你的瓶颈是审查，还是 footprint。

这个区别正是仓库特定 eval 重要的原因。公共基准测试会把模型行为压平成一个在巨大规模上聚合的数字。真实代码则会把它变成针对你的特定代码库和标准的工作流决策。

我使用了 Stet，一个我正在为真实仓库编码 agent 基准测试构建的评估框架，来评分不止测试通过/失败：相对于人类补丁的行为等价性、代码审查可接受性、footprint risk，以及 craft/discipline rubrics。这篇文章并不是关于所有编码任务的断言。它是对三个前沿模型在两个真实代码库上行为方式的具体观察。

简短版本

GPT-5.5 是质量领先者。它通过的测试最多，最常匹配人类补丁，并且通过审查者的频率大约是 Opus 的三倍。

Opus 是 footprint 领先者。按照 Stet 的 footprint 模型，它的补丁更小，风险更低。但只有完整的小补丁才是好补丁。Opus 反复出现的失败模式是通过可见测试，却漏掉人类 PR 中包含的配套工作。

GPT-5.5 也是 token 和挂钟时间上的效率领先者。相比两个竞争者，它每个任务使用的输入 token 更少、输出 token 更少、平均 agent 时间也更短。GPT-5.4 仍然是单任务成本领先者，因为它的定价更低，但在这些运行中，成本优势没有抵消 clean-pass 差距。

按仓库拆分时，结果开始变得有意思：

在 Zod 上，GPT-5.5 和 Opus 在测试上打平。GPT-5.5 赢在审查者判断。Opus 赢在 diff 大小。

在 graphql-go-tools 上，GPT-5.5 直接胜出。它通过更多测试，产生多得多的 clean pass，并且更接近人类补丁。Opus 仍然写出最小的补丁，但这种小补丁策略漏掉了太多东西。

完整记分卡

质量分数行的作用，是避免把“通过更多测试”当成全部故事。代码审查是其中一个 grader：在可用时评估正确性、引入 bug 的风险和可维护性。Custom grader 平均分是另一层：八个附加 rubric，分成五个 craft 维度和三个 discipline 维度。跨这两层看，GPT-5.5 并不只是抽象意义上更受偏好。相对于请求的任务，它在正确性、更低的引入 bug 风险、GraphQL 可维护性、连贯性、鲁棒性、范围纪律和 diff minimality 上评分更高。Opus 仍然赢下机械 footprint 这一行，这就是有用的张力：diff 更小，但并不稳定地更有纪律。

基准测试如何运作

每个任务都来自一个真实合并的 commit。模型会拿到一个冻结的仓库快照、一个描述变更的 prompt，并有一次机会产出补丁——它运行在自己的原生已发布 agent harness 中，没有 Stet 侧脚手架：Opus 4.7 在 Claude Code 中运行（claude -p）；GPT-5.5 和 GPT-5.4 在 OpenAI Codex CLI 中运行（codex exec）；两者都使用默认设置。Stet 应用补丁，并在隔离容器中运行该任务的测试。

然后 Stet 会在通过/失败之外继续评分：

• 测试： 补丁是否满足可执行的验收测试？
• 等价性： 候选补丁是否完成了与原始人类补丁相同的行为变更？
• 代码审查： 考虑正确性、引入 bug 的风险、可维护性和边界情况，审查者会接受这个补丁吗？
• Footprint risk： 这个补丁创建了多少审查和回归表面？
• Craft/discipline rubrics： 清晰性、简单性、连贯性、意图性、鲁棒性、指令遵循、范围纪律和 diff minimality。

每个模型在每个任务上用单一 seed 运行一次。等价性和 rubrics 的 judge 模型是 GPT-5.4，三个实验臂使用完全相同的 rubric 版本。每个补丁都是独立评分的——judge 看到的是补丁和任务，而不是实验臂标签，也不是产出它的模型。这里没有双评审者校准，所以绝对分数应当按方向性理解；跨实验臂的差值才是值得信任的部分。

GPT-5.5 拉大了差距

在这两个仓库上，GPT-5.5 对编码 agent 工作来说优于 GPT-5.4。简短版本并不只是 GPT-5.5 通过了更多测试。它还产出了更多与人类等价的补丁、更多被审查者接受的补丁，以及更多 clean pass。

这个基准测试给出的实际答案是：GPT-5.5 更可发布，而 GPT-5.4 单任务更便宜。GPT-5.4 仍然可以是一个合理的成本控制选择，但质量差距大到让我不会把它作为这些仓库的默认发布模型。

测试是信号，不是终点

表格里最有用的行不是测试。它是 clean pass：测试通过，并且代码审查 grader 接受补丁。

在 Zod 上，Opus 和 GPT-5.5 都通过了 27 个已评分任务中的 12 个。如果你停在那里，两个模型看起来打平。但 GPT-5.5 产生了 10 个 clean pass；Opus 产生了 5 个。

在 graphql-go-tools 上，同样的模式被放大了。GPT-5.5 通过了 29 个测试中的 26 个，并产生了 18 个 clean pass。Opus 通过了 21 个测试，但只产生了 5 个 clean pass。

这就是你会在代码审查中感受到的差距。测试说：“这个补丁大概能工作。”审查者问：“这是我们想要维护的补丁吗？”

一个 GraphQL 任务展示了这种差异。PR #1001 修改了 HTTP datasource 的 OnFinished hook，让消费者能够检查请求和响应元数据。三个模型都通过了测试，并被判为等价。只有 GPT-5.5 通过了代码审查。另外两个围绕 API 形状、原始 HTTP 对象暴露以及 hook 边界处的鲁棒性收到了警告。

这不是基准测试技巧；相反，这反映了正常的工程文化：代码会被审查，三个补丁可以满足同一个测试，却在审查质量上有实质差异。你只想合并高质量且可维护的代码，即使它在技术上能工作。

审查者看到了什么

代码审查和 craft/discipline 行解释了为什么结果不能简化成“GPT-5.5 改了更多文件”。两个补丁验尸让这些数字不那么抽象。

Zod 异步 codecs 和 defaults。 这个任务是让 codec pipelines 能够配合 async transforms 工作，防止 defaults 变成 undefined，并为构建生成 stub package manifests。三个模型都没有通过测试。如果你只看测试行，这个任务什么也告诉不了你。

审查者在底下发现了真实排序。Opus 修改了 8 个文件，并漏掉了核心语义：defaults 仍然可能允许 undefined，核心 codec 定义仍然是同步的，生成的 stubs 没有发布，而且 prefault() 被收紧了，尽管请求说的是 .default()。GPT-5.4 用 11 个文件的补丁更接近，并被判为行为等价，但它仍然通过限制 prefault 过度收紧了相邻 API。GPT-5.5 也没有通过测试，但它被判为等价，并在正确性和引入 bug 风险上得分更高，因为它更干净地覆盖了 schema/build 行为：codec/default 测试、版本元数据、stub-manifest 脚本，以及相关的 packages/zod/src/v4/*/schemas.ts 表面。

这是不同于通过/失败的另一种信号。它说明 GPT-5.5 并不只是测试运气更好；即使在一次失败中，它也更常移动正确的部件。

GraphQL Apollo 兼容验证。 PR #1169 让字段选择验证错误与 GraphQL spec 和 Apollo Router 约定保持一致。三个模型都产出了补丁。三个都通过了测试。只有 GPT-5.5 通过了等价性和审查。

Opus 触及 11 个文件并通过了测试，但漏掉了 enum 和 wrapped-scalar leaf validation，把一些 leaf-selection 位置指向了字段而不是 selection set，留下了一个不符合 spec 的 inline-fragment 消息，并且没有统一应用 validation status。GPT-5.4 触及 12 个文件，也通过了测试，但在错误的地方拓宽了行为：无条件 validation metadata、不完整的 enum/wrapped scalar 处理、过宽的 request-error 转换，以及过期的 compatibility API。

GPT-5.5 触及的文件比两者都少，总共 10 个，其中 6 个非测试文件，同时仍然加入了更有针对性的行为：对齐的 field-selection 消息、请求的位置，以及集中的 Apollo validation metadata。这是干净的审查者示例：测试看到的是三个通过；语义评分看到的是一个真正匹配该 PR 想要建立的约定的补丁。

这就是分数行试图概括的东西。GPT-5.5 最大的审查领先项是正确性：3.16，对比 GPT-5.4 的 2.60 和 Opus 的 2.11。Custom graders 从另一个角度说了同一件事：GPT-5.5 领先于连贯性和鲁棒性，因为它的补丁更常把变更贯穿到仓库的既有表面，而不是停在第一个能通过的路径上。

Discipline 行是我不会过度宣称的一行。GPT-5.5 领先，但领先很窄：2.36，对比 Opus 的 2.20 和 GPT-5.4 的 2.16。Opus 赢下原始 footprint。GPT-5.5 小幅赢下相对于任务的 discipline。Grader 在区分“小”和“范围恰当”。如果一个补丁在任务完成前就停下了，它可以很紧凑，但仍然没有纪律。

Opus 在做什么

Opus 4.7 很谨慎。它写出的补丁更小，触及的文件更少，并且在两个仓库中都有最低的 footprint risk。

在 Zod 上，这种谨慎经常很有吸引力。Zod 有很多边界清晰的任务，正确做法就是一次精确的源代码编辑、一个类型变更，也许再加一个小测试更新。Opus 在测试上追平 GPT-5.5，同时保持了更低的补丁 footprint。

但 Opus 的克制有一个反复出现的失败模式：它实现标题行为，然后在配套工作完成前停下。

Zod 让这一点很容易看清。Zod 有并行的 Node 和 Deno 树。测试会覆盖主 src/ 路径，所以一个补丁可以通过测试，同时让 Deno mirrors 过期。在几个 Opus 测试通过但不等价的任务上，实际发生的正是这种情况。一个 CIDR validation 变更在 Opus 触及四个文件后通过了测试。GPT-5.5 触及十一个文件，因为它也更新了并行分发表面。Judge 标记 Opus 不等价，因为人类补丁完成了配套工作。

同样的行为在 graphql-go-tools 上看起来更糟。那个仓库是一个 Go federation engine，planner、datasource、hook、validation 和 runtime 路径都需要对齐。如果真实变更跨越了多个 engine 表面，一个最小补丁是不够的。

在 PR #1155 上，任务覆盖了 gRPC datasource 中的 repeated scalar fields、request building、response marshaling、null 和 invalid responses、error status information、disabled datasources，以及动态创建的 clients。Opus 没有产出补丁。GPT-5.5 通过了测试，匹配了人类补丁，并通过了审查。

这就是关键区别：Opus 的小补丁在局部任务上可以是纪律，在集成繁重的任务上可能是实现不足。

从 GPT-5.4 到 GPT-5.5 发生了什么变化

GPT-5.5 不只是通过率更高的 GPT-5.4。失败模式发生了转移。

GPT-5.4 经常看到了大体正确的做法，但执行失败。在 Zod 上，它有 18 个等价性 yes 判断，与 GPT-5.5 持平，但只有 9 个测试通过。等价性 grader 识别出了预期行为；可执行验证仍然失败。

GPT-5.5 缩小了这个差距。它保留了更多广泛的集成行为，同时产出更少破损补丁。

三个 Zod 例子很有用。

首先，一个 schema-to-TypeScript 生成器。任务要求对 Zod schema definitions 做递归 visitor。Opus 和 GPT-5.5 都识别出这是一个实现任务，并构建了 visitor。GPT-5.4 产出了仓库指令文件，而不是这个功能。这不是一个微妙的算法失误。它把工作分类错了。

其次，一个递归 parser 修复。两个 GPT 模型都采用了 visit-count tracking。GPT-5.4 添加了一个 inProgress sentinel 和 reset logic。GPT-5.5 保留了 count-and-cache-error 行为，并移除了额外状态。大体思路相同，移动部件更少，测试通过。

第三，CIDR validation。GPT-5.4 和 GPT-5.5 有相似的核心算法：按 / split，验证 address，验证 prefix。GPT-5.5 更新了 Deno mirrors。GPT-5.4 没有。这不是推理跃迁，而是仓库卫生。

在 graphql-go-tools 上，区别更偏操作层面。PR #1232 要求 deduplicate 相同的 single fetches，同时重写指向被移除重复项的 dependency references。一个补丁可以看起来合理，却仍然留下过期的 fetch dependencies。GPT-5.5 是唯一一个通过测试、匹配人类行为并通过审查的模型。

模式是：GPT-5.5 会做更多无聊的集成工作，把一个聪明的局部修复变成可发布的仓库变更。

做更多事的成本

GPT-5.5 写出的补丁比 Opus 更大。

在 graphql-go-tools 上，GPT-5.5 的平均补丁大小约为 33 KB，GPT-5.4 为 27 KB，Opus 为 19 KB。Footprint 分数也相应移动：Opus 0.19，GPT-5.4 0.32，GPT-5.5 0.34。

这不是免费的。更大的补丁更难审查，更容易冲突，也更可能触及敏感路径。如果你的工作流主要受可审计性支配，Opus 仍然有真实优势。

但 craft rubric 显示了为什么原始大小还不够。在 GraphQL 上，GPT-5.5 拥有最大的补丁，却仍然在相对于任务的 diff minimality 上小幅领先。Grader 问的不是“谁改了最少的字节？”它问的是“谁用解决实际请求所需的最少字节完成了工作？”

这个区别就是整个基准测试的缩影。一个漏掉必需表面的 5 KB 补丁，并不比一个完成工作的 20 KB 补丁更 minimal。

成本故事在两个仓库之间也发生了变化。在 Zod 上，Opus 和 GPT-5.5 的操作表现相似：Opus 使用了 53.0M 输入 token 和 359K 输出 token；GPT-5.5 使用了 50.4M 输入和 290K 输出。Opus 每个任务更快，4m25s 对 5m09s，并且略便宜，$1.69/任务 对 $1.73/任务。

GraphQL 则反了过来。Opus 使用了 186.1M 输入 token 和 934K 输出 token。GPT-5.5 使用了 151.4M 输入和 431K 输出。Opus 平均每个任务 17m43s；GPT-5.5 平均 8m36s。这看起来不像 Opus 在消极应付。它看起来像 Opus 工作更久、发出更多 token，却仍然收敛到更小、更不完整的补丁。

行为指标指向同一个方向。在 GraphQL 上，Opus 每个任务平均有 3.17 次显式 planning calls；GPT-5.5 平均为零。Opus 每个任务发起 10.2 次 patch calls；GPT-5.5 发起 9.9 次。Opus 并不是早早放弃。区别在于探索风格：GPT-5.5 发起了大约两倍的 shell calls 和更多 search calls，而 Opus 把更多预算花在 planning 和 patch rewrite churn 上。在这个仓库里，更广泛的仓库检查似乎比围绕更窄补丁的深思熟虑更重要。

每个模型的性格，用一段话概括

Opus 4.7——触达不足。 保守、精确、低 footprint。当任务是局部的、期望变更表面很窄时很强。当人类补丁包含测试没有完全覆盖的配套表面时较弱。它的失败模式经常是“测试通过，但这不是同一个变更。”

GPT-5.4——形状正确，执行错误。 方向上有能力，但不稳定。它经常找到预期形状，这就是为什么它的等价性数字还不错，但它更容易出现过期 mirrors、额外 bookkeeping、缺乏依据的 refactors，以及 judge 喜欢但测试套件不喜欢的补丁。

GPT-5.5——更宽、更大的 footprint。 在集成表面上更完整。它更可能更新周边代码、通过审查，并把预期行为转化成能通过的代码。它的风险是补丁 footprint：当它错的时候，可能会在更多文件上错。

为什么这很重要

实际问题不是“哪个模型最好？”

实际问题是：

对于这个仓库，在这个 harness 下，在我们实际发布的这类任务上，哪个模型产出的补丁值得我们信任？

答案会随仓库变化。

Zod 让 GPT-5.5 对 Opus 看起来像一种取舍：相同的测试通过数，GPT-5.5 有更好的审查者对齐，Opus 有更小的补丁。

graphql-go-tools 让这个取舍不再那么对称：在已测量任务上，GPT-5.5 明显更可发布，而 Opus 的小补丁优势伴随着太多漏掉的集成工作。

这就是为什么 Stet 围绕真实仓库任务构建，而不是围绕合成 prompts。你的仓库有自己的 mirror trees、codegen surfaces、测试盲点、hook conventions、planner invariants 和审查标准。你也有自己的 AGENTS.md、skills、model 和 harness settings，等等。正是这些细节决定一个模型的“性格”是资产还是负债。

注意事项

五十六个已评分任务仍然很少。一个任务的摆动就能让仓库级别的比例移动几个点。每个模型在每个任务上只运行一次。一些接近的判断在重跑时会翻转。

等价性和 rubric judge 是 GPT-5.4。这可能引入同族偏差。我不认为它能解释整个结果：GPT-5.5 明显击败 GPT-5.4，Opus 仍然赢下 footprint，而且许多 Opus 等价性失败都是具体漏掉文件或缺少配套表面。

结果也受 harness 条件影响。Claude Code 和 Codex CLI 带有不同的 system prompts、planning loops 和 tool surfaces，每个模型都运行在其供应商发布的 harness 中。通过 API 在 Codex 里运行 Opus 4.7，或者在 Claude Code 里运行 GPT-5.5，都会改变画面。这里的数字描述的是这些模型在真实工程师实际使用它们的 harness 中的表现，而不是孤立的模型本身。

结论

如果要概括这 56 个已评分任务：

• GPT-5.5 是这两个仓库中最好的默认发布模型。
• Opus 4.7 仍然是低 footprint 模型，并且在窄 diff 最重要时可能更适合。
• GPT-5.4 单任务更便宜，但成本上没有好到足以弥合这里的 clean-pass 差距。
• 只看测试会隐藏最重要的结果。
• 同一个模型排名会随仓库变化，而这正是重点。

有意思的模型 eval 不再是“模型能解决一个困难 prompt 吗？”而是“这个模型在我的代码库里倾向于产出什么样的补丁，而这是否匹配我的团队发布软件的方式？”

你的仓库不一样——这正是在你的工作上测量，而不是依赖公共基准测试的意义。这就是 Stet 的用途。