Cursor 平台模型对比：DeepSeek V3/R1 对战 Claude 3.5 Sonnet 实测

DeepSeek 最新模型实测：V3 和 R1 对比 Claude 3.5 Sonnet，谁更胜一筹？

DeepSeek 近期在 Cursor 平台上线了他们的两款新模型：DeepSeek V3 和 R1。目前，许多开发者（包括我们）主要使用 Claude 3.5 Sonnet (最新版本 claude-3-5-sonnet-20241022) 作为主力语言模型。为了了解新模型的实际表现，我们决定对 DeepSeek 的这两款模型与 Claude 3.5 Sonnet 进行一次真刀真枪的对比测试。

DeepSeek 模型简介

DeepSeek 最近因为开源了其强大的 R1 模型而备受关注。R1 模型的各项性能指标号称可以媲美 OpenAI 的 o1 模型，这可不是一件容易的事。DeepSeek 官方发布的编程基准测试数据显示，R1 在大多数情况下，性能有望超越 Claude 3.5 Sonnet 和 GPT-4o。Cursor 平台向来行动迅速，DeepSeek 模型一上线，大家就迫不及待地开始了实际应用测试。

性能对比参考
DeepSeek 官方发布的 DeepSeek R1 和 V3 性能数据，与 OpenAI 的 o1 和 o1-mini 模型进行了对比。

测试任务概览

本次对比测试包含两个主要部分：

• 聊天模式 —— 模拟日常开发场景，探讨如何在 Next.js 应用中为一个对话框组件添加服务端操作。
• 代码生成模式 —— 模拟代码维护场景，修改一个 CircleCI 配置文件，目标是移除前端部署相关配置以及不再需要的 E2E (端到端) 测试步骤。

需要注意的是，Cursor 平台的“代理模式”（Agent Mode，通常指模型可以自主执行操作、调用工具的模式）目前仅对 Anthropic 模型和 GPT-4o 开放，因此本次测试不涉及代理模式。

聊天模式对比

任务描述

我们提出的问题是，如何在 Next.js 应用中，为一个对话框组件正确地添加服务端操作。具体的问题提示是：

“请说明如何实现一个服务端操作，并将其正确地传递给这个对话框组件？”

为了提供更具体的上下文，我们还附上了包含对话框组件相关代码的文件。

DeepSeek R1 的表现

DeepSeek R1 因为其高关注度，自然成为了我们的首选测试对象。但在使用 R1 的过程中，我们很快发现了两个比较明显的问题：

• 输出流式传输速度慢
  R1 在生成回答时速度较慢，需要等待较长时间才能看到完整输出。
• 回答开头带有明显的 块
  R1 在正式回答前，会先输出一大段 标签包裹的内容，类似于思考过程的展示。虽然这种预处理步骤如果能显著提升最终答案的质量，我们是可以接受的。但问题在于，它与缓慢的流式输出叠加在一起，就明显延迟了实际有效信息的呈现。例如，模型先输出一大段 内容，然后才开始缓慢地流式传输实际的回答，整个等待时间就变得很长。理论上，可以通过设置 Cursor 规则来跳过 部分，但这不在我们本次默认状态的测试范围内。

此外，R1 的回答建议安装 next-safe-action/hooks 库来解决问题，但它并没有在后续的回答中进一步解释如何使用这个库来实现服务端操作。对于我们提出的这个相对简单的问题来说，仅仅建议安装一个额外的库，似乎有些“小题大做”了。

DeepSeek V3 的表现

DeepSeek V3 的表现也还不错，它甚至推荐使用 React 19 的新特性 useFormStatus。这表明 V3 模型学习了较新的前端技术和代码库。不过，V3 在代码实现上存在一个关键错误：它直接在客户端组件中调用了服务端操作。在 Next.js 中，这种做法是 不可行 的。（知识补充：Next.js 为了保证安全性、性能和代码组织，约定服务端代码必须在服务端环境执行，客户端组件中的代码默认运行在浏览器端。直接在客户端组件中调用服务端代码会导致错误，例如无法找到服务端模块、网络请求失败等。）例如，直接在客户端 JavaScript 代码中调用服务端函数，会导致运行时错误，或者服务端代码根本没有被执行。

与 R1 类似，V3 的输出流式传输速度也比较慢。但由于 V3 没有 R1 那种冗长的 块，所以整体体验比 R1 稍好一些。

Claude 3.5 Sonnet 的表现

