用完刚开源的MiniMax，我们决定给它发个工牌

如果说 Vibe Coding 最早震撼的是新手开发者，那么在今年，职业程序员已经集体迎来了它带来的工作流革命。

身边一位资深工程师提到，在今年下半年之前，他的 AI Coding 体验依然非常僵硬，极度依赖指令工程。为了让模型写出一段合格的代码，他往往需要事无巨细地堆砌 40 多行指令，包括指定技术栈、实现逻辑的具体步骤以及详尽的约束条件。

从 Copilot 模式过渡到 Agent 模式，这看起来是无法回避的问题。

但现在，他表示，AI Coding 顺畅多了，Prompt 的“存在感”正变得越来越低 —— 一方面，模型能力在提升；另一方面，模型及工具的工程能力也在提升。

这也让开发者开始以工程尺度来衡量 AI Coding 的价值：重要的不是单项能力的峰值参数（比如代码生成速度），而是模型在长上下文、多语言、多轮任务中的整体稳定性，以及是不是足够实惠。

因此，当 MiniMax 更新并继续开源 M 系列模型时，很多开发者迫不及待上手实测。

M2.1 着重提升模型在真实世界复杂任务的表现。从指标上看，M2.1 在多语言软件工程测试 SWE-Multilingual 得分达到 72.5%，超越了 Sonnet 4.5；在 VIBE-bench 中以 88.6% 的成绩，超越 Gemini 3 Pro。在定价策略上，MiniMax 将 Coding Plan 订阅服务价格压缩至 Claude 对应方案的 1/10。

在国际开发者社区，M2.1 的表现也得到了专业人士关注。

前 Twich 和 Amazon 工程师，T3 Chat 创始人 Theo Browne 前几天也直播对比测试了 M2.1 在内的开源模型。在直播中，他表示 MiniMax 在处理长任务、生成计划方面表现出色，且价格“便宜得离谱”，在性能可以媲美 Opus 4.1 的基础上价格仅为其 1/60。

前 Meta AI 工程师，DAIR.AI 创始人 Elvis S. 表示，他利用 M2.1 构建深度研究 Agent 后发现，M2.1 生成的报告质量高，且相比前代显著降低了 Token 损耗。

那么，M2.1 真的能打吗？

我们将 M2.1 投入到了存量业务的周期迭代、从 0 到 1 的新产品构建，以及跨语言的二次开发这三类真实“深水区”场景中。希望看到抛开一切滤镜后，M2.1 的实际表现。

在评估 M2.1 的实战表现前，我们首先需要明确：什么才是真正的 Agent 能力？

我们认为，模型的 Agent 能力最终取决于它能否在真实团队与真实项目中持续交付。为此，我们刻意选择了三个能够覆盖工程研发全生命周期的典型场景，包括周期性的后端业务（年度报告功能）迭代、原生 App 的 0-1 交付、以及跨语言开源项目的二次开发。

它们恰好覆盖了工程团队的日常主流工作：年度报告是典型的周期性重复需求，最能检验 AI 对存量业务的提效价值；iOS 开发代表了新业务启动从空白到可运行的典型路径；而 Rust+TS 项目则是开发者在遗留代码与既定约束中进行功能演进的缩影。

这些任务强制模型进入从理解到交付的完整闭环。模型必须在真实约束下，完成从读懂原始需求、拆解复杂任务、产出技术方案到多轮调试修错、最终交付上线的全过程。这不仅是对长上下文和跨文件理解力的考验，更是对 Agent 在多轮协作中保持逻辑一致性的实战演习。

通过这些测试，我们希望回答两个关键问题：M2.1 多大程度上仍是一个编程工具？又有多大程度已具备 Agent 所需的可靠执行能力？

我们对 M2.1 的首个测试，是直接把它扔进真实的工作项目。

每年年末，极客时间 APP 都会上线“年度学习报告”，为每位用户提供个性化的年度回忆，就像每年网易云音乐会收到今年的听歌总结一样。

这是一个周期性重复、代码结构稳定，但是对安全和严谨性要求很高的场景。其中，api 层的代码逻辑高度一致，但是程序员需要在不触动旧系统，不破坏接口与数据结构的约束下，做好年度迁移。

