MiniMax M3 实测，已经对执行层动手了华尔街日报

MiniMax M3旗舰模型聚焦Coding与Agent能力，具备百万级长上下文和原生多模态，支持自主执行复杂长任务（如论文复现、CUDA优化）。实测中，其代码交付高效，能高精度复刻网页并推断交互逻辑。

一款开源模型，能否同时拥有顶级编程能力、超长上下文理解能力和原生多模态能力？

这几乎就是 Agent 的全部意涵。而我们提出这个问题，是因为从 OpenClaw 时代开始，一家公司就已经无法仅仅凭借在模型上的投入，证明自己是一家押注未来的公司。胜负全在 Agent。

MiniMax M3 似乎也意识到了这一点。

作为 MiniMax 的最新款旗舰模型，M3 重点强化了 Coding 与 Agent 能力。相比传统代码模型的“把代码写出来”，它更强调长期规划、多轮协作和自主执行复杂任务的能力。

通俗地说，这些能力共同指向一个目标，那就是让模型独立学习几十万字的资料、持续工作数小时、调用工具、编写代码，并最终交付一个真正可用的结果。这成为了同步推出的 MiniMax Code 产品的核心技术基础。

那么衍生出来的问题是，当 Claude Code 已经成为开发者最认可的 Agent 工具之一，M3 的能力，又是否足以支撑 MiniMax 建立一个自己的，真正有竞争力的 Agent 生态？

12 小时自主工作，你说的长任务有多长？

Coding 能力的进化，已经不仅仅是写代码了。

如果只把 MiniMax M3 当成一个更擅长写代码的模型，会严重低估此次发布的重点。M3 更值得拿出来讨论的，是它在长任务、长上下文和 Agentic 工作流上的能力。

官方给出的两个案例很能说明这一点。一个是 M3 用接近 12 小时自主复现 ICLR 论文，另一个是用约 24 小时、147 轮迭代完成 CUDA Kernel 优化。这两个例子本质上都是典型的长链路任务，模型需要理解目标、拆解步骤、不断检查中间结果，并在失败之后继续调整。

从模型架构上看，MiniMax M3 的 1M token 上下文和 MSA 稀疏注意力架构，就是为这类场景服务的。长上下文的意义不只是能塞进更多文本，更重要的是降低长任务中的信息断裂。比如一个真实代码仓库、一个复杂需求文档、一组历史修改记录，这些真实需求都不是几千 token 就能讲清楚的。如果模型每次只能看到局部，就很容易出现“前面答得对，后面改崩了”的情况。而更长的上下文窗口，则给了模型跨文件、跨阶段理解任务的可能。

不过必须澄清的是，官方宣传的 1M 上下文，并不等于当前所有开发者都能无门槛、稳定地使用完整的 1M 上下文能力。模型页虽然写明“支持最高 1M，保证至少 512K”，但按量计费页进一步说明，超过 512K 的输入能力在发布初期属于限时、限量供应，需要联系销售开通。

长上下文能力确实是这次 M3 发布的核心亮点，但在真实任务中，它更适合被理解成一种“能力上限”，而不是一个已经对所有用户完全开放的默认规格。

创业模拟器，M3 与 Sonnet 4.6 的直接竞技

为了测试 M3 的代码交付能力，我设计了一个相对完整的小项目，让模型从零实现一个“创业模拟器”小游戏。同样接受这项考验的，还有 Claude Sonnet 4.6。

请从零开发一个 AI 创业模拟器 Web App。

1. 用户可以创建一家初创公司，输入公司名、行业、初始资金、目标用户。

2. 游戏采用回合制，每一轮代表一个月。

3. 用户每轮可以选择 3 个经营决策，例如产品开发、市场推广、招聘、融资、降本、用户调研。

4. AI 根据当前公司状态和用户决策生成月度报告。

5. 页面需要展示资金、用户数、收入、团队士气、产品完成度、市场热度、竞争压力。

6. 每轮结束后更新这些指标。

7. 需要有成功和失败结局。

8. 使用 React + Tailwind 实现，界面要像一个现代化创业经营游戏。

9. AI 接口可以先用 mock 数据，但代码结构要方便之后接入真实 LLM API10。

10. 请保证项目可以运行，并提供启动方式。

提示词并不复杂，但这项任务其实很适合测试 Coding Agent 的综合能力。因为它同时考验需求理解、状态管理、UI 设计、数值系统和平衡性。用户在游戏中扮演创业者，每一轮需要决定做什么产品、招什么人、怎么定价、要不要融资、如何营销，AI 则根据这些决策反馈用户增长、现金流、团队士气、市场反应和竞争压力。

