昨天凌晨，沒有任何預兆的情況下。

小米的MiMo-V2.5和MiMo-V2.5-Pro上線了。

API也已經(jīng)正式上線。

最近不知道怎么了，各種大模型真的發(fā)的一個賽一個一個猛，上周Claude Opus 4.7，這周Kimi K2.6，昨天 MiMo-V2.5-Pro ，還有姚順雨帶隊的全新HY3，今天又發(fā)了GPT-5.5，估計馬上還有DeepSeek V4。。。

這個蓬勃的時代啊。

MiMo的模型我其實一直都比較喜歡，自從羅福莉去了小米之后，肉眼可見小米的大模型水平在直線上升。

當然，最關(guān)鍵的原因，還是是因為，我是十二年的米粉，還是喜歡很喜歡小米的設計和硬件的，甚至我全家的所有家電都是小米。。。

不過在昨天下午試完 MiMo-V2.5-Pro 后，有一說一，這是我覺得，能跟GLM-5.1和Kimi k2.6掰掰手腕的模型，說實話，是有點超出我的預期的。

正兒八經(jīng)的可以躋身第一梯隊的那種，群里很多開發(fā)也都在聊。

還是老規(guī)矩，先來放一下跑分，不過也就大概看一眼就行，反而大家都是贏學。

在AA榜上，目前跟Kimi K2.6并列開源第一。

成績很不錯，跑分上，也比自家之前進步不少。

然后上下文窗口很香，是100萬，感覺現(xiàn)在百萬的上下文已經(jīng)成為各大模型的標配了，今天發(fā)的GPT-5.5也支持了1M上下文。

然后就是價格方面，這塊我其實一般都是放在最后提，但是這次，一定得放在前面，因為真的性價比很高，而且估計剛出沒有多少人用，接了API之后，那速度是真快啊。。。

不像有些國產(chǎn)模型，都能干到延遲好幾秒。。。

通過API key調(diào)用的價格是，在0到256k token內(nèi)，是￥7/￥21每百萬token（輸入/輸出）。

在256k到1M token內(nèi)是￥14/￥42每百萬token（輸入/輸出）。

Opus 4.6這塊，是$5/$25每百萬token（輸入/輸出）。

大概能便宜60%左右。

除了API之外，MiMo這次也出了新的Token Plan，也不區(qū)分256K和1M上下文，統(tǒng)一收費。

這個價格，我坦誠的講， 挺良心了。

我自己測試下來，其實工具調(diào)用和Coding開發(fā)能力，意外的還不錯，非常像那個味道，而且，說人話。。。

我是在Claude Code里面用的，相信我，Claude Code + MiMo-V2.5-Pro ，是我現(xiàn)在非常非常推薦的國內(nèi)Agent組合，很多朋友不是搶不到智譜的Coding Plan，用不到GLM-5.1嗎，你相信我，此時此刻，用 Claude Code + MiMo-V2.5-Pro 就是我覺得目前效果最好的組合。

便宜大碗省token，效果還很好，關(guān)鍵現(xiàn)在沒啥人用，速度還賊快。

我自己雖然依然還是會選擇Coding用Claude Opus 4.7，知識創(chuàng)作用Claude Opus 4.6的組合，但是我知道，并不是每個人都能用上Claude的，甚至GPT都用不上，去裝個Claude Code + MiMo-V2.5-Pro 的組合，非常的絲滑。

怎么裝Claude Code，以及怎么通過cc-switch在Claude Code里接國產(chǎn)大模型，我周一發(fā)過，我就不細說了，還沒用的朋友可以去翻一下。

那在周一那篇教程之上，我們想把模型換成這個新的，操作也不復雜。

我們雙擊打開cc-switch。

在Claude下，點擊右上角的加號。

供應商選擇Xiaomi MiMo，然后填入API Key。

模型名填上mimo-v2.5-pro。

添加，在首頁啟用之后，打開Claude Code，就可以直接用上了。

給大家看一個，我下午測試，自己通過MiMO搓的還挺滿意的一個case。

就是我一直有個想法，想自己做一個更好用的公眾號文章數(shù)據(jù)分析平臺。

你們知道的，我一直覺得，文章創(chuàng)作不是發(fā)出去就完事的，讀者的反饋超級無敵至關(guān)重要。

到現(xiàn)在，我們的公眾號已經(jīng)發(fā)了612篇文章了，也積累了很多很多的數(shù)據(jù)反饋。

