國產大模型跑分一個比一個高，到底誰能真的干活？

最近這幾個月，相信大家都被大模型反復“轟炸”了，從4月的DeepSeek V4開始，然后是GLM 5.2 、Kimi 2.7、MiniMax M3，每一個大模型都會拿出跑分來證明，說自己非常厲害。

但是在實際的工作中，它們到底是“真神”還是“花架子”？ 這個問題可能每個人都有自己的看法。

作為一名混跡后端多年的資深碼農，我不太看重這些評分，更相信自己的手感。

所以，我打算掏點兒真金白銀，把DeepSeek V4 Pro、Kimi 2.7、MiniMax M3拉到同一個競技場(GLM 5.2缺席，實在搶不到它的Coding Plan)，在長上下文、多模態理解、辦公、Coding領域找一些真實場景，看看它們的表現到底怎么樣。

01

真實代碼修復

現在的大模型如果不配置1M上下文，感覺都不好意思和人打招呼了。

既然如此，那我就不客氣了，找一個大型項目試一試。

Django，我很早之前用過的一個Python Web框架，大概有50萬行Python代碼，足夠大了。

不但考驗各個模型的長上下文窗口，更考驗它的有效理解和推理能力。

我還特意找了一個真實的issue：

https://code.djangoproject.com/ticket/36940，

打算讓這個三個模型修復一下，看看效果如何。

不過這個issue寫得太細節了，直接展示了要改的class，不好不好，我重新寫了一下，站在用戶角度描述：

提示詞（可上下滾動）

在Django部署了兩個應用：

/myapp/ → 應用 A

/myapplication/ → 應用 B

最近有用戶報告以下異常行為：

用戶反饋 1: 當用戶訪問https://example.com/myapp/profile 行為正常，進入自己的 profile 頁面。

用戶反饋 2：當用戶訪問：https://example.com/myapplication/profile 返回了404

你幫我看看是怎么回事？

結果，可能是我這個描述寫得有過于貼近用戶了，導致難度過高，三個模型雖然都猜到了大概的問題，但是都把注意力放到了應用的urls.py文件，而不是修復框架的Bug。

沒辦法，我只好更加明確一點，提示它們去框架的ASGI模塊去看看。

這一下，差別就出來了。

MiniMax M3精準地定位了Bug： removeprefix是純字符串前綴匹配，不尊重路徑段邊界。

這正是產生這個Bug的準確原因。

給出的修復建議也非常準確： 按“段邊界”做strip.

更讓我意外的是，它還對比了WSGI ，說WSGI 服務器把 SCRIPT_NAME 和 PATH_INFO 分開傳給 Django，Django 不做 strip，直接讀 PATH_INFO，ASGI 這層自己動手strip，反而引入了 bug。

嗯，舉一反三，觀察全局，感覺像個老程序員的樣子。

相比而言，Kimi 2.7 和 DeepSeek V4 Pro 還是沒有定位到問題。

Kimi說真正出問題的地方在resolvers.py ：

神奇的是，DeepSeek 也認為 ASGI Handler沒問題，認為問題出在resolvers.py，兩個家伙像商量好的一樣。

不過，我再稍微提示一下，Kimi 和 DeepSeek都能正確地解決問題了。

可以看出，三個大模型都準確地理解了問題，并且推導出是url解析匹配的問題。

但是真正定位的時候，MiniMax M3表現要好一些，找到了準確的地方，Kimi 和 DeepSeek差不太多，還需要進一步輔助。

不過我必須得說一下，對于這種巨型復雜項目中一個細碎的Bug，定位和修復起來是非常有挑戰的，關鍵的問題就是一定得提供足夠的上下文信息，否則即使是一個非常有經驗的程序員，他也不一定能快速搞定，更不用說初次面對這個源碼的大模型了。

M3 的 1M 上下文確實很長，但在使用上也有些注意事項，它主要用于項目級代碼理解和重構，長文檔全文處理，不適合短問答/單輪對話，以及無上下文依賴的輕量創作。

在Agent中使用的時候默認還是512K 上下文，需要 1M 的還要手動切換，Prompt結構最好是固定內容前置(系統提示、參考文檔、代碼庫)，變化內容后置(當前查詢)，這樣可以提升cache命中率。

更詳細的用法可以參考一下MiniMax官方在小紅書上分享的使用指南：

02

城市躲避游戲

