圣誕寫代碼，AI誰最強？M2.1、GLM-4.7、K2正面硬剛

作者 ｜ 周一笑
郵箱 ｜ zhouyixiao@pingwest.com

2025年的圣誕節，大模型戰場沒有停戰。

12月23日，MiniMax正式獲得中國證監會備案通過。加上此前通過港交所聆訊，這家成立不到四年的AI公司，距離敲鐘只剩一步之遙，按目前節奏，MiniMax計劃于2026年1月登陸港股，也將成為從成立到IPO最快的AI公司。

而就在IPO沖刺的關鍵節點，MiniMax沒有選擇低調，反而高調發布了新一代文本模型M2.1。

在這個背景下，M2.1的發布更像是一份寫給市場的答卷。不只是會講故事，產品也在持續進化。

那么問題來了，M2.1的實際表現究竟如何？我們決定用最直接的方式驗證，讓它和另外兩個國產模型（智譜GLM-4.7、月之暗面Kimi K2）正面PK。同樣的任務，同樣的標準，看看他們的表現怎么樣。

1

實測：三大國產模型的圣誕編程對決

我們設計了三個測試任務，覆蓋"從0到1"的前端生成、物理引擎實現、以及科學可視化場景。測試環境統一使用Cursor接入各模型API，Prompt完全一致，均為one-shot。

圣誕祝福網頁

第一個任務相對基礎，生成一個帶雪花動畫、圣誕樹、閃爍彩燈的節日祝福頁面。我們在Prompt中給出了明確的技術規格，包括顏色參數、動畫要求、性能約束等。

Prompt：

需求：圣誕節祝福單頁應用

技術棧

- 純前端實現，單HTML文件，內聯CSS和JavaScript

- 動畫使用CSS Animation + requestAnimationFrame

- 不依賴外部庫

視覺規格

- 背景：深藍色漸變( → )

- 雪花：50個白色圓點，隨機大小(2-5px)，勻速下落+輕微橫向擺動

- 主標題："Merry Christmas 2025"，字體Playfair Display（Google Fonts），金色()，帶text-shadow發光

- 圣誕樹：純CSS繪制，三層三角形堆疊，樹干用棕色矩形

- 彩燈：樹上8-10個小圓點，紅/綠/金三色，opacity閃爍動畫，周期錯開

性能要求

- 雪花動畫使用transform而非top/left，避免重排

- 控制總動畫元素數量，保證60fps流暢

響應式

- 移動端標題字號縮小，圣誕樹等比縮放

請輸出完整可運行的HTML代碼。

M2.1的cursor過程記錄：

需求：圣誕節祝福單頁應用

技術棧

純前端實現，單HTML文件，內聯CSS和JavaScript

動畫使用CSS Animation + requestAnimationFrame

不依賴外部庫

視覺規格

背景：深藍色漸變( → )

雪花：50個白色圓點，隨機大小(2-5px)，勻速下落+輕微橫向擺動

主標題："Merry Christmas 2025"，字體Playfair Display（Google Fonts），金色()，帶text-shadow發光

圣誕樹：純CSS繪制，三層三角形堆疊，樹干用棕色矩形

彩燈：樹上8-10個小圓點，紅/綠/金三色，opacity閃爍動畫，周期錯開

性能要求

雪花動畫使用transform而非top/left，避免重排

控制總動畫元素數量，保證60fps流暢

響應式

移動端標題字號縮小，圣誕樹等比縮放

請輸出完整可運行的HTML代碼。

Thoughtfor 1s

用戶想要創建一個圣誕節祝福的單頁應用，使用純前端技術實現。讓我仔細分析需求：

技術棧要求

純前端單HTML文件

內聯CSS和JavaScript

CSS Animation + requestAnimationFrame

不依賴外部庫

視覺規格

背景：深藍色漸變( → )

雪花：50個白色圓點，隨機大小(2-5px)，勻速下落+輕微橫向擺動

主標題："Merry Christmas 2025"，字體Playfair Display（Google Fonts），金色()，帶text-shadow發光

圣誕樹：純CSS繪制，三層三角形堆疊，樹干用棕色矩形

彩燈：樹上8-10個小圓點，紅/綠/金三色，opacity閃爍動畫，周期錯開

性能要求

雪花動畫使用transform而非top/left，避免重排

控制總動畫元素數量，保證60fps流暢