相比之下，Claude 3.5 Sonnet 的响应速度是最快的，即使在 “慢请求模式” 下（例如，当每月 API 请求次数超过免费额度，进入付费请求后，可能会遇到请求速度限制）。虽然 Sonnet 没有像 V3 那样推荐最新的 React 特性 (useFormStatus)，并且也犯了和 V3 类似的错误，直接在客户端组件中调用服务端操作，但它给出的解决方案更接近实际可用的答案。Sonnet 建议在服务端操作函数中加上 'use server' 指令，就能满足 Next.js 的要求。（知识补充：'use server' 是 Next.js 13 版本及以后引入的关键指令，用于显式声明一个函数为服务端操作。添加 'use server' 后，Next.js 才能正确地将该函数识别为服务端代码，并允许客户端组件安全地调用它。） 实际上，只需要简单地添加 'use server' 声明，Sonnet 的方案就能基本解决问题，比 DeepSeek 模型给出的方案更实用。

代码生成模式对比

任务描述

在这个测试环节，我们提供了一个用于部署全栈应用的 CircleCI 配置文件。这个应用包含一个纯 React 前端和一个 Node.js 后端。原有的部署流程包含多个步骤。我们的目标是修改这个配置文件，同时完成以下两点：

• 移除所有与前端部署相关的配置
• 识别出应用只剩下后端，E2E 测试 (端到端测试，End-to-End Testing，通常用于测试用户完整使用流程) 已经不再需要，并移除相关的配置步骤。 （知识补充：E2E 测试主要用于模拟用户行为，验证前端与后端交互的完整流程。如果应用只剩下后端，不再有用户界面，E2E 测试就失去了意义。常用的 E2E 测试框架包括 Cypress、Selenium 等。）

我们在问题提示中明确指出 “移除所有与前端部署相关的部分”，并将完整的 CircleCI 配置文件作为上下文提供给模型。

DeepSeek R1 的表现

我们原本期望，带有 块的 R1 模型在处理这种需要理解上下文、进行多处修改的任务 (Composer 任务) 时，能够表现得更出色。然而，实际情况却不尽如人意：

• R1 遗漏了一些明显与前端部署相关的配置 （例如，配置文件中仍然保留了提及构建 webapp 引用的部分）。但值得肯定的是，它正确地识别出 deploy-netlify (部署到 Netlify 平台的步骤，Netlify 常用作前端静态资源托管平台) 这一步骤不再需要，并将其移除。
• 同时，R1 错误地移除了标记为 deploy_production_api 的后端部署步骤，这可能会导致后端服务无法正常部署。此外，R1 未能发现 E2E 测试已经不再有意义，仍然保留了相关的配置。

DeepSeek V3 的表现

DeepSeek V3 在代码修改任务上的表现比 R1 稍好一些。它修正了一些 R1 遗漏的前端部署配置，但也暴露了新的问题——例如，V3 仍然保留了 deploy-netlify 步骤，这表明它没有完全理解任务要求。值得肯定的是，V3 在 保持后端部署步骤完整 方面做得不错，没有像 R1 那样误删后端部署配置。但和 R1 一样，V3 也没能判断出 E2E 测试部分可以删除。

Claude 3.5 Sonnet 的表现

老牌的 Claude 3.5 Sonnet 在这项代码修改任务中表现最佳：

• Sonnet 成功移除了大部分与前端部署相关的命令，虽然和 V3 一样，它也 未能删除 deploy-netlify 步骤。
• 在后端部署步骤方面，Sonnet 也保持了完整，没有误删。
• 最关键的是，Sonnet 精准地识别出，由于只剩下后端服务，E2E 测试已经完全没有必要。因此，Sonnet 将包括 Cypress 二进制缓存 (Cypress Binary Cache，用于加速 Cypress 测试的缓存) 等所有 E2E 测试相关的配置都一并移除。（知识补充：Cypress 二进制缓存用于缓存 Cypress 测试运行所需的二进制文件，可以加快后续测试的启动速度。但如果 E2E 测试被移除，这个缓存配置也应该一并删除，以避免冗余配置。） 这一点是本次测试中最佳的解决方案，体现了 Sonnet 对任务意图的深刻理解和更全面的代码修改能力。

总结

Cursor 平台不断引入新的 AI 模型，总是能给开发者带来新的选择和可能性。尽管本次对比测试的任务相对简单，但已经足以初步展示 DeepSeek 两款模型在实际开发场景中的能力。与 Claude 3.5 Sonnet 相比，DeepSeek 的模型各有优缺点。

综合来看，无论是响应速度还是输出质量，Claude 3.5 Sonnet 在本次测试中都 明显领先 于 DeepSeek 的两款模型。虽然 DeepSeek 模型在未来的版本中，响应速度可能会因为服务器优化、网络分布等因素得到改善，但就目前的实际测试结果而言，Claude 3.5 Sonnet 在 实用性 和 可靠性 方面仍然稳居第一梯队。

总而言之，本次测试表明，Claude 3.5 Sonnet 依然是目前 Cursor 平台上更成熟、更可靠的选择。但 DeepSeek 的新模型也展现出了一定的潜力，值得开发者持续关注和尝试。随着模型的不断迭代和完善，未来可能会有更好的表现。