雖然公眾號后臺有現(xiàn)成的數(shù)據(jù)分析工具，但對我們來說是不夠用的。

首當其沖，它給的數(shù)據(jù)分析指標很有限，肉眼去看只能看個大概趨勢。

我們自己也是去抓了更詳細的數(shù)據(jù)，之前也給大家看過，我們的那張數(shù)據(jù)分析表。

但咋說呢，數(shù)據(jù)的分析和洞察，還是太少了，而且每次看的我頭疼，密密麻麻的數(shù)據(jù)太多了。

我一直想的是，能不能有一種更好的方式，把這些數(shù)據(jù)量化，然后從里面挖出一些可能被我們忽略的趨勢，或者信號。

比如這周一發(fā)的Claude Code保姆級教程那一篇，我對他的數(shù)據(jù)是很看好的。

剛發(fā)出來的閱讀量和轉(zhuǎn)發(fā)率也確實不錯。

一個小時的轉(zhuǎn)發(fā)就有近7000次。

但后續(xù)的數(shù)據(jù)顯然動力就不足了，增長得相當緩慢。

那我們肯定就需要復盤，除了平臺流量的因素之外，還有沒有什么原因，才有了這樣的問題。

之前一直就想搓一個這樣的網(wǎng)站，直接把飛書多維表格當數(shù)據(jù)庫，然后網(wǎng)頁做數(shù)據(jù)分析，再部署上到我們自己的服務器上，做好企業(yè)權(quán)限管理，給我們公司的小伙伴一起看。

所以正好就借著MiMo-V2.5-Pro的發(fā)布，看看能做成啥樣。

我就直接在Claude Code里直接開著語音輸入法直接口噴。

然后他就根據(jù)我說的這一堆，開始非常有條理地逐個輸出。

先給了我技術(shù)棧，架構(gòu)設計。

然后是數(shù)據(jù)分析邏輯，包括我提到的指標體系，轉(zhuǎn)發(fā)加速曲線，對比基線。

然后又輸出了項目結(jié)構(gòu)，頁面設計，實現(xiàn)步驟，驗證方式和清單等等等等究極詳細的方案。。

說真的，我跟MiMo-V2.5-Pro對話的時候，莫名其妙的，有一股子Opus 4.6的感覺。

說人話，給圖表，真好啊。。。

然后就直接開發(fā)了，過程我就不放了，大概就是每天腳本定時請求我們飛書數(shù)據(jù)庫，然后拿到最新的數(shù)據(jù)，做可視化分析。

最后，出來的是這么個東西。

因為我們的數(shù)據(jù)分析是要看三日的完整數(shù)據(jù)來進行分析，所以這里顯示的最新的文章還是周一的那一篇。

你能非常快速并且直觀地看到這篇文章各項的數(shù)據(jù)分布。

那明顯這一篇文章的短板數(shù)據(jù)主要還是在完讀率上面，以及它的轉(zhuǎn)發(fā)率是很明顯到后面動力不足的。

教程類的文章，轉(zhuǎn)發(fā)出去的多，但是真正會看的少，更別提會看完的了。

還有他的核心指標的分布。

這篇文章在我們過去所有的核心指標上都有怎樣的表現(xiàn)，也是一目了然。

還會生成一篇單獨的報告。

每篇文章的診斷報告也非常全面，不僅告訴你好的地方在哪，還有不太好的數(shù)據(jù)背后的原因是什么，以及可以改進的地方是什么。

還有我們的周報看板，展開后是這個樣子，能夠非常快速地看到過去四周發(fā)的每一篇文章的基本數(shù)據(jù)。

這個任務，到這里還沒完。

因為它還是靜態(tài)的頁面，我們公司的小伙伴，還是沒辦法訪問。

后面，我還讓他調(diào)用我自己給公司搓的服務器skill，把這個網(wǎng)站部署到了我們內(nèi)部的服務器上。

說實話，我這個服務器skill還是比較復雜的，因為跟飛書的認證做了打通，只有公司的小伙伴才能用，還有無數(shù)的隔離，讓大家的項目要跑在不同的容器里。

說實話，笨一點的模型，這個首次部署流程，都搞不定，我真的試過用一些國產(chǎn)的XX模型，真的，就部署這一步，直接失敗了。。。

