作者 | 陳姚戈

就在剛剛，MiniMax M2.1 正式官宣開源。

如果說 Vibe Coding 最早震撼的是新手開發(fā)者，那么在今年，職業(yè)程序員已經(jīng)集體迎來了它帶來的工作流革命。

身邊一位資深工程師提到，在今年下半年之前，他的 AI Coding 體驗(yàn)依然非常僵硬，極度依賴指令工程。為了讓模型寫出一段合格的代碼，他往往需要事無巨細(xì)地堆砌 40 多行指令，包括指定技術(shù)棧、實(shí)現(xiàn)邏輯的具體步驟以及詳盡的約束條件。

從 Copilot 模式過渡到 Agent 模式，這看起來是無法回避的問題。

但現(xiàn)在，他表示，AI Coding 順暢多了，Prompt 的“存在感”正變得越來越低 —— 一方面，模型能力在提升；另一方面，模型及工具的工程能力也在提升。

這也讓開發(fā)者開始以工程尺度來衡量 AI Coding 的價值：重要的不是單項能力的峰值參數(shù)（比如代碼生成速度），而是模型在長上下文、多語言、多輪任務(wù)中的整體穩(wěn)定性，以及是不是足夠?qū)嵒荨?/p>

因此，當(dāng) MiniMax 更新并繼續(xù)開源 M 系列模型時，很多開發(fā)者迫不及待上手實(shí)測。

M2.1 著重提升模型在真實(shí)世界復(fù)雜任務(wù)的表現(xiàn)。從指標(biāo)上看，M2.1 在多語言軟件工程測試 SWE-Multilingual 得分達(dá)到 72.5%，超越了 Sonnet 4.5；在 VIBE-bench 中以 88.6% 的成績，超越 Gemini 3 Pro。在定價策略上，MiniMax 將 Coding Plan 訂閱服務(wù)價格壓縮至 Claude 對應(yīng)方案的 1/10。

在國際開發(fā)者社區(qū)，M2.1 的表現(xiàn)也得到了專業(yè)人士關(guān)注。

前 Twich 和 Amazon 工程師，T3 Chat 創(chuàng)始人 Theo Browne 前幾天也直播對比測試了 M2.1 在內(nèi)的開源模型。在直播中，他表示 MiniMax 在處理長任務(wù)、生成計劃方面表現(xiàn)出色，且價格“便宜得離譜”，在性能可以媲美 Opus 4.1 的基礎(chǔ)上價格僅為其 1/60。

前 Meta AI 工程師，DAIR.AI 創(chuàng)始人 Elvis S. 表示，他利用 M2.1 構(gòu)建深度研究 Agent 后發(fā)現(xiàn)，M2.1 生成的報告質(zhì)量高，且相比前代顯著降低了 Token 損耗。

那么，M2.1 真的能打嗎？

我們將 M2.1 投入到了存量業(yè)務(wù)的周期迭代、從 0 到 1 的新產(chǎn)品構(gòu)建，以及跨語言的二次開發(fā)這三類真實(shí)“深水區(qū)”場景中。希望看到拋開一切濾鏡后，M2.1 的實(shí)際表現(xiàn)。

1 InfoQ 實(shí)測，新模型肚子里有多少“貨”？

在評估 M2.1 的實(shí)戰(zhàn)表現(xiàn)前，我們首先需要明確：什么才是真正的 Agent 能力？

我們認(rèn)為，模型的 Agent 能力最終取決于它能否在真實(shí)團(tuán)隊與真實(shí)項目中持續(xù)交付。為此，我們刻意選擇了三個能夠覆蓋工程研發(fā)全生命周期的典型場景，包括周期性的后端業(yè)務(wù)（年度報告功能）迭代、原生 App 的 0-1 交付、以及跨語言開源項目的二次開發(fā)。

