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 进行对比。
测试任务概述
此次测试分为两个主要部分:
聊天模式 —— 讨论如何在 Next.js 应用中为对话框添加服务端操作;
代码生成模式 —— 修改一个 CircleCI 配置文件,移除前端部署相关内容以及不再需要的 E2E 测试步骤。
需要说明的是,目前代理模式只对 Anthropic 模型和 GPT-4o 开放,因此这里不涉及该部分测试。
聊天模式
任务描述
问题要求说明如何在 Next.js 应用中,为一个对话框组件正确添加服务端操作。具体提示如下:
“如何实现一个服务端操作,并将其正确传递给这个对话框?”
同时,我们还附上了包含对话框组件的相关文件作为上下文。
DeepSeek R1 的表现
从媒体关注度来看,R1 自然成为首选测试对象。使用 R1 时,很快发现两个问题:
输出流式传输速度较慢
R1 在输出时显得不够敏捷,等待时间较长。回答开头带有较大的
<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 后端。部署流程中包含多个步骤,需要同时完成以下两点:
移除所有与前端部署相关的部分;
识别出既然只有后端存在,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 在实用性上依然稳居首位。