OpenAI GPT-5.5 编码模型：Codex 测试

简而言之：OpenAI GPT-5.5 编码模型感觉与众不同

OpenAI GPT-5.5 编码模型是 Codex 许久以来首次不仅仅在原始能力上取得提升的升级版本。根据我的经验，我在真实的缺陷修复中对其进行了测试，其主要区别在于控制力：它能进行更有针对性的更改，编辑更少的无关代码，并且通常只需一个提示词就能解决范围明确的问题。

OpenAI 于 2026 年 4 月 23 日发布了 GPT-5.5，官方发布将其定位为该公司迄今为止最强大的代理式（agentic）编码模型。这是一个宏大的声明，但与实际操作感受相符。OpenAI GPT-5.5 编码模型不仅仅是编写更多代码。它似乎更擅长理解哪些内容不应更改。这正是最让我印象深刻的地方。最好的编码代理并非那些生成最大补丁的模型，而是那些既能解决问题又能保持系统其余部分稳定的模型。

OpenAI 官方公告内容

OpenAI 将 GPT-5.5 描述为一种面向复杂现实世界工作的模型：编写和调试代码、在线研究、分析数据、创建文档和电子表格、操作软件，并在不同工具间切换直至任务完成。

据 OpenAI 称，该模型能更快地理解意图，在 Codex 任务中使用更少的 token，并且在现实世界服务中与 GPT-5.4 保持相同的每 token 延迟。

Codex 用户的可用性

对于开发者而言，关键的可用性详情如下：

重要的细微差别在于：本文讨论的是 OpenAI GPT-5.5 编码模型目前在 Codex 中的工作方式，而非完整的 API 迁移计划。

来源：OpenAI, Introducing GPT-5.5。

OpenAI GPT-5.5 编码模型基准测试

OpenAI 发布了三项与编码相关且对开发者至关重要的结果：

为何 Terminal-Bench 很重要

Terminal-Bench 2.0 的分数是代理式编码最清晰的公共信号。Terminal-Bench 测试的是命令行工作流，模型需要在其中进行规划、运行命令、协调工具并迭代以达成结果。这与现代编码代理的实际使用方式高度吻合。

对于 OpenAI GPT-5.5 编码模型而言，在 Terminal-Bench 2.0 上取得的 82.7% 是引人注目的数字。它在 OpenAI 的表格中远超 GPT-5.4，也领先于 OpenAI 列出的 Claude 和 Gemini 分数。

为何需谨慎看待 SWE-Bench

SWE-Bench Pro 仍然有用，但需要谨慎对待。OpenAI 自己也指出，实验室已发现该评估中存在记忆化（memorization）的证据。这并不意味着分数毫无价值，但这确实意味着我不应仅凭 SWE-Bench 来评判整个模型。

Expert-SWE 是内部测试，因此我将其视为 OpenAI 自身的信号，而非独立可复现的排行榜。不过，这一趋势与我的实际测试一致：OpenAI GPT-5.5 编码模型在需要上下文、克制和验证的长周期工程任务中表现更强。

其他开发者的看法

我发现的外部反应与我自己的测试结果一致。CodeRabbit 的早期基准测试报告称，GPT-5.5 在审查工作流中更快、更精简、更直接。他们的实际结论是，该模型产生了更好的审查信号，在其策划的测试中发现了更多有用的问题，且精度更高。

这与我的观察相符：当任务具体时，OpenAI GPT-5.5 编码模型的噪音更少。

CodeRabbit 报告了这些早期审查指标：

来源：CodeRabbit GPT-5.5 benchmark report。

Matt Shumer 的评论也指向同一方向：GPT-5.5 在处理令人烦恼、模糊不清、涉及安全敏感、受设计约束或可能以微妙方式出错的任务时表现最强。他的核心观点是，前沿编码模型已经非常强大，因此改进在最艰难、最混乱的工作中体现得最为明显。

来源：Matt Shumer, My GPT-5.5 Review。

这正是我关心的开发者用例。不是玩具示例，不是单文件演示，而是具有现有约定、奇怪边缘情况且无关变更成本高昂的真实代码库。

我在 Codex 中的实际体验

我在那些通常会暴露模型弱点的工作中测试了 OpenAI GPT-5.5 编码模型：修复审查发现、在不干扰相邻系统的情况下更改一种行为、保持 SEO/管理流程的一致性，以及验证结果而不是停留在看似合理的补丁上。

