把 MiniMax M2.7 扔進真實業務里：它替我省了 BI 和程序員的錢

作者 | 駱駝

回看 2025 年 Q2 到 2026 年 Q1，AI 的發展路徑清晰得驚人：上下文擴充、成本降低，最終催生了 Agent 的爆發。在這場狂奔中，MiniMax 僅用 270 余天就迭代了五個模型版本，點亮了從上下文長度到 Agent 能力所有的“技能點”，甚至跑走完了上市流程——對于一家只有四百余名員工的公司，這本身就是一場 AI Native 組織的極限實驗。

我們都在等待 MiniMax 證明一個問題：一個 AI-Native 型的創業組織，能跑多久，到達何種位置？

這也是我們為何必須測試一下 MiniMax M2.7 。

為了驗證這一點，我在 3 月 18 日發布前一天拿到的測試資格，第一時間把 API 接入了 Cursor，同時在 MaxClaw 上加載了 MiniMax 自己開源的應用開發系列的 Skills，基本就算完成了所有測試準備。

這個過程我沒考慮 Claude Code，也沒選擇 OpenClaw —— MiniMax 自始至終都是一家對 C 端 /D 端體驗比較關注的 AI 平臺型公司，那就不妨讓這種體驗再平權一些：價格高的、部署復雜的，咱都不考慮。

從官方消息來看，MiniMax M2.7 的更新重點有四類：

1. 更真實的軟件工程能力，包括 Agent 場景下的 Cowork 能力；

2. 專業辦公能力；

3. 自我進化能力；

4. 更好的互動娛樂表現，包括人設保持和情商；

除了互動娛樂表現，其他三項都在本次測試計劃內。我避開了寫游記、做網頁等常規 Demo，設計了一套更貼近真實業務“爛攤子”的測試題：

1. 輸入端（辦公測試）：扔給它一份包含非標數據、公式斷裂的“圓明園式” Excel，看它能不能像 BI 一樣挖掘數據價值；

2. 生產端（工程測試）：不給詳細需求文檔，讓它從零開發一套管理系統，并在報錯中自主迭代，驗證其“自我進化”能力；

3. 協作端（MaxClaw 測試）：體驗多 Agent 協同，看它能否真正理解并執行復雜的技能流。

從數據處理到系統構建再到多智能體協作，最終指向一個終極問題：AI 能否真正“干活”而非“演示”？ 測試結果，出乎我的意料。

當 Excel 變成“壓縮包”
它比 BI 更懂業務

談及專業辦公，一個事實情況是，大語言模型不能很好的處理表格數據。因此業內有許多大數據團隊、BI 類產品，正在進行低調的二次創業，產品理念就是 AI + BI，處理 Excel 數據。

看起來， Excel 呈現的是一些結構化數據；實際上，Excel 更像一個“壓縮包”，里面包含了公式、格式、引用關系、命名區域等雜七雜八的對象。而大模型的輸入只是 Token 序列，兩者之間存在結構性錯位。

此外，當數據以 Excel 的形式輸入大模型，消耗的 Token 量輕松翻倍，即使上下文窗口達到 100K ，很容易導致一個中等大小的 Excel 報表被截斷。

最后，所謂的結構化數據，放在實際業務場景中，一般都是非結構化的……以媒體業務為例，內容類型的標準寫法通常是：圖文、視頻、音頻、博文……實際的填寫情況一般是：頭條、三條、單推、微博置頂三天……這種混亂是真實業務的常態，也是大模型最容易翻車的地方。

總結一下，在我們眼里一個結構精美的 Excel 報表，在大模型眼里可能就跟圓明園差不多——所以我特地準備了一份結構有“一點”復雜的真實業務報表，200 多行，100 多列，包含文字、數字、日期、公式、表格合并等要素，涵蓋 InfoQ 過去一年的主要合作情況。

這份報表在經過基本的脫敏工作以后，我投喂過 ChatGPT 等一眾主流 ChatBot，會被截斷，無法正常解讀；投喂過一家創業公司的 Agent 平臺，導致對話卡死，無法回復，報了 Bug。現在又被我投喂給了 M2.7。

我們先來看看上下文問題。

Q1：現在你是我的業務助理秘書，附件是過去一年我業務的經營數據，現在你讀到了多少行、多少列數據？

