很幸运前两天受邀参加了 M2.1 的内测，然后今天看到 MiniMax 官方正式发布了，先说结论：我觉得叫 M2.1 有点谦虚了，因为实际体验下来，MiniMax M2.1 的提升很明显。
1.延迟和长程任务的管理明显做了优化，同样的任务比之前效率更高，消耗更少的tokens，写代码不啰嗦；
2.另外指令遵循能力变强；
3.代码能力绝对称得上第一梯队（包括开源和闭源）
实际上，Minimax 在发布 M2 的时候讨论度就很高了，取得了很好的口碑，当时 M2 的拿到了全球前五，开源第一的成绩，尤其在AI coding Agent工具圈子很受欢迎。也是没想到还不到两个月，就更新了 M2.1。
从官方公布的SWE-bench Verified评测结果来看，M2.1（74%）的表现现在不仅是开源第一梯队，更是可以直接跟Claude sonnet 4.5、Gemini 3 pro这种商业模型掰手腕了。
同时M2.1 的激活参数在闭源模型里是最少了，这也是它推理效率高的重要原因之一。
上面提到，M2.1（也包括之前的M2）主打的是AI Coding Agent场景，所以我也是建议把它接入到这类工具中使用。
最推荐 Claude Code 或 Cursor 中的 Claude Code 插件。
一是因为官方提供了标准的接入方法；
二是对于国内的用户来说，Claude Code 用它自己的模型有点不方便，同时也很贵。
接入第三方模型是个不错的方案，能同时体验 Claude Code CLI 的强大和最大程度发挥模型的能力。
Mimax M2.1 接入 Claude Code 的方法如下，安装好Claude code之后，把下面这段配置写入到配置文件中（路径：~/.claude/settings.json）:
1 2 3 4 5 6 7 8 9 10 11 12 13
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.minimaxi.com/anthropic",
"ANTHROPIC_AUTH_TOKEN": "<MINIMAX_API_KEY>",
"API_TIMEOUT_MS": "3000000",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1,
"ANTHROPIC_MODEL": "MiniMax-M2.1",
"ANTHROPIC_SMALL_FAST_MODEL": "MiniMax-M2.1",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "MiniMax-M2.1",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "MiniMax-M2.1",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "MiniMax-M2.1"
}
}
把其中的<MINIMAX_API_KEY>换成自己的就可以了，API Key申请地址：https://platform.minimaxi.com/user-center/basic-information/interface-key
这样 Claude Code 的默认模型就是M2.1了。
以下是我这两天使用和测试 M2.1 的一些例子。
从零构建一个“食物营养分析”应用
这是我最近遇到的一个需求和想法，作为一个健身佬，平时有记录饮食摄入量的习惯，之前用的一些健康类APP一般都是手动记录每餐吃了什么，很不方便。而现在多模态大模型完全有分析食物热量的能力，所以就想到如果可以把每餐的照片发给大模型让它自动分析和记录，就方便多了，于是就有了做这样一个应用的想法。
说干就干，我直接把下面这段提示词甩给M2.1，核心需求就是上传图片，调用大模型API进行图片分析，得到结构化的分析结果，然后记录下来。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
创建一个本地运行的饮食营养分析web应用，主要功能如下：
1、核心功能：
- 实现用户上传食物照片功能（支持单张或多张拍摄/上传）
- 集成多模态大模型API（以Gemini 2.5 flash）进行图像识别和分析
- 输出详细的营养结构分析报告，包括：
- 三大营养素比例（碳水化合物、脂肪、蛋白质）
- 微量营养素（维生素、矿物质等）
- 总热量估算（千卡）
- 食物成分识别清单
2、目标用户特性：
- 针对体重控制人群的特殊需求：
- 提供每日/每餐营养摄入统计
- 可设置个人营养目标（如低碳、高蛋白等）
- 热量缺口/盈余计算功能
- 健康饮食建议生成
3、质量要求：
- 营养分析准确率需达到85%以上
- 图片识别响应时间<3秒
- 支持中英文双语界面
这是它直出的效果⬇️
核心模块和功能已经实现了，其实我并没有在prompt中指定技术栈，采用什么样的方案完全是模型自己根据需求和功能决定的。
前端采用了原生HTML，后端用的Flash 3.0，数据库用本地SQLite，图片处理用Pillow。
我第一次测试的时候上传图片、点击分析后，半天没有反应，查看日志提示模型调用失败，一开始以为是网络问题或M2.1调用方式不对，导致的Gemini模型用不起来，所以第二轮对话我让它把模型换成Qwen的。
（后来发现其实第一轮的代码没问题，真正原因是我使用测试图片太大了。）
这是这一轮修改的效果，按照要求调用了Qwen的模型进行照片分析，给出分析报告以及自动记录到当天的饮食记录中。所有功能模块正常运行。
接下来就是在此基础上不断的优化或增加功能。比如说我接下来让它
增加日历视图，点击任意日期查看该日饮食摄入;
补录饮食记录，比如某天忘记记录了，可以选在对应日期进行补充；
支持通过手动输入食物描述进行食物营养分析;
UI和交互页面的改进; 等等
这是最后的效果（当然还以继续增加功能和优化，比如选择不同的模型，设置API Key，以及用户登录系统等等）
这个测试案例测下来有几点明显的感受：
1.一是速度很快，明显比之前的Minimax M2要快，不仅表现在延迟低，还有看回答和它的思考过程不冗长，我感觉这是一个“代码模型”应该具备的素质，专注干活就行了
2.二是指令遵循能力很好，在理解了意图之后自动分解任务和生成对应的代码
3.M2.1 在保持高智商的同时，降低了 Agent 调用的延迟和成本，这对于大规模自动化的软件工程（SWE-Agent）非常关键
“从夯到拉”生成器
让大模型生成一个从夯到拉的生成器，其实就是Tier list maker。
1 2 3 4 5 6 7 8 9 10 11 12 13
prompt:
实现一个 Tier list 生成器，可以本地运行的web应用。
核心需求：
- 默认等级是中文互联网流行的“从夯到拉”，即“夯”、“顶级”、“人上人”、“NPC”、“拉完了”5个等级
- UI 布局： 左侧是竖向排列的彩色等级标签（红/橙/黄/米/白），右侧是对应的深色宽长条容器（拖放区域）。整体使用暗黑模式风格
- 顶部导航栏：包含新建任务、保存、设置等基础功能；还要有帮助按钮，点击后弹出悬浮页面，内容是本应用的使用方法
- 交互功能：
- 支持点击“设置”按钮弹出下拉菜单（包含：自定义等级，添加图片、重新排列、全部删除等）。
- 如果是自定义等级，则采用T0、T1、T2。。。。的命名方式
- 上传的图片显示在页面右侧（长条容器右侧）
- 核心功能： 实现原生的 Drag & Drop (拖拽) 逻辑，允许将上传的图片拖入右侧的各个层级容器中
- 点击保存，可以将排序结果（完整图片）保存在本地
- 细节： 请确保左侧标签内的文字（如“夯”、“顶级”）可编辑，右侧容器内有“拖放内容到这里”的占位文字。
这个任务其实不算难，但我之前试过几个模型，包括Gemini 3 pro，DeepSeek v3.2，都没有一次做完美的。遇到的问题，包括图片图片无法正确拖动，或者拖动一张后其余图片就自动消失了等等。
试了下M2.1，直出的效果很不错，没发现有什么bug⬇️
这肯定要给MiniMax一个夯了。
同样的prompt我让Gemini 3 pro跑了一下，没有一次成功：
3D场景模拟
创建一个细节丰富、精致的体素艺术3D场景，prompt来自网友：
1
Design and create a very creative, elaborate, and detailed voxel art scene of a pagoda in a beautiful garden with trees, including some cherry blossoms. Make the scene impressive and varied and use colorful voxels. Use whatever libraries to get this done but make sure I can paste it all into a single HTML file and open it in Chrome. Add a browser-native import map that maps the library bare specifier and path to the correct CDN URLs.
以下来自三个模型的对比：
在细节丰富度上，M2.1 的细节明显比 M2 和 Gemini 3 pro 更加丰富，渲染效果好很多；但是画面的平滑度，Gemini 3 pro 效果更好。
多语言编程能力的进化
从官方披露的信息来看，这次模型升级的一大亮点是多语言编程能力的提升。
现在绝大多户模型都有一个问题，当你让它写一个 Python 数据清洗脚本，或者生成一段 React 前端代码，它能表现的像一个工作多年的老程序员；
但一旦场景切换到后端或那种高并发服务（Go/Java），或者底层系统开发（C++/Rust），AI 往往会瞬间降智。
目前金融、通信、工业软件领域存在大量使用 C++/Java 构建的遗留系统，俗称“屎山”，此前的 AI 很难介入这些领域，因为它们太复杂且容错率低。
这个问题很重要的原因是训练数据分布的不均匀。
M2.1在多语言编程能力上做了优化，注意是系统性的增强，这种能力的提升大概率不是通过喂更多代码来实现的，而是一种基于工程思维的逆向优化。
也就是说并不是看到代码 → 学习语法 → 预测下一个 Token；而是定义岗位，定义任务，让模型学习这段代码是前端还是后端，还是底层开发，然后解决什么问题或实现什么功能，最后才是使用什么语言特性。
这使得 M2.1不“偏科”，这对于一个以实用性和工程能力为目标的代码模型来说很关键。
VIBE与AaaV：评估方法的转变
这里多提一句，注意到官方发布M2.1的博文中，开源了一个新的Benchmark——VIBE (Visual & Interactive Benchmark for Execution in Application Development)。
在此之前，对于代码模型，我们一般关注逻辑修正和通过单元测试，类似的benchmark比如SWE-bench等。
但真实的全栈开发，特别是同时涉及到前端、移动端（iOS/Android），不仅仅是逻辑通顺，更关乎交互逻辑和视觉呈现。
Minimax 的思路是引入一个 Agent-as-a-Verifier (AaaV)，对于VIBE上的任务，模型生成交付结果，然后部署到容器/模拟器，由AI Agent 像真实用户一样去点击、交互、“看”界面，从而评估视觉美感和交互逻辑。
这套评估逻辑我觉得还是很适应当前全栈AI coding agent和vibe coding的大趋势的。
以上是 M2.1 对比其他模型在 VIBE 上的表现，看得出来它更有优势，比如VIBE-Web (91.5分) 和 VIBE-Android (89.7分) 这类子项上，处于领先地位，说明模型已经不仅懂代码，还开始懂“产品”了。
这对目前移动端AI辅助开发效率低的问题很有启发了。
小结
总体来说，M2.1 作为 M2 系列的一次升级，可圈可点。鉴于当前大模型趋势是把代码（尤其是agentic coding）当作主力来推，我认为Minimax的做法非常符合目前市场需求，同时从社区的反馈来看，这种做法是成功的。
从我了解的情况来看，国产的开源模型在编程智能体圈子里扮演的角色越来越重，老外那里每次期待值和评价都很高。
对于M2.1来说，带来的启示就是，未来的大模型不能只满足于写一个小游戏，而是开始在复杂项目中发力，以后就是要求 AI 去重构一个遗留的 Java 系统，去优化一个 Go 服务的吞吐量，去从零构建一个交互完美的 iOS App。
最后，如开头提到的，推荐知友结合Claude Code等Agent工具使用M2.1 模型，不仅降低了Claude Code 的使用门槛，还能最大程度释放和发挥M2.1 的编程能力。