測完了大型項目的代碼修復，接下來我想試試這幾個國產模型的綜合編程能力。

我不想用電商網站、博客等CRUD的系統，太簡單了，我打算用3D游戲來考驗一下它們，畢竟3D游戲涉及到多個技術領域的協同：

3D 圖形（Three.js），數學（向量、矩陣、碰撞檢測），物理模擬，相機控制，動畫系統， 輸入系統（鍵盤、鼠標）， 游戲狀態管理， UI 與 HUD....

這種測試更接近真實的軟件工程，也更能拉開模型之間的差距。

提示詞（可上下滾動）

請生成一個完整的 HTML 文件，實現一個可以直接運行的 3D 城市躲避游戲。

要求所有代碼寫在一個 HTML 中，僅允許使用 Three.js，不得依賴任何外部模型、貼圖、音頻或其他資源，所有場景和物體都需要程序生成。

游戲玩法

玩家扮演一名城市中的行人，需要不斷向前奔跑，在繁忙的街道中躲避車輛，同時盡可能收集金幣獲得更高分數。

游戲目標是在保證生存的情況下獲得最高分。

玩家控制

WASD 控制移動

Space 跳躍

Shift 加速奔跑

鼠標拖動旋轉視角

攝像機采用第三人稱跟隨模式，能夠平滑跟隨玩家

城市場景

自動生成一個具有現代城市風格的場景，包括：

道路

十字路口

人行道

建筑物（高度隨機，要帶窗戶紋理）

樹木

路燈

紅綠燈

草地區域

整個城市不需要無限大，但要有一定規模，避免場景過于單調。

所有建筑均使用程序生成。

車輛系統

自動生成不同顏色和尺寸的車輛。

車輛需要：

沿道路正常行駛

在路口能夠轉彎或直行

保持合理車速

不要互相穿模

數量會隨著游戲時間逐漸增加

車輛應持續刷新，而不是一次生成后保持靜止。

收集系統

地圖隨機生成金幣。

玩家接觸金幣后：

金幣消失

播放簡單動畫

分數增加

隨機位置重新生成新的金幣

碰撞規則

玩家撞到汽車：

扣除生命值

玩家短暫后退

有短暫無敵時間

生命值歸零：游戲結束

顯示最終得分

支持重新開始

難度系統

游戲運行過程中：

每隔 30 秒：

汽車數量增加

汽車速度略微提升

金幣刷新速度提高

難度應平滑增長。

HUD

屏幕左上角實時顯示：

當前分數

剩余生命

游戲時間

當前難度等級

游戲結束時顯示：

Game Over

最終得分

存活時間

Restart 按鈕

光照

至少包含：

環境光

平行光（太陽）

陰影

畫面具有一定層次感。

動畫效果

包括但不限于：

玩家跑步動畫（可簡單擺臂）

金幣旋轉

汽車持續運動

攝像機平滑跟隨

玩家受擊動畫

性能要求

即使存在：

數十輛汽車

上百棟建筑

多個金幣

依然保持流暢運行。

盡量減少重復創建對象。

代碼要求

代碼結構清晰，建議劃分為：

場景初始化

玩家控制

城市生成

車輛系統

金幣系統

碰撞檢測

UI

游戲循環

所有邏輯放在一個 HTML 文件中，可直接保存后打開運行。

這次測試的結果比較有意思，首先三個模型都是一次開發完成，立刻可以運行，角色移動，Shift加速，Space跳躍，鼠標拖動旋轉視角，收集金幣，躲避車輛全都一次實現，可見國產的模型現在發展得都相當不錯了。

從實現速度上來看， DeepSeek v4 Pro > Kimi 2.7 > MiniMax M3。

但我也注意到，MiniMax M3慢的主要原因是它寫完代碼后，主動進行了測試，這也讓它在邏輯實現上基本沒有問題，而另外兩家多少有點兒小Bug。

從效果上來看，DeepSeek構建了一個密集街區的“水泥森林”，樹和路燈太多了，操作起來略微費勁，道路、長椅、垃圾箱、金幣實現得都不錯，角色和車輛碰撞時實現了抖動、變色的特效。

（注意：由于我要求不依賴任何外部模型和貼圖，所以人物、車輛、樹基本上都是幾何體的堆疊，這不是測試的重點，不用在意。）

（DeepSeek的效果）

有個唯一的小Bug：開場時，由于玩家操作的人物出現的位置是隨機的，有時候會被困某個障礙物中，動彈不得，不過這是個小問題。

