MiniMax M3 實測：第一流的模型，已經對執行層動手了
MiniMax 發佈旗艦模型 M3，重點強化編程與 Agent 能力。該模型具備 1M token 長上下文、原生多模態及自主執行復雜任務特性，能獨立進行長期規劃與多輪協作。實測顯示其可自主復現論文或優化代碼長達數十小時，旨在構建具有競爭力的 Agent 生態，挑戰現有開發者工具地位。
一款開源模型，能否同時擁有頂級編程能力、超長上下文理解能力和原生多模態能力？
這幾乎就是 Agent 的全部意涵。而我們提出這個問題，是因為從 OpenClaw 時代開始，一家公司就已經無法僅僅憑藉在模型上的投入，證明自己是一家押注未來的公司。勝負全在 Agent。
MiniMax M3 似乎也意識到了這一點。
作為 MiniMax 的最新款旗艦模型，M3 重點強化了 Coding 與 Agent 能力。相比傳統代碼模型的 “把代碼寫出來”，它更強調長期規劃、多輪協作和自主執行復雜任務的能力。
通俗地説，這些能力共同指向一個目標，那就是讓模型獨立學習幾十萬字的資料、持續工作數小時、調用工具、編寫代碼，並最終交付一個真正可用的結果。這成為了同步推出的 MiniMax Code 產品的核心技術基礎。
那麼衍生出來的問題是，當 Claude Code 已經成為開發者最認可的 Agent 工具之一，M3 的能力，又是否足以支撐 MiniMax 建立一個自己的，真正有競爭力的 Agent 生態？
12 小時自主工作，你説的長任務有多長？
Coding 能力的進化，已經不僅僅是寫代碼了。
如果只把 MiniMax M3 當成一個更擅長寫代碼的模型，會嚴重低估此次發佈的重點。M3 更值得拿出來討論的，是它在長任務、長上下文和 Agentic 工作流上的能力。
官方給出的兩個案例很能説明這一點。一個是 M3 用接近 12 小時自主復現 ICLR 論文，另一個是用約 24 小時、147 輪迭代完成 CUDA Kernel 優化。這兩個例子本質上都是典型的長鏈路任務，模型需要理解目標、拆解步驟、不斷檢查中間結果，並在失敗之後繼續調整。
從模型架構上看，MiniMax M3 的 1M token 上下文和 MSA 稀疏注意力架構，就是為這類場景服務的。長上下文的意義不只是能塞進更多文本，更重要的是降低長任務中的信息斷裂。比如一個真實代碼倉庫、一個複雜需求文檔、一組歷史修改記錄，這些真實需求都不是幾千 token 就能講清楚的。如果模型每次只能看到局部，就很容易出現 “前面答得對，後面改崩了” 的情況。而更長的上下文窗口，則給了模型跨文件、跨階段理解任務的可能。
不過必須澄清的是，官方宣傳的 1M 上下文，並不等於當前所有開發者都能無門檻、穩定地使用完整的 1M 上下文能力。模型頁雖然寫明 “支持最高 1M，保證至少 512K”，但按量計費頁進一步説明，超過 512K 的輸入能力在發佈初期屬於限時、限量供應，需要聯繫銷售開通。
長上下文能力確實是這次 M3 發佈的核心亮點，但在真實任務中，它更適合被理解成一種 “能力上限”，而不是一個已經對所有用户完全開放的默認規格。
創業模擬器，M3 與 Sonnet 4.6 的直接競技
為了測試 M3 的代碼交付能力，我設計了一個相對完整的小項目，讓模型從零實現一個 “創業模擬器” 小遊戲。同樣接受這項考驗的，還有 Claude Sonnet 4.6。
|
請從零開發一個 AI 創業模擬器 Web App。 要求： 1. 用户可以創建一家初創公司，輸入公司名、行業、初始資金、目標用户。 2. 遊戲採用回合制，每一輪代表一個月。 3. 用户每輪可以選擇 3 個經營決策，例如產品開發、市場推廣、招聘、融資、降本、用户調研。 4. AI 根據當前公司狀態和用户決策生成月度報告。 5. 頁面需要展示資金、用户數、收入、團隊士氣、產品完成度、市場熱度、競爭壓力。 6. 每輪結束後更新這些指標。 7. 需要有成功和失敗結局。 8. 使用 React + Tailwind 實現，界面要像一個現代化創業經營遊戲。 9. AI 接口可以先用 mock 數據，但代碼結構要方便之後接入真實 LLM API10。 10. 請保證項目可以運行，並提供啓動方式。 |
提示詞並不複雜，但這項任務其實很適合測試 Coding Agent 的綜合能力。因為它同時考驗需求理解、狀態管理、UI 設計、數值系統和平衡性。用户在遊戲中扮演創業者，每一輪需要決定做什麼產品、招什麼人、怎麼定價、要不要融資、如何營銷，AI 則根據這些決策反饋用户增長、現金流、團隊士氣、市場反應和競爭壓力。
具體來説，真正的難點主要包括三個維度：
- 狀態管理：小遊戲一旦進入多輪決策，就很容易出現頁面刷新後數據丟失、上一輪數據覆蓋下一輪、歷史記錄無法回看、進度條超過 100% 之類的問題。甚至遊戲只是這些問題的高發場景，類似的需求，在很多軟件開發任務中都可以看到。
- UI 表現：很多模型生成的 “遊戲” 其實只是一個表單加幾個按鈕，功能能跑，但一眼看過去就有股 “塑料感”。
- 數值平衡：這是最難的一環，數值設計不當很容易出現一兩輪遊戲之後現金流爆炸、用户數異常增長、遊戲迅速失控的問題，最終影響可玩性。什麼樣的數值設計可以説是平衡？這需要模型在複雜任務拆解之外，更有一層對遊戲的審美和品味。
M3 用大約 11 分鐘完成了程序編寫和代碼檢查。最終生成的小遊戲可以正常運行，界面簡潔，並且帶有一定動畫效果。更重要的是，它基本處理好了前面提到的幾個核心難點，公司數據展示清晰，歷史記錄可以回看，遊戲進度和經營指標也沒有明顯混亂。
作為對比的是，Sonnet 4.6 完成同一任務大約用了 19 分鐘。它同樣讓遊戲正常跑了起來，還在內容設計上增加了一點小巧思。比如加入突發事件，讓遊戲難度和不確定性更強，遊戲性確實更高。
這是個很有意思的差異。
基於 M3 的 MiniMax Code 更像是一個執行力很強的工程師 Agent，它會非常忠實地圍繞你的 prompt 做交付。優勢也在這裏，動作快，完成度高，指令給過去，他會圍繞最終產物，把頁面、邏輯、狀態和基礎交互一起搭出來。
而基於 Sonnet 4.6 的 Claude Code 則更像一個會主動補充產品想法的合作者，它可能會在需求之外加入一些額外的設計。
這兩種風格沒有絕對好壞。如果你的需求非常明確，希望模型嚴格按照指令快速完成，M3 的表現會非常令人舒適，畢竟誰不想要一個指哪打哪的員工。但如果你期待模型主動補完產品創意、增強玩法、提出更多可能性，Sonnet 4.6 目前在創造性擴展上仍然更有優勢。
看圖寫前端：原生多模態能力實測
相比於長任務和 Coding 能力，多模態可能是 MiniMax M3 身上最容易被低估的一項能力。
很多模型宣傳自己支持圖片輸入，但實際體驗下來，往往停留在 “看圖説話” 的階段，能夠描述頁面裏有哪些元素，卻很難將這些視覺信息進一步轉化為可運行的代碼。而 M3 此次給我的最大驚喜恰恰在於，它展現出了從視覺理解到工程交付的完整鏈路能力。
為了測試這一點，我選擇了一個非常直接的場景，將 MiniMax 自己的官網首頁作為測試對象。我向 M3 提供了兩張首頁截圖，並要求它使用 React 與 Tailwind CSS 對頁面進行復刻。
|
根據這張網頁截圖，使用 React + Tailwind CSS 完整復刻頁面。 要求： 1. 儘可能還原原頁面的：
2. 頁面必須響應式，適配：
3. 識別並還原：
4. 使用組件化結構：
5. 不要使用佔位符代碼。 6. 輸出完整可運行代碼。 讓生成頁面與截圖視覺相似度達到 90% 以上。 |
之所以選擇官網首頁，是因為這類營銷頁面往往包含大量視覺設計細節：導航欄、卡片模塊、漸變背景、按鈕樣式、信息層級以及複雜的頁面佈局。對於模型而言，這不僅是在識別圖片中的文字，更是在理解整個頁面背後的設計邏輯。
最終結果讓我有些意外。
首先是頁面結構的還原度。
僅憑兩張截圖，M3 對首頁整體佈局的復刻已經達到了極高的水平。導航欄、Hero 區域、功能介紹模塊以及各個內容板塊之間的層級關係都被準確識別出來，頁面整體結構與原網頁幾乎保持一致。
如果只從宏觀佈局來看，幾乎已經到了以假亂真的程度。剩下的差異主要集中在一些字體間距、元素對齊方式等細節層面。但就是把這些不一樣的局部畫面單獨截圖出來，你都得回憶一下，MiniMax 那個正版的官網畫面是不是就長這樣。
更有意思的是，M3 並沒有機械地 “照抄截圖”。
由於測試時我只提供了首頁部分內容，理論上模型無法得知頁面下半部分應該如何設計。但在實際生成過程中，M3 並沒有簡單地留下空白，而是主動分析了官網整體的視覺風格和配色特點，自行為後續頁面補充了若干風格一致的內容模塊。雖然這些內容並不完全對應真實官網，但無論是配色方案還是設計語言，都與原頁面保持了高度一致，整體看起來並不會讓人產生明顯的割裂感。
這一點其實非常重要。因為它説明模型並不僅僅是在做 OCR 或者截圖復刻，而是在嘗試理解頁面背後的設計規律，並利用這種理解完成合理推斷。
除了視覺層面的還原之外，M3 對交互元素的識別也給我留下了不錯的印象。
在生成結果中，模型正確識別出了導航欄、按鈕等交互式組件，併為這些元素賦予了實際功能，例如導航欄中的菜單項可以直接跳轉到對應內容區域，按鈕組件也被正確實現為可點擊元素。
更進一步，M3 還主動為頁面補充了交互動效。當鼠標懸停在按鈕上時，頁面會出現過渡動畫與視覺反饋。這些效果並沒有出現在我的提示詞中，而是模型根據現代 Web 產品的設計習慣自行加入的細節。
綜合來説，M3 展現出了相當強的競爭力。它不僅能夠理解網頁截圖中的結構信息，還能識別交互邏輯、推斷缺失內容，並最終生成一個能夠運行、能夠交互、視覺風格高度一致的前端頁面。
當然，它並非沒有不足。頁面中仍然存在一些排版細節上的偏差，但考慮到整個過程幾乎完全由模型自主完成，並且輸入僅僅是兩張截圖，這樣的結果已經遠超最初的預期。
價格也是生產力
價格是大模型競爭中最現實的話題。過去一年，AI 行業幾乎經歷了一輪全面價格戰，DeepSeek 用極低的 API 成本掀翻市場，OpenAI、Anthropic 和 Google 持續提升模型能力的同時也在不斷調整定價策略。
從官方定位來看，M3 主打的是 Frontier Coding、Agent、多模態與百萬級上下文能力。這首先決定了它的競爭對手，不是那些用於智能客服、會議紀要的中端模型，而是當前行業最前沿的一批旗艦模型，比如 Claude Opus 4.8、GPT-5.5、Gemini 2.5 Pro、GLM-5.2 以及 DeepSeek V4-Pro 等。
直接看價格，目前 Claude Opus 4.8 的 API 價格為輸入 5 美元/百萬 Token、輸出 25 美元/百萬 Token。GPT-5.5 為輸入 5 美元、輸出 30 美元。DeepSeek V4-Pro 在最新降價後為輸入 0.435 美元、輸出 0.87 美元。相比之下，MiniMax M3 官方價格為輸入 0.6 美元、輸出 2.4 美元。
如果以 Claude Opus 4.8 為基準，M3 的輸入成本僅約為其 12%，輸出成本不到 10%，即便面對 OpenAI 最新的 GPT-5.5，M3 的調用成本也只有其十分之一左右。換句話説，在同樣消耗 100 萬輸入 Token 和 100 萬輸出 Token 的情況下，使用 GPT-5.5 需要 35 美元，使用 Claude Opus 4.8 需要 30 美元，而 M3 僅需 3 美元。
對於用量不大的普通用户來説，這種差異尚不明顯，但如果你是已經習慣了每天靠大量 Agent 處理長文檔、批量生成代碼或者構建 AI 應用的開發者，成本差距則會被迅速放大。假設一個項目每月消耗 1000 萬輸入 Token 和 1000 萬輸出 Token，使用 Claude Opus 4.7 的成本約為 300 美元，而使用 M3 僅需 30 美元左右。在保持接近旗艦模型能力的前提下，十倍左右的成本優勢已經足以影響技術選型。
當然，價格從來不能脱離能力討論。
如果 M3 只有廉價可圈可點，那麼這樣的比較並沒有意義。但有意思的是，在 MiniMax 公佈的多項評測中，M3 瞄準的正是 Claude Opus 4.7、GPT-5.5 和 Gemini 旗艦模型所在的競爭區間。在 SWE-Bench Pro 等代碼能力測試中，M3 已經超過 GPT-5.5 與 Gemini 旗艦模型，接近 Claude Opus 4.7，在長任務 Agent 場景下，官方展示的論文復現和 CUDA 優化案例甚至能夠持續自主運行十幾個小時以上。
更關鍵的是，M3 並非依靠閹割能力來換取低價格。如前所述，這份價格背後是 100 萬 Token 上下文窗口、原生多模態架構以及 Agent 工作流能力，而 Claude、GPT 和 Gemini 恰恰也是沿着同樣的方向演進。換句話説，M3 試圖參與競爭的並不是 “便宜模型市場”，而是最昂貴、也是技術含量最高的旗艦模型市場。
因此，如果只看絕對價格，DeepSeek V4-Pro 仍然是目前最激進的價格屠夫。但如果同時考慮 Coding、Agent、多模態和超長上下文這些旗艦能力，那麼 M3 可能是目前整個市場裏最具衝擊力的性價比選手之一。
MiniMax Code 的野心
幾項測試下來，MiniMax M3 給我的感受是，它已經可以位列國產模型裏最值得關注的 Coding / Agentic 底座模型之一，尤其在長任務、長上下文、多模態輸入和代碼交付方面，展現出了很強的競爭力。
注意底座模型這個定位，此前城頭變幻大王旗的各種 Benchmark 一度讓性能水平成為衡量大模型的唯一角度。但是當我們討論 Agent，討論落地，更現實的維度是可用性。MiniMax M3 看起來無意再去挑戰 “最強模型” 的地位，而是在嘗試成為 Agent 時代最具性價比的基礎設施。
這是一條更清晰的路徑。隨着 Claude Code、Codex 等 Agent 產品逐漸成為開發者的主要入口，模型越來越迴歸其原本的角色，即一種底層能力。對於開發者而言，一個模型是否能完成長任務、調用工具、理解圖像並控制成本，遠比單純跑分更重要。
從這個角度看，MiniMax 的策略相當清晰。M3 在長上下文、多模態和 Coding 能力上穩穩躋身第一梯隊，同時又以遠低於 GPT、Claude 的價格，將這些能力帶到更多真實工作流之中。
真實工作流，這也是 MiniMax Code 此刻問世的原因。
賣 Token 的商業模式曇花一現，事實是開發者用腳投票的時候毫不猶豫，API 供應商越來越容易被替代。在這種情況下，模型能力領先 3 個月，不代表就有 3 個月的商業優勢。這迫使模型廠商追問，為什麼要把最有議價權的入口拱手讓人？
此外今天生產級的 Agent，已經是一種高度集成的系統工程能力。一個複雜任務的交付水平，只有部分取決於模型，還有部分取決於 Agent Runtime。如果找對測評角度，每家都有 “SOTA” 模型，那麼執行層的爭奪將成為新的競爭焦點之一。
所以 MiniMax Code 是一個寫代碼的軟件嗎？
這仍然是 IDE 的視角。它實際上是模型、代碼庫上下文、工具調用、執行環境、工作流編排，所有決定 Agent 最終效果的東西都在這裏了。有了這些，MiniMax 才有了爭奪開發者工作流入口的資格。
本文來源：雷峯網
