今天早上，MiniMax 正式发布了全新的 MiniMax M3 大模型。

先看看官方给的关键词：前沿 Coding 能力、Agentic 能力、100 万 tokens 超长上下文、原生多模态。这几个词单独拎出来，哪个都不算新鲜——对吧？现在市面上，会写代码的模型不少，能稳定处理大型工程的却不多；支持长上下文的也很多，但一到真实项目就开始“看不全、找不准”；多模态模型就更不用说了，很多只能看图回答，很难真正把图像理解变成可运行的前端代码；至于 Agentic 能力，很多号称行的模型一放进 Claude Code 这种工程环境，就暴露了规划能力弱、工具调用乱、长任务稳定性差的问题。

所以这次，我没只看官方发布稿，而是直接把 MiniMax M3 接进了 Claude Code，做了一轮贴近真实开发场景的测试。结果相当有意思——它不是一个只会刷榜的模型，在真实工程任务里的表现，确实有点东西。

一、MiniMax M3 到底强在哪里？

MiniMax M3 最核心的卖点，不是单点能力的突出，而是三种能力第一次被组合在了一起。

第一，Coding 和 Agentic 能力。它不只是补全代码，而是要面向真实工程任务：理解项目、定位问题、拆解方案、修改文件、解释改动、完成验证。第二，100 万 tokens 超长上下文。这意味着它可以把大型代码库、长文档、复杂日志、小说文本、项目说明等内容全部放进来处理。第三，原生多模态能力。它不仅能读文字，还能理解截图、图像甚至视频，并把视觉理解转化成前端页面、UI 复刻、交互设计等实际产物。

这三个能力组合起来，MiniMax M3 的定位就很清楚了：它不是一个单纯的聊天模型，也不是代码补全模型，而是更接近一个可以长期协作的 AI 工程助手。

二、为什么 100 万上下文很关键？

很多人看到“100 万 tokens”，第一反应可能是：这不就是个营销数字吗？但在真实工程场景里，长上下文不是锦上添花，而是决定模型能不能真正理解复杂任务的基础能力。

比如你让模型分析一个大型代码库，普通模型往往只能看到局部文件。它能回答某个函数是什么意思，但很难理解整个项目的架构关系。如果让它分析几十万行代码，情况就更明显了：它必须知道配置在哪里，调用链从哪里开始，哪些文件是核心逻辑，哪些只是辅助，还得判断某个 bug 的根因来自局部实现还是系统设计。

这时候，长上下文的价值就出来了——它让模型不再只是“猜代码”，而是有机会真正“读项目”。

MiniMax M3 采用的是 MiniMax Sparse Attention，也就是 MSA 架构。简单来说，它的目标就是降低长上下文带来的计算压力，让模型在百万级上下文中依然保持较好的效率和可用性。官方提到，在 100 万上下文长度下，M3 每个 token 的计算量只有上一代模型的 1/20，并且在预填充和解码阶段都有明显加速。这也是为什么 MiniMax M3 能把长上下文、Coding 和 Agent 能力放到一起，而不是只把长上下文当成一个参数展示。

三、实测一：接入 Claude Code，直接跑工程级任务

这次测试，先把 Claude Code 的 base URL 和模型 ID 改成 MiniMax M3。也就是说，不是在网页聊天框里让它“帮我写一个函数”，而是让它真正进入 Claude Code 的工程环境，像一个 coding agent 一样工作。

第一个测试项目是 OpenClaw。这是一个比较庞大的开源项目，代码量大，结构复杂，issues 里也存在不少真实 bug。用它来测试，比让模型写个 demo 更有参考价值。

我先让 MiniMax M3 对项目执行 init，生成 CLAUDE.md，对项目做初步理解。接着，从 OpenClaw 的 issue 中选择一个代表性 bug，让它先定位 bug 原因，而不是直接修复。这里它的表现比较关键——它没有一上来就乱改代码，而是先分析根因，解释问题出在哪里，并拆解触发 bug 的路径。

随后我继续要求它修复这个 bug，并提出几个约束：改动尽量小；保持原有代码风格；不要引入不必要的重构；只做精准修复。MiniMax M3 的表现很像一个经验比较成熟的工程师。它没有立刻动手，而是先给出 3 个修复方向，并说明每个方向会影响哪些文件、改动面多大、是否需要引入新的配置开关。

这点非常重要。真实工程开发中，最怕的不是模型不会写代码，而是模型“太积极”：明明只需要修一个小 bug，它却顺手重构半个项目。MiniMax M3 在这里表现出了一种很好的工程克制感：先分析，再给方案，再让用户选择，最后执行。选择其中一个方案后，它开始修改代码，几分钟后完成修复，并给出了修改文件、行为变化和修复说明。这个测试说明：MiniMax M3 在 Claude Code 中不只是能生成代码，它具备一定的工程判断能力。