它們恰好覆蓋了工程團(tuán)隊的日常主流工作：年度報告是典型的周期性重復(fù)需求，最能檢驗(yàn) AI 對存量業(yè)務(wù)的提效價值；iOS 開發(fā)代表了新業(yè)務(wù)啟動從空白到可運(yùn)行的典型路徑；而 Rust+TS 項目則是開發(fā)者在遺留代碼與既定約束中進(jìn)行功能演進(jìn)的縮影。

這些任務(wù)強(qiáng)制模型進(jìn)入從理解到交付的完整閉環(huán)。模型必須在真實(shí)約束下，完成從讀懂原始需求、拆解復(fù)雜任務(wù)、產(chǎn)出技術(shù)方案到多輪調(diào)試修錯、最終交付上線的全過程。這不僅是對長上下文和跨文件理解力的考驗(yàn)，更是對 Agent 在多輪協(xié)作中保持邏輯一致性的實(shí)戰(zhàn)演習(xí)。

通過這些測試，我們希望回答兩個關(guān)鍵問題：M2.1 多大程度上仍是一個編程工具？又有多大程度已具備 Agent 所需的可靠執(zhí)行能力？

場景一：年度報告 API 接口功能開發(fā)

我們對 M2.1 的首個測試，是直接把它扔進(jìn)真實(shí)的工作項目。

每年年末，極客時間 APP 都會上線“年度學(xué)習(xí)報告”，為每位用戶提供個性化的年度回憶，就像每年網(wǎng)易云音樂會收到今年的聽歌總結(jié)一樣。

這是一個周期性重復(fù)、代碼結(jié)構(gòu)穩(wěn)定，但是對安全和嚴(yán)謹(jǐn)性要求很高的場景。其中，api 層的代碼邏輯高度一致，但是程序員需要在不觸動舊系統(tǒng)，不破壞接口與數(shù)據(jù)結(jié)構(gòu)的約束下，做好年度遷移。

我們將編寫年度報告 API 接口功能代碼的任務(wù)，一個有真實(shí)上線需求的 Golang 后端項目交給 M2.1。

M2.1 需要在理解既有業(yè)務(wù)邏輯的基礎(chǔ)上、梳理完整調(diào)用鏈路，并在不破壞接口與數(shù)據(jù)結(jié)構(gòu)的前提下編寫代碼。

在與 M2.1 進(jìn)行兩輪交流后，它寫出了不用修改就能直接上線使用的代碼！

第一輪交流，我們要求 M2.1 首先理解 2024 年的項目的代碼邏輯：

閱讀當(dāng)前項目，學(xué)習(xí)并理解 2024 年度學(xué)習(xí)報告的 API 業(yè)務(wù)邏輯。

我們故意給出高度模糊的指令，考驗(yàn)?zāi)Ｐ屠斫庥脩糁噶詈椭虚g過程的能力。

從 M2.1 展現(xiàn)了完整的思維鏈可以看到，其閱讀代碼的方式貼近資深程序員：

先使用關(guān)鍵詞搜索，快速縮小范圍，從數(shù)百個文件中篩選出最相關(guān)的 31 個文件。

隨后按照 Golang 的分層架構(gòu)，從 API 入口文檔（.md）開始，按順序閱讀控制器（report.go）、業(yè)務(wù)服務(wù)（service.go）、數(shù)據(jù)結(jié)構(gòu)（model.go）和數(shù)據(jù)訪問層（dao.go），逐步還原完整的調(diào)用鏈路。

最后，進(jìn)行精準(zhǔn)搜索，查找具體的變量名或數(shù)據(jù)表名，以此確認(rèn) 2024 年業(yè)務(wù)邏輯中的特定細(xì)節(jié)，確保理解準(zhǔn)確無誤。

注：年度報告 API 接口功能開發(fā)過程中，我們與 M2.1 的第一輪對話

在第一輪完成了對項目代碼邏輯的理解后，我們要求它基于 2024 年的架構(gòu)，開發(fā) 2025 年的新接口：