最大的改进在于控制力。旧的编码模型通常会解决可见的问题，但会创建不必要的周围变更。它们可能会重命名过多内容、过度重构，或者将一个小 bug 修复变成更广泛的重构。

GPT-5.5 感觉更有纪律。它仍然会犯错，但它更有可能触及正确的文件，保留现有风格，并在问题真正解决后停止。

关键行为

大多数生产工作并非从零开始的编码。大多数生产工作是受限编辑。一个好的编码模型应该做到以下五点：

OpenAI GPT-5.5 编码模型并非完美，但在这种模式上明显更好。

“一次提示修复”正成为现实

“一次提示”这个词听起来可能像炒作，所以我想精确一点。我的意思并不是说每个严肃的工程任务都应该用一条懒惰的指令来解决。我的意思是，当提示词包含问题、验收标准和相关约束时，GPT-5.5 通常能一次性完成任务，而无需反复纠正。

这与早期的工作流程不同，早期你需要先要求修复，然后要求它撤销无关更改，接着要求它运行测试，再要求它缩小补丁范围，最后要求它解释为何行为发生了改变。

一次提示成功是什么样子的

使用 OpenAI GPT-5.5 编码模型时，我看到了更多首次尝试就已形状正确的情况：

这就是它感觉稳健的原因。该模型不仅能力更强，而且更不混乱。

为何针对性更改优于大规模重写

对于编码代理而言，原始智力只有一半的问题，另一半是克制。一个为了修复 20 行问题而更改 800 行代码的模型，在演示中可能看起来令人印象深刻，但在真实仓库中会变得昂贵。每一个不必要的更改都会增加审查时间、测试风险、合并冲突风险以及未来的调试成本。

OpenAI GPT-5.5 编码模型似乎更擅长局部推理。它可以检查周围系统，而不会感到必须重写它。这使得它适用于：

这也是 Terminal-Bench 等基准测试重要的原因。编码代理必须能够完成一个过程，而不仅仅是生成一个函数。它需要使用工具、解释结果、进行调整并避免制造混乱。

我仍会谨慎的地方

GPT-5.5 令人印象深刻，但我不会将其视为魔法。首先，基准测试不等于你的代码库。Terminal-Bench 和 SWE-Bench 是有用的信号，但你的仓库拥有本地约定、隐藏的产品决策、旧的迁移、环境怪癖，以及可能无法捕捉真正风险的测试。

其次，API 在发布时不可用。如果你的生产自动化依赖于直接 API 访问，那么在 OpenAI 在 API 中开放 gpt-5.5 之前，当前的实际路径是 Codex 或 ChatGPT。

第三，更强的编码能力增加了对更好工具链的需求。一个没有测试、类型契约、沙箱和审查纪律的强大模型，仍然可能更快地发布错误的东西。

第四，OpenAI 的系统卡（System Card）包含了大量关于计算机使用、网络、生物、幻觉和对齐的安全性评估。这很重要，因为一个更强大的编码模型也可能执行更敏感的操作。请认真对待权限、密钥、破坏性命令和生产访问。

来源：OpenAI GPT-5.5 System Card。

我推荐的 GPT-5.5 编码工作流

为了获得最佳效果，我会少把 GPT-5.5 当作自动补全，多把它当作一个专注的工程代理。

像工程师一样提示它

给它提供：

一个强有力的提示词是这样的： “用最小的安全补丁修复此问题。保留现有的路由契约，不要重构无关代码，并在总结前运行相关的类型/ lint/构建检查。如果修复需要更广泛的更改，请在编辑前解释原因。”

这种提示词非常适合 OpenAI GPT-5.5 编码模型，因为该模型似乎擅长在整个任务中贯彻约束。

那么，OpenAI GPT-5.5 编码模型值得使用吗？

值得。对于真实的 Codex 工作而言，OpenAI GPT-5.5 编码模型是我测试过的最令人印象深刻的编码模型升级之一。基准测试的故事很强，尤其是 Terminal-Bench 2.0。外部评论也指向同样的实际模式：更直接、更可控、信号更好。

我自己的经历也证实了这一点。GPT-5.5 感觉更稳健，进行的更改更有针对性，围绕修复的无关代码更改更少，并且通常只需一个范围明确的提示词就能解决问题。

这才是开发者真正能感受到的进步。不是因为它写出了更炫酷的代码，而是因为它在代码写完后减少了清理工作。

来源