MiniMax M2.1 首发评测:专治祖传屎山,这种爽感谁用谁懂
而前段时间,MiniMax M2 刚在 OpenRouter 上拿下了“全球前五、开源第一”的成绩,GitHub 上的 Cline、Roo Code 等硬核开发社区都在热议这个来自中国的模型。就在大家还在回味 M2 的代码生成能力时,MiniMax 团队没有任何喘息,反手又把 M2.1 端到了我们面前,在正式发布之前,先在社群里面掀起了一波讨论和内测高潮。CSDN也特别申请了内测资格,来个一手的评测体验.
为了验证它到底是不是真有“资深维护工程师”的素养,这次测评我们决定玩点狠的。我们摒弃了那些常规的玩具级测试,专门构建了一个名为 LegacyShop 的电商后台项目。这个系统虽然表面上基于 React 与 TypeScript 的标准技术栈,但内里被我们刻意埋设了严重的性能陷阱、高度耦合的巨型模块以及基础设施配置的缺失。

现状可谓惨烈:本地实测 LCP(最大内容绘制)高达 4.57 秒,这意味着用户打开页面后要盯着白屏发呆近 5 秒;CLS(累积布局偏移)高达 0.50,代表页面元素在渲染时像疯了一样乱跳,想点个按钮结果它自己跑了。更致命的是,由于 useEffect 里存在闭包陷阱,定时器从未被正确清除,浏览器内存占用曲线走出了一条惊悚的“上扬线”。


它通过精确计算可视窗口高度,引入 VirtualList 将页面承载的 DOM 节点从数千个瞬间压缩至几十个,从根本上解决了渲染阻塞;同时在处理隐蔽的内存泄漏时,模型表现得更为老练。它没有止步于简单补齐 clearInterval,而是巧妙地引入 useRef 挂载回调,这种高级技巧不仅完美规避了闭包陷阱,更避免了因依赖项抖动导致的定时器频繁重建。
结果是直观且震撼的:LCP 从 4.57 秒暴跌至 0.16 秒,基本上鼠标刚松开页面就刷出来了,实现了真正的瞬开;CLS 直接归零,整个布局稳得像张静态图片。这种从代码底层运行机制出发的精准治理,证明 M2.1 在微观层面已经超越了简单的“翻译代码”,它懂的不仅仅是语法,而是代码在浏览器里到底是怎么跑的。








如果将业务重构视为功能交付的表层升级,那么工程基础设施建设则是保障系统稳定性的底层防线。在 LegacyShop 项目中,这道防线几乎形同虚设:核心的登录组件缺乏测试覆盖,一旦修改极易引发回归问题;而陈旧的构建工具配置导致热更新(HMR)失效,每一次微小的样式调整都需要忍受漫长的手动刷新,开发体验堪比坐牢。
在测试编写环节,我们将目光锁定于关键的 LoginPage 组件。不同于简单的静态展示页,这个组件包含了表单验证、异步接口请求与路由跳转等复杂交互。M2.1 并未产出那种仅校验 DOM 是否存在的“注水代码”,而是基于 React Testing Library 交付了一套完整的行为驱动测试用例。

值得一提的是,在编写测试的过程中,M2.1 展现出了 TDD(测试驱动开发) 的敏锐度。它发现原有业务代码中的中文报错提示与测试用例不符,于是竟然主动修改了 src/pages/Login/index.tsx 源码,将错误信息标准化为英文 "Password is required",从而确保了代码与测试的一致性。

随后,我们将矛头对准了失效的构建配置。面对被我们恶意破坏的 webpack.config.js,M2.1 展现出了精准的诊断能力。它迅速识别出 hot: false 和 liveReload: false 是导致热更新瘫痪的元凶,并顺手补回了丢失的 cacheDirectory 缓存配置与 CSS Modules 支持。



这绝不是写几个 CSS 动画画个圆那么简单。我要求它必须在浏览器里从零手搓一个微型物理引擎:彻底抛弃预设动画,严格基于牛顿万有引力公式实时计算天体轨迹;不仅要处理三维空间中的向量运算来实现公转与自转的力学闭环,还要搞定复杂的 Raycasting(光线投射) 算法来实现 3D 交互——鼠标拖拽旋转、滚轮无级缩放、点击行星精准反馈。这哪里是考代码,分明是在考它能不能把高等数学和天体力学完美翻译成 JavaScript。

物理逻辑更是严谨。通过阅读源码我们发现,行星的公转速度与相对距离经过了数学换算,不再是简单的平移运动。交互层面,Raycaster 射线检测准确无误,点击行星后的弹窗信息响应极快。这种将天体物理公式瞬间转化为三维视觉交互的能力,代表 M2.1 不仅仅精通代码语法,更展现出了物理、数学与设计美学的融合能力。

这次评测给我们的最大感受,不是“被替代”的恐惧,而是一种久违的职业解脱感。我们亲历了 AI 从单一的代码片段生成工具,进化为通晓架构拆解、测试驱动与工程构建的全栈协作伙伴。
夸了这么多,说说不足吧。我们在用M2.1生成测试项目的时候,因为要做一些劣质代码,所以不是按套路地提要求。对于这种复杂要求,M2.1 在规划任务时还是有点问题。当我要求 M2.1生成“请你生成一套可以运行,但充满坏味道的代码” 之后,并没有触发任务规划,而是依次生成项目文件,并且生成的代码会报错,无法运行,但是在后续我们先创建基础项目,再做破坏性建设的思路下就没有出现这个问题。因此需要加强一下任务规划能力。
说实话,M2.1 在实战中展现出的多维素养表明,它完全有能力接管高风险的存量治理工作。既然 AI 能搞定基础设施维护与技术债治理这种消耗热情的“脏活累活”,那我们人类开发者就该腾出手来,回归架构设计与业务创新的高地。
从 LegacyShop 的起死回生到太阳系的无中生有,M2.1 的表现恰恰印证了 MiniMax 在 Multi-SWE 赛道上的技术远见。作为一款专为 Coding、复杂 Agent 工作流及长链条推理任务设计的模型 ,它的核心竞争力正在从单一的代码生成向深度的工程理解跃迁。它跳出了单纯比拼生成速度的怪圈,转而攻克复杂上下文理解与存量债务治理这两个最难啃的硬骨头 。这种进化让 M2.1 不再局限于做一个只会补全语法的插件,而是真正成为了能独立思考架构并解决系统级问题的工程智能体。这才是我们真正需要的未来分工,让机器去消化那些确定性的工程繁琐,让人类彻底回归不确定性的价值创造。
年底了,与其盯着那些枯燥的跑分榜单看,不如直接前往 MiniMax 开放平台上手跑一跑。把你手头最棘手、最复杂的真实业务场景丢进去,看看这位 AI 工程师到底能不能抗住压力——它大概率会给你一点小小的震撼。
扫一扫,关注我们