基于 2024 年的年度報告，寫一個 2025 年的年度報告 API，請求和響應(yīng)不變，API 路徑和對應(yīng)的數(shù)據(jù)改成 2025。

按照要求，M2.1 識別了我們請求修改代碼的需求，并自主分析了項目結(jié)構(gòu)，確定了需要修改的文件和具體內(nèi)容，提出了具體的代碼修改方案（添加 2025 年的路由配置），并詢問用戶是否執(zhí)行這些編輯。

我們 review 后發(fā)現(xiàn)，M2.1 一次性生成了可以直接上線使用的代碼，代碼量接近一百行。

注：年度報告 API 接口功能開發(fā)過程中，我們與 M2.1 的第二輪對話

值得注意的是，M2.1 過于忠實(shí)地執(zhí)行了“基于 2024 年”的指令，以至于在涉及代碼復(fù)用的地方，它選擇了寫兩遍，而非主動進(jìn)行重構(gòu)。

在“是否允許重構(gòu)”上默認(rèn)選擇更加保守的策略對生產(chǎn)其實(shí)是好事，但要讓它更像團(tuán)隊里的資深工程師，就需要程序員在需求里明確哪些可抽象、哪些必須保持原樣，并把重構(gòu)邊界寫清楚。

場景二：iOS APP 的 0-1 開發(fā)

在第一個測試場景中，我們驗(yàn)證了 M2.1 在既有業(yè)務(wù)環(huán)境中補(bǔ)位執(zhí)行的能力。

但一個真正實(shí)用的 Agent，還必須具備從無到有啟動業(yè)務(wù)的能力。

對此我們選擇了 iOS 原生 App 研發(fā)場景。這類任務(wù)路徑更長，考驗(yàn)?zāi)Ｐ偷拈L上下文能力；涉及到 UI 和交互方式的約束，考驗(yàn)?zāi)Ｐ蛯υO(shè)計和審美的理解；同時工程環(huán)境也相較復(fù)雜，要求模型具有文件組織能力。

我們用聊天一樣的的自然語言描述任務(wù)，要求 M2.1 開發(fā)一款幫助年輕上班族決定今天吃什么的抽卡應(yīng)用：

我想要開發(fā)一個 app，核心需求是，實(shí)現(xiàn)中午吃啥的選擇，主要是解決用戶不知道中午吃啥的問題，風(fēng)格活潑可愛，畫風(fēng)簡單，可以錄入大量的附近的可選午餐數(shù)據(jù)，然后首頁的卡片隨機(jī)選擇，卡片切換動畫流暢絲滑，view 之間過度銜接完美，目前的代碼可以忽略甚至重構(gòu)掉，按照你的想法，結(jié)合需求，先設(shè)計合適的功能，然后再實(shí)現(xiàn)這個 app 的開發(fā)，目標(biāo)是年輕群體的上班族

注：上方是用戶輸入的指令，下方是 M2.1 接到指令后，向用戶細(xì)化詢問的問題。

接到指令后，M2.1 展現(xiàn)出了極強(qiáng)的 Agent 自覺。它沒有直接輸出代碼，而是反向詢問了數(shù)據(jù)錄入、卡片交互細(xì)節(jié)、歷史記錄等關(guān)鍵點(diǎn)。這種“多想一步”的深度交互，有效減少了軟件開發(fā)初期因信息不對稱帶來的返工風(fēng)險。

在確認(rèn)需求后，模型自主將開發(fā)拆解為四個階段：基礎(chǔ)框架搭建、核心功能實(shí)現(xiàn)、歷史統(tǒng)計、優(yōu)化完善。

在隨后不到 30 分鐘內(nèi)，它便生成了完整的項目結(jié)構(gòu)、核心代碼及本地運(yùn)行指令，完成了 APP 從 0 到 1 的搭建。

在第一輪對話后，M2.1 就已經(jīng)搭建出了適配 Liquid Glass 的視覺風(fēng)格的 UI 界面。

