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

關(guān)于 DeepSeek

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

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

測試任務(wù)概述

此次測試分為兩個主要部分：

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

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

聊天模式

任務(wù)描述

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

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

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

DeepSeek R1 的表現(xiàn)

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

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

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

DeepSeek V3 的表現(xiàn)

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

Claude 3.5 Sonnet 的表現(xiàn)

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

代碼生成模式

任務(wù)描述

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

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

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

DeepSeek R1 的表現(xiàn)

對于 Composer 任務(wù)，我們原本期待帶有 <think> 塊的 R1 能在處理多個部分變動時表現(xiàn)更為出色。然而實際情況并不理想：

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

DeepSeek V3 的表現(xiàn)

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

Claude 3.5 Sonnet 的表現(xiàn)

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

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

總結(jié)

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

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