我们将编写年度报告 API 接口功能代码的任务，一个有真实上线需求的 Golang 后端项目交给 M2.1。

M2.1 需要在理解既有业务逻辑的基础上、梳理完整调用链路，并在不破坏接口与数据结构的前提下编写代码。

在与 M2.1 进行两轮交流后，它写出了不用修改就能直接上线使用的代码！

第一轮交流，我们要求 M2.1 首先理解 2024 年的项目的代码逻辑：

阅读当前项目，学习并理解 2024 年度学习报告的 API 业务逻辑。

我们故意给出高度模糊的指令，考验模型理解用户指令和中间过程的能力。

从 M2.1 展现了完整的思维链可以看到，其阅读代码的方式贴近资深程序员：

先使用关键词搜索，快速缩小范围，从数百个文件中筛选出最相关的 31 个文件。

随后按照 Golang 的分层架构，从 API 入口文档（.md）开始，按顺序阅读控制器（report.go）、业务服务（service.go）、数据结构（model.go）和数据访问层（dao.go），逐步还原完整的调用链路。

最后，进行精准搜索，查找具体的变量名或数据表名，以此确认 2024 年业务逻辑中的特定细节，确保理解准确无误。

注：年度报告 API 接口功能开发过程中，我们与 M2.1 的第一轮对话

在第一轮完成了对项目代码逻辑的理解后，我们要求它基于 2024 年的架构，开发 2025 年的新接口：

基于 2024 年的年度报告，写一个 2025 年的年度报告 API，请求和响应不变，API 路径和对应的数据改成 2025。

按照要求，M2.1 识别了我们请求修改代码的需求，并自主分析了项目结构，确定了需要修改的文件和具体内容，提出了具体的代码修改方案（添加 2025 年的路由配置），并询问用户是否执行这些编辑。

我们 review 后发现，M2.1 一次性生成了可以直接上线使用的代码，代码量接近一百行。

注：年度报告 API 接口功能开发过程中，我们与 M2.1 的第二轮对话

值得注意的是，M2.1 过于忠实地执行了“基于 2024 年”的指令，以至于在涉及代码复用的地方，它选择了写两遍，而非主动进行重构。

在“是否允许重构”上默认选择更加保守的策略对生产其实是好事，但要让它更像团队里的资深工程师，就需要程序员在需求里明确哪些可抽象、哪些必须保持原样，并把重构边界写清楚。

在第一个测试场景中，我们验证了 M2.1 在既有业务环境中补位执行的能力。

但一个真正实用的 Agent，还必须具备从无到有启动业务的能力。

对此我们选择了 iOS 原生 App 研发场景。这类任务路径更长，考验模型的长上下文能力；涉及到 UI 和交互方式的约束，考验模型对设计和审美的理解；同时工程环境也相较复杂，要求模型具有文件组织能力。

我们用聊天一样的的自然语言描述任务，要求 M2.1 开发一款帮助年轻上班族决定今天吃什么的抽卡应用：

我想要开发一个 app，核心需求是，实现中午吃啥的选择，主要是解决用户不知道中午吃啥的问题，风格活泼可爱，画风简单，可以录入大量的附近的可选午餐数据，然后首页的卡片随机选择，卡片切换动画流畅丝滑，view 之间过度衔接完美，目前的代码可以忽略甚至重构掉，按照你的想法，结合需求，先设计合适的功能，然后再实现这个 app 的开发，目标是年轻群体的上班族

注：上方是用户输入的指令，下方是 M2.1 接到指令后，向用户细化询问的问题。

接到指令后，M2.1 展现出了极强的 Agent 自觉。它没有直接输出代码，而是反向询问了数据录入、卡片交互细节、历史记录等关键点。这种“多想一步”的深度交互，有效减少了软件开发初期因信息不对称带来的返工风险。

在确认需求后，模型自主将开发拆解为四个阶段：基础框架搭建、核心功能实现、历史统计、优化完善。

在随后不到 30 分钟内，它便生成了完整的项目结构、核心代码及本地运行指令，完成了 APP 从 0 到 1 的搭建。

在第一轮对话后，M2.1 就已经搭建出了适配 Liquid Glass 的视觉风格的 UI 界面。

随后我们继续使用自然语言，让模型对 UI 进行微调。

