# 影片筆記：我以为DeepSeek V4.1 flash拉了，后来发现是自己用错了...


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結

作者經過五天實際測試 DeepSeek V4.1 Flash 後發現，該模型在 DeepSeek Harness 環境中因上下文污染與過度調用工具導致體驗極差（被比喻為「竄稀」），但遷回 Hermes 工作流後表現優異，能高效處理複雜任務；結論強調模型能力無誤，問題在於工作流適配與使用方式。

## 核心重點

*   **速度與體感反差**：DeepSeek V4.1 Flash 輸出速度極快（約 230-250 tokens/秒，極端接近 300），作者比喻為「竄稀式輸出」，遠快於本地模型（45-100 tokens/秒）及 V4 Flash（150 tokens/秒）。
*   **環境適配性決定體驗**：
    *   在 **DeepSeek Harness** 中：體驗不佳，被稱為「串天猴」。常見問題包括上下文污染導致靜默、誤讀技能、過度調查歷史記錄（暴力搜索聊天數據庫）、工具調用次數過多。
    *   在 **Hermes 工作流** 中：體驗極佳，恢復「呼風喚雨」的感覺，速度與能力均優於 V4 Flash，能處理如雲端伺服器搬家等巨型任務。
*   **核心觀點**：「沒有垃圾的模型，只有不會用的人」。模型本身具備高智能與速度，表現差異主要源於工作流設計、提示詞策略及上下文管理。
*   **數據驗證**：API 用量數據真實反映模型在特定工作流下的實用性。V4.1 Flash 因限時 4 倍用量，用量回升，證明其在正確工作流下的價值。

## 詳細大綱

### I. 背景與測試初衷
*   **測試動機**：DeepSeek V4.1 Flash 發布，作者期待其速度與能力超越 V4 Pro。
*   **前期痛點**：作者此前使用本地部署模型（提及「前问 3.82GB」），因運算導致主機過熱。
*   **測試規模**：實際測試五天，消耗數億 Token，旨在驗證模型在真實工作流中的表現。

### II. 速度對比與體感描述
*   **速度基準對比**：
    *   本地模型（千問系列）：約 45-100 tokens/秒，作者比喻為「便秘」。
    *   DeepSeek V4 Flash：約 150 tokens/秒，作者認為舒適。
    *   DeepSeek V4.1 Flash：約 230-250 tokens/秒，極端情況下接近 300 tokens/秒。
*   **體感描述**：
    *   V4.1 速度極快，比喻為「竄稀」，眼睛跟不上操作，頁面瞬間刷滿。
    *   工具調用速度極快，尚未反應過來已執行完畢。

### III. 在 DeepSeek Harness 中的測試與問題
*   **測試環境**：DeepSeek Harness（雲端服務器），結合本地 4090 主機運行 Llama、NInfer 等配置。
*   **問題一：上下文污染與靜默**
    *   現象：在舊 Session 中熱切換至 V4.1 時，出現「竄稀式」快速滾動但 3 分鐘未輸出任何內容的情況。
    *   對比：使用本地千問僅需 1 分鐘即可查閱配置。
    *   解決：開啟新 Session 後，速度恢復正常（270 tokens/秒），成功完成任務。
    *   結論：上下文污染會嚴重影響模型表現，即使 V4.1 擁有 100 萬上下文窗口。
*   **問題二：意圖理解與過度調查**
    *   現象：模型常誤讀技能，並開始爬取 DeepSeek Harness 及隔壁 Hermes 的歷史記錄。
    *   體感：V4.1 似乎有「內在動力」要去調查清楚才肯動手，類似上一代 Agent 的行為。
    *   對比：千問 3.8 27b 能直接讀取技能並一次性完成任務。
*   **問題三：工具調用過量**
    *   案例 1：配置本地模型框架時，V4.1 暴力搜索近 2GB、十萬條信息的聊天數據庫，耗時 10 分鐘才找到相關信息。
    *   案例 2：寫稿任務中，V4.1 進行 32 次工具調用（其中 12 次為翻閱過往 Session），而 V4 Flash 僅需 5 次調用和 30 秒。
    *   不穩定性：部分 Session 中 V4.1 表現正常（20 秒進入狀態），顯示行為不穩定。

### IV. 遷回 Hermes 工作流後的體驗
*   **體驗反差**：
    *   在 DeepSeek Harness 中：體驗差，被稱為「串天猴」，速度快但難以駕馭。
    *   在 Hermes 中：體驗極佳，恢復「呼風喚雨、指哪打哪」的感覺，能力與速度均優於 V4 Flash。
*   **Hermes 工作流測試內容**：
    *   開 40 多個會話，5000 多條消息。
    *   任務包括：寫稿、改稿、配图、繼續舉行測試、1380 b 新框架及併發優化、改造 Hermes desktop、網站前端改動、電商後台開發。
*   **巨型任務測試**：
    *   雲端伺服器搬家（更換服務商）：作者未動手，僅開通帳號與付款，由 V4.1 從早上 5 點工作至下午 2-3 點，完美完成所有重裝與配置工作。

### V. 總結與反思
*   **核心觀點**：
    *   「沒有垃圾的模型，只有不會用的人」。
    *   同檔次及以上模型已具備高智能與速度，若覺得不好用，可能是用戶用法問題。
    *   模型表現與工作流（Harness vs. Hermes）及用戶習慣高度相關。