具体来说，真正的难点主要包括三个维度：

▪︎状态管理：小游戏一旦进入多轮决策，就很容易出现页面刷新后数据丢失、上一轮数据覆盖下一轮、历史记录无法回看、进度条超过 100% 之类的问题。甚至游戏只是这些问题的高发场景，类似的需求，在很多软件开发任务中都可以看到。

▪︎UI 表现：很多模型生成的“游戏”其实只是一个表单加几个按钮，功能能跑，但一眼看过去就有股“塑料感”。

▪︎数值平衡：这是最难的一环，数值设计不当很容易出现一两轮游戏之后现金流爆炸、用户数异常增长、游戏迅速失控的问题，最终影响可玩性。什么样的数值设计可以说是平衡？这需要模型在复杂任务拆解之外，更有一层对游戏的审美和品味。

M3 用大约 11 分钟完成了程序编写和代码检查。最终生成的小游戏可以正常运行，界面简洁，并且带有一定动画效果。更重要的是，它基本处理好了前面提到的几个核心难点，公司数据展示清晰，历史记录可以回看，游戏进度和经营指标也没有明显混乱。

作为对比的是，Sonnet 4.6 完成同一任务大约用了 19 分钟。它同样让游戏正常跑了起来，还在内容设计上增加了一点小巧思。比如加入突发事件，让游戏难度和不确定性更强，游戏性确实更高。

这是个很有意思的差异。

基于 M3 的 MiniMax Code 更像是一个执行力很强的工程师 Agent，它会非常忠实地围绕你的 prompt 做交付。优势也在这里，动作快，完成度高，指令给过去，他会围绕最终产物，把页面、逻辑、状态和基础交互一起搭出来。

而基于 Sonnet 4.6 的 Claude Code 则更像一个会主动补充产品想法的合作者，它可能会在需求之外加入一些额外的设计。

这两种风格没有绝对好坏。如果你的需求非常明确，希望模型严格按照指令快速完成，M3 的表现会非常令人舒适，毕竟谁不想要一个指哪打哪的员工。但如果你期待模型主动补完产品创意、增强玩法、提出更多可能性，Sonnet 4.6 目前在创造性扩展上仍然更有优势。

看图写前端：原生多模态能力实测

相比于长任务和 Coding 能力，多模态可能是 MiniMax M3 身上最容易被低估的一项能力。

很多模型宣传自己支持图片输入，但实际体验下来，往往停留在“看图说话”的阶段，能够描述页面里有哪些元素，却很难将这些视觉信息进一步转化为可运行的代码。而 M3 此次给我的最大惊喜恰恰在于，它展现出了从视觉理解到工程交付的完整链路能力。

为了测试这一点，我选择了一个非常直接的场景，将 MiniMax 自己的官网首页作为测试对象。我向 M3 提供了两张首页截图，并要求它使用 React 与 Tailwind CSS 对页面进行复刻。

根据这张网页截图，使用 React + Tailwind CSS 完整复刻页面。

1. 尽可能还原原页面的：

▪︎整体布局

▪︎字体层级

▪︎卡片设计

▪︎配色方案

▪︎间距与留白

▪︎按钮样式

2. 页面必须响应式，适配：

▪︎Desktop

▪︎Tablet

▪︎Mobile

3. 识别并还原：

▪︎Hero Section

▪︎Feature Cards

▪︎CTA Button

▪︎Banner

▪︎Footer

4. 使用组件化结构：

▪︎Navbar.tsx

▪︎Hero.tsx

▪︎FeatureCard.tsx

▪︎Footer.tsx

5. 不要使用占位符代码。

6. 输出完整可运行代码。

让生成页面与截图视觉相似度达到 90% 以上。

之所以选择官网首页，是因为这类营销页面往往包含大量视觉设计细节：导航栏、卡片模块、渐变背景、按钮样式、信息层级以及复杂的页面布局。对于模型而言，这不仅是在识别图片中的文字，更是在理解整个页面背后的设计逻辑。

最终结果让我有些意外。

首先是页面结构的还原度。

仅凭两张截图，M3 对首页整体布局的复刻已经达到了极高的水平。导航栏、Hero 区域、功能介绍模块以及各个内容板块之间的层级关系都被准确识别出来，页面整体结构与原网页几乎保持一致。

如果只从宏观布局来看，几乎已经到了以假乱真的程度。剩下的差异主要集中在一些字体间距、元素对齐方式等细节层面。但就是把这些不一样的局部画面单独截图出来，你都得回忆一下，MiniMax 那个正版的官网画面是不是就长这样。

更有意思的是，M3 并没有机械地“照抄截图”。