2026-06-02 20:00NiceKate AI觀看原文9 分鐘

NiceKate AI：MiniMax M3 實測 — 1M 上下文 + 多模態，編碼工作流更順了

嘉嘉實測 MiniMax M3，從 macOS 應用開發到舊專案改造，驗證 1M 長上下文與原生多模態在真實編碼場景中的表現，並分享與 GPT-5.5 搭配使用的經濟組合策略。

MiniMax M3 AI編碼多模態 1M上下文 NiceKate AI 實測

開場閒聊

嘉嘉一開場就聊到 MiniMax M3 正式發布的消息，語氣中帶著驚喜。她說 M3 是目前國內首個同時實現前沿編碼能力、百萬級上下文和原生多模態能力的模型。

最讓她意外的是，在多模態測試集 OmniBench 上，MiniMax M3 的得分竟然超過了 Gemini 1.5 Pro。

「這讓我真的很意外，」嘉嘉說，「在我的實測裡，我多次用到了 M3 的圖片識別能力。有了多模態之後，編碼確實方便了很多。」

懶人包速覽

核心痛點	解決方案 / 關鍵觀點
多模態編碼流程中，UI 設計意圖難以精確傳達給模型	直接上傳 UI 截圖讓 M3 視覺理解，無需用文字描述介面佈局
編碼模型遇到錯誤時無法自主定位與修復	M3 會自主拆解 Todo 清單逐一執行，遇到錯誤自動分析日誌並修正
長上下文項目中，舊代碼改造需要重複解釋上下文	1M token 上下文可直接載入整個專案，M3 能自主理解目錄結構與技術棧
國產模型與頂尖模型各有優劣，成本與品質難兼顧	用 M3 負責編碼 + GPT-5.5 審查代碼的「經濟組合」，兼顧效率與品質

這支影片我完整看完了，資訊量不小。嘉嘉從頭到尾用真實專案驗證了 MiniMax M3 的能力，不是念規格表或跑 benchmark，而是真的打開編輯器讓模型寫代碼。

我整理出三個最關鍵的測試環節，並在文末附上 QA 與我的補充看法。

MiniMax M3 的第一個實戰：從 UI 圖生成 macOS 應用

嘉嘉的第一個測試是讓 M3 根據一張由 GPT-4o 生成的 App UI 圖，從零開始構建一個 macOS 應用。

這個 App 的功能是對接本地 OLLMX，用 AI 視覺模型識別圖片內容，然後自動給圖片重新命名。

有趣的是，M3 沒有直接埋頭寫代碼。它先反問嘉嘉很多問題，把需求一一對齊，然後生成了一份詳細的計劃。

嘉嘉審查計劃時發現了一個問題：UI 圖裡的端口是 8791，但 M3 寫成了 8000。

她讓 M3 修正後，又臨時追加了一個需求：升級命名模板。

M3 把任務拆成了 21 個 Todo，然後直接生成可運行的程序。在構建過程中遇到失敗時，它也會自己分析原因並解決——這正是 MiniMax 模型 Agent 處理能力的強項。

Bug 定位與根因分析：M3 的排查過程

App 上線後遇到了一個詭異的 bug：上傳圖片後，程式一直處於「處理中」狀態，沒有任何結果返回。

嘉嘉把畫面截圖發給 M3，讓它分析原因。M3 按概率給出了幾個可能的失敗原因，其中最可能的是 App 沒有真正走 OLLMX 的視覺理解流程。

M3 指出，千問 3.6-35B A3B 4 比特從命名來看更像是 LLM 而不是 VLM，即使模型收到了 base64 圖片，也可能拒絕處理或者直接瞎編。

接著嘉嘉把 OLLMX 的日誌發給 M3。M3 分析後認為 OLLMX 返回的內容根本不是 Prompt 要求的 JSON。

嘉嘉讓 M3 用 curl 繼續追查，M3 找到了關鍵線索：模型確實收到了圖片，但沒有正確處理。

最後嘉嘉把 OLLMX 版本資訊發給 Groq，Groq 確認這是 OLLMX 的已知 Bug。更新到 0.4.0-rc2 後，App 就能正常識別圖片了。

整個排查過程歷經了截圖排查、日誌分析、curl 驗證、版本比對四個環節，M3 在每個環節都提供了有價值的分析。

舊專案改造：M3 對既有代碼的理解能力

第二個測試是讓 M3 對嘉嘉的一個既有專案做改造。

嘉嘉先讓 M3 介紹這個專案，M3 詳細說明了目錄結構、技術棧、後端架構和值得注意的細節。

她接著問 M3 是不是透過 SDK 接入，M3 找到了關鍵代碼位置。然後嘉嘉把 MiniMax 開發者後台的 OpenAI 兼容接入 SDK 文檔連結發給 M3。

M3 拆解出 10 個 Todo，對多個界面內容進行了修改，包括文案、資料庫和核心調用層。修改後它還主動進行了驗證。

運行後第一次提問出現了報錯：「無法訪問與值無關的本地變量 reasoning buffer」。嘉嘉截圖發給 M3，M3 很快完成了修復。

不過在對話標題裡，嘉嘉發現思考過程和結果輸出都被截斷了。她讓 M3 修改，M3 還貼心地問了她的偏好，以及線程被污染的標題應該怎麼處理。

嘉嘉請 M3 搜索網路看看有沒有解決方案，M3 找到了一個 GitHub Issue，然後給出修復意見——直接拼接。修改後結果就能完整展示了。