*   **數據驗證**：
    *   OpenCode 用量圖顯示：V4 Flash 因漲價用量下降，V4.1 Flash 因限時 4 倍用量，用量回升。
    *   模型的好用與否隨時間、工作流變化，API 用量是最真實的反饋。
*   **呼籲**：歡迎觀眾分享不同工作流下的體驗差異。

## 工具 / 模型 / 名詞整理

*   **模型/技術名稱**：
    *   DeepSeek V4.1 Flash
    *   DeepSeek V4 Flash
    *   DeepSeek V4 Pro
    *   千問 3.8 2GB（筆記中提及，疑點見下方）
    *   千問 3.8 27b（筆記中提及，疑點見下方）
    *   千問 3.87b（筆記中提及，疑點見下方）
    *   Llama
    *   NInfer
    *   GPT 5.6（疑點：需查證是否存在此版本，或為口誤）
    *   Luna（疑點：需查證是否為特定模型或代號）
    *   1380 b（疑點：需查證是否為參數量或模型名稱的一部分）
*   **工具/平台/產品名稱**：
    *   OpenCode
    *   DeepSeek Harness
    *   Hermes
    *   Gateway（本地 Gateway / 服務器 Gateway）
    *   Codex
    *   電商後台
    *   雲端服務器

## 操作流程整理

1.  **環境切換與速度驗證**：
    *   從本地部署模型（如千問系列）切換至 DeepSeek V4.1 Flash。
    *   觀察輸出速度（tokens/秒），確認是否達到預期的高速表現。
2.  **問題排查（Harness 環境）**：
    *   若遇到輸出靜默或滾動異常，檢查是否為上下文污染。
    *   嘗試開啟新 Session 以重置上下文，恢復正常速度。
    *   監控工具調用次數，若發現過度搜索歷史記錄或暴力調用，需調整提示詞或工作流。
3.  **工作流適配（Hermes 環境）**：
    *   將模型遷移至 Hermes 工作流。
    *   進行多會話、多消息的複雜任務測試（如寫稿、改稿、前端改動等）。
    *   執行巨型任務（如雲端伺服器搬家），監控模型從開通帳號到完成配置的完整流程。
4.  **數據回顧與優化**：
    *   查看 OpenCode 等平台的 API 用量數據，評估模型在特定工作流下的實用性。
    *   根據用量與體驗反饋，調整工作流設計或提示詞策略。

## 值得注意的限制或風險

*   **上下文污染風險**：在 DeepSeek Harness 等環境中，舊 Session 的上下文可能導致 V4.1 Flash 出現靜默或行為異常，即使擁有 100 萬上下文窗口，管理不當仍會影響表現。
*   **過度調用工具**：模型可能產生「內在動力」去調查歷史記錄，導致不必要的工具調用（如暴力搜索聊天數據庫），增加成本與耗時。
*   **工作流依賴性**：模型表現高度依賴工作流設計。在不適配的環境（如 Harness）中，即使模型速度快，體驗也可能極差（「串天猴」）。
*   **行為不穩定性**：部分 Session 中 V4.1 表現正常，而其他則出現問題，顯示模型在特定條件下行為可能存在不穩定性。

## 逐字稿辨識疑點

*   **「前问 3.82GB」**：逐字稿開頭提及「前问 3.82GB」，後文又提及「千问3.827b」及「千问3.87b」。推測可能均指代「千問」（Qwen）系列的某個模型，但「前问」與參數量/版本號的組合（3.82GB, 3.827b, 3.87b）存在聽寫或口誤嫌疑，需查證具體模型名稱。
*   **「GPT 5.6」**：逐字稿提及「在Codex里面我就是用GPT 5.6 sol做一个巨大的plan」，GPT 5.6 並非已知公開版本，疑為口誤或特定內部版本/代號。
*   **「Luna」**：逐字稿提及「直接硬切Luna让它继续执行」，Luna 在此處指代不明，疑為模型名稱或代號，需查證。
*   **「1380 b」**：逐字稿提及「1380 b的新框架」，參數量或模型縮寫格式不常見，需查證。
*   **「Deepseaqv4.1flash」**：逐字稿結尾處拼寫為「deepseaqv4.1flash」，疑為口誤或聽寫錯誤，應指 DeepSeek V4.1 Flash。
*   **「竄稀」/「串天猴」**：作者使用的比喻詞彙，非正式名稱，但為影片核心描述詞。
*   **「Hermes 的 desktop」**：指代不明，疑為 Hermes 平台的某個桌面應用或組件。

## 可延伸追問

*   如何具體優化 DeepSeek Harness 中的上下文管理，以避免上下文污染導致的靜默問題？
*   在 Hermes 工作流中，有哪些特定的提示詞策略或配置可以進一步減少不必要的工具調用？
*   對於「1380 b」或「GPT 5.6」等疑似辨識錯誤的名稱，是否有官方文件或社群討論可查證？
*   不同工作流（Harness vs. Hermes）在架構設計上有何根本差異，導致 V4.1 Flash 表現如此不同？
*   如何平衡模型的高速輸出與工具調用的精確性，以避免「竄稀式」輸出帶來的操作困難？