DeepSeek 剛剛在 Cursor 平臺(tái)上線了它的兩款模型：DeepSeek V3 和 R1。目前，許多開發(fā)者（包括我們?cè)趦?nèi)）主要依賴 Claude 3.5 Sonnet（最新版本 claude-3-5-sonnet-20241022）作為主要語(yǔ)言模型，因此我們決定對(duì)這幾款新模型進(jìn)行實(shí)戰(zhàn)對(duì)比。

關(guān)于 DeepSeek

DeepSeek 最近因開源了其備受矚目的 R1 模型而登上新聞?lì)^條，該模型的各項(xiàng)性能指標(biāo)與 OpenAI 的 o1 相比毫不遜色，絕非易事。官方公布的編程相關(guān)基準(zhǔn)測(cè)試數(shù)據(jù)也顯示，大多數(shù)情況下它的表現(xiàn)有望超越 Claude 3.5 Sonnet 和 GPT-4o。Cursor 一貫動(dòng)作迅速，新模型上架后，大家就迫不及待地開展了實(shí)際應(yīng)用測(cè)試。

對(duì)比基準(zhǔn)
DeepSeek R1 與 V3 的性能數(shù)據(jù)（由 DeepSeek 發(fā)布）與 OpenAI 的 o1 和 o1-mini 進(jìn)行對(duì)比。

測(cè)試任務(wù)概述

此次測(cè)試分為兩個(gè)主要部分：

1. 聊天模式 —— 討論如何在 Next.js 應(yīng)用中為對(duì)話框添加服務(wù)端操作；
2. 代碼生成模式 —— 修改一個(gè) CircleCI 配置文件，移除前端部署相關(guān)內(nèi)容以及不再需要的 E2E 測(cè)試步驟。

需要說明的是，目前代理模式只對(duì) Anthropic 模型和 GPT-4o 開放，因此這里不涉及該部分測(cè)試。

聊天模式

任務(wù)描述

問題要求說明如何在 Next.js 應(yīng)用中，為一個(gè)對(duì)話框組件正確添加服務(wù)端操作。具體提示如下：

“如何實(shí)現(xiàn)一個(gè)服務(wù)端操作，并將其正確傳遞給這個(gè)對(duì)話框？”

同時(shí)，我們還附上了包含對(duì)話框組件的相關(guān)文件作為上下文。

DeepSeek R1 的表現(xiàn)

從媒體關(guān)注度來看，R1 自然成為首選測(cè)試對(duì)象。使用 R1 時(shí)，很快發(fā)現(xiàn)兩個(gè)問題：

1. 輸出流式傳輸速度較慢
   R1 在輸出時(shí)顯得不夠敏捷，等待時(shí)間較長(zhǎng)。
2. 回答開頭帶有較大的 <think> 塊
   雖然這個(gè)預(yù)處理塊如果能提升最終答案的質(zhì)量，我們并不介意，但它與緩慢的流式輸出疊加，明顯延遲了實(shí)際回答的呈現(xiàn)。例如，它在回答一開始就輸出了一大段 <think> 內(nèi)容，再加上緩慢的流式傳輸，整個(gè)過程耗時(shí)較長(zhǎng)。理論上，通過設(shè)置 Cursor 規(guī)則來跳過這部分內(nèi)容是可以解決的，但此處我們測(cè)試的是默認(rèn)狀態(tài)。

此外，R1 的回答中提到需要安裝 next-safe-action/hooks 來解決問題，但實(shí)際上并未在后續(xù)的回答中展示如何使用這個(gè)方案。對(duì)于這樣簡(jiǎn)單的問題來說，僅僅建議安裝額外的包顯得有些大材小用。

DeepSeek V3 的表現(xiàn)

V3 的表現(xiàn)也不俗，甚至推薦使用 React 19 的新特性 useFormStatus，這表明它對(duì)較新的代碼庫(kù)有一定的學(xué)習(xí)。不過，它在實(shí)現(xiàn)上有一個(gè)致命問題：直接在客戶端組件中調(diào)用了創(chuàng)建的服務(wù)端操作，而在 Next.js 中，這種寫法是不可行的。比如，如果直接在客戶端調(diào)用服務(wù)端代碼，可能會(huì)導(dǎo)致頁(yè)面報(bào)錯(cuò)或無法正常運(yùn)行。
另外，V3 同樣在輸出流式傳輸上顯得較慢，但由于它沒有 R1 那樣的冗長(zhǎng) <think> 塊，總體體驗(yàn)稍微好一些。