響應式

移動端標題字號縮小，圣誕樹等比縮放

我需要創建一個完整的HTML文件，包含所有這些功能。讓我開始編寫代碼。

我來為你創建一個精美的圣誕節祝福單頁應用！

christmas.html(new)

+415-1

Thoughtfor 1s

Thoughtfor 1s

完美！?? 圣誕節祝福單頁應用已經創建完成！

文件位置

/Users/smiletalker/Desktop/minimax demo/christmas.html

功能特性

? 視覺效果

深藍色漸變背景 ( → )

50個飄落雪花，隨機大小 (2-5px)

金色發光標題 "Merry Christmas 2025"（使用 Playfair Display 字體）

純 CSS 繪制的三層圣誕樹 + 棕色樹干 + 金色星星

9個彩燈（紅/綠/金三色），錯開時間閃爍

? 性能優化

雪花動畫使用 transform: translate3d() 而非 top/left，避免重排

使用 requestAnimationFrame 保證 60fps 流暢動畫

will-change: transform 提示瀏覽器優化

? 響應式設計

移動端自動縮小標題字號

圣誕樹等比縮放適配不同屏幕

? 動畫效果

標題發光脈動動畫

彩燈閃爍動畫（不同相位）

祝福語淡入上升動畫

使用方法

直接在瀏覽器中打開 christmas.html 文件即可查看效果。也可以雙擊文件或拖入瀏覽器中打開。祝你圣誕節快樂！?

三款模型都在幾秒內完成了代碼生成，我們直接來看效果。

M2.1 的效果很完整，雪花勻速飄落，軌跡自然，圣誕樹上的彩燈按紅、綠、金三色閃爍，節奏錯開，和Prompt描述一致。整體視覺干凈，唯一的不足就是圣誕樹做的有點小，代碼一次跑通：

K2的視覺效果依然不錯，但是把彩燈理解成了獨立的裝飾元素，沒有掛在樹上，而是單獨做了一組燈串。這也反映出模型在理解空間關系時的差異：

GLM-4.7 完成了整體框架，圣誕樹和標題都正常渲染，也是最標準的“圣誕樹”，但雪花動畫在部分區域出現了缺失，飄落覆蓋范圍不完整：

圣誕物理小球模擬器

第二個任務提高難度，用Canvas實現一個2D物理引擎，20個圣誕裝飾球在重力作用下掉落、碰撞、反彈，支持鼠標拖拽交互。

這個任務考驗的不只是代碼生成能力，還包括對物理邏輯的理解，重力加速度、碰撞檢測、能量衰減，每一個參數都會影響最終的“手感”。

Prompt：

圣誕主題物理引擎Demo

概述

實現一個基于Canvas的2D物理模擬，圣誕主題裝飾球在重力和碰撞下運動。

技術實現

- 渲染：HTML5 Canvas 2D Context

- 物理循環：requestAnimationFrame，固定時間步長16ms

- 碰撞檢測：圓-圓碰撞（距離判定），圓-邊界碰撞（AABB）

物理參數

| 參數 | 值 |

| 重力加速度 | 0.3 px/frame2 |

| 碰撞恢復系數 | 0.7 |

| 摩擦/阻尼 | 0.99 |

| 小球數量 | 20 |

| 小球半徑范圍 | 15-30px |

視覺設計

- 背景：

- 小球顏色：隨機取自['', '', '', '']

- 小球樣式：徑向漸變 + 白色高光點模擬3D感

- 雪花：30個，勻速下落，循環

交互

- 鼠標按下拖拽小球

- 鼠標釋放時，根據拖拽速度給小球一個初速度

代碼結構建議

class Ball { position, velocity, radius, color, update(), draw() }

class PhysicsEngine { balls[], gravity, detectCollision(), resolve() }

主循環: update() → draw() → requestAnimationFrame

請輸出完整單文件HTML。

M2.1 完整實現了物理引擎的核心邏輯，小球從屏幕頂部落下，相互碰撞時會彈開，觸碰邊界會反彈，鼠標可以拖拽拋擲。整體流暢度不錯，不過當多個小球堆積在底部時，會出現輕微的“鬼畜”，這是碰撞檢測精度的常見問題：

K2 的表現和M2.1接近，物理引擎運行正常，同樣存在底部堆積時的細微抖動。兩者在這個任務上的完成度相當：