MiniMax 比較精巧的一點是，官網默認訪問 MiniMax Agent，而非一個 ChatBot，所以面對這個問題直接拉起 Agent 開始寫 Python 腳本。

最終輸出為：

• 交付物統計：406 行 × 147 列（列數最多）

• 2025 年 項目看板：405 行 × 130 列

這個數字證明，Excel 不但沒有被截斷，數據量比我預想的還要大。仔細檢查表格后我才發現，在上百空行后，存在一個孤零零的誤錄入數據，此前一直沒有被發現過：

Q2：此前所有的合作中，合作規模最大的五名客戶的情況整理給我，子業務的合作直接統計到集團口徑下，如飛書屬于字節跳動旗下，飛書合作合并至字節跳動整體。**

這其實是個非常模糊的提問，我并未說明所謂的合作規模用什么數據界定。同時子業務與集團的關系，需要模型自己去查證判斷。

M2.7 沒有被這份'爛數據'帶偏——分類邏輯、金額匯總、集團歸并全部正確。

Q3：文章、視頻類內容分別合作了多少次？總體金額分別是多少？還有哪些數據趨勢值得被關注？

這屬于業務經營的常規問題，但標準同樣模糊，同時考驗對數據的整體理解和分析。

M2.7 的數據解讀無誤：

同時模型也提供了業務發展的四個關鍵洞察，且都有數據佐證：

• Q2 和 Q4 是交付旺季，需提前儲備人力和資源；

• xx 的已交付項目尚未回款，建議加強應收賬款管理（數據不準確，但是數據源的問題，而非解析問題）；

• 2025 年新項目金額同比增長 58%，業務增長強勁；

• 內容能力是核心，深度稿件貢獻超 1/4 收入；

至此，數據分析的結論已經有了，但如何將結論以專業、直觀的形式呈現，是辦公場景的另一大挑戰。于是我提出了第四個問題：

Q4：基于以上數據，幫我生成一個透視方案，展示每一個項目經理的季度項目承接金額，同時分析每一個項目經理服務的企業偏好，最終報告結論：是否有必要圍繞某幾家頭部合作伙伴組建服務專班？**

M2.7 調用了 Excel 處理技能，構建了透視表框架，準確設置了行、列及多個值字段，并按要求分項目經理創建了對比視圖。最終交付物是一個結構清晰、可直接用于對比分析的工作報表稽核，以及一份關于專班組建策略的業務洞察和分析報告。

（受限于業務敏感數據，僅展示部分分析結果）

從讀懂數據、理解業務邏輯，到直接生成可匯報的分析圖表——對辦公能力的考察可以告一段落了。尤其是 Excel 數據處理的能力考察，我覺得可以告一段落了，同時也給行業留下了幾個問題：

1. 我一度想采購智能 BI 產品做數據分析，但現在覺得用 MiniMax 就夠了，如果這是普遍情況，那么 BI 類產品對小微企業的商業邏輯是否面臨調整？

2. MiniMax 不做 ChatBot ，但做了 Agent 平臺。在 AI 辦公領域，ChatBot “水土不服”的情況早已出現，MiniMax 做了很好地產品演示。

3. MiniMax Agent 免費版每天提供 200 積分，上述交互一共開銷 117 積分，智能成本還在降低。

根據 MiniMax 財報電話會的情況看，壓注 2026 AI 辦公賽道，是個確鑿無疑的事情。緊接著另一個大命題就是軟件工程能力——VibeCoding 因為代碼太過隨性而遭受詬病，正在走向臺前的是 Harness Engineering，這也成為了對 MiniMax M2.7 的測試重點。

從修 Bug 到改架構，
看見“自我進化”的雛形

關于軟件工程，我的測試方向是開發一款業務流管理軟件。眾所周知，在國內做類似的軟件開發是不賺錢的——錢少事兒多難復制。比如對于一家媒體公司而言，選題就是生命線，但市面上還沒有成熟的選題管理工具。媒體公司要么自研，要么降級使用表格或多維表格。

于是我給了 MiniMax M2.7 一個非常籠統的指令，調用平臺為 Cursor——

Q1: 幫我做一個媒體選題管理工具

過往應用構建平臺，遇見此類籠統問題，大概有兩種處理模式，一種是蒙，既然 Prompt 不夠好，那就隨便做，質量不能保證；還有一種是對話式詢問，需要用戶階段性提供關鍵信息和指令。

