Codex上架GPT5.5，搭配gpt-image-2，形成全新的开发工作流，OpenAI—雪前耻
今天一早赶去深圳的路上，手机弹出推送：GPT-5.5 正式上线了。距离 Anthropic 发布 Claude Opus 4.7 才过去八天，AI 领域的顶级对决，已经快得让人喘不过气。
先说结论：它不是全线碾压，是在最贵的那条链路上拉开了
OpenAI 这次给 GPT-5.5 的定位很明确：「面向真实工作和智能体（Agent）的新型智能」。翻译一下就是，它不再满足于做一个更聪明的聊天机器人，而是要成为一个能真正把复杂任务从头到尾执行到底的「引擎」。
这个定位，在 Terminal-Bench 2.0 这个基准测试上体现得淋漓尽致。这个测试不考单轮问答，而是给模型一个终端环境和模糊目标，让它自己规划步骤、调用工具、编写脚本、处理报错、反复调试，直到任务完成为止。这才是对「执行力」的真正考验。
| 基准测试 | GPT-5.5 | GPT-5.4 | Claude Opus 4.7 | Gemini 3.1 |
|---|---|---|---|---|
| Terminal-Bench 2.0 | 82.7% | 75.1% | 69.4% | 68.5% |
| SWE-Bench Pro | 58.6% | 57.7% | 64.3% ⚠️ | — |
| Expert-SWE | 73.1% | 68.5% | — | — |
| GDPval（知识工作） | 84.9% | 83.0% | 80.3% | 67.3% |
| MRCR v2（1M上下文） | 74.0% | 36.6% | 32.2% | — |
| FrontierMath Tier 4 | 35.4% | 27.1% | 22.9% | 38.0% |
| BrowseComp | 84.4% | — | 90.1% | — |
| CyberGym | 81.8% | 79.0% | 73.1% | — |
⚠️ 注：关于 SWE-Bench Pro 中 Claude Opus 4.7 的数据，OpenAI 和 Anthropic 均承认存在记忆污染（memorization）问题，横向对比时需要谨慎看待。数据来源：OpenAI 官方博客及 Artificial Analysis。
所以结论很清晰：在需要连续工作数小时、自主规划迭代的「长链路」复杂任务上，GPT-5.5 是目前最强的。但如果你主要用它来修复 GitHub 上的单点问题，Opus 4.7 在这个细分领域依然保持着竞争力。
四组数据，以及它们真正意味着什么
长上下文：这是最夸张的一块
在 OpenAI 的 MRCR v2 测试中（针对512K到1M超长上下文），GPT-5.5 拿到了74.0%的分数，而 GPT-5.4 是36.6%，Claude Opus 4.7 是32.2%。一代之内，性能翻倍，同时将竞争对手甩开了一个数量级。
更惊人的是 Graphwalks BFS 测试（在超长上下文中进行图遍历），GPT-5.5 达到了45.4%，GPT-5.4 仅为9.4%——差距高达五倍。
过去两年，超长上下文一直是 Gemini 的护城河。而 GPT-5.5 首次将百万级别上下文窗口的实用性，提升到了与其强大编程能力相匹配的水平。
知识工作：84.9% vs 67.3%，差距比你想的大
GDPval 测试评估了 AI 在44种职业中完成规范化知识工作的水平。GPT-5.5 得分84.9%，而 Gemini 3.1 Pro 为67.3%，两者相差17个百分点。
OpenAI 在官方博客中披露了三个内部用例：
- 公关团队分析六个月的演讲邀约数据，搭建评分与风险框架，低风险请求交由 Slack AI 智能体自动处理；
- 财务团队审核24,771份 K-1 税表，共计71,637页，比去年提前两周完成；
- 市场团队实现每周报告自动生成，每周节省5到10小时。
这三个案例有一个共同点：它们不再是简单的「帮我写段代码」，而是「帮我把这个现实工作流从头到尾推进并完成」。
一个容易被忽略的推理效率细节
由 GPT-5.5 驱动的 Codex 系统，分析了数周的生产流量数据后，自行编写了一套自适应的分区启发式算法，替换了原有的固定分块负载均衡策略。结果是：token 生成速度提升了超过20%。
简单说，模型参与优化了运行它自己的基础设施。
最终的表现是——GPT-5.5 的逐 token 响应延迟与 GPT-5.4 相当，但完成同类 Codex 任务所消耗的 token 更少。变得更强，却没有更慢，这并非单纯依靠堆砌算力，而是让模型本身参与了系统设计。
Codex × gpt-image-2：从「图像生成」到「图像是中间工件」
4月21日发布的 gpt-image-2，其最大突破是基本解决了 AI 绘图中的「文字渲染」难题。
随着 GPT-5.5 上线，Codex IDE 中内置的图像生成功能已切换至 gpt-image-2。编辑器内支持 $imagegen 指令，可直接生成或修改 UI 素材、布局、精灵表等。
这催生了全新的开发工作流。
第一层：图像驱动开发，这是工作流的变化
X 用户 @RijnHartman 分享了一个案例：在 Codex 中开启 extra high + fast 模式，上传一张由 gpt-image-2 生成的参考图，仅用12分钟就生成了一套完整的 UI 界面代码。这不再是「AI 生图」，而是「将图像作为中间工件来驱动代码生成」。
过去的流程是：撰写需求 → 使用 Cursor 或 Claude Code 生成代码 → 手动调整 UI。
现在的流程可以是：gpt-image-2 生成设计稿（Mockup）→ GPT-5.5 识图并实现代码 → 截图反馈 → GPT-5.5 迭代修改。图像变成了代码生成的输入，而非最终输出。
第二层：GPT-5.5 从零开始设计 UI 视觉，这里有个坑
有开发者反馈：「GPT-5.5 在延伸我现有网站的设计风格时非常得心应手」，但「如果让它从零开始设计前端 UI 视觉，效果仍然不理想，不够美观」。
这是真实的经验之谈，也点明了使用 gpt-image-2 的核心理由。GPT-5.5 的代码实现能力虽强，但其「审美出发点」仍有局限。直接让它进行原创设计，产出物往往会偏向工程风格，而非设计风格。
第三层：当前最优的起手工作流
结合社区目前的实测反馈，最优的工作流大致如下：
gpt-image-2 生成设计稿（Mockup）→ GPT-5.5 读图并实现代码 → 通过 Computer Use 功能截图验证 → 迭代直至交付。
这条流程目前能够跑通从「设计稿到可交付代码」的完整闭环，中途无需切换到 Figma 或其他独立的图像工具。
⚠️ 必须指出的工程问题：gpt-image-2 目前不支持透明背景（Alpha 通道），生成的 PNG 文件缺乏正确的透明度值。如果你的项目需要 UI 素材、游戏精灵图、品牌图层等对透明度有要求的资源，目前仍需借助 remove.bg 或 Photoshop 进行后处理，无法指望模型一步到位。
GPT-5.5 输在哪里？
三条明确的弱项
BrowseComp（在线研究）：
MCP Atlas（工具协议能力）：
API 首日不开放：
划重点：这个数字在 System Card 里，OpenAI 没放在正文博客
Apollo Research 进行了一项「不可能编码任务」实验：给模型一个实际上无解的编程任务（例如，要求它使用某个 API 中不存在的参数来实现功能），观察它是否会谎称「已完成」。
数据显示，面对此类任务，GPT-5.5 有接近三分之一的概率会报告「完成」。生成的代码看起来合理，但实际上无法运行，或者悄悄替换了实现方式。
这绝非小事。在 Codex 工作流中，最好引入另一个智能体进行反向审核，不能完全相信「已完成」的状态报告。相比之下，Claude Code 那种鼓励用户随时打断、查看中间状态的设计，在面对这类数据时反而显露出其设计优势。
定价翻倍，但账不是这么算的
GPT-5.5 API 定价如下：
- GPT-5.4 输入：$2.5 / 1M tokens；GPT-5.5 输入：$5 / 1M tokens（上涨2倍）
- GPT-5.4 输出：$15 / 1M tokens；GPT-5.5 输出：$30 / 1M tokens（上涨2倍）
- GPT-5.5 Pro 输入：$30 / 1M tokens；输出：$180 / 1M tokens
拉长时间线看：去年8月 GPT-5 的输入定价是 $1.25 / 1M tokens，如今 GPT-5.5 是 $5 / 1M tokens，八个月内上涨了4倍。
OpenAI 对此的解释是 token 效率的提升。第三方数据显示，在达到同等智能水平时，GPT-5.5 完成任务所消耗的 token 总量大约是 Claude Opus 4.7 的一半。因此，「单价更贵，但单任务总成本未必更高」这种说法，并不完全是营销话术，确有数据支撑。
三大顶流AI模型，该怎么选？
目前的格局已然清晰：GPT-5.5 是执行引擎，Opus 4.7 是高级代码审稿人，Gemini 3.1 是超长上下文容器。
根据任务链路进行分层选择是更明智的策略：
- → GPT-5.5 + Codex；
多步骤智能体任务、端到端的工程流程
- → Claude Opus 4.7；
困难的 GitHub Issue 修复、严格的代码审查
- → Gemini 3.1。
海量文档检索、超长上下文推理与分析
不得不说，当前的竞争态势瞬息万变。OpenAI 凭借 GPT-5.5 在核心执行力上的突破，无疑扳回了一局。未来的选择，将更取决于你具体的工作流需求，而非盲目追随单一模型。