但在 UI 微调中，我们也发现了模型的边界：当我们说“往上移一点”或“统一视觉整体”时，模型倾向于执行量化的代码操作，而非理解背后的美学意图。

因此，如果有更严格的上架需求，模型仍需要人类完成工程化交付的最后一公里。

在开发 APP 的过程中，M2.1 经历了 70 多轮循环对话中，上下文拉升至 160K 以上，生成近 30 个代码文件，且能根据运行结果自行反馈修正。

整场高压测试下来，M2.1 仅出现了一次工具调用报错。这种极低的错误率，证明了 MiniMax 针对长上下文和多轮 Agent 调用做了深度工程优化。

这次测试还带给我们一个关于 Agent 落地的重要思考：模型需要搭配合适的脚手架。

在开发初期，我们尝试使用 Claude Code 作为调用工具，但发现 M2.1 的长上下文优势难以完全发挥。而切换至 Kilo Code 后，稳定性与连贯性显著提升。

这说明，当工具在上下文管理与循环执行方面更强时，M2.1 的能力上限会显著释放。

iOS APP 的开发检验了 M2.1 从 0 到 1 的交付能力。但在真实工作中，在遗留代码与既定约束中进行功能迭代才是常态。

因此在最后一项测试中，我们让 M2.1 挑战跨语言、跨框架的复杂开源项目重构，选择基于开源项目 Chorus（一款 macOS AI Chat 客户端）进行测试。

我们的任务是，在完全不提供修改路径指引的前提下，要求模型自主在 Chorus 中新增对 MiniMax API Provider 的原生支持。

Chorus 采用了典型的 Tauri 2 架构：底层由 Rust 负责系统调用与 API 通讯，前端则由 TypeScript 驱动界面。

增加一个新的 Provider 不仅意味着要编写 UI 层的配置项，更要深入其底层抽象层，处理 Rust 的类型定义、异步请求以及跨进程通信。

这种测试能直接暴露模型的多语言能力与长程任务中的指令遵循稳定性。

我们采取了“任务导向”的交互方式，将 M2.1 推入这个陌生的工程环境。

首轮交流中，我们投喂了项目源码并要求增加 MiniMax Provider：

阅读当前项目, 增加 MiniMax provider 的支持, 注意查一下如何对接 MiniMax 的 API, 然后接入以下模型：

模型名称 输入输出总 token 模型介绍

MiniMax-M2.1 204800 强大多语言编程能力，全面升级编程体验

MiniMax-M2-lightning 204800 更快，更敏捷

MiniMax-M2 204800 专为高效编码与 Agent 工作流而生

在编译运行 M2.1 输出的首轮代码时，UI 层的模型列表并未如预期更新。我们发现对话框可以选择的模型列表里并没有出现 MiniMax 模型。在我们指出这一点后，M2.1 进行了自动诊断和修复。

第三轮交流中，我们指出模型列表出现了 MiniMax，但是无法点击选择。

在这一步，有意思的事情发生了。模型向用户询问 MiniMax 的 icon 旁是否是 to add 字符以及字符的状态，并通过询问交互界面 icon 的状态反馈来倒推逻辑错误的位置。

这意味着，M2.1 和 Gemini 3 一样，都能够理解设计思维——不仅知道按钮应该是什么样子，还理解它们存在的意义。这种将视觉逻辑与底层通讯逻辑实时映射的能力，让它在处理复杂的前端交互时具有极高的确定性。

注：模型向用户询问 icon 状态，由此倒推逻辑错误的位置。

编程过程中，我们对于多语言的“无感”也很有意思。我们所做二次开发的这个开源项目，是基于 Rust + TypeScript 写出来的。但在与模型的交流中，我们仅仅提出了功能目标，而没有下达“修改某个 Rust 文件”这样的具体指令。这意味着，对于 M2.1 来说，编程语言的界限正在消失，它处理的是工程本身。

从后端业务、原生 App 交付，到跨语言工程扩展，MiniMax M2.1 展现出对真实世界复杂工程任务的适应。它不只是一个“会写代码的模型”，而是一个具备长期工作、稳定协作、真实交付属性的 Agent 雏形。

如果说 coding 能力是 M2.1 的基石，那么当它进入更广阔的通用办公场景时，它能否真正像一名“数字员工”一样处理日常琐事？