MiniMax M3 生成的地圖區域很大，顯得比較空曠，光影效果也可以，有意思的是它還給角色戴了一個小紅帽。

像DeepSeek一樣，基本功能也都實現了，我還注意到還實現了雙向兩車道效果，DeepSeek有時候會出現兩車互相穿過，MiniMax這邊不存在這種情況。

（MiniMax M3的效果）

Kimi設計的街區也很空曠，也實現了基本功能，就是角色形象丑一點兒，道路也沒有體現出那種柏油馬路的效果，垃圾桶、長椅、路燈也不太好看，但是建筑設計得錯落有致的，在玩兒起來的時候感覺更加絲滑。

（Kimi 2.7效果）

Kimi在開始的時候有個比較嚴重的Bug，就是“上下鍵”的效果弄反了，稍一提示就改了過來：

總的來說，我覺得DeepSeek V4 Pro呈現的效果最好，MiniMax M3 在邏輯上實現得最完善。

03

PDF 問答

前面兩個都是讓大模型看代碼，寫代碼，在辦公領域，它們的表現怎么樣呢？

我找了一個英偉達的2025年報PDF，這個文件很大，48M，181頁。

我想把它發給三個大模型，看看它們能不能像一個人一樣“讀文件做工作”，能不能在幾十頁甚至上百頁的文檔里準確找到需要的數據，看懂表格里的數字關系，把分散在不同頁面的信息拼起來，再做一步甚至多步計算，最后給出一個靠譜的答案，而不是憑感覺亂猜。

問題1：Data Center 收入與 Gaming 收入相比，在 FY2025 是多少倍？

這個問題比較簡單，就是從表格中提取數據。

MiniMax M3 找到了正確的表格，數據最為精確：

DeepSeek 和 Kimi 又像商量好似的，不約而同地找到了另外一個表格中的粗略的值，真是有意思：

問題2 ： 計算 NVIDIA 從 FY2023 到 FY2025 的營收復合年增長率（CAGR）。

這個問題不但涉及到數據提取，還要進行多步計算，三個模型的回答都非常漂亮，完全一致，這里貼一個MiniMax M3的截圖：

問題3：在 FY2025 中，是 Data Center 對營收增長的貢獻更大，還是其他所有業務合計貢獻更大？請給出計算過程。

這個問題就更難了，有點兒像分析師的工作了，這次三個模型都正確地計算了英偉達總營收的增長，Data Center的增長，其他業務的增長，并且計算得出了結論：DataCenter的貢獻更大。

但是很明顯，MiniMax M3給出的結果最詳細，最清晰，最精確：

總之，給我的感覺是三個大模型在對PDF問答時表現都相當好，MiniMax M3相對更加精準一些。

04

金融場景

我在測試MiniMax的時候，偶然間發現MiniMax Agent 網頁端上線了金融場景相關的模塊。

https://agent.minimaxi.com/

通過它可以鏈接金融數據庫，目前覆蓋A/H/美股、基金、期貨、固收和宏觀數據的問答場景。

比如，可以問它一個問題：中證紅利低波動指數最近半年怎么樣？

這對于投資/炒股的同學來說是個相當不錯的工具，有空大家可以去試一下。

05

我發現做這種評測還是挺費勁的，先構思場景，然后每種場景都得讓幾個大模型都跑一遍，仔細觀察和分析，看看它們的輸出結果，很耗費時間（我甚至有點兒慶幸，沒有搶到GLM-5.2，要不然就更費勁了）。

不過，觀察各個大模型在同一場景進行競賽，也是挺有意思的一件事情，從我有限的測試看：

三個大模型PDF問答方面都非常棒，都能理解問題，進行準確推理和計算，可以成為辦公的好幫手了。

MiniMax M3 在大型代碼庫修復Bug，長上下文方面超出我的預料，非常精準。

在復雜的3D游戲領域，DeepSeek V4 Pro干活兒很快，代碼也寫得很好，很老道，MiniMax M3 在邏輯方面考慮得很完善，Kimi 2.7 則中規中矩。

總之，我覺得完全可以放心地把這些國產開源大模型接入到工作流當中了，但是程序員還得盡可能地去提供更多上下文，指導AI工作。

下一次測試我會爭取更多的場景，更多的模型（尤其是海外的模型），也希望國產開源模型有更優異的表現。