MiMo-V2.5-Pro正常走了用戶首次的部署邏輯，需要進行認證，跟飛書企業(yè)對比，看看是不是我們公司的員工。

Mimo的理解和調(diào)用過程也非常絲滑，我把驗證碼給他后，按部就班的所有步驟，就成了，非常牛逼。

然后這一步還是沒完，因為上一步卡的是部署權(quán)限，但是部署上去的網(wǎng)址，其實所有人都可以公開訪問的，這肯定不是我們想要的，應該只有公司員工才能訪問才對。

于是，我又把我Coding的給內(nèi)部用的統(tǒng)一登錄中臺，也給它街上，這樣就能進行登錄權(quán)限管控了。

我們中臺上我放了一個接入文檔，因為平時我們小伙伴Coding的亂七八糟的東西太多了，每個人都有部署和管控登錄權(quán)限的需求，所以我就搞了這么一個文檔，他們把文檔鏈接發(fā)給Claude Code，就能把這個項目自動接入到我們的統(tǒng)一登錄中臺里面。

這文檔東西真的挺多的，因為還分了好多種方式和渠道，還要同步用戶信息等等亂七八糟的東西，我們還有三家飛書主體，每個權(quán)限還都不一樣，笨一點的模型，我在測試的時候，真的經(jīng)常接出BUG。。。

但是MiMo-V2.5-Pro，一輪，沒有任何修改，直接接完了。

我讓同事試了一下，沒毛病。

然后，到這一步，我看了一下整體的消耗。

1.2M的輸出，157.1K的輸出，緩存命中了29.6M，緩存現(xiàn)在還是限時免費，所以消耗還意外的少。

說實話，MiMo-V2.5-Pro，是有點東西的。

飛書數(shù)據(jù)通過飛書CLI一次拿到，正常開發(fā)，我的服務器skill一次部署成功，登錄中臺一次性接入成功，很帥。

我們公司我還搓了一個skills同步平臺，因為有很多同時自己都會搞各種各樣的skill，也會經(jīng)常分著用，但是以前的分發(fā)效率太低下了，都是在微信上互相穿skill，太呆了。

我就搓了個這么個東西，能讓大家把skill都上傳上去，其他人可以訂閱，訂閱了以后本地就會安裝那個skills，以后線上一更新，訂閱者本地就會跟著更新，非常的方便。

今天其實才第一次正式運行，之前是Opus 4.6開發(fā)的有一些BUG我就擱置了，然后，今天這些BUG，都是MiMo V2.5 Pro直接修好的。。。

甚至打標簽、加頭像之類的各種亂七八糟的功能，也都是我用MiMo V2.5 pro直接開發(fā)的。

是真的有點東西。

然后還有個很好玩的。

我把160萬字的甄嬛傳丟給了MiMo-V2.5-Pro，讓他分析人物關(guān)系圖，情節(jié)線，人物志，最后做了個可交互的網(wǎng)頁。

為了好看，我還讓他去搜電視劇演員的劇照換上。

最后的網(wǎng)頁還挺有意思，你能快速清楚整部劇每個重要角色，每個人物之間的關(guān)系。

還有時間線，各個人物陣營。

真的很好玩。

當然，MiMo-V2.5-Pro又有個缺點，就是前端審美的能力，確實還沒趕上模型其他方面的能力。

所以一開始在生成頁面的時候，會有那么一點勸退。

出來的視覺效果，說實話就是能用兩個字，談不上什么設計感，還是得配上一些前端設計的Skill，這個點跟GPT-5.4和5.5啥的真的就很像。

但是我感覺無傷大雅，前端設計有很多能彌補的點，但是很多邏輯類和代碼類的東西，這個才是核心。

就目前來說，MiMo-V2.5-Pro，確實就是我覺得配合Claude Code的國內(nèi)最好的模型之一。

這種窗口期我覺得不會太長，等大家都反應過來了，速度可能就沒這么快了，plan計劃可能也不一定好買了。

最后，祝大家。

創(chuàng)造愉快。

以上，既然看到這里了，如果覺得不錯，隨手點個贊、在看、轉(zhuǎn)發(fā)三連吧，如果想第一時間收到推送，也可以給我個星標?～謝謝你看我的文章，我們，下次再見。

>/ 作者：卡茲克、tashi

>/ 投稿或爆料，請聯(lián)系郵箱：wzglyay@virxact.com