Claude 3.5 Sonnet 的表現(xiàn)

Claude 3.5 Sonnet 的響應(yīng)速度最快，即便在“慢請(qǐng)求模式”下（例如當(dāng)每月超過 500 次付費(fèi)請(qǐng)求時(shí)）。雖然它沒有采用最新的 React 特性（例如 useFormStatus），并且同樣直接在客戶端組件中調(diào)用服務(wù)端操作，但它給出的解決方案更接近實(shí)際可用的答案。只需在服務(wù)端操作中加上 use server 聲明，就能滿足 Next.js 的要求。

代碼生成模式

任務(wù)描述

在這部分測(cè)試中，我們提供了一個(gè)用于部署全棧應(yīng)用的 CircleCI 配置文件。該應(yīng)用擁有一個(gè)純 React 前端和一個(gè) Node.js 后端。部署流程中包含多個(gè)步驟，需要同時(shí)完成以下兩點(diǎn)：

1. 移除所有與前端部署相關(guān)的部分；
2. 識(shí)別出既然只有后端存在，E2E 測(cè)試（使用 Cypress）也不再必要，并將其相關(guān)步驟一并去除。

提示內(nèi)容明確指出“移除所有與前端部署相關(guān)的部分”，同時(shí)配置文件作為上下文也一并提供。

DeepSeek R1 的表現(xiàn)

對(duì)于 Composer 任務(wù)，我們?cè)酒诖龓в?<think> 塊的 R1 能在處理多個(gè)部分變動(dòng)時(shí)表現(xiàn)更為出色。然而實(shí)際情況并不理想：

• R1 遺漏了幾處明顯與前端部署相關(guān)的內(nèi)容（例如提及構(gòu)建 webapp 的引用），但它正確識(shí)別出不再需要 deploy-netlify 這一步驟，這部分表現(xiàn)值得肯定；
• 同時(shí)，R1 移除了標(biāo)記為 deploy_production_api 的后端部署步驟，但未能發(fā)現(xiàn) E2E 測(cè)試已無意義這一問題。

DeepSeek V3 的表現(xiàn)

V3 在 Composer 任務(wù)上比 R1稍有優(yōu)勢(shì)，它修正了一些 R1 遺漏的問題，但同時(shí)也暴露出自己的不足——例如保留了 deploy-netlify 的步驟。值得一提的是，V3 在保持后端部署步驟完整方面表現(xiàn)不錯(cuò)，但同樣未能判斷出 E2E 測(cè)試部分可以刪除。

Claude 3.5 Sonnet 的表現(xiàn)

老牌的 Sonnet 在這項(xiàng)任務(wù)中表現(xiàn)最佳：

• 它成功移除了大部分與前端部署相關(guān)的命令，雖然也未能刪除 deploy-netlify 步驟；
• 在后端部署步驟方面，Sonnet 同樣保持了完整；
• 最關(guān)鍵的是，Sonnet 精準(zhǔn)識(shí)別出由于只剩后端，E2E 測(cè)試完全沒必要，并將包括 Cypress 二進(jìn)制緩存等所有相關(guān)部分一并移除。這一點(diǎn)無疑是最佳解決方案的體現(xiàn)。

總結(jié)

Cursor 平臺(tái)不斷引入新模型，總能給開發(fā)者帶來新的驚喜。盡管這兩項(xiàng)測(cè)試任務(wù)較為簡(jiǎn)單，但足以展示 DeepSeek 模型在實(shí)際場(chǎng)景中的表現(xiàn)，與 Claude 3.5 Sonnet 相比，各有優(yōu)劣。

綜合來看，無論是在響應(yīng)速度還是輸出質(zhì)量上，Claude 3.5 Sonnet 均顯著領(lǐng)先于 DeepSeek 的兩款模型。雖然未來響應(yīng)速度方面可能會(huì)因服務(wù)器分布等因素得到改善，但就目前的實(shí)際測(cè)試結(jié)果來看，Sonnet 在實(shí)用性上依然穩(wěn)居首位。