对比了 Gemini 和 Sonnet 4.5，我才知道 MiniMax M2.1 写代码这么强

2025 年快到尾声了，人类世界的圣诞、新年、年终总结轮番上场，模型世界也像是进入了“加班季”：11 月刚把 MiniMax M2 的能力用热乎了，到了 12 月底，MiniMax 又把 M2.1 推了出来。虽然版本号只是加了个 “1”，但这次的发布同样是重量级的：以后用模型写代码，不光是前端和 Python 脚本漂亮，后端使用的所有编程语言，都可以写得又快又好。

因为，M2.1 的目标是多岗位、多语言的软件工程（Multi-SWE）可用性。

一、多语言优化，代表的是更多工作岗位、更多编程语言的可用性

我们是 MiniMax 的老用户，所以第一批次就开始使用和测试 M2.1 这个新版本了。这次 M2.1 的特性之一就是多语言编程优化。刚开始听到这个概念，会以为是多支持了几门语言，但用起来才知道，这里的指向不是语法覆盖，而是他们在针对性的解决一个编程模型领域的行业痛点：

以前很多模型在 JS/TS 前端和 Python 脚本上“干的非常漂亮”——事实上早期很多 demo 和原型项目都是基于 JS 和 Python 做出来的，一旦转到 Java 后端、Golang 服务、C++ 客户端/SDK，代码质量就会明显下滑：代码结构、工程习惯、接口的边界、并发/内存这些东西就开始出错。

为什么会这样？这并不是因为模型“偏心”，而是由训练数据的形态、语言本身的特性以及工程复杂度这三个维度共同决定的。简单来说：JS/Python 往往是“所见即所得”的逻辑，处理好这些就行了，而 Java/Golang/C++ 会有更多“草蛇灰线般”的架构约束。

举个例子：你让 AI 写一个 Python 爬虫，它主要关注 requests.get 然后做 parse 就可以了，都是线性操作。让 AI 写一个 C++ 网络库，它不仅要处理逻辑，还要处理 std::move，锁的粒度，以及析构函数的副作用。早期的 AI 很难在没有全局上下文的情况下处理好这些“隐式约束”。

除此之外，还得考虑岗位上下文、后端、客户端、基础设施、工具链等等，对应的约束非常复杂。

M2.1 着力解决的就是这些问题，最终形成用前后端更多编程语言构建工程化项目的能力。

具体来看，M2.1系统性提升了 Rust / Java / Golang / C++ / Kotlin / Objective-C / TypeScript / JavaScript 等语言的能力，多语言任务整体表现达到业内领先水平，覆盖了从底层系统到应用层开发的完整链路。

为了衡量模型“从零到一”构建完整、可运行应用程序的全栈能力，MiniMax 还构建并开源了全新基准 VIBE，能够自动评估生成的 Application 在真实运行环境中的交互逻辑与视觉美感。

MiniMax-M2.1 在 VIBE 综合榜单中表现卓越，以平均 88.6 分的成绩展现了接近Claude Opus 4.5的全栈构建能力，并在几乎所有子集上都显著优于Claude Sonnet 4.5。

二、M2.1：把写代码这件事，从 Coding 本身变成一种更值钱的工程能力

很多模型都是能写 Java，也能写 Go，但是后端研发的同事总是和我反馈，AI 写后端总有一种“前端思维硬套后端”的味道：为了过测试而过测试，为了让代码看起来完整而把复杂度堆进去。墨问的后端主要编程语言是 Go，AI 写出来总像是 JS，维护起来十分麻烦。

M2.1 这次提供的能力更贴近真实工程：包的结构和接口设计、并发模型、设计模式运用等等，表现都不错，覆盖了从底层系统到应用层开发的完整链路。

是的，这次 M2.1 还加强了原生 Android / iOS 开发能力，Web 的开发能力，在我们的使用过程里，模型在 Web 与 App 场景中的设计理解与美学能力增强了，能够出色地构建复杂交互场景，模拟和可视化表达做得也非常出色。

M2 自发布以来，获得了大量好评，很大程度来自“M2 在开发者的工作流里是个好工具”：

MiniMax-M2 在多文件编辑、“编码-运行-修复”循环以及可测试验证的代码修复方面表现优异。在 Terminal-Bench 和 (Multi-)SWE-Bench 类任务上表现非常亮眼，这些都证明了 M2 在跨语言的终端、IDE 和 CI（持续集成）环境中的实战能力。

相比 M2，MiniMax-M2.1 的模型回复以及思维链更加简洁，在实际编程与交互体验中，响应速度显著提升，Token 消耗明显下降，在 AI Coding 与 Agent 驱动的连续工作流中更加流畅和高效。

同时，M2.1 把“多语言能力”放到了核心位置上，本质上是在做一种平衡：不仅仅是前端写得好写得快，还会补齐后端工程语言“更难、更隐蔽、但更值钱”的能力。

我提到了更值钱，是因为这里对应了更多的岗位：后端、基础设施、客户端、工具链、web3 协议实现等等……这些岗位的代码，往往更接近业务的“骨架”，也更接近团队每天真正要维护的东西。模型一旦能在这里变得可靠，价值会更容易被持续感知，而不只是停留在惊鸿一瞥的前端界面上。