隨后我們繼續(xù)使用自然語言，讓模型對 UI 進(jìn)行微調(diào)。

但在 UI 微調(diào)中，我們也發(fā)現(xiàn)了模型的邊界：當(dāng)我們說“往上移一點(diǎn)”或“統(tǒng)一視覺整體”時，模型傾向于執(zhí)行量化的代碼操作，而非理解背后的美學(xué)意圖。

因此，如果有更嚴(yán)格的上架需求，模型仍需要人類完成工程化交付的最后一公里。

在開發(fā) APP 的過程中，M2.1 經(jīng)歷了 70 多輪循環(huán)對話中，上下文拉升至 160K 以上，生成近 30 個代碼文件，且能根據(jù)運(yùn)行結(jié)果自行反饋修正。

整場高壓測試下來，M2.1 僅出現(xiàn)了一次工具調(diào)用報錯。這種極低的錯誤率，證明了 MiniMax 針對長上下文和多輪 Agent 調(diào)用做了深度工程優(yōu)化。

這次測試還帶給我們一個關(guān)于 Agent 落地的重要思考：模型需要搭配合適的腳手架。

在開發(fā)初期，我們嘗試使用 Claude Code 作為調(diào)用工具，但發(fā)現(xiàn) M2.1 的長上下文優(yōu)勢難以完全發(fā)揮。而切換至 Kilo Code 后，穩(wěn)定性與連貫性顯著提升。

這說明，當(dāng)工具在上下文管理與循環(huán)執(zhí)行方面更強(qiáng)時，M2.1 的能力上限會顯著釋放。

場景三：Rust + TypeScript 項目的二次開發(fā)

iOS APP 的開發(fā)檢驗(yàn)了 M2.1 從 0 到 1 的交付能力。但在真實(shí)工作中，在遺留代碼與既定約束中進(jìn)行功能迭代才是常態(tài)。

因此在最后一項測試中，我們讓 M2.1 挑戰(zhàn)跨語言、跨框架的復(fù)雜開源項目重構(gòu)，選擇基于開源項目 Chorus（一款 macOS AI Chat 客戶端）進(jìn)行測試。

我們的任務(wù)是，在完全不提供修改路徑指引的前提下，要求模型自主在 Chorus 中新增對 MiniMax API Provider 的原生支持。

Chorus 采用了典型的 Tauri 2 架構(gòu)：底層由 Rust 負(fù)責(zé)系統(tǒng)調(diào)用與 API 通訊，前端則由 TypeScript 驅(qū)動界面。

增加一個新的 Provider 不僅意味著要編寫 UI 層的配置項，更要深入其底層抽象層，處理 Rust 的類型定義、異步請求以及跨進(jìn)程通信。

這種測試能直接暴露模型的多語言能力與長程任務(wù)中的指令遵循穩(wěn)定性。

我們采取了“任務(wù)導(dǎo)向”的交互方式，將 M2.1 推入這個陌生的工程環(huán)境。

首輪交流中，我們投喂了項目源碼并要求增加 MiniMax Provider：

閱讀當(dāng)前項目, 增加 MiniMax provider 的支持, 注意查一下如何對接 MiniMax 的 API, 然后接入以下模型： 模型名稱 輸入輸出總 token 模型介紹 MiniMax-M2.1 204800 強(qiáng)大多語言編程能力，全面升級編程體驗(yàn) MiniMax-M2-lightning 204800 更快，更敏捷 MiniMax-M2 204800 專為高效編碼與 Agent 工作流而生

在編譯運(yùn)行 M2.1 輸出的首輪代碼時，UI 層的模型列表并未如預(yù)期更新。我們發(fā)現(xiàn)對話框可以選擇的模型列表里并沒有出現(xiàn) MiniMax 模型。在我們指出這一點(diǎn)后，M2.1 進(jìn)行了自動診斷和修復(fù)。

