当前位置: 首页 > article >正文

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

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 进行对比。

测试任务概述

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

  1. 聊天模式 —— 讨论如何在 Next.js 应用中为对话框添加服务端操作;

  2. 代码生成模式 —— 修改一个 CircleCI 配置文件,移除前端部署相关内容以及不再需要的 E2E 测试步骤。

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


聊天模式

任务描述

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

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

同时,我们还附上了包含对话框组件的相关文件作为上下文。

DeepSeek R1 的表现

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

  1. 输出流式传输速度较慢
    R1 在输出时显得不够敏捷,等待时间较长。

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

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

DeepSeek V3 的表现

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

Claude 3.5 Sonnet 的表现

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


代码生成模式

任务描述

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

  1. 移除所有与前端部署相关的部分;

  2. 识别出既然只有后端存在,E2E 测试(使用 Cypress)也不再必要,并将其相关步骤一并去除。

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

DeepSeek R1 的表现

对于 Composer 任务,我们原本期待带有 <think> 块的 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 在实用性上依然稳居首位。


http://www.kler.cn/a/544167.html

相关文章:

  • [MySQL]5-MySQL扩展(分片)
  • 游戏内常见加密
  • 机器学习 - 词袋模型(Bag of Words)实现文本情感分类的详细示例
  • innovus如何分步长func和dft时钟
  • 强化学习之 PPO 算法:原理、实现与案例深度剖析
  • 信创领域的PostgreSQL管理员认证
  • Vulnhub靶机渗透-DC1
  • CTF-WEB: 利用Web消息造成DOM XSS
  • 服务器芯片合封电源解决方案
  • 系统漏洞扫描服务:安全风险识别与防护指南
  • AI模型指标
  • Vue.js学习笔记(八)H5性能优化——首屏加载速度提升
  • DeepSeek之Api的使用(将DeepSeek的api集成到程序中)
  • React 第二十四节 useDeferredValue Hook 的用途以及注意事项详解
  • 热更图片方案
  • 【STM32】通过HAL库Flash建立FatFS文件系统并配置为USB虚拟U盘MSC
  • 构建Python量化交易环境:从基础安装到项目创建
  • STM32 RCC功能说明 复位和时钟控制RCC
  • 自然语言处理(NLP)在智能语音助手中的应用进展
  • ECharts鼠标悬浮提示框数字设置鼠标在左侧时 tooltip 显示到右侧,鼠标在右侧时 tooltip 显示到左侧。
  • git fetch和git pull 的区别
  • 1. 对比 LVS 负载均衡群集的 NAT 模式和 DR 模式,比较其各自的优势 。2. 基于 openEuler 构建 LVS-DR 群集。
  • 算法练习0212
  • 用什么格式的文件存储双语对照的文本比较好
  • ARM Cortex-M3/M4 权威指南 笔记【二】架构
  • GitCode 助力 Dora SSR:开启游戏开发新征程