把 MiniMax M2.7 扔進(jìn)真實業(yè)務(wù)里：它替我省了 BI 和程序員的錢

作者 | 駱駝

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

我們都在等待 MiniMax 證明一個問題：一個 AI-Native 型的創(chuàng)業(yè)組織，能跑多久，到達(dá)何種位置？

這也是我們?yōu)楹伪仨殰y試一下 MiniMax M2.7 。

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

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

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

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

2. 專業(yè)辦公能力；

3. 自我進(jìn)化能力；

4. 更好的互動娛樂表現(xiàn)，包括人設(shè)保持和情商；

除了互動娛樂表現(xiàn)，其他三項都在本次測試計劃內(nèi)。我避開了寫游記、做網(wǎng)頁等常規(guī) Demo，設(shè)計了一套更貼近真實業(yè)務(wù)“爛攤子”的測試題：

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

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

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

從數(shù)據(jù)處理到系統(tǒng)構(gòu)建再到多智能體協(xié)作，最終指向一個終極問題：AI 能否真正“干活”而非“演示”？ 測試結(jié)果，出乎我的意料。

當(dāng) Excel 變成“壓縮包”
它比 BI 更懂業(yè)務(wù)

談及專業(yè)辦公，一個事實情況是，大語言模型不能很好的處理表格數(shù)據(jù)。因此業(yè)內(nèi)有許多大數(shù)據(jù)團隊、BI 類產(chǎn)品，正在進(jìn)行低調(diào)的二次創(chuàng)業(yè)，產(chǎn)品理念就是 AI + BI，處理 Excel 數(shù)據(jù)。

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

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

最后，所謂的結(jié)構(gòu)化數(shù)據(jù)，放在實際業(yè)務(wù)場景中，一般都是非結(jié)構(gòu)化的……以媒體業(yè)務(wù)為例，內(nèi)容類型的標(biāo)準(zhǔn)寫法通常是：圖文、視頻、音頻、博文……實際的填寫情況一般是：頭條、三條、單推、微博置頂三天……這種混亂是真實業(yè)務(wù)的常態(tài)，也是大模型最容易翻車的地方。

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

這份報表在經(jīng)過基本的脫敏工作以后，我投喂過 ChatGPT 等一眾主流 ChatBot，會被截斷，無法正常解讀；投喂過一家創(chuàng)業(yè)公司的 Agent 平臺，導(dǎo)致對話卡死，無法回復(fù)，報了 Bug。現(xiàn)在又被我投喂給了 M2.7。

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

Q1：現(xiàn)在你是我的業(yè)務(wù)助理秘書，附件是過去一年我業(yè)務(wù)的經(jīng)營數(shù)據(jù)，現(xiàn)在你讀到了多少行、多少列數(shù)據(jù)？

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

最終輸出為：

• 交付物統(tǒng)計：406 行 × 147 列（列數(shù)最多）

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

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

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

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

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

Q3：文章、視頻類內(nèi)容分別合作了多少次？總體金額分別是多少？還有哪些數(shù)據(jù)趨勢值得被關(guān)注？

這屬于業(yè)務(wù)經(jīng)營的常規(guī)問題，但標(biāo)準(zhǔn)同樣模糊，同時考驗對數(shù)據(jù)的整體理解和分析。

M2.7 的數(shù)據(jù)解讀無誤：

同時模型也提供了業(yè)務(wù)發(fā)展的四個關(guān)鍵洞察，且都有數(shù)據(jù)佐證：

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

• xx 的已交付項目尚未回款，建議加強應(yīng)收賬款管理（數(shù)據(jù)不準(zhǔn)確，但是數(shù)據(jù)源的問題，而非解析問題）；

• 2025 年新項目金額同比增長 58%，業(yè)務(wù)增長強勁；

• 內(nèi)容能力是核心，深度稿件貢獻(xiàn)超 1/4 收入；

至此，數(shù)據(jù)分析的結(jié)論已經(jīng)有了，但如何將結(jié)論以專業(yè)、直觀的形式呈現(xiàn)，是辦公場景的另一大挑戰(zhàn)。于是我提出了第四個問題：

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

M2.7 調(diào)用了 Excel 處理技能，構(gòu)建了透視表框架，準(zhǔn)確設(shè)置了行、列及多個值字段，并按要求分項目經(jīng)理創(chuàng)建了對比視圖。最終交付物是一個結(jié)構(gòu)清晰、可直接用于對比分析的工作報表稽核，以及一份關(guān)于專班組建策略的業(yè)務(wù)洞察和分析報告。

（受限于業(yè)務(wù)敏感數(shù)據(jù)，僅展示部分分析結(jié)果）

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

1. 我一度想采購智能 BI 產(chǎn)品做數(shù)據(jù)分析，但現(xiàn)在覺得用 MiniMax 就夠了，如果這是普遍情況，那么 BI 類產(chǎn)品對小微企業(yè)的商業(yè)邏輯是否面臨調(diào)整？

2. MiniMax 不做 ChatBot ，但做了 Agent 平臺。在 AI 辦公領(lǐng)域，ChatBot “水土不服”的情況早已出現(xiàn)，MiniMax 做了很好地產(chǎn)品演示。

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

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

