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 在實用性上依然穩居首位。