第三輪交流中，我們指出模型列表出現(xiàn)了 MiniMax，但是無法點(diǎn)擊選擇。

在這一步，有意思的事情發(fā)生了。模型向用戶詢問 MiniMax 的 icon 旁是否是 to add 字符以及字符的狀態(tài)，并通過詢問交互界面 icon 的狀態(tài)反饋來倒推邏輯錯誤的位置。

這意味著，M2.1 和 Gemini 3 一樣，都能夠理解設(shè)計思維——不僅知道按鈕應(yīng)該是什么樣子，還理解它們存在的意義。這種將視覺邏輯與底層通訊邏輯實(shí)時映射的能力，讓它在處理復(fù)雜的前端交互時具有極高的確定性。

注：模型向用戶詢問 icon 狀態(tài)，由此倒推邏輯錯誤的位置。

編程過程中，我們對于多語言的“無感”也很有意思。我們所做二次開發(fā)的這個開源項目，是基于 Rust + TypeScript 寫出來的。但在與模型的交流中，我們僅僅提出了功能目標(biāo)，而沒有下達(dá)“修改某個 Rust 文件”這樣的具體指令。這意味著，對于 M2.1 來說，編程語言的界限正在消失，它處理的是工程本身。

從后端業(yè)務(wù)、原生 App 交付，到跨語言工程擴(kuò)展，MiniMax M2.1 展現(xiàn)出對真實(shí)世界復(fù)雜工程任務(wù)的適應(yīng)。它不只是一個“會寫代碼的模型”，而是一個具備長期工作、穩(wěn)定協(xié)作、真實(shí)交付屬性的 Agent 雛形。

如果說 coding 能力是 M2.1 的基石，那么當(dāng)它進(jìn)入更廣闊的通用辦公場景時，它能否真正像一名“數(shù)字員工”一樣處理日?，嵤拢?/p>

接下來，我們將進(jìn)入自動化辦公的模擬戰(zhàn)場。

2 從 AI Coding 工具，到數(shù)字員工

在與 MiniMax M2.1 長達(dá)十個小時的密集協(xié)作中，我們看到，其在多語言支持、長程任務(wù)處理能力、指令遵循、中間過程等方面的良好表現(xiàn)，正將 M2.1 的能力邊界從單純的提效工具推向真正的“數(shù)字員工”。

實(shí)際協(xié)作中，我們使用極其日常的語言，有時指令甚至非常模糊。普通代碼工具通常會基于概率盲目生成代碼片段，導(dǎo)致無效迭代。而 M2.1 表現(xiàn)出一種極其難得的“工程自覺”。當(dāng)面臨不完整信息時，它的第一反應(yīng)不是盲目行動，而是通過追問來澄清目標(biāo)、梳理方案。

這種“先問后做”的優(yōu)先級，正是人類員工接手陌生任務(wù)時的本能反應(yīng)。一位資深開發(fā)者在社群中分享，M2.1 的引導(dǎo)提示做得非常好，在他體驗(yàn)過的各種 AI IDE 里表現(xiàn)突出。

長程任務(wù)的穩(wěn)定性是衡量數(shù)字員工能力的硬性標(biāo)準(zhǔn)。在一次超過 30 輪的 APP 開發(fā)對話中，我們因臨時事務(wù)中斷了對話。數(shù)小時后，當(dāng)我們回到對話并繼續(xù)輸入指令，M2.1 并未要求重復(fù)上下文，而是直接承接此前進(jìn)度，準(zhǔn)確指出下一步待修改的文件與具體行數(shù)。這意味著 M2.1 具備極高的檢索精度，并能夠維持長程的推理鏈條。這種在長時、中斷的協(xié)作中仍能保持任務(wù)狀態(tài)的能力，是它能夠成為數(shù)字同事的基礎(chǔ)。

