<mark id="oztn4"></mark>
0
和單純的文本或圖像生成相比，代碼更明確的規則、嚴格的語法和可驗證的結果只是部分原因。更為特殊之處在于，在 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 模型的一大痛點。
03
如果說任務 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 各環節得分
04
到此為止，已經可以算出綜合排名。
令我們意外的是，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 作為性價比之王當之無愧，花最少的錢，就能買到中上的能力，而 GLM 5.1 則還在試用期。
復盤整場比賽，MiniMax M3 的奪冠也讓我們重新思考 Coding 能力的競爭。或許這條賽道上真正的比拼，早就從寫出更優雅的算法，進化到了誰能理解更復雜的工程約束，甚至擁有或是模仿一種玄而又玄的工程師嗅覺。畢竟在真實業務場景中，一個能精準定位競態條件、給出工業級修復方案的模型，遠比一個會寫快速排序的模型有價值。
在這場國產大模型的混戰中，有人比拼能力上限，有人重新定義性價比的底線。而開發者的幸福在于，你終于可以不再被價格綁架，根據團隊規模和項目需求，選一個真正適合你的“賽博同事”了。
雷峰網特約稿件，未經授權禁止轉載。詳情見轉載須知。