在我看來兩種都不夠科學。許多 AI Builder 不具備軟件工程能力和產品能力，意味著他們天然無法很好地描述一個軟件架構。如果 AI 不能根據模糊指令產出一個質量足夠高的軟件作品，使用上就會面臨很大的限制，不叫 AI Coworker，應該叫 AI Codeveloper。

M2.7 的交付物至少具備完整的功能設計，以及進一步優化和迭代的基礎。至少對于小團隊來說，是絕對可以投入使用的：

這里有一些 UI 問題，我們留到后面解決。關于軟件邏輯的優化，也一并放在后續測試中。

Q2: 幫我開發完整的日志系統，包括記錄每一次選題的新增、修改、刪除操作，包含操作時間和操作內容；記錄每一次導出操作；記錄每一次報錯信息。

添加日志系統，是為了盡量填補非職業開發者和職業開發者之間的界限，實現非職業開發者也能一定程度上嘗試定位系統問題。

這次開發遇見報錯，指使 M2.7 自查并修復了問題：

修復后，可以看到日志系統已添加，且可以將選題數據導出為 Json 文件：

Q3：對日志系統進行修補，增加 1、 日志按日期分文件存儲；2、提供一個日志查看界面，支持按日期和操作類型篩選；3、 日志文件超過 10MB 自動歸檔"。4、其他你覺得必要的改動。

這是本次測試最值得記錄的一個瞬間——M2.7 沒有等我提問，沒有停留在簡單的指令遵循層面，而是自己重寫了存儲架構，自主完成了進化。

但同時，這次自主進化也導致了新的 Bug 出現，頁面再一次無法正常顯示了。

Q4：頁面無法正常顯示，嘗試檢修問題，測試日志系統是否記錄了此 Bug，如果沒有，確保日志系統會記錄 bug，并且可以在本地對日志進行查看。

這次的修復比較復雜，非開發者已經看不懂了，內容如下：

問題分析與修復

發現的問題

• Logger 異步初始化問題：之前的 logger.js 使用了復雜的 async/await 和 .bind() 模式，導致 Logger 方法在 IndexedDB 初始化完成前不可用

• 全局錯誤處理器的同步調用：在模塊加載時直接調用異步的 logger.logError() 會導致問題

修復內容

• Logger 重寫為同步優先架構：

• • 即使 IndexedDB 不可用，內存存儲仍能正常工作

  • 后臺異步嘗試持久化到 IndexedDB

  • 所有日志方法立即寫入內存（同步操作）

• 全局錯誤處理器安全包裝：

  };

• 降級方案：

• 最多保存 100 條內存日志

• IndexedDB 不可用時自動降級到內存存儲

值得肯定的是，M2.7 工程判斷能力在線，它重新設計了日志系統的架構，采用了生產級日志系統的標準設計模式。一個 AI 在沒有被明確要求的情況下，自主收斂到了這個方案，說明它對"日志系統應該長什么樣"有真實的工程認知，不只是在修 bug。

不過問題是，走到正確判斷的路途是相對曲折的——M2.7 的推理過程更像是“試錯”，充斥著大量類似詞匯："The issue is likely...""Wait, let me re-read...""Actually the bigger problem...""But wait...""Let me reconsider..."，注意力焦點有些漂移，中途一度想加一個安全檢查，打補丁了事。

但換個角度想，只要推理不是過于漫長，那么對于 AI 來說，時間不是個稀缺資源——AI 可以 24 小時工作，保障正確即可：

至此，可以說 MiniMax M2.7 有足夠的工程能力去做應用，而不是 Demo。但作為業務負責人，我已經厭倦了不停驅使它調試 Bug，我需要它自己設計好升級節奏。

Q5：對當前的選題管理平臺進行軟件系統和產品層面的雙向評估，結合剛才的所有報錯，告訴我你的改進計劃，分天執行，先執行今天的。

M2.7 規劃了一個“7 天改進計劃”：

關于生產級軟件開發評測的最后一 Part，我想增加兩個極限壓力測試。這里“極限”的概念與軟件研發領域的“極限”概念不同，我無意寫 Python 腳本去考驗這個作品的讀寫性能，但想把業務場景真實的混亂和矛盾帶給它，看看它的“智能極限”在哪里。比如：

1. 如果一次性給出 8 條含約束條件的復雜指令，它還能做好指令遵循嗎？