接下来，我们将进入自动化办公的模拟战场。

在与 MiniMax M2.1 长达十个小时的密集协作中，我们看到，其在多语言支持、长程任务处理能力、指令遵循、中间过程等方面的良好表现，正将 M2.1 的能力边界从单纯的提效工具推向真正的“数字员工”。

实际协作中，我们使用极其日常的语言，有时指令甚至非常模糊。普通代码工具通常会基于概率盲目生成代码片段，导致无效迭代。而 M2.1 表现出一种极其难得的“工程自觉”。当面临不完整信息时，它的第一反应不是盲目行动，而是通过追问来澄清目标、梳理方案。

这种“先问后做”的优先级，正是人类员工接手陌生任务时的本能反应。一位资深开发者在社群中分享，M2.1 的引导提示做得非常好，在他体验过的各种 AI IDE 里表现突出。

长程任务的稳定性是衡量数字员工能力的硬性标准。在一次超过 30 轮的 APP 开发对话中，我们因临时事务中断了对话。数小时后，当我们回到对话并继续输入指令，M2.1 并未要求重复上下文，而是直接承接此前进度，准确指出下一步待修改的文件与具体行数。这意味着 M2.1 具备极高的检索精度，并能够维持长程的推理链条。这种在长时、中断的协作中仍能保持任务状态的能力，是它能够成为数字同事的基础。

此外，在智能体能力评估体系 TheAgentCompany 中，M2.1 也展现出较完整的自动化办公能力。TheAgentCompany 是目前较为成熟的评估 Agent 能力 benchmark 之一，它构建了一个高度还原真实职场的软件公司模拟环境，要求模型以数字员工的身份完成闭环任务（已精简）

可以看到，在通讯软件的测试环境下，M2.1 能主动收集员工的设备申请需求，随后前往企业内部服务器检索相关文档，获取设备价格，计算总成本并判断部门预算是否充足，最终完成设备变更记录。

在项目管理软件中，M2.1 能主动查找被阻塞或积压的问题，并通过通讯工具联系相关员工咨询解决方案，再根据反馈更新任务状态。

在研发协作场景下，M2.1 还能直接在代码库中检索信息。例如，当同事询问“最近修改某个文件的合并请求是哪一个”时，它可以定位对应的合并请求，找到编号并反馈结果。

综合这些表现可以看到，MiniMax M2.1 已经具备构建全链路办公自动化工具的基础能力。

MiniMax 在 M2.1 中特别强调数字员工能力，本质上是在为下一阶段铺路：

当模型已经能够稳定承担工程任务，下一步自然是让它嵌入企业流程、承担明确职责，成为可复用的生产角色，而不再只是开发者手中的工具。

编程工具的天花板正在收敛，而“数字员工”的门槛才刚刚变得清晰。

从 M2 强调跨文件、跨模块的深度编程支持，到 M2.1 将多语言代码能力和真实办公场景作为核心升级方向，MiniMax 始终围绕一个问题推进：即致力于提升模型在真实世界复杂任务中的表现，让 AI 真正渗透进更多岗位工种与生产场景中创造价值。

通过实测我们看到，M2.1 正在跨越“辅助工具”的边界，进化为具备可靠执行力的 Agent 雏形。

与之形成对比的是，目前市场上的 AI 编程产品，差距更多体现在效率与使用体验，而非角色定位本身，许多厂商仍然将 AI Coding 视为一种“更聪明的工具”。

这种理解在 MiniMax 冲刺港股上市的节点显得尤为关键。MiniMax 没有选择在此时抛出华丽的叙事包装，而是继续把资源投入到模型能力本身的推进上，用 M2.1 的硬核能力向市场证明：Coding 的商业天花板，不是程序员工具，而是自动化的数字员工。

一旦将 AI Coding 的目标上调——要求其像工程师一样，在真实组织中持续工作、理解约束并对结果负责，现有模型和工具的差距就会迅速显现，随之而来的是 AI Coding 公司的洗盘。

而低调的 MiniMax，正在这条更长周期的竞争中，提前占据位置。

目前，M2.1 已 正式开源，且 1 月 15 日前购买，首月只需 9.9 元。

MiniMax M2.1 的真实能力如何？欢迎在评论区留下你的想法。