三、写了这么多，咱得上手实战啊，我使用的感觉是：对比 Gemini 与 Sonnet，M2.1 的“工程感”更强。

那种“以前不敢用、现在敢用了”的感觉出现了。

Case 1：真实工程里的 Go 代码优化

在真实的工程中，随着业务功能的不断演进，一套代码经历的时间越久，代码的业务复杂度越高，维护越难，解决这个问题通常的做法是通过 linter 工具不断检查、不断优化，来减缓代码复杂度的“熵增”。

下面是我们工程中的一段 Go 代码， golangci-lint 提示复杂度过高，存在 nestif（嵌套 if）的问题。我们把 golangci-lint 的告警丢给了最近大火的 Gemini 3 Flash ，结果并不理想。

经过十几秒的思考，Gemini 3 Flash 给出了一系列的 Todolist，Gemini 不但要优化告警中提到的部分，还要顺带优化其它的部分——在我看这里有点过度思考了——随着不断的修改和不断的检测，从左侧的 code map 的 diff 中可以看到，第一步就改了很多代码了。随后代码开始出现语法错误，Gemini 又忙着修改衍生的语法错误，最终我们只能停掉回滚。

同样的问题我们丢给了 MiniMax M2.1，模型在经过二到三次思考后，立即发现 nestif 的问题所在， 进行了 2 行代码的变更（图中的 +17 -19，其实就是去掉了 2 行），修改就结束了。

可以看到，M2.1 并没有过度优化，只是针对代码中 nestif 的部分进行了改动——并且，在最后的最后，还提示我，其它位置可以做类似的优化，体贴不逾矩，难得。从优化方案中可以看到，M2.1 通过合并了 2 层 if，在解决 nestif 问题的同时，也降低了这段代码的圈复杂度，改动量最小。

同样的问题也丢给了 Sonnet 4.5，它的策略相对“中庸”：选择把中间 nestif 的部分抽取出来，形成了一个新的方法。哪里复杂度高，就把哪里抽取出来，因为有了新方法，复杂度就重新计算了。这种方式是目前大模型在处理类似问题时的常规做法，也算迂回解决了问题。而这种通用的解决方式，同时意味着模型并不是真正了解 Go 语言的特性。

Case 2：Agent 场景下的多文件改造（为我们微服务 MonoRepo 下，所有子服务（54 个），升级 DockerFile，做容器瘦身）

在这个 Case，我想知道模型能不能当工具用。

在我们这个 MonoRepo 里，包含 54 个子项目以及多种格式的 Dockerfile，基于不同 image 做 base 镜像的，写法各不相同。我们的 Prompt 是：

我们能看到，M2.1 会基于不同的子项目，以及不同的书写风格，先进行分类，形成 Todolist。（其中有 3 个子项目我之前已经做完了，M2.1 也能够识别出来，直接跳过了）

执行 10 分钟不到，过程平稳，没卡顿、没跑偏、没崩溃，给我省大事了：

四、把 M2.1 放到 IPO 招股书里：技术投入不再只是“烧钱”，而是“可验证的产出”

MiniMax 最近开始准备 IPO 了，很可能成为从成立到 IPO 历时最短的AI公司。招股书我都看了，营收爆发式增长，毛利率显著改善，非常好的事情。

谈 IPO 其实很现实：资本市场不怕投入大，怕的是投入之后，未来看不到产出路径。

近期看到很多公开报道，对 MiniMax 招股书/聆讯后资料集的解读是：持续的研发与训练投入，以及成本结构如何随规模与效率改善而变化。

事实上 MiniMax 早期一直把重心放在大模型架构与多模态建模等底层能力上，这条路线投入重、见效慢，但一旦跑通，回报也更“长期主义”。

在这个场景里，M2.1 的意义就不只是“又发了个新模型”，而是给“技术投入”提供了更多可验证的工程产出：

1、后端/客户端/多语言工程能力，过去往往是模型的短板，也是最容易在真实团队里暴露的问题。补足这个能力，等于把投入转成可复用的生产力。

2、推出并开源 VIBE 这种更贴近真实交互与运行环境的评测范式，让模型评估更加精准透明。

3、多模态与工程场景并重：当这些投入的成果不断体现在产品和模型迭代上，商业模式跑的也越来越顺畅。

IPO 从来不奖励“烧钱”，但可以复用的工程能力永远是资本青睐的。M2.1 在这方面的叙事可以说非常硬朗。

五、模型的进步，开始从“拼聪明”转向“拼岗位感”

M2.1 这次最值得被看见的地方，是它把“工程世界的现实”当成了训练与产品的中心：编程语言只是表层能力，对应的岗位与长任务规划才是底层逻辑。

从 M2 的工具化口碑，到 M2.1 对多语言编程与多岗位的能力加强，加上 IPO 对长期研发投入的解释，MiniMax 这条路线越来越像是在回答一个更具体的问题：模型不仅要更聪明更强大，还要能成为团队里那个放心干活的“人”。

咱们先把 MiniMax M2.1 用起来，期待 MiniMax 上市顺利～

现在 MiniMax M2.1 API 已在开放平台全量上线：

https://platform.minimaxi.com/docs/guides/text-generation

另外，MiniMax 的编程套餐已经支持 M2.1 的使用，点击阅读原文直达。