SVG 生成與多模態優勢：手繪圖、鏡像字、機械錶盤

M3 的多模態能力在幾個視覺任務上表現突出。

嘉嘉讓 M3 解釋一份手寫的 MSP（微服務協議）流程圖。M3 先根據這張圖生成整體流程，然後詳細介紹了每一步、核心設計思想，最後做了總結。

對於千字盤上的鏡像字識別（凸起的鏡像字），M3 也能很好地辨識，雖然它誠實地表示「完整逐字精確轉錄比較困難」，但還是識別出了多個可辨認的字詞，並介紹了歷史背景與文化價值。

作為對比，Gemini 1.5 Pro 也能識別出這是左右鏡像反轉，但對於千字盤上的文字識別，明顯與原圖不是一一對應。

接著嘉嘉讓 M3 生成機械錶盤爆炸示意圖。第一次生成的錶盤指針位置有問題，嘉嘉截圖提示修改後，M3 增加了 7 個 Todo，對指針、螺絲等細節進行了升級。

第二次生成後的頁面明顯美觀很多，支援自動演示，齒輪細節的轉動展示也很好。只用了兩次提示就達到這個效果，嘉嘉認為 M3 在這個任務上完成得不錯。

嘉嘉還讓 M3 生成了「被理髮的小羊」和一個迷你博物館（至少六個展櫃，每個展櫃有不同的展品），M3 的生成結果都比上一代 M2.7 明顯更好。

QA 精選

Q1：MiniMax M3 跟上一代 M2.7 比，進步最大的地方在哪？

從實測來看，M3 最大的進步是原生多模態能力與編碼能力的結合。嘉嘉在影片中多次強調，有了多模態之後，提示詞可以少很多費力的解釋——直接把 UI 截圖、錯誤畫面、手繪圖發給 M3，它就能理解意圖。

官方數據顯示，在 SVG-bench 基準上，M3 超過了 Opus 4.7。同樣的任務，M3 生成的代碼行數比 M2.7 更多，品質也更好。

Q2：1M 上下文在實際編碼中真的用得上嗎？

嘉嘉的實測證明 1M 上下文在兩種場景下非常實用：一是大型專案的從零構建（M3 拆了 21 個 Todo 來完成 macOS 應用），二是既有專案的改造（M3 需要理解整個專案的目錄結構、技術棧和後端架構）。

沒有足夠的上下文，M3 就無法正確理解千問 3.6-35B 模型其實是 LLM 而非 VLM 這個關鍵判斷——這是 bug 排查過程中的轉折點。

Q3：M3 的自主 Agent 能力跟其他編碼模型比如何？

嘉嘉的實測展示了 M3 在多個環節的自主決策：需求對齊（主動反問確認）、錯誤修復（分析日誌後自行修正）、Todo 拆解（21 個任務逐一執行）。

特別是在 bug 排查環節，M3 不僅分析了日誌內容，還能主動建議用 curl 做進一步驗證——這種「提出下一步診斷方法」的能力，顯示 M3 具備一定的 Agent 思維鏈。

Q4：嘉嘉推薦的國產編碼模型搭配策略是什麼？

嘉嘉在影片尾聲提出了一個很實用的建議：「讓國產編碼模型搭配一個強大的驗證模型，比如讓 GPT-5.5 審查代碼，讓 M3 負責編碼，這樣會更經濟一些。」

她舉了一個例子：讓 M3 生成迷你博物館後，請 GPT-5.5 檢查程式碼並打分。GPT 給了 76 分，指出了導航狀態機邏輯不一致、手屏導航被展櫃遮擋等具體問題。

這個「M3 編碼 + GPT 審查」的組合，兼顧了成本與品質。

Q5：MiniMax M3 什麼時候會推出更快版本？Hermes Agent 搭配體驗如何？

嘉嘉在影片最後透露官方的「快速版」M3 近期會推出，她表示非常期待。

她還特別提到：「我認為搭配 Hermes Agent 會很好用。」考慮到 M3 的長上下文和多模態特性，確實很適合做為 Agent 背後的大腦來驅動複雜的編碼工作流程。

主編隨筆

嘉嘉在影片中展示了 M3 多模態編碼的完整流程，從 UI 圖生成到 bug 定位再到舊專案改造，確實讓人印象深刻。不過我認為最有價值的不是 M3 有多強，而是她展示的「人機協作節奏」——不是把任務丟給模型然後等結果，而是在每個關鍵節點介入審查（端口號 8791 vs 8000 的修正、對話標題截斷的優化），這種協作方式才是目前 AI 編碼的正確姿勢。

從成本角度來看，她提出的「M3 編碼 + GPT-5.5 審查」策略我特別認同。這就像團隊裡有兩個工程師，一個負責寫 code，一個負責 code review。國產模型的編碼能力已經夠用，但讓更強的模型做驗證，整體成本反而比只用一個頂尖模型更低。這在實際專案中是一個很實用的思路。

另外值得一提的是 M3 對 OLLMX bug 的排查過程。從截圖排查到日誌分析再到 curl 驗證，M3 展現了從現象推到根本原因的能力——這不是單純的「程式碼生成」，而是真正的 debug 思維。如果後續版本能讓這個排查流程更自動化（比如直接掛載調試器），那 Agent 驅動的開發體驗會再上一個台階。