2. 如果給出一條自相矛盾的指令，它會如何處理？

于是問題 6 和 7 應運而生：

Q6：在現有工具基礎上增加以下功能：

① 新增'預計閱讀量'字段，只接受數字輸入；

② 狀態字段新增'已歸檔'選項；

③ 熱度評分改為 1-10 分制，低于 6 分自動標紅；

④ 新增選題導出功能，導出為 md 格式；

⑤ 導出時自動過濾掉'已歸檔'狀態的選題；

⑥ 頁面頂部顯示當前未歸檔選題總數；

⑦ 所有時間字段統一顯示為 MM-DD 格式；

⑧ 新增一個'備注'字段，支持多行文本輸入

Q7：導出功能需要同時滿足：① 選題導出的范圍，要包括已歸檔的選題；② 已歸檔的選題為廢棄選題，不能導出；③ 只有一個導出按鈕

第六個問題，指令全部完成，沒有丟失。第七個問題則徹底把 M2.7 繞進去了，它沒有再次跟我確認指令的矛盾之處，而是選擇把已歸檔選題直接過濾掉。

這延伸出一個直觀問題：如果要構建一個生產級的復雜系統，自洽的產品設計仍然應該是前置的、必須的，全部扔給模型邊看邊做，很可能會出現問題——畢竟 AI 可以支持長上下文，人卻可能自相矛盾。

一個龍蝦彩蛋：
MaxClaw多步驟Agent測試

在 Agent 社區“龍蝦模式”爆火的當下，MiniMax 順勢也推出了 自己的龍蝦模式：MaxClaw，內置模型也更新成了 M2.7。

就在 M2.7 發布的同一天，被龍蝦帶火的第三方測評榜單 PinchBench 更新了排名。

在 Best Score 口徑下，M2.7 以 86.2% 的任務完成率擠進全球第四，超越了 NVIDIA 的 Nemotron 3，與第一名 Sonnet 4.6 的差距只有 0.7 個百分點，進一步驗證了其在復雜 Agent 任務上的競爭力。

說實在的，用了接 M2.7 的 MaxClaw 以后，我已經完全不想體驗其他的 OpenClaw 產品了。

切換會話環境以后導致 Skill 無法正常觸發，因為權限問題導致對話無響應，出現問題無法自查只能窮舉原因……最近調試各路 “OpenClaw”讓我仿佛回到了程序員時代，不是不能 Debug，而是厭倦 Debug。MaxClaw 讓我重新找到了“寄存大腦”的感覺。

• 安裝 Skills 直接拋鏈接，遇到網絡問題自己重試

• 完全拋棄配置頁面，只負責對話框給信息

• 一句話拉起四個 Agent 開始干活

• 遇見問題自主解決，自主推進流程

必須要強調，在我看來，AI 時代所有軟件層面的使用困難，都是產品力和研發效能不足的直觀體現，用“動手能力” PUA 用戶的時代應該結束了。在這點上，MaxClaw 做得很好。

結 語

綜合來看，MiniMax M2.7 在辦公場景的能力，軟件工程能力，與自家 MaxClaw 的適配度都超出我的預期。應該說，上市前后，MiniMax 管理團隊面向資本市場拋出了許多“故事”和“大餅”，但實現速度也比市場預期的更快——至少幫我節省了許多 BI 工具和 Coding 產品的訂閱費用。

核心待優化點，仍然是最復雜事件的處理，包括相對復雜的 Bug 的快速定位；大規模改寫代碼時，如何降低出錯概率；多輪對話中，針對自相矛盾的 Prompt，如何更妥善的進行處理。這些恐怕也是當下所有 Coding Agents 面對的共同課題。

如果你是一個“一人公司”的實踐者、小微公司的管理層，MiniMax M2.7 可能會在一個統一的平臺上，幫你解決多個維度的問題，同時不需要支出大筆的訂閱費用，也不需要到處跑會，學習“龍蝦部署”。

這次測試給我留下最深印象的，不是某一個具體的答對或答錯，而是一種感覺——AI 正在悄悄越過'輔助工具'的邊界，開始侵蝕專業人員的領域。MiniMax 的 Agent 平臺，正讓這條邊界變得越來越模糊。至于這對 BI 賽道、對 AI 辦公、對創業公司意味著什么——答案已經在數據里了。