鴿了這麼久，DeepSeek V4 終於發佈了，慶幸不是在五一假期。
新模型的定位非常明確，主打代碼能力與超長上下文處理，符合當下最迫切的需求。
國內也已經有其它幾款百萬上下文模型，但一般都是線性注意力模型，DeepSeek V4 則依靠的是稀疏注意力機制，前者弱化注意力連接強度，後者弱化注意力關注範圍。
當然在實戰下，這些都不重要，還是來看結果吧。知危此次的關注點也會在這兩個維度上，並分別在網頁端和 Claude Code 上測試。
首先關註上下文長度的有效性。業內其實都默認，百萬上下文中有用的基本不到四分之一，能達到二分之一的算神級了。
檢測上下文有效性最便捷的方式是 「 大海撈針 」，就是在大量文本中找目標標記。
知危選取了一本中文版一百萬字級別的小說，總計 900 頁左右，先在開頭加上了一個標記「 deepseekv4 」，然後每隔 100 頁左右隨機插入一個，總計 10 個 「 deepseekv4 」 標記。
然後在網頁端開啟專家模式，將小說的 txt 文檔直接發送給 DeepSeek，並提問：「 查找這個文檔里有幾個 『 deepseekv4 』，並指出第 5 個的位置。」
DeepSeek 沒有思考多久就給出了答案，很明顯 「 總數 5 個 」 是錯的，而且除了第一個最容易找的，其它幾個都錯了，比如關於第三個標記的位置描述，其實是第四個標記的，其它幾個描述的位置並不存在標記。
DeepSeek 提供的答案 「 5 個 」 和我的問題是相關的，所以我又換了個問法，讓它查找第 3 個。結果這回 DeepSeek 找到的標記數從 5 個變成了 2 個。
這個結果並不讓人意外，畢竟都把上下文填滿了。
接下來，我們把文本長度直接減半，看看效果如何。減半後，標記數量剩下 5 個，並讓 DeepSeek 指出第三個的位置。
DeepSeek 沒有準確指出標記總數，但準確地找到了第三個標記的位置。
但再讓它找第四個時，它找到的是第五個標記。
總體結果是不夠令人滿意的，無法認為 DeepSeek V4 的上下文有效性能達到二分之一。
所以我們再次將文本減半，標記總數剩下 3 個，並讓 DeepSeek 找第二個標記的位置。這回 DeepSeek 準確地算出了標記的總數，但又把第三個標記認成了第二個。
最後一次減半，標記總數剩下 2 個，並讓 DeepSeek 指出第二個的位置。這回 DeepSeek 總算兩個任務都成功了。
當然，到這裡問題已經過度簡化了，剩下的兩個標記一個在開頭一個在末尾，都是比較好找的。因此我再次在中間位置隨機插入一個標記，看 DeepSeek 能不能過這一關，結果又翻車了，它居然說總共只有一個標記，但實際上有 3 個。
最後這個版本大概 10 萬字，大約相當於 10 萬 token，已經只有十分之一總長度了。
到此，對 DeepSeek V4 的有效上下文還沒有明確的邊界。只是在實戰中，簡單寫個網頁的初版都能達到 5 到 8 萬個 token，DeepSeek V4 能在實戰中穩住幻覺率嗎？
那就直接試試吧。直接用之前測試過 GPT-5 和 Gemini 3 Pro 的網頁版 Excel 案例來上難度。
DeepSeek 給到的第一版，先別說其它錯誤有多少，剛要點擊單元格輸入，網頁就白屏了。
由於錯誤太多，我直接讓 DeepSeek 自己檢查錯誤並修復，然後 DeepSeek 給了我一個白屏。
於是我先把難度降低，讓它寫一個 2048 小遊戲，這回順利完成了。
再往上挑戰一下高難度，構建一個 3D 樂高積木軟件，這次倒是一次成了，基本功能都能實現，就是沒有實現自由選擇零件的功能，只能使用一種長方形板磚積木。
提示 DeepSeek 修復這個問題後，它給了我沒有任何變化的修改版。
再次降低難度，讓它生成一個樹生長的動畫，按照推特上的展示，Qwen 3.6 和 Gemma 4 能很好完成這個任務。
提示詞：
用一個包含全屏畫布的 HTML 文件（ 不使用任何庫 ）來製作一棵樹的動畫，樹從屏幕底部中心實時生長。樹榦首先向上生長，然後樹枝以遞歸的方式分叉，角度和長度略有隨機性。每一代樹枝都應該更細，顏色略淺。當樹枝達到最終大小時，在枝梢添加一些柔和的綠色小圓圈作為葉子。樹完全生長大約需要 15 秒。使用暖棕色表示木頭，使用各種綠色表示葉子，背景為柔和的天藍色漸變。
結果很不錯，DeepSeek V4 不僅完成了任務，最終畫面還有不錯的美感。
到這裡，DeepSeek V4 的整體表現天花板不高，也不夠穩定。
但在 Claude Code 框架下的編程模型通常能更好發揮，所以接下來要將 DeepSeek V4 接入 Claude Code 來繼續測試。
然後，它給我寫了一個初始化狀態錯誤所以沒法玩的 2048 小遊戲。
當然，這只是個小錯誤，但也能看出 DeepSeek V4 出現幻覺的概率挺高的，即便在比較簡單的任務下。
接下來我們還要嘗試一個新場景，用網頁模擬康威生命遊戲，模擬時長一分鐘，並能實時通過鼠標點擊加入新種子，難度介於 Excel 和模擬樹生長之間。
提示詞：
請使用單個 HTML 文件實現一個完整的《康威生命遊戲（Conway』s Game of Life）》動畫程序，要求如下：
一、技術約束
僅使用 HTML + CSS + 原生 JavaScript
禁止使用任何第三方庫或框架
所有代碼必須寫在同一個 HTML 文件內
不允許引入外部資源（CDN、圖片庫等）
二、畫布與渲染
使用
<canvas>
作為全屏繪製區域
自動適配瀏覽器窗口大小（100% 寬高）
支持高分辨率屏幕（考慮 devicePixelRatio）
網格應為等比例方格（例如 10px～20px 可調）
三、遊戲邏輯（康威生命遊戲規則）
每個細胞只有兩種狀態：存活 / 死亡
每一代按照經典規則更新：
少於2個鄰居 → 死亡（孤立）
2或3個鄰居 → 存活（延續）
超過3個鄰居 → 死亡（過度擁擠）
死細胞剛好3個鄰居 → 復活
四、初始化狀態
初始隨機生成 40%~60% 的存活細胞
支持預設一個有趣的圖案（如滑翔機 + 隨機噪聲混合）
五、動畫要求
動畫持續運行 60秒
幀率控制在 10～30 FPS（避免過度計算）
60秒結束後：
自動停止更新
停留在最終狀態
六、視覺效果
存活細胞：亮綠色方塊
死亡細胞：黑色或深色背景
可選輕微視覺增強（例如漸隱、拖影效果），但不能影響性能
背景簡潔，無多餘 UI
七、性能要求
必須使用二維數組或優化結構存儲狀態
更新時避免重複 DOM 操作（只用 canvas 重繪）
盡量優化鄰居計算（避免 O(n²) 過重實現）
八、增強（加分項）
支持暫停 / 繼續（按空格鍵）
支持點擊畫布切換細胞狀態
支持按 R 重置隨機世界
DeepSeek 的實現結果很漂亮，而且確實可以用鼠標添加種子，把一些進入靜息狀態的生命再次激活。
DeepSeek V4 這次的任務執行時長是分鐘級。作為對比，GPT-5.3 幾乎是瞬間就生成了代碼，簡直是複製黏貼般的速度，而且程序也能正常運行，當然，視覺上的粒度和審美感要差了很多。
最後我們還是讓 DeepSeek V4 再次挑戰一下網頁版 Excel 案例。
在純自主執行的條件下，DeepSeek V4 用將近半小時實現了一個基本完成的版本，但還是有一些小錯誤，比如對齊功能失效。
其實按照開源模型目前在 Coding Agent 生態中的定位，還是更合適在頂尖閉源模型把控下做具體的執行工作。
所以，我先把任務傳遞給 GPT-5.3，讓它給出執行規劃，然後把任務和規劃一併給到 DeepSeek V4 執行。
這回，DeepSeek V4 給了一個漂亮的結果，基本沒有錯誤。
根據 Claude Code 的 Context 統計結果，當前上下文總量是 81.6k token，占上下文極限的 8% 。
最後看看 API 用量，以上四個任務，總共花了 8 人民幣左右，將近百分百都是 DeepSeek V4 Pro 模型消耗的。
但這並不意味着 DeepSeek V4 Flash 模型沒有發揮作用，更具體的數據表明，DeepSeek V4 Flash 模型的調用次數和 DeepSeek V4 Pro 相當，就是 token 消耗量少一個量級。
到這裡測評就結束了。
從目前測試結果來看，DeepSeek V4 的百萬上下文長度有效性百分比不是很高，幻覺率較高導致不管在簡單還是較困難的任務中都有可能出現低級錯誤，導致表現不穩定。在 Claude Code 中的代碼審查階段，有時要消耗三分之一到一半的時間來改代碼。
思考時間過長可能是最尷尬的問題。即便是網頁版 Excel 也不算很複雜的案例，而 DeepSeek V4 動輒十幾分鐘的思考時間，加上執行時間就更久了，總時長經常達到三十分鐘左右。
其實人們現在對思維鏈已經祛魅了，它頂多是通過提升算力來提升準確率的工程手段，在 Coding Agent 場景中可能大部分都被忽略不看。
模型能力上限使其不太可能在實際編程任務中擔任主導角色，作為執行者速度又太慢，關閉 Thinking 模式或者換成 Flash 模型是否還能保證執行準確率，時間原因，目前知危這裡還沒有測試案例可循。
總的來說，從我們測試的這些案例的視角來看，DeepSeek V4 的表現沒有想像中的好，並且能力表現似乎也不是特別穩定。但是其實官方技術報告里本來也就大大方方的說了自己跟閉源頂級模型仍有差距，本次更新只是縮小了差距，所以這個結果也不意外。
但是吧，還是那句話，你再看看它的價格，都這麼便宜了，能忍。