四、实测二：分析 50 多万行 Claude Code 源码

第二个测试，进一步加大难度。让 MiniMax M3 分析 Claude Code 泄露出来的 50 多万行源码，目标是找出 Claude Code 如何进行用户遥测。

这个任务很适合测试长上下文能力和代码理解能力。它不是让模型看一个文件，而是要求模型在大量代码中定位关键逻辑：遥测出口端点在哪里；相关文件路径是什么；具体代码行数在哪里；有哪些控制开关；设备 ID 或身份指纹如何生成；哪些功能可以开启或关闭。

MiniMax M3 很快完成了分析。它从源码中找出了多个出口端点，给出了具体文件位置和代码行数，还整理出了控制遥测功能的开关，并分析了设备 ID、身份指纹等相关逻辑。这个结果印象比较深，因为这类任务最考验模型的不是“会不会解释代码”，而是能不能在巨大代码库中快速定位真正重要的部分。如果模型上下文不够长，它很容易只看到局部；如果检索能力不够好，它会漏掉关键文件；如果工程理解不够强，它会把无关代码也当成核心逻辑。

MiniMax M3 在这个测试中表现出来的能力是：它能把长上下文、代码搜索、结构化总结结合起来，完成一个比较接近真实代码审计的任务。这说明它的 100 万 tokens 上下文不是摆设。在大型代码库分析、隐私逻辑审计、安全审查、项目迁移、技术债梳理等场景里，这类能力会非常有价值。

五、实测三：读完整部《西游记》，生成交互式取经路线图

接下来，换了一个完全不同的测试。这次不是代码库，而是长文本理解。

把完整《西游记》文本交给 MiniMax M3，让它先通读全文，然后用前端技术生成一张可交互的唐僧取经路线图。要求包括：整理取经途中的主要国家和地点；列出每个地点遇到的妖怪；总结关键剧情事件；按顺序生成路线节点；点击节点后弹出妖怪、事件、危险等级等细节；视觉风格要有古典卷轴感。

这个任务看起来像前端开发，但本质上是一个综合任务：需要长文本阅读；需要文学内容理解；需要信息抽取；需要结构化整理；需要前端可视化；还需要 UI 审美。MiniMax M3 的处理方式比较聪明。它没有硬读全部内容然后直接生成，而是先用搜索方式定位关键章节，再派生多个 subagents 执行任务。

最终生成的页面是一个古典卷轴风格的取经路线图。打开之后，可以看到多个路线节点。点击“长安”，会弹出对应的介绍和关键事件；点击“鹰愁涧”，能看到第 15 回、危险等级、关键事件、主要妖怪和取经收获；点击“狮驼国”，也能看到主要妖怪、剧情概要和危险等级。尤其是“狮驼国”的危险等级划分，可以说非常准确。

这个测试说明 MiniMax M3 不只是能“装下”长文本，更重要的是它能从长文本中抽取结构化信息，并进一步转化成可交互产品。这类能力非常适合用在知识库、课程内容、小说可视化、长文档分析、历史事件地图、企业内部手册可视化等场景。

六、实测四：看 Apple Music 截图，复刻前端 UI

然后测试了多模态能力。给它三张 Apple Music 的截图，要求用 HTML、CSS 和 JS 高保真复刻一个类似 Apple Music 风格的音乐播放器界面。

这个任务的难点在于：模型要先理解截图里的布局；再理解颜色、层级、卡片、封面、导航、按钮；然后把视觉理解转化成前端代码；最后还要生成一个可交互 UI。几分钟后，MiniMax M3 完成了页面。打开效果后，可以看到它复刻出来的界面确实很接近 Apple Music 风格。有侧边栏，有主页，有音乐卡片，有封面图，有播放器区域，也有对应的交互元素。整体还原度主观判断能达到 90% 左右。

这说明 MiniMax M3 的多模态能力不是停留在“看图描述”层面，而是可以把截图理解变成可运行的前端页面。这对开发者很实用——以后如果看到一个网页、App 或仪表盘设计，只要给模型截图，就可以让它快速生成一个高保真前端原型。对独立开发者、产品经理、前端工程师、内容创作者来说，这种能力会大幅降低从灵感到 demo 的成本。

七、实测五：Three.js 生成 3D 游戏

最后，测试了 MiniMax M3 的创意代码生成能力。

