DeepSeek 入駐 Cursor —— 表現(xiàn)能否超越 Claude？
DeepSeek 剛剛在 Cursor 平臺上線了它的兩款模型：DeepSeek V3 和 R1。目前，許多開發(fā)者（包括我們在內(nèi)）主要依賴 Claude 3.5 Sonnet（最新版本 claude-3-5-sonnet-20241022）作為主要語言模型，因此我們決定對這幾款新模型進(jìn)行實(shí)戰(zhàn)對比。
關(guān)于 DeepSeek
DeepSeek 最近因開源了其備受矚目的 R1 模型而登上新聞頭條，該模型的各項(xiàng)性能指標(biāo)與 OpenAI 的 o1 相比毫不遜色，絕非易事。官方公布的編程相關(guān)基準(zhǔn)測試數(shù)據(jù)也顯示，大多數(shù)情況下它的表現(xiàn)有望超越 Claude 3.5 Sonnet 和 GPT-4o。Cursor 一貫動作迅速，新模型上架后，大家就迫不及待地開展了實(shí)際應(yīng)用測試。
對比基準(zhǔn)
DeepSeek R1 與 V3 的性能數(shù)據(jù)（由 DeepSeek 發(fā)布）與 OpenAI 的 o1 和 o1-mini 進(jìn)行對比。
測試任務(wù)概述
此次測試分為兩個主要部分：
- 聊天模式 —— 討論如何在 Next.js 應(yīng)用中為對話框添加服務(wù)端操作；
- 代碼生成模式 —— 修改一個 CircleCI 配置文件，移除前端部署相關(guān)內(nèi)容以及不再需要的 E2E 測試步驟。
需要說明的是，目前代理模式只對 Anthropic 模型和 GPT-4o 開放，因此這里不涉及該部分測試。
聊天模式
任務(wù)描述
問題要求說明如何在 Next.js 應(yīng)用中，為一個對話框組件正確添加服務(wù)端操作。具體提示如下：
“如何實(shí)現(xiàn)一個服務(wù)端操作，并將其正確傳遞給這個對話框？”
同時，我們還附上了包含對話框組件的相關(guān)文件作為上下文。
DeepSeek R1 的表現(xiàn)
從媒體關(guān)注度來看，R1 自然成為首選測試對象。使用 R1 時，很快發(fā)現(xiàn)兩個問題：
- 輸出流式傳輸速度較慢
R1 在輸出時顯得不夠敏捷，等待時間較長。 - 回答開頭帶有較大的
<think>塊
雖然這個預(yù)處理塊如果能提升最終答案的質(zhì)量，我們并不介意，但它與緩慢的流式輸出疊加，明顯延遲了實(shí)際回答的呈現(xiàn)。例如，它在回答一開始就輸出了一大段<think>內(nèi)容，再加上緩慢的流式傳輸，整個過程耗時較長。理論上，通過設(shè)置 Cursor 規(guī)則來跳過這部分內(nèi)容是可以解決的，但此處我們測試的是默認(rèn)狀態(tài)。
此外，R1 的回答中提到需要安裝 next-safe-action/hooks 來解決問題，但實(shí)際上并未在后續(xù)的回答中展示如何使用這個方案。對于這樣簡單的問題來說，僅僅建議安裝額外的包顯得有些大材小用。
DeepSeek V3 的表現(xiàn)
V3 的表現(xiàn)也不俗，甚至推薦使用 React 19 的新特性 useFormStatus，這表明它對較新的代碼庫有一定的學(xué)習(xí)。不過，它在實(shí)現(xiàn)上有一個致命問題：直接在客戶端組件中調(diào)用了創(chuàng)建的服務(wù)端操作，而在 Next.js 中，這種寫法是不可行的。比如，如果直接在客戶端調(diào)用服務(wù)端代碼，可能會導(dǎo)致頁面報錯或無法正常運(yùn)行。
另外，V3 同樣在輸出流式傳輸上顯得較慢，但由于它沒有 R1 那樣的冗長 <think> 塊，總體體驗(yàn)稍微好一些。
Claude 3.5 Sonnet 的表現(xiàn)
Claude 3.5 Sonnet 的響應(yīng)速度最快，即便在“慢請求模式”下（例如當(dāng)每月超過 500 次付費(fèi)請求時）。雖然它沒有采用最新的 React 特性（例如 useFormStatus），并且同樣直接在客戶端組件中調(diào)用服務(wù)端操作，但它給出的解決方案更接近實(shí)際可用的答案。只需在服務(wù)端操作中加上 use server 聲明，就能滿足 Next.js 的要求。
代碼生成模式
任務(wù)描述
在這部分測試中，我們提供了一個用于部署全棧應(yīng)用的 CircleCI 配置文件。該應(yīng)用擁有一個純 React 前端和一個 Node.js 后端。部署流程中包含多個步驟，需要同時完成以下兩點(diǎn)：
- 移除所有與前端部署相關(guān)的部分；
- 識別出既然只有后端存在，E2E 測試（使用 Cypress）也不再必要，并將其相關(guān)步驟一并去除。
提示內(nèi)容明確指出“移除所有與前端部署相關(guān)的部分”，同時配置文件作為上下文也一并提供。
DeepSeek R1 的表現(xiàn)
對于 Composer 任務(wù)，我們原本期待帶有 <think> 塊的 R1 能在處理多個部分變動時表現(xiàn)更為出色。然而實(shí)際情況并不理想：
- R1 遺漏了幾處明顯與前端部署相關(guān)的內(nèi)容（例如提及構(gòu)建 webapp 的引用），但它正確識別出不再需要 deploy-netlify 這一步驟，這部分表現(xiàn)值得肯定；
- 同時，R1 移除了標(biāo)記為 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 在這項(xiàng)任務(wù)中表現(xiàn)最佳：
- 它成功移除了大部分與前端部署相關(guān)的命令，雖然也未能刪除 deploy-netlify 步驟；
- 在后端部署步驟方面，Sonnet 同樣保持了完整；
- 最關(guān)鍵的是，Sonnet 精準(zhǔn)識別出由于只剩后端，E2E 測試完全沒必要，并將包括 Cypress 二進(jìn)制緩存等所有相關(guān)部分一并移除。這一點(diǎn)無疑是最佳解決方案的體現(xiàn)。
總結(jié)
Cursor 平臺不斷引入新模型，總能給開發(fā)者帶來新的驚喜。盡管這兩項(xiàng)測試任務(wù)較為簡單，但足以展示 DeepSeek 模型在實(shí)際場景中的表現(xiàn)，與 Claude 3.5 Sonnet 相比，各有優(yōu)劣。
綜合來看，無論是在響應(yīng)速度還是輸出質(zhì)量上，Claude 3.5 Sonnet 均顯著領(lǐng)先于 DeepSeek 的兩款模型。雖然未來響應(yīng)速度方面可能會因服務(wù)器分布等因素得到改善，但就目前的實(shí)際測試結(jié)果來看，Sonnet 在實(shí)用性上依然穩(wěn)居首位。