GLM-4.7 生成了一個靜態的場景布局，小球和背景都正常渲染，但物理循環沒有啟動，畫面保持靜止。需要額外調試才能讓小球動起來：

前沿科學研究的可視化

第三個任務是基于最近一篇真實的科學新聞（斯圖加特大學團隊在《Nature Communications》發表的量子隱形傳態研究），生成一個交互式的科學可視化頁面，包含粒子動畫、糾纏態演示、狀態坍縮效果等。綜合考驗模型對科學概念的理解、Canvas粒子系統的實現、以及學術美感的視覺呈現。

Prompt：

任務：構建“量子隱形傳態”交互式科學落地頁

核心目標：

基于 2025年12月22日發布的最新新聞（斯圖加特大學團隊在《Nature Communications》發表的量子隱形傳態突破），創建一個高端、極簡、具有 Nature 期刊質感的 單頁 HTML 應用。

內容素材 (基于新聞事實)：

1. 標題：Quantum Teleportation Realized: The Stuttgart Breakthrough (Dec 2025)

2. 核心發現：研究團隊利用專門設計的半導體光源（semiconductor light sources）生成了無法區分的“雙胞胎光子”（Doppelganger Photons），成功在物理隔離的實驗室環境間傳輸了量子極化狀態。

3. 意義：這是邁向“量子互聯網”（Quantum Internet）和“不可破解網絡”（Unhackable Life）的關鍵一步。

技術棧 (Engineering Specs)：

- 結構：單文件 HTML (HTML5 + CSS3 + ES6 JS)。

- 渲染：文字排版使用 CSS Grid/Flex；核心可視化使用 HTML5 Canvas。

- 無依賴：不引入外部庫，所有邏輯手寫。

視覺設計 (Vibe Coding - High End Academic)：

1. 配色：深邃的“量子黑”背景 ()，搭配“激光紅” () 和 “糾纏藍” () 作為高光色。文字使用類似 LaTeX 的襯線字體 (Times New Roman 或 Georgia)。

2. 交互式 Canvas 演示 (Hero Section)：

- 場景：繪制兩個物理分離的節點（Alice 和 Bob）。

- 粒子系統：生成大量微小的粒子流代表光子。

- 交互邏輯：

- 用戶點擊“Generate Entanglement”按鈕。

- 屏幕中間生成一對糾纏光子（顏色不斷變換，表示 Superposition）。

- 光子分發給 Alice 和 Bob。

- 用戶點擊 Alice 端的光子進行“狀態測量”（State Measurement）。

- 瞬間（瞬間！），Bob 端的光子狀態坍縮為與 Alice 一致（視覺上顏色瞬間同步鎖定），并伴隨發光漣漪特效。

3. 排版風格：模仿頂級學術期刊的排版，大留白，左側為可交互演示，右側（或下方）為優雅的新聞摘要卡片。

輸出要求：

輸出完整的、可直接運行的 `index.html` 代碼。確保 Canvas 動畫流暢，粒子效果具有高級感（使用 globalCompositeOperation 實現光暈疊加）。

M2.1 的實現視覺效果不錯，粒子流動順暢，糾纏態的顏色變換和狀態坍縮的漣漪特效都較為細膩。整體呈現出Prompt要求的前沿學術質感，用戶點擊測量時，粒子瞬間坍縮、變色的動效，非常視覺化地呈現了“量子糾纏”這個抽象的概念：

K2 采用了一種獨特的實現思路，交互邏輯和視覺布局都與另外兩款有所不同，反而帶來了新鮮感，效果同樣可圈可點。

GLM-4.7 在這個任務上恢復了水準，視覺呈現和交互邏輯都較為完整，粒子效果也有不錯的層次感：

通過我們的一些測試，我們能夠看到國產大模型在 Coding 能力上的整體水位都不錯。在基礎的代碼生成上，三家都能做到。但M2.1 給我們的感覺是，指令遵循方面表現穩定，輸出和預期的一致性更好。但總的來看，沒有哪款模型能在所有任務上碾壓對手。選擇哪個，取決于你的具體場景和偏好。

1

從M2到M2.1的延續與升級

在繼續聊M2.1之前，先簡單回顧一下M2。

