國產 Coding 爭霸賽：MiniMax 爆冷登頂，DeepSeek 性價比稱王

雷峰網訊 你很難把 Coding 僅僅視為大模型的諸多能力維度之一。和單純的文本或圖像生成相比，代碼更明確的規則、嚴格的語法和可驗證的結果只是部分原因。更為特殊之處在於，在 ChatBot 到 Agent 這條進化鏈上，Coding 意味著的工具調用、數據處理和複雜流程自動化，幾乎承載了模型從“會說”走向“能幹”的絕大部分期待。一個值得關注的變化是，Coding 正在從眼花繚亂的 Benchmark 榜單中脫穎而出，成為一種模型競爭的基礎設施級指標。無論 OpenAI、Anthropic、Google 還是其他廠商，在發佈新模型時幾乎都會將 Coding 場景作為大秀肌肉的選擇。某種意義上，這就是正在形成中的行業共識，即代碼能力不僅意味著編程水平，更是衡量模型邏輯推理、工具使用和實際生產力的重要角度。我們也很好奇，國產模型如今在 Coding 這條卷生卷死的賽道里已經進化到了何種程度。為此我們選擇了五款以編程能力見長的國產模型，包括 DeepSeek V4 Pro、Kimi K2.6、Qwen 3.7 Max、GLM 5.1 和 MiniMax M3，將它們放進同一個真實工程任務的場景裡，並讓 Claude Opus 4.7 擔任裁判模型，從可運行性、正確性、可讀性、可維護性四個維度量化評分。接下來就看看，各家模型的表現如何。編者注：此次測試選用模型，為截至 2026 年 6 月 10 日各家最新款旗艦模型，故隨後發佈的 Kimi K2.7 及 GLM-5.2 均未參賽。對上述兩款模型的測試也將陸續發佈，歡迎關注。01不寫八股文，真正的壓力測試Coding 能力的測試也大有講究。HumanEval、MBPP 這些業界常見的 Coding Benchmark，本質上都在測試模型會不會寫代碼。最常見的模式就是給出一道算法題，看模型能不能給出正確的解法。只能說程序員有自己的八股文，LLM 來了也得寫一遍。這種測試和真實工程開發之間，還有著不小的距離。實際幹過開發工作的人就知道，最頭疼的是產品經理甩過來一份含混不清的需求，你得自己去理清邊界條件，此外數據庫表能跑還不夠，設計的時候就要把未來三個月的業務擴展都考慮進去。還有可維護性，你寫的代碼，同事也得能看懂，線上出了 Bug，得從日誌裡能定位到根因。跟這些相比，把代碼寫出來只是開始。所以我們不做 LeetCode 跑分，不刷榜。這次測試選擇用真實工程任務加裁判模型量化評分的模式，所有結果只有一個標準，那就是工程場景能不能用起來。我們為這五款模型設計了兩項任務。任務 A 是完整交付一套優惠券系統，從數據庫 DDL 設計到 Python 核心邏輯，再到 API 文檔和部署方案，都需要模型獨立完成。很多模型發佈的時候會選擇一些“一鍵生成”的小遊戲或者小程序作為 Coding 能力的展示，乍看亮眼，實際都是輕量級的小玩意兒。而這項測試考的就是“從無到有”的架構能力，字典表擴展性、雙模式有效期、併發鎖設計、滑動窗口防刷、模糊需求澄清，還要做到中國手機號正則校驗。任務 B 是 常見的 Bug 診斷修復，但我們在測試強度上下了功夫。模型會拿到一段包含五個預設陷阱的高併發秒殺代碼，我們要求它診斷根因並修復。陷阱包括競態條件超賣、Redis 緩存穿透、連接池配置不足、事務隔離級別不當、異常回滾遺漏。這項測試，關注的是模型“從壞到好”的工程嗅覺。裁判模型 Claude Opus 4.7 會從可運行性（30%）、正確性（30%）、可讀性（20%）、可維護性（20%）四個維度量化打分，最終成績加權計算。02優惠券系統，差點集體翻車測試剛剛開始，五款模型的表現就讓人大跌眼鏡。問題就出在需求澄清這個環節。我們在 Prompt 裡故意埋了一個模糊表述："短時間內高頻領取需攔截"。看到這裡，一個成熟的工程師就該主動追問了，什麼叫短時間，一分鐘還是五分鐘，什麼又叫高頻，五次還是十次？但令人意外的是，沒有任何一款模型主動要求我們澄清這項需求，剛才提到的參數都是模型自己假設的。工程師素養是一個很難量化的隱形維度，至少在這一關，五家打了個平手：誰都沒追問，誰也不比誰強。在後續的架構設計層面，模型的表現出現了分化。MiniMax M3 拿到了全場最高的 95 分，裁判評語是："整體屬於資深架構師水準的方案，正確性和可運行性最為出色。"它在核心服務實現環節的 70 分雖然不是最高，但防刷與併發安全環節以 80 分領先。在高併發場景下，MiniMax M3 不僅關注到了功能實現，更可貴的是系統穩定性與可用性。比如通過 Redis Lua 腳本實現庫存原子扣減，從根源上避免超賣問題，採用滑動窗口限流機制，較傳統固定窗口更精準地應對突發流量和惡意刷請求，同時引入熔斷與降級策略，在下游服務異常時保障核心業務持續運行。這一整套組合拳，被裁判稱為“工業級實現”。Kimi K2.6 與 MiniMax M3 並列拿下了架構設計環節的第一名 95 分，但它的得分路徑完全不同。裁判給 Kimi 的評語是：“整體是接近資深架構師水準的方案，正確性與可維護性最佳。”它的數據庫設計同樣採用了字典表管理優惠券類型，沒有掉進硬編碼三個 type 字段的坑裡。但 Kimi 真正的殺手鐧在可維護性，它為每個接口編寫了完整的類型註解和文檔字符串，連 Redis 連接池的異常重試策略都寫了詳細的註釋說明。Opus 4.7 在可讀性維度上給了 4 分，扣掉的 1 分是因為它用了 ASCII 流程圖來展示架構，“排版略遜”。但到了核心服務實現環節，Kimi 只拿到 70 分，與 MiniMax 持平。問題出在一個架構級的致命疏忽：Redis 扣減庫存成功後，如果 DB 落庫失敗，系統沒有最終一致性補償機制。這意味著在大促期間一旦出現網絡抖動，用戶明明搶到了券、Redis 也扣了庫存，但數據庫裡卻沒有記錄，也就是券憑空消失了。Opus 4.7 的原話是：“Redis 與 DB 無最終一致性補償機制，高併發下可能出現數據不一致。”這是一個典型的“想得周全、做得規範、但漏了最關鍵的一環”的案例。DeepSeek V4 Pro 在架構設計環節拿到了 85 份，表現尚可，裁判稱讚其“正確性最佳，幾乎完全覆蓋需求與邊界場景”。但到了核心代碼實現環節，分數跌到了 65 分。問題出在業務邏輯正確性上，Opus 4.7 發現 discount_value 範圍限制和防刷的 key_TTL 的設置有誤。前者可能導致異常折扣甚至業務規則失效，後者則意味著限流窗口過短、過長或被不斷刷新，從而削弱防刷效果甚至影響正常用戶使用，都踩在真實場景的雷區上。Opus 4.7 評語的原話是：“結構與併發處理思路最好，最差是正確性。”這揭示了一個有趣的現象，DeepSeek V4 Pro 很會"想"，但不太會"做"。它在架構層面的抽象能力堪稱一流，數據庫設計用了字典表管理優惠券類型，而不是硬編碼三個字段。但當涉及到把設計落地為可運行代碼時，它卻會在邊界條件上犯低級錯誤。此外 Qwen 3.7 Max 和 GLM 5.1 也各有可圈可點之處。Qwen 3.7 Max 在架構設計環節拿到了 90 分，裁判評語是：“正確性和可運行性表現最佳，覆蓋參考答案全部要點且落地方案完整。”它的亮點在於工程化考慮非常周全，不僅實現了核心邏輯，還主動給出了 Docker Compose 部署配置和壓測腳本，Opus 4.7 在可運行性維度上直接給了 5 分的成績。但 Qwen 的短板也很鮮明。核心服務實現只拿到 60 分，突出問題是折扣類型用 if/elif 硬編碼分支，而不是策略模式或配置化。這意味著如果下個月業務方說要新增一種“隨機立減券”，開發者必須改核心代碼、重新部署服務，這在真實工程裡是不可接受的。此外，Opus 4.7 還提到它的可讀性“相對最弱”，原因是缺少架構圖示，純文字描述讓方案的直觀性打了折扣。可以說，Qwen 是一個“能跑起來、但不好維護”的典型。這是 OPC 驗證的首選，但對於長期迭代的任務，還需要努努力。GLM 5.1 同樣在架構設計環節拿到了 90 分，裁判評語幾乎和 Qwen 的一樣：“正確性和可運行性是最強項，覆蓋參考答案全部要點並落地完整。”它的數據庫設計被 Opus 4.7 評價為“兼具可執行性與可擴展性”，優惠券類型字典表、有效期雙模式、防刷滑動窗口等核心錨點全部命中。但 GLM 在核心服務實現環節也只拿到 60 分，問題出在安全性而非架構上。Opus 4.7 發現它的 schemas.py 中，CouponCreate 的 type 字段缺少合法的枚舉校驗，這意味著攻擊者可以直接傳入一個非法的優惠券類型值，系統不會攔截，而是可能直接入庫。在真實生產環境中，這是一個潛在的安全漏洞。更致命的是併發安全環節，GLM 只拿到 75 分，是五家中的倒數第二。它的防刷實現雖然用了滑動窗口的大框架，但細節上有瑕疵。Opus 4.7 指出“限流粒度偏粗，未區分用戶級與 IP 級雙層防護”，在面對專業羊毛黨時可能會被突破。表 1：任務 A 各環節得分不過綜合成績看下來，所有模型在這項任務中的表現都算不上優秀。MiniMax M3 和 Kimi K2.6 並列第一，拿下 81.0，最低分則是 DeepSeek V4 Pro 的 73.5。放在百分制裡看，這相當於全班第一名考了 81 分。不是學霸太強，是試卷太難。這種複雜架構的從零生成，的確是今天 Coding 模型的一大痛點。03Debug 是所有人的舒適區如果說任務 A 是一次集體掛科的期中考試，那任務 B 就是期末補考。全班都及格了，甚至考得還不錯。得分最高的仍然是 MiniMax M3，拿下 89.7 分，分數最低的 GLM 5.1 也有 79.0，基本都在 80 分段以上。這意味著，給一個現成的 Bug 讓模型找，比讓模型從零寫一個無 Bug 的系統，要容易得多。在找 Bug 這件事上，MiniMax M3、DeepSeek V4 Pro、Qwen 3.7 Max 的成績並列。三家的 Bug 發現率都拿到了 90 分，也就是命中了五個預設陷阱中的至少四個。DeepSeek V4 Pro 在這一環節的表現尤其值得關注。雖然在任務 A 中排名墊底，但在 Bug 診斷中它與 MiniMax M3 和 Qwen 3.7 Max 並列第一。Opus 4.7 指出，它覆蓋了全部預設問題且結構清晰，在正確性和可讀性上表現最佳。一種可能的解釋是，或許 DeepSeek V4 Pro 的強項恰恰是理解複雜邏輯。在修復質量上，Kimi 與 MiniMax 的得分並列第一。Kimi K2.6 以 90 分的總分與 MiniMax M3 持平，裁判給了很高的評價，稱其修復方案“整體是一份接近生產級的修復方案，可讀性和可維護性最佳，包括註釋三段式、配置中心和結構化日誌。”一個值得注意的細節是，Kimi 在修復代碼中引入了配置中心，也就是將將限流閾值、連接池參數、超時時間全部外置。如果這三者被寫死在代碼裡，那麼一旦線上流量變化或環境切換，就必須重新修改代碼、測試併發布版本，維護成本很高，也容易引入新的問題。Opus 4.7 評價其為生產級的原因也在這裡，引入配置中心意味著這些運行參數與業務邏輯解耦，運維或開發人員可以根據實際負載動態調整配置，無需重新部署服務，大幅提升了系統的靈活性和可運維性。更重要的是，開發、測試、預發、生產的不同環境下往往需要不同參數配置。配置中心能夠實現統一管理、版本控制和灰度發佈，避免“本地正常、線上異常”的配置漂移問題。在高併發系統中，限流、連接池和超時參數本身就是穩定性治理的重要抓手，將其外置說明 Kimi K2.6 考慮到了系統長期運行和持續演進的需求，而不是僅滿足當前場景。在基礎修復之外，五款模型都給出了架構層面的優化建議。MiniMax M3、Kimi K2.6、GLM 5.1 在這一環節都拿到了 90 分，其中 MiniMax M3 的建議被認為在“結構化呈現 + 全維度運維考量”上最為出色，涵蓋了緩存預熱、異步落庫補償、限流降級、監控告警和容量規劃五個維度。▎容量規劃Kimi 和 Qwen 在架構優化中都提到了“擴容”，但基本上是“建議增加 Redis 節點”這種原則性表述。MiniMax M3 則給出了具體的擴容閾值和分片策略，比如 QPS 達到多少時觸發擴容、Redis Cluster 分幾個 shard、每個 shard 的內存上限設多少。Opus 4.7 正是因為這些數字而扣了它的分（“部分容量數字未給出具體計算依據”），但反過來看，敢給具體數字本身就說明它在運維落地層面想得比其他模型深一層。▎異步落庫補償機制其他模型（包括 DeepSeek V4 Pro 和 Qwen 3.7 Max）都提到了“異步寫 DB 來降低 Redis 延遲”，但基本上點到為止。MiniMax M3 則在這個基礎上補了一個補償鏈路的設計，如果異步落庫失敗，如何通過消息隊列重試、失敗後多久觸發告警、以及如何在不一致時做數據對賬修復。這是一個很多工程師在真實項目裡都會漏掉的點：寫了異步邏輯，但沒寫失敗兜底。▎灰度發佈方案MiniMax M3 的文檔中包含了漸進式灰度切流的部署策略——先小流量驗證庫存扣減一致性，再逐步放大。這個維度在 Kimi 和 Qwen 的文檔中完全沒有出現。GLM 5.1 雖然提到了“運維方案”，但更多是監控和日誌層面，沒有涉及發佈策略。DeepSeek V4 Pro 在這一環節的 80 分是全場最低，裁判評語是“缺少監控/限流具體實現細節”。有意思的是，這與它在任務 A 中展現的“架構抽象能力強但落地細節弱”的特徵高度一致。表 2：任務 B 各環節得分04MiniMax 爆冷奪冠到此為止，已經可以算出綜合排名。令我們意外的是，MiniMax M3 以 85.3 的綜合得分爆冷奪冠。其在 Bug 診斷與修復環節的表現尤為突出（89.7 分），而DeepSeek V4 Pro 雖然綜合得分排名第四（78.6 分），但憑藉最低的 API 定價，性價比指標（CPP $0.20）全場最優，是預算敏感型團隊的首選。表 3：綜合排名在此前的兩項測試任務中，五款模型表現出了迥異的特性。MiniMax M3 的 Task B 得分（89.7）全場最高，Bug 診斷和修復都堪稱工業級。如果比作工程師的話，它應該是團隊裡那個在 Code Review 時一眼看出代碼裡競態條件的人，也是那個在故障排查時最快定位根因的人。但它不是那種能從零搭建完整系統的人，至少不是做得最好的那個。Task A 的 81.0 雖然也是並列第一，但這個分數本身就意味著"還有 19 分的提升空間"。寫代碼對它來說不是舒適區，找 Bug 才是。Kimi K2.6 的表現同樣亮眼，所有子項得分都在 70-90 分之間，這是一份沒有明顯短板，還能夠一夠單項最高的成績。它的文檔和運維方案被 Opus 4.7 反覆稱讚為“最出彩”、“最詳實可落地”，其中在修復實現環節引入配置中心和結構化日誌的做法，堪稱這次比賽中工程實踐可維護性的標杆。不過之前沒有提到的一處隱憂是，Kimi K2.6 在任務 A 的核心代碼實現中遺漏了 Redis 與 DB 的最終一致性補償。在秒殺場景下，這可能是個致命的錯誤。這種畫像有點像是一個做事很規範的工程師，但偶爾也會在大局觀上失焦。Qwen 3.7 Max 的表現，用一個詞形容就是"穩"。Task A 77.5，Task B 87.0，綜合 82.2，排名第三。我們覆盤成績的時候發現，它在任何環節都沒有拿過第一名，但也沒有跌出過前三。不驚豔，但絕不會出大錯，這就是你在任何項目上都可以放心用的人。對於 DeepSeek V4 Pro，則有不小的爭議，長處和短板都相當明顯。綜合得分 78.6，排名第四的背後，是幾乎溢出的架構設計能力和火候欠缺的工程落地表現。前一腳能在需求澄清與架構設計環節拿到 85 分，後一步就在核心代碼實現上跌到 65。更極端的是，它在 Bug 診斷環節以 90 分並列第一。這說明它不是不懂，而是在從“想”到“做”的轉化過程中出了問題。GLM 5.1 的特性也很鮮明。雖然在兩項任務中都是最後一名，但它在修復實現的可讀性維度上拿到了 5 分，在架構優化環節也拿到了 90 分。這說明當給定明確方向時，它就能給出結構清晰、覆蓋面廣的方案。但在沒有錨點的創造性任務中，它容易被其他模型拉開差距。這是最適合最為輔助性編程工具的選手，人類工程師的主導和方向支持下，就會發揮出最強的性能。05性價比對決：誰是開發者的最優解？數據截至 2026 年 6 月 3 日，各模型國際官網標價：表 4：各模型官網最新 API 定價對比這份價格表裡有幾個值得注意的點。DeepSeek V4 Pro 在 5 月 31 日之後，原本的 75% off 折扣價已成為正式官方價，使其成為五家中單價最低的模型，輸出價格甚至不到 Kimi 的四分之一。MiniMax M3 採用階梯定價，目前官網正在進行限時 5 折活動，折扣後價格甚至低於 DeepSeek。Qwen 3.7 Max 是五家中最貴的，約為 DeepSeek 的 3-4 倍。光比能力不分價格，是耍流氓。假設你是一箇中小團隊的 Tech Lead，每天跑一箇中度 Agent workload（日耗 100 萬 Input Token + 10 萬 Output Token），那麼按上面這份各模型官網最新標價，一個月的賬單如下：表 5：月度成本與性價比對比可以看到幾個驚人的數字。DeepSeek V4 Pro 的 CPP（成本性價比）為 $0.20，意味著花 20 美分就能買到 1 分的能力。相比之下，Qwen 3.7 Max 買同樣的 1 分能力需要 $0.59，貴了整整 3 倍。用 Qwen 一個月的預算（$48.75），可以跑三個月 DeepSeek 還剩 $1.77。MiniMax M3 的限時 5 折價使其月度成本僅為 $12.60，CPP 僅 $0.15，甚至比 DeepSeek 還便宜。但需要注意這是限時折扣價，標準價 $25.20 的 CPP 為 $0.30，仍優於 Kimi 和 Qwen。如果你是對預算極度敏感的個人開發者或初創公司，DeepSeek V4 Pro 就是最經濟的選擇。當然對於追求折扣紅利的短期項目而言， MiniMax M3 的五折價也是一個方案。而且綜合實力最強、Bug 診斷最佳的成績，讓這款模型在標準價之下也相當有競爭力。如果想作為團隊主力長期使用，則可以考慮 Kimi K2.6。雖然綜合得分第二，但也勝在沒有明顯短板、規範性強上。而對於為生態集成買單的阿里雲用戶來說，Qwen 3.7 Max 的表現也同樣可靠。如果把這次評測比喻成一場招聘面試，五家模型各自拿到了不同的 offer。MiniMax M3 是高級工程師，Bug 排查能力全場最強，但入職後需要配一個架構師幫它把關從零建系統的活兒。Kimi K2.6 拿到了技術骨幹的 offer，沒有明顯短板，規範性強，是任何團隊都可以放心託付的主力。Qwen 3.7 Max 更像資深工程師，穩健可靠，但工資要求最高。DeepSeek V4 Pro 作為性價比之王當之無愧，花最少的錢，就能買到中上的能力，而 GL