此外，在智能體能力評估體系 TheAgentCompany 中，M2.1 也展現(xiàn)出較完整的自動化辦公能力。TheAgentCompany 是目前較為成熟的評估 Agent 能力 benchmark 之一，它構(gòu)建了一個高度還原真實(shí)職場的軟件公司模擬環(huán)境，要求模型以數(shù)字員工的身份完成閉環(huán)任務(wù)（已精簡）

可以看到，在通訊軟件的測試環(huán)境下，M2.1 能主動收集員工的設(shè)備申請需求，隨后前往企業(yè)內(nèi)部服務(wù)器檢索相關(guān)文檔，獲取設(shè)備價格，計算總成本并判斷部門預(yù)算是否充足，最終完成設(shè)備變更記錄。

在項目管理軟件中，M2.1 能主動查找被阻塞或積壓的問題，并通過通訊工具聯(lián)系相關(guān)員工咨詢解決方案，再根據(jù)反饋更新任務(wù)狀態(tài)。

在研發(fā)協(xié)作場景下，M2.1 還能直接在代碼庫中檢索信息。例如，當(dāng)同事詢問“最近修改某個文件的合并請求是哪一個”時，它可以定位對應(yīng)的合并請求，找到編號并反饋結(jié)果。

綜合這些表現(xiàn)可以看到，MiniMax M2.1 已經(jīng)具備構(gòu)建全鏈路辦公自動化工具的基礎(chǔ)能力。

MiniMax 在 M2.1 中特別強(qiáng)調(diào)數(shù)字員工能力，本質(zhì)上是在為下一階段鋪路：

當(dāng)模型已經(jīng)能夠穩(wěn)定承擔(dān)工程任務(wù)，下一步自然是讓它嵌入企業(yè)流程、承擔(dān)明確職責(zé)，成為可復(fù)用的生產(chǎn)角色，而不再只是開發(fā)者手中的工具。

3 結(jié)尾：如果目標(biāo)最夠高，AI Coding 仍未至終局

編程工具的天花板正在收斂，而“數(shù)字員工”的門檻才剛剛變得清晰。

從 M2 強(qiáng)調(diào)跨文件、跨模塊的深度編程支持，到 M2.1 將多語言代碼能力和真實(shí)辦公場景作為核心升級方向，MiniMax 始終圍繞一個問題推進(jìn)：即致力于提升模型在真實(shí)世界復(fù)雜任務(wù)中的表現(xiàn)，讓 AI 真正滲透進(jìn)更多崗位工種與生產(chǎn)場景中創(chuàng)造價值。

通過實(shí)測我們看到，M2.1 正在跨越“輔助工具”的邊界，進(jìn)化為具備可靠執(zhí)行力的 Agent 雛形。

與之形成對比的是，目前市場上的 AI 編程產(chǎn)品，差距更多體現(xiàn)在效率與使用體驗(yàn)，而非角色定位本身，許多廠商仍然將 AI Coding 視為一種“更聰明的工具”。

這種理解在 MiniMax 沖刺港股上市的節(jié)點(diǎn)顯得尤為關(guān)鍵。MiniMax 沒有選擇在此時拋出華麗的敘事包裝，而是繼續(xù)把資源投入到模型能力本身的推進(jìn)上，用 M2.1 的硬核能力向市場證明：Coding 的商業(yè)天花板，不是程序員工具，而是自動化的數(shù)字員工。

一旦將 AI Coding 的目標(biāo)上調(diào)——要求其像工程師一樣，在真實(shí)組織中持續(xù)工作、理解約束并對結(jié)果負(fù)責(zé)，現(xiàn)有模型和工具的差距就會迅速顯現(xiàn)，隨之而來的是 AI Coding 公司的洗盤。

而低調(diào)的 MiniMax，正在這條更長周期的競爭中，提前占據(jù)位置。

目前，M2.1 已 正式開源，且 1 月 15 日前購買，首月只需 9.9 元。

MiniMax M2.1 的真實(shí)能力如何？歡迎在評論區(qū)留下你的想法。