今年10月，MiniMax發布并開源了M2，主打“Agent原生”和”極致性價比”，價格只有Claude Sonnet的8%，速度快一倍。發布后，M2迅速在OpenRouter上爬升至全球前五、開源第一，在GitHub的Cline、Roo Code等開發者社區引發熱議。

用MiniMax自己的話說，M2解決的是“成本和可訪問性”問題，讓更多人用得起、用得上。

而M2.1要解決的問題，是怎么在真實世界的復雜任務里，真正頂用。

官方給出的四大升級方向：

1. 多語言編程能力： 系統性提升了Rust、Java、Go、C++、Kotlin、TypeScript、JavaScript等語言的能力，覆蓋從底層系統到應用層開發的完整鏈路。不再只是”Python專精”，而是全棧都能打。

2. Web與App開發： 針對業界普遍存在的移動端開發短板，M2.1顯著加強了原生Android/iOS開發能力，同時提升了設計理解與美學表達——官方的說法是“讓vibe coding成為可持續、可交付的生產實踐”。

3. 更簡潔高效： 相比M2，M2.1的輸出更精煉，思維鏈更簡潔，響應速度更快，token消耗更低。這對于實際開發場景很重要，沒人喜歡一個”話癆”模型。

4. Interleaved Thinking： 作為開源模型中首個系統性引入“交錯思考”的模型系列，M2.1在處理復合指令約束時表現更好，這讓它在真實辦公場景中具備更高的可用性。

說白了，M2.1的定位是，從“能用”升級到“好用”，從“便宜”升級到”專業”。

1

100億參數的“以小博大”

Demo之外，我們也來看看M2.1在標準化基準測試上的成績。

在軟件工程領域最具代表性的SWE-bench Verified榜單上，M2.1拿到了74.0分，超過了DeepSeek V3.2（73.1）和Kimi K2（71.3）。這個榜單直接衡量模型"解決真實GitHub Issue"的能力，74分意味著它能搞定大多數真實世界的代碼修復任務。

在多語言編程能力上，M2.1的表現更突出：Multi-SWE-Bench得分49.4%，SWE-Bench Multilingual得分72.5%，均超過Claude Sonnet 4.5，接近Claude Opus 4.5的水平。

更值得關注的是，M2.1總參數量為2300億，只有100億激活參數。

這意味著什么？在保持高性能的同時，推理成本大幅下降。據官方披露，M2.1 版本的輸入價格為2.1元/百萬Tokens，輸出價格8.4元/百萬Tokens，不到Claude的十分之一。

這種“以小博大”的策略，對于被高昂API成本勸退的開發者和企業來說，提供了一個真正可落地的選項。

1

寫第一行代碼只占10%的時間

最后聊一個容易被忽視的點。

在真實的軟件工程中，寫出第一行代碼只占10%的時間，剩下90%都在修Bug、重構、寫文檔和做測試。這就是為什么"從1到100"的能力，往往比"從0到1"更重要。

M2.1在這方面下了功夫。官方強調的"復合指令約束"能力提升，翻譯成人話就是：它不僅能幫你寫Demo，還能深入復雜倉庫、理解幾千行代碼的上下文，然后做精準修改。

這對于Agent在復雜工作流中的穩定性至關重要，一個只會寫新代碼、不會維護舊代碼的AI，在真實生產環境中幾乎沒用。

1

2026年的關鍵詞：從“能跑”到“能用”

回到開頭的問題，M2.1的發布，對于即將IPO的MiniMax意味著什么？

過去兩年，我們見證了模型參數的狂飆，而展望2026，行業的關鍵詞將徹底轉向“落地”。

誰能以更低的成本、更穩的工程能力、更全面的技術棧（覆蓋Web到Mobile），誰就能贏得開發者的鍵盤，也能贏得資本市場的信心。

從技術路徑看，MiniMax一直走的是全模態的路線。先在單點做到領先，再補齊全局。語音（Speech 2.6）、視頻（Hailuo 2.3）、音樂（Music 2.0）等模態已經率先跑出成績。在文本模型這條線上，從M2到M2.1的快速迭代，也是全模態技術路線的持續。

M2.1并不是一個試圖“秒殺所有人”的全能神，但它是一個務實、精準打擊痛點、性價比極高的選擇。MiniMax選擇在IPO前夜發布它，既是秀肌肉，也是表態，技術投入和進步不會因為上市而放緩。

點個“愛心”，再走 吧