曾左

2024 年 12 月 26 日，杭州深度求索人工智能基礎技術研究有限公司發布 DeepSeek-V3 大模型。官方宣稱：（1）基于自研的 MoE 模型和 671B 參數，在 14.8T token 上進行了預訓練；（2）多項評測成績超越了 Qwen2.5 - 72B 和 Llama - 3.1 - 405B 等其他開源模型，在性能上與世界頂尖的閉源模型 GPT-4o 以及 Claude-3.5-Sonnet 不分伯仲。個人自 2025 年 1 月 3 日開始試用，至今兩周零兩天，以下是使用過程中的心得體會與經驗總結，僅供參考。

DeepSeek V3 免費使用地址：https://chat.deepseek.com/

一、先說結論

以下結論僅針對免費使用版（非開源版）：

（1）優點：整體回答效果優于 GPT-4o（GPT-4o 溫度設置為 0.8，下同）。

（2）不足：給出錯誤答案（幻覺）的概率高于 GPT-4o。

（3）適用范圍：相比 GPT-4o，DeepSeek V3 更適合用于解答開放式問題。對于較為具體的細節問題，兩者各有優勢，GPT-4o 更保守且更可靠，DeepSeek 廣度和維度更高但也更容易出錯。建議根據實際需求選用或兩者參照使用。

（4）個人選擇：目前在日常工作中，開放性問題以 DeepSeek V3 為主、GPT4-o 為輔；細節問題則對照兩者使用，且仍以 DeepSeek V3 的回答為主并二次驗證。

（5）未來看法：隨著 DeepSeek V3 崛起，受沖擊最大的或許不是 GPT，而是以千問、豆包和文心一言為代表的國產頭部大模型，其市場可能被嚴重擠壓。不過，目前 DeepSeek 產品力和生態較弱，與 coze 等相比，其普通用戶端競爭力仍有待提升，不過其突出的核心競爭力不容小覷。最終 DeepSeek V3 能發展到何種程度，首先要看能否繼續保持以問答效果為關鍵的核心競爭力；其次要找到便于用戶使用的合適產品形態，就這一點而言，我認為字節相關產品目前處于領先地位；最后提高服務的穩定性至關重要，目前DeepSeek V3回復經常超時。

二、使用過程

1. 一天嘗鮮試用 - 確實不錯

1 月 3 日周五，在上班路上刷阮一峰的 科技愛好者周刊（第 332 期）：西蒙·威利森的年終總結，梁文鋒的訪談。看到阮大師分享及推薦了 DeepSeek V3，而后在朋友圈也看到一些推薦和分享。當天是周五，組內有新技術探索安排，于是我抱著好奇、嘗鮮、懷疑和謹慎的態度測試了一下，看看 DeepSeek V3 是否真如宣傳所說那么好？

我承認剛開始我是懷疑的，以為又是個嘴炮，畢竟類似的事情遇到不少，前幾天剛被 Logback 坑了，Logback 官方自稱其性能遠高于 Log4j2，實際上只是在某個時間點（2021 年），在特定配置和特定版本下的極限測試結果，且其測試基準不符合實際生產環境需求，比如將 FileAppender 的 immediateFlush 設置為 false，所以無實際指導性意義。時至今日，兩者真實性能已截然不同，在當前最新版本和相同配置下，兩者性能總體相當，甚至在部分場景下 Logback 性能反而不如 Log4j2，向作者反饋后，他仍舊選擇了沉默，更別說同步更新或撤銷Logback 性能說明文檔。

由于之前有多次類似工作，積累了不少 CASE，于是選取了其中部分典型的研發 CASE，以 GPT-4o 為基準，快速測試及驗證。

當時的結果及初步結論如下：

（1）DeepSeek V3 在研發技術方面的回答效果略好于 GPT-4o，得分為 106.5 分（以 GPT-4o 為基線，總分為 100 分）。

（2）官方文檔比較簡陋，WEB 頁面功能少，設計和交互體驗一般。

（3）部分問答結果感覺是在 GPT-4 基礎之上做了升華和補充，有些懷疑其使用了 GPT-4 的訓練數據。網絡上也有類似的聲音：DeepSeek 把自己誤認成了 ChatGPT？分析人士稱，或用了 GPT 生成文本做訓練數據。

部分測試 CASE 如下：

說明： 以上 CASE 僅供參考，評分結果依賴個人主觀評價。由于大語言模型先天存在幻覺問題，無法保證答案及其效果的可重復性。

2. 一周進階使用 - 缺點很致命

嘗鮮后，感覺 DeepSeek V3 確實不錯，遠超預期。不過心中仍有所保留，國產大模型（含商業版）各個都說自己不亞于 GPT-4，但實際使用來看，暫時還沒有綜合實力比 GPT-4 強的產品。此外，既然 DeepSeek V3 效果比 GPT-4o 好，是否應該將其作為我日常工作的第一 LLM？我不可能長時間將同一問題，同時向 GPT-4o 和 DeepSeek 發問，而后細看兩者回答，最后再取長補短。所以本階段我將日常工作中遇到的各類問題，同時向 DeepSeek V3 和 GPT-4o 提問，通過對比兩者效果，以幫助我更客觀和更全面地判斷兩者優劣，便于我未來二選一。

使用總結：

（1）DeepSeek V3 的問答效果波動性較大，不靠譜的概率較高，好的時候比 GPT-4 好不少，差的時候則各種瞎說。

舉例三個明顯坑爹的回答：

（1）RandomAccessFile 竟然使用了內存映射文件的技術？事實當然不是