第一个游戏是 3D 侏罗纪风格的皮卡车狩猎恐龙游戏。要求使用 Three.js，在浏览器中运行。玩家可以驾驶皮卡车，车上有机枪，可以控制方向并射击远处走来的恐龙。MiniMax M3 生成后，页面中有开始按钮，进入游戏后可以看到皮卡车、机枪、恐龙、射击效果和音效，恐龙被击中后会消失。

第二个游戏是墓xue探险游戏。要求是第一人称视角，玩家在古墓里探险，头灯只能照亮前方一小片区域，其余部分处于黑暗中。玩家可以前进、后退、转向、射击，还会遇到怪物和药箱。生成出来的效果也比较完整：有第一人称视角；有灯光范围；有古墓走廊和拐角；有手枪和射击效果；子弹打到墙上会冒火光；怪物可以被击中倒下；玩家可以拾取药箱；失败后可以重新开始。

这类游戏 demo 当然不能和专业游戏相比，但作为一次模型生成测试，它已经说明 MiniMax M3 具备比较强的前端创意实现能力。它不是只会写静态页面，而是能生成具备交互、状态、视觉效果和游戏机制的浏览器应用。

八、对 MiniMax M3 的真实判断

经过这轮测试，对 MiniMax M3 的判断是：它最强的地方，不是某一个 benchmark 分数，而是“长上下文 + Coding + Agentic + 多模态”组合后的真实可用性。

很多模型看起来单项能力很强，但一到真实工作流就会掉链子。MiniMax M3 在这几个测试里表现出的特点是：

第一，它适合大型代码库分析。无论是 OpenClaw bug 修复，还是 50 多万行 Claude Code 源码分析，它都能比较快地定位关键问题。第二，它适合长文本理解和结构化生成。完整《西游记》路线图测试，说明它不仅能读长文本，还能把长文本转化成可交互产品。第三，它的视觉理解和前端生成能力比较强。Apple Music UI 复刻说明它可以根据截图生成接近真实产品风格的前端界面。第四，它具备不错的复杂交互生成能力。Three.js 游戏测试说明它可以完成带状态、交互、视觉效果和玩法机制的浏览器应用。第五，它的 API 成本优势明显。如果价格长期保持在相对较低水平，那么 MiniMax M3 很可能成为很多开发者在 Claude、GPT、Gemini 之外的重要替代选择。

九、它能不能替代 Claude？

这是大家最关心的问题。从测试结果来看，在很多任务上，MiniMax M3 已经具备替代 Claude 系列模型的潜力，但还很难简单地说它能全面替代 Claude。

如果你的任务是：大型代码库阅读、长文档分析、前端 UI 生成、多模态截图转代码、Claude Code 中的工程辅助、成本敏感型 Agent 工作流、长上下文内容处理——那么 MiniMax M3 很值得尝试。尤其是在需要大量 tokens 的场景里，它的性价比会非常突出。

但如果你的任务极度依赖长期稳定性、复杂推理一致性、极高可靠性的代码审查，或者你已经有一套成熟的 Claude 工作流，那么更建议把 MiniMax M3 作为“第二主力模型”来测试，而不是立刻完全替换。更合理的做法是：Claude 继续负责最高风险、最高价值的任务；MiniMax M3 负责大量长上下文、代码阅读、UI 生成、原型开发和成本敏感任务。这样可以在不牺牲质量的前提下，大幅降低成本，并提升任务吞吐量。

十、结论：MiniMax M3 真正打动人的，不是参数，而是“工程感”

这次 MiniMax M3 最让人惊讶的地方，不是它有 100 万 tokens，也不是官方 benchmark 分数多高。真正让人觉得值得关注的是：它在真实工程任务中表现出了一种“工程感”。

它会先理解项目；会先定位 bug；会给出多个修复方案；会考虑改动面；会尽量避免不必要重构；会在大型代码库中找关键文件；会把长文本变成结构化产品；会把截图变成可运行 UI；会把创意需求变成浏览器游戏。这不是传统意义上的“聊天机器人”了。它更像是一个可以进入真实开发环境、处理复杂上下文、执行多步任务的 AI 工程助手。

所以，MiniMax M3 的意义可能不只是“又一个国产大模型发布了”。它真正代表的是：国产模型正在从单纯拼参数、拼榜单，进入到拼真实工作流、真实工程能力、真实 Agent 可用性的阶段。如果你正在使用 Claude Code、Cursor、OpenClaw 或其他 AI Coding 工具，那么 MiniMax M3 绝对值得接入测试。因为它可能会成为接下来一段时间里，最值得关注的高性价比 Coding Agent 模型之一。