DeepSeek 入驻 Cursor —— 表现能否超越 Claude？

diannao

DeepSeek 刚刚在 Cursor 平台上线了它的两款模型：DeepSeek V3 和 R1。目前，许多开发者（包括我们在内）主要依赖 Claude 3.5 Sonnet（最新版本 claude-3-5-sonnet-20241022）作为主要语言模型，因此我们决定对这几款新模型进行实战对比。
关于 DeepSeek

DeepSeek 最近因开源了其备受瞩目的 R1 模型而登上新闻头条，该模型的各项性能指标与 OpenAI 的 o1 相比毫不逊色，绝非易事。官方公布的编程相关基准测试数据也显示，大多数情况下它的表现有望超越 Claude 3.5 Sonnet 和 GPT-4o。Cursor 一贯动作迅速，新模型上架后，大家就迫不及待地开展了实际应用测试。

对比基准
DeepSeek R1 与 V3 的性能数据（由 DeepSeek 发布）与 OpenAI 的 o1 和 o1-mini 进行对比。

测试任务概述

此次测试分为两个主要部分：

• 聊天模式 —— 讨论如何在 Next.js 应用中为对话框添加服务端操作；
  
• 代码生成模式 —— 修改一个 CircleCI 配置文件，移除前端部署相关内容以及不再需要的 E2E 测试步骤。
  

需要说明的是，目前代理模式只对 Anthropic 模型和 GPT-4o 开放，因此这里不涉及该部分测试。
聊天模式

任务描述

问题要求说明如何在 Next.js 应用中，为一个对话框组件正确添加服务端操作。具体提示如下：

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

同时，我们还附上了包含对话框组件的相关文件作为上下文。
DeepSeek R1 的表现

从媒体关注度来看，R1 自然成为首选测试对象。使用 R1 时，很快发现两个问题：

• 输出流式传输速度较慢
  R1 在输出时显得不够敏捷，等待时间较长。
  
• 回答开头带有较大的 块
  虽然这个预处理块如果能提升最终答案的质量，我们并不介意，但它与缓慢的流式输出叠加，明显延迟了实际回答的呈现。例如，它在回答一开始就输出了一大段  内容，再加上缓慢的流式传输，整个过程耗时较长。理论上，通过设置 Cursor 规则来跳过这部分内容是可以解决的，但此处我们测试的是默认状态。
  

此外，R1 的回答中提到需要安装 next-safe-action/hooks 来解决问题，但实际上并未在后续的回答中展示如何使用这个方案。对于这样简单的问题来说，仅仅建议安装额外的包显得有些大材小用。
DeepSeek V3 的表现

V3 的表现也不俗，甚至推荐使用 React 19 的新特性 useFormStatus，这表明它对较新的代码库有一定的学习。不过，它在实现上有一个致命问题：直接在客户端组件中调用了创建的服务端操作，而在 Next.js 中，这种写法是不可行的。比如，如果直接在客户端调用服务端代码，可能会导致页面报错或无法正常运行。
另外，V3 同样在输出流式传输上显得较慢，但由于它没有 R1 那样的冗长  块，总体体验稍微好一些。
Claude 3.5 Sonnet 的表现

Claude 3.5 Sonnet 的响应速度最快，即便在“慢请求模式”下（例如当每月超过 500 次付费请求时）。虽然它没有采用最新的 React 特性（例如 useFormStatus），并且同样直接在客户端组件中调用服务端操作，但它给出的解决方案更接近实际可用的答案。只需在服务端操作中加上 use server 声明，就能满足 Next.js 的要求。
代码生成模式

任务描述

在这部分测试中，我们提供了一个用于部署全栈应用的 CircleCI 配置文件。该应用拥有一个纯 React 前端和一个 Node.js 后端。部署流程中包含多个步骤，需要同时完成以下两点：

• 移除所有与前端部署相关的部分；
  
• 识别出既然只有后端存在，E2E 测试（使用 Cypress）也不再必要，并将其相关步骤一并去除。
  

提示内容明确指出“移除所有与前端部署相关的部分”，同时配置文件作为上下文也一并提供。
DeepSeek R1 的表现

对于 Composer 任务，我们原本期待带有  块的 R1 能在处理多个部分变动时表现更为出色。然而实际情况并不理想：

• R1 遗漏了几处明显与前端部署相关的内容（例如提及构建 webapp 的引用），但它正确识别出不再需要 deploy-netlify 这一步骤，这部分表现值得肯定；
  
• 同时，R1 移除了标记为 deploy_production_api 的后端部署步骤，但未能发现 E2E 测试已无意义这一问题。
  

DeepSeek V3 的表现

V3 在 Composer 任务上比 R1稍有优势，它修正了一些 R1 遗漏的问题，但同时也暴露出自己的不足——例如保留了 deploy-netlify 的步骤。值得一提的是，V3 在保持后端部署步骤完整方面表现不错，但同样未能判断出 E2E 测试部分可以删除。
Claude 3.5 Sonnet 的表现

老牌的 Sonnet 在这项任务中表现最佳：

• 它成功移除了大部分与前端部署相关的命令，虽然也未能删除 deploy-netlify 步骤；
  
• 在后端部署步骤方面，Sonnet 同样保持了完整；
  
• 最关键的是，Sonnet 精准识别出由于只剩后端，E2E 测试完全没必要，并将包括 Cypress 二进制缓存等所有相关部分一并移除。这一点无疑是最佳解决方案的体现。
  

总结

Cursor 平台不断引入新模型，总能给开发者带来新的惊喜。尽管这两项测试任务较为简单，但足以展示 DeepSeek 模型在实际场景中的表现，与 Claude 3.5 Sonnet 相比，各有优劣。
综合来看，无论是在响应速度还是输出质量上，Claude 3.5 Sonnet 均显著领先于 DeepSeek 的两款模型。虽然未来响应速度方面可能会因服务器分布等因素得到改善，但就目前的实际测试结果来看，Sonnet 在实用性上依然稳居首位。