GPT-5对阵Claude Opus：编码能力全面对比

OpenAI 刚刚发布了 GPT-5。它基于 GPT 和 O-series 推理模型构建，旨在更快、更智能、更高效。我将它与 Anthropic 的 Claude Opus 4.1 进行了对比，看看哪一个在真实开发工作中能提供更多帮助。

本次对比中生成的所有代码都可以在这里找到：github.com/rohittcodes/gpt-5-vs-opus-4-1。

没有时间？这是结论：

算法题：GPT-5 在速度和 token 上获胜（8K vs 79K）

Web 开发：Opus 4.1 更好地匹配 Figma 设计，但消耗更多 token（900K vs 1.4M+ tokens）

总体而言，GPT-5 是更好的日常开发搭档（快速且便宜），与 Opus 4.1 相比节省约 90% 的 token。如果设计保真度很重要且预算灵活，Opus 4.1 表现出色。

成本：GPT-5（Thinking）约 $3.50 vs Opus 4.1（Thinking, Max）$7.58（约 2.3 倍）用于将 Figma 设计转换为代码。

Claude Opus 4.1 配备了 200K token 的上下文窗口。GPT-5 将其提升到 400K tokens，最大输出 128K。尽管有两倍的上下文空间，但 GPT-5 在完成相同工作时始终使用更少的 token，使其运行更具成本效益。

SWE-bench 结果显示 GPT-5 在编码基准上略领先 Opus 4.1，但基准不是全部。这就是为什么我在真实任务上测试了它们。

我如何测试这些模型

我在相同的挑战中运行了两个模型：

语言：Java 用于算法，TypeScript/React 用于构建 Web 应用

任务：

• 通过 Rube MCP - 通用 MCP 层，将 Figma 设计转换为 NextJS 代码（这是我们的新产品，试试吧，很棒）
• LeetCode 高级算法
• 客户流失预测模型管道

环境：带有 Rube MCP 集成的 Cursor IDE

衡量指标：Token 使用量、耗时、代码质量、实际结果

两个模型都收到了完全相同的 prompt 以保持公平。

Rube MCP - 通用 MCP 服务器

Rube MCP（由 Composio 提供）是 Figma、Jira、GitHub、Linear 等 MCP 工具包的通用连接层。探索工具包：docs.composio.dev/toolkits/introduction。

前往 rube.composio.dev。

点击"Add to Cursor"

在提示时安装 MCP 服务器并启用它。

1) 第一轮：Figma 设计克隆

我从 Figma Community 中挑选了一个复杂的仪表盘设计，要求两个模型都用 Next.js 和 TypeScript 重新创建。Figma 设计：链接。我使用了我们的通用 MCP，并将其转换为 HTML、CSS 和 Typescript。

Create a Figma design clone using the given Figma design as a reference: [FIGMA_URL]. Use Rube MCP's Figma toolkit for this task.
Try to make it as close as possible. Use Next.js with TypeScript. Include:
- Responsive design
- Proper component structure
- Styled-components or CSS modules
- Interactive elements

GPT-5 结果

GPT-5 在约 10 分钟内用 906,485 个 tokens 交付了一个可工作的 Next.js 应用。该应用运行良好，但视觉精度令人失望。它捕捉到了基本想法，但遗漏了大量设计细节、颜色、间距、排版，与原始设计明显不同。

成本：对输出而言合理

Claude Opus 4.1 结果

Opus 4.1 消耗了 1.4M+ tokens（比 GPT-5 多 55%），最初在 Tailwind 配置上卡住了，尽管我明确请求使用 styled-components。在我手动修复配置问题后，结果令人惊艳；UI 几乎完美匹配 Figma 设计。视觉保真度远超 GPT-5。

Tokens：1,400,000+（比 GPT-5 多约 55%）

耗时：由于更多迭代，耗时更长

Opus 4.1 提供了远更好的视觉保真度，但代价是更高的 token 消耗和一些手动设置。

2) 算法挑战

我向两个模型提出了经典的"两个有序数组的中位数"LeetCode 困难问题。这测试了数学推理和优化技能，复杂度要求为 O(log(m+n))。这对于这些模型来说根本不是一个困难的问题，很可能在训练数据中。我只想知道它们有多快以及在 token 方面有多高效。

For the below problem description and the example test cases try to solve the problem in Java. Focus on edge cases as well as time complexity:

Given two sorted arrays nums1 and nums2 of size m and n respectively, return the median of the two sorted arrays. The overall run time complexity should be O(log (m+n)).

Example 1:
Input: nums1 = [1,3], nums2 = [2]
Output: 2.00000

Example 2:
Input: nums1 = [1,2], nums2 = [3,4]
Output: 2.50000

Template Code:
class Solution {
    public double findMedianSortedArrays(int[] nums1, int[] nums2) {

    }
}

GPT-5 结果

直截了当。在 13 秒内使用了 8,253 个 tokens，交付了一个干净的 O(log(min(m,n))) 二分查找解决方案。适当的边界情况处理，最优时间复杂度。就是能工作。

Claude Opus 4.1 结果

更加彻底。在多个推理步骤中消耗了 78,920 个 tokens（比 GPT-5 多近 10 倍）。采取了一种有方法的方法，附带详细解释、综合注释和内置测试用例：相同算法，教育价值远更高。

Tokens：78,920（比 GPT-5 多约 10 倍，跨多个推理步骤）

两者都以最优方式解决了问题。GPT-5 使用的 tokens 大约少 90%。

3) ML/推理任务（和成本现实）

我计划了第三个更大的测试，围绕 ML 和推理：端到端构建客户流失预测管道。在看到 Opus 4.1 在 Web 应用上使用 1.4M+ tokens 后，由于成本原因，我跳过了在那里运行它。我确实运行了 GPT-5。

Build a complete ML pipeline for predicting customer churn, including:
1. Data preprocessing and cleaning
2. Feature engineering
3. Model selection and training
4. Evaluation and metrics
5. Explain the reasoning behind each step in detail

GPT-5 生成了一个可靠的、有效的管道：清洁的预处理、合理的特征工程；多个模型（逻辑回归、随机森林、可选的 XGBoost 随机搜索）；SMOTE 用于类平衡、通过 ROC-AUC 的最佳模型选择，以及彻底的评估（准确率、精度、召回、F1）。解释清楚而不冗长。

该测试的成本（真实数字）

GPT-5（Thinking）：总计约 $3.50 - Web 应用约 $2.58、算法约 $0.03、ML 约 $0.88。它没有 Opus-4.1 那么昂贵。

Opus 4.1（Thinking + Cursor 中的 Max 模式）：总计 $7.58 - Web 应用约 $7.15、算法约 $0.43。

两个模型都很好地利用了大型上下文窗口，但它们以不同方式消耗 tokens，因此产生了很大的成本差距。

在算法任务上减少约 90% 的 tokens

更快、更实用的日常工作

对大多数工作而言具成本效益

清晰、逐步的解释

在编码时学习是很好的

出色的设计保真度（非常接近 Figma）

当你能承受时进行深度分析

我的看法

使用 GPT-5 用于算法、原型和大多数日常工作；它更快且更便宜。当视觉精度真正重要时选择 Opus 4.1（面向客户的 UI、营销页面），且你能预算更多 tokens。实践流程：用 GPT-5 构建核心，然后用 Opus 4.1 来打磨关键屏幕。