（2）FileAppender 竟然不支持無 GC 模式，MemoryMappedFileAppender 竟然支持文件滾定？事實與之相反

（3）RandomAccessFile 中 immediateFlush 默認值竟然是 false？實際上 immediateFlush 默認值是 true

3. 一周深度使用 - 選對場景避短揚長

經上階段使用后，由于 DeepSeek V3 的缺點（給出錯誤答案的概率高于 GPT-4o）很致命，一度讓我想放棄。然而，它的優點（整體回答效果優于 GPT-4o）又讓我十分不舍，比如在嘗鮮階段測試 CASE 中的“ts 中如何避免濫用 any 類型”問題上，DeepSeek V3 的回答是迄今為止我見過的最好的，沒有之一。相比坑爹的回答，優秀案例比例更高。所以在本階段，繼續使用 DeepSeek V3，希望能總結其特點，找到合適的適用場景，從而最大化地發揮它的優勢。

經過一周使用后，個人認為：DeepSeek V3 更適合用于解答開放式問題。對于較為具體的細節問題，兩者各有優勢，GPT-4o 更保守且更可靠，DeepSeek 廣度和維度更高但也更容易出錯。建議用戶根據實際需求選用，或兩者參照使用。

三、總結與建議

（1）從個人使用來看，DeepSeek V3 效果確實很好，還能免費使用，NB。期望 DeepSeek V3 能越做越好，能優先支持自定義 BOT。

（2）個人建議在日常工作中，開放性問題可以以 DeepSeek V3 為主、GPT4-o 為輔；細節問題則對照兩者使用，以 DeepSeek V3 的回答為主，并進行二次驗證。

四、附優秀案例 - DeepSeek V3 關于“ts 中如何避免濫用 any 類型”問題的解答

在 TypeScript 中，any 類型是一種“逃逸艙”，它可以繞過類型檢查，但過度使用 any 會削弱 TypeScript 的類型安全性。為了避免使用 any，可以采取以下策略：

1. 明確類型

始終為變量、函數參數和返回值指定明確的類型，而不是使用 any。

示例：

// 不推薦
function processData(data: any) {
    // ...
}

// 推薦
function processData(data: { id: number; name: string }) {
    // ...
}

2. 使用聯合類型

當某個值可能是多種類型時，使用聯合類型（|）而不是 any。

示例：

// 不推薦
let value: any;

// 推薦
let value: string | number;

3. 使用類型別名或接口

對于復雜的數據結構，使用類型別名（type）或接口（interface）定義類型。

示例：

// 不推薦
function getUser(user: any) {
    // ...
}

// 推薦
interface User {
    id: number;
    name: string;
    email: string;
}

function getUser(user: User) {
    // ...
}

4. 使用泛型

當函數或類需要處理多種類型時，使用泛型（Generic）而不是 any。

示例：

// 不推薦
function identity(value: any): any {
    return value;
}

// 推薦
function identity<T>(value: T): T {
    return value;
}

5. 使用類型斷言

如果明確知道某個值的類型，可以使用類型斷言（as）而不是 any。

示例：

let value: unknown = "Hello, TypeScript";

// 不推薦
let length = (value as any).length;

// 推薦
let length = (value as string).length;

6. 使用 unknown 類型

當類型不確定時，使用 unknown 類型而不是 any。unknown 是類型安全的，因為它要求在使用前進行類型檢查。

示例：

// 不推薦
function processValue(value: any) {
    // ...
}

// 推薦
function processValue(value: unknown) {
    if (typeof value === "string") {
        console.log(value.toUpperCase());
    } else if (typeof value === "number") {
        console.log(value.toFixed(2));
    }
}

7. 使用類型守衛

通過類型守衛（Type Guard）縮小 unknown 或聯合類型的范圍。

示例：

function isString(value: unknown): value is string {
    return typeof value === "string";
}

function processValue(value: unknown) {
    if (isString(value)) {
        console.log(value.toUpperCase());
    }
}

8. 使用工具類型

TypeScript 提供了許多工具類型（Utility Types），可以幫助避免 any。

示例：

// 使用 Partial<T> 表示部分屬性可選
interface User {
    id: number;
    name: string;
    email: string;
}

function updateUser(user: Partial<User>) {
    // ...
}

9. 啟用嚴格模式

在 tsconfig.json 中啟用嚴格模式，可以避免隱式的 any。

示例：

{
  "compilerOptions": {
    "strict": true
  }
}

嚴格模式包括以下選項：

• noImplicitAny：禁止隱式的 any 類型。
• strictNullChecks：確保變量不能為 null 或 undefined。
• strictFunctionTypes：確保函數參數類型嚴格匹配。
• 等等。

10. 使用第三方庫的類型定義

如果使用第三方庫，確保安裝了對應的類型定義文件（@types 包）。

示例：

npm install --save lodash
npm install --save-dev @types/lodash

11. 逐步替換 any

如果項目中已經存在大量 any，可以逐步替換：

1. 使用 eslint 或 tslint 禁止使用 any。
2. 逐步為每個 any 添加明確的類型。

12. 使用 never 類型

對于不可能存在的值，使用 never 類型。

示例：

function throwError(message: string): never {
    throw new Error(message);
}

總結

避免使用 any 是編寫高質量 TypeScript 代碼的關鍵。通過明確類型、使用聯合類型、泛型、類型斷言、unknown 類型、類型守衛和工具類型，可以顯著提高代碼的類型安全性和可維護性。同時，啟用嚴格模式和逐步替換 any 也是有效的策略。