從修 Bug 到改架構(gòu)，
看見“自我進(jìn)化”的雛形

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

于是我給了 MiniMax M2.7 一個非常籠統(tǒng)的指令，調(diào)用平臺為 Cursor——

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

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

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

M2.7 的交付物至少具備完整的功能設(shè)計，以及進(jìn)一步優(yōu)化和迭代的基礎(chǔ)。至少對于小團隊來說，是絕對可以投入使用的：

這里有一些 UI 問題，我們留到后面解決。關(guān)于軟件邏輯的優(yōu)化，也一并放在后續(xù)測試中。

Q2: 幫我開發(fā)完整的日志系統(tǒng)，包括記錄每一次選題的新增、修改、刪除操作，包含操作時間和操作內(nèi)容；記錄每一次導(dǎo)出操作；記錄每一次報錯信息。

添加日志系統(tǒng)，是為了盡量填補非職業(yè)開發(fā)者和職業(yè)開發(fā)者之間的界限，實現(xiàn)非職業(yè)開發(fā)者也能一定程度上嘗試定位系統(tǒng)問題。

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

修復(fù)后，可以看到日志系統(tǒng)已添加，且可以將選題數(shù)據(jù)導(dǎo)出為 Json 文件：

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

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

但同時，這次自主進(jìn)化也導(dǎo)致了新的 Bug 出現(xiàn)，頁面再一次無法正常顯示了。

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

這次的修復(fù)比較復(fù)雜，非開發(fā)者已經(jīng)看不懂了，內(nèi)容如下：

問題分析與修復(fù)

發(fā)現(xiàn)的問題

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

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

修復(fù)內(nèi)容

• Logger 重寫為同步優(yōu)先架構(gòu)：

• • 即使 IndexedDB 不可用，內(nèi)存存儲仍能正常工作

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

  • 所有日志方法立即寫入內(nèi)存（同步操作）

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

  };

• 降級方案：

• 最多保存 100 條內(nèi)存日志

• IndexedDB 不可用時自動降級到內(nèi)存存儲

值得肯定的是，M2.7 工程判斷能力在線，它重新設(shè)計了日志系統(tǒng)的架構(gòu)，采用了生產(chǎn)級日志系統(tǒng)的標(biāo)準(zhǔn)設(shè)計模式。一個 AI 在沒有被明確要求的情況下，自主收斂到了這個方案，說明它對"日志系統(tǒng)應(yīng)該長什么樣"有真實的工程認(rèn)知，不只是在修 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 有足夠的工程能力去做應(yīng)用，而不是 Demo。但作為業(yè)務(wù)負(fù)責(zé)人，我已經(jīng)厭倦了不停驅(qū)使它調(diào)試 Bug，我需要它自己設(shè)計好升級節(jié)奏。

Q5：對當(dāng)前的選題管理平臺進(jìn)行軟件系統(tǒng)和產(chǎn)品層面的雙向評估，結(jié)合剛才的所有報錯，告訴我你的改進(jìn)計劃，分天執(zhí)行，先執(zhí)行今天的。

M2.7 規(guī)劃了一個“7 天改進(jìn)計劃”：

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

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

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

于是問題 6 和 7 應(yīng)運而生：

Q6：在現(xiàn)有工具基礎(chǔ)上增加以下功能：

① 新增'預(yù)計閱讀量'字段，只接受數(shù)字輸入；

② 狀態(tài)字段新增'已歸檔'選項；

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

④ 新增選題導(dǎo)出功能，導(dǎo)出為 md 格式；

⑤ 導(dǎo)出時自動過濾掉'已歸檔'狀態(tài)的選題；

⑥ 頁面頂部顯示當(dāng)前未歸檔選題總數(shù)；

⑦ 所有時間字段統(tǒng)一顯示為 MM-DD 格式；

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

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

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

這延伸出一個直觀問題：如果要構(gòu)建一個生產(chǎn)級的復(fù)雜系統(tǒng)，自洽的產(chǎn)品設(shè)計仍然應(yīng)該是前置的、必須的，全部扔給模型邊看邊做，很可能會出現(xiàn)問題——畢竟 AI 可以支持長上下文，人卻可能自相矛盾。

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

在 Agent 社區(qū)“龍蝦模式”爆火的當(dāng)下，MiniMax 順勢也推出了 自己的龍蝦模式：MaxClaw，內(nèi)置模型也更新成了 M2.7。

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

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

說實在的，用了接 M2.7 的 MaxClaw 以后，我已經(jīng)完全不想體驗其他的 OpenClaw 產(chǎn)品了。

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

• 安裝 Skills 直接拋鏈接，遇到網(wǎng)絡(luò)問題自己重試

• 完全拋棄配置頁面，只負(fù)責(zé)對話框給信息

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

• 遇見問題自主解決，自主推進(jìn)流程

必須要強調(diào)，在我看來，AI 時代所有軟件層面的使用困難，都是產(chǎn)品力和研發(fā)效能不足的直觀體現(xiàn)，用“動手能力” PUA 用戶的時代應(yīng)該結(jié)束了。在這點上，MaxClaw 做得很好。

結(jié) 語

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

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

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

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