MiniMax M3：百万 token、原生多模态推理，以及中国对编码智能体的押注
上周我在给一个副业项目选模型，需求是读懂一个中等规模的仓库然后生成结构性的改动。比了一圈，MiniMax M3 冒了出来。意外。这家公司几个月没出现在我雷达上，只隐约听到传闻说他们在搞一个大家伙，要跟 GPT-4o、Claude 4、Gemini 2.5 Pro 掰手腕。百万 token 上下文，原生多模态，聚焦编码和智能体——看到这几个词，我停下来了。
不是 benchmark 打动了我。benchmark 这东西只会让我累。我停下来是因为 M3 摆出了一个不舒服的问题：一个模型能读完你整个代码库、看懂你附上的文档、瞥一眼 bug 截图，然后不需要你一块一块喂上下文就能给你一个 patch——这种事真发生了会怎样？这是它许诺的东西。我去验证了。
去掉营销后，M3 是什么
MiniMax M3 是中国 AI 公司 MiniMax 的最新模型。这家公司之前已经在做语言、视频和音频生成。M3 想把这些能力统一到一个通用多模态模型里，但有个明确的转向：它不是作为又一个聊天机器人卖的，而是给软件工程师、自主智能体和长工作流设计的。
根据官方发布，M3 的要点：百万 token 上下文窗口（英文大约 75 万词，够塞下几个完整的中型项目）；原生多模态推理（图像、视频、音频不走单独的视觉模块，由模型直接处理）；强调编码能力（在 SWE-bench 风格任务、多文件重构、代码库理解上有强力宣称）；以及智能体能力（工具使用、多步规划、自主执行）。通过 MiniMax API 和 Hailuo AI 等消费级产品提供。
他们不想做最好的聊天工具。想做程序员和智能体真正用来推进工作的引擎。
百万 token 不是数字，是工作流变化
128K、200K token 的模型我都用过。有用，但手工活还是那些：复制代码片段、总结 issue、粘贴文档、提醒模型三条消息前的上下文在哪。比没有强，但没改变我编程的方式。
到了百万 token，等式变了。理论上你可以塞进一个中型应用的整个 src/、一套完整的 API 文档、若干 issue tracker 对话、几张 bug 截图，还能留出回复的余地。
我不那么关心模型是否理解得更多。我关心的是，你能不能相信它理解这一切之间的关系。用得不好的长上下文，只是更整齐的噪音。
我的第一个测试：上传一个约 4 万行 TypeScript 的仓库，让它找出两个模块之间共享状态在哪里处理。回答在结构上是正确的，但漏掉了一个测试里出现的边界情况。我觉得这合理——模型看到了森林，漏掉的树我自己查。
原生多模态：为什么对开发者重要
以前想让模型"看"东西，常见选择是 GPT-4V、Claude with vision、Gemini。能用，但总觉得像用胶带粘了个扩展：语言模型处理文本，偶尔收到另一个系统生成的图像描述。
MiniMax 说 M3 不一样。架构从根源就是多模态的，实际效果上，文本、图像、视频之间的推理应该能不丢失连贯性地交叉进行。作为工程师，我能想到的用途：发一张浏览器报错截图，模型把 UI 和代码关联起来；上传 mockup 让它生成组件结构；模型同时看到 diff、结果图和 ticket 描述来做 PR 审查；从一张图或线框图一步变成可运行代码。
这些在我的测试里并非都完美。简单截图理解得不错，但面对信息密集的 UI，它开始编造不存在的类名。这个阶段这很正常。重要的是天花板似乎比分离式视觉流水线更高。
编码与智能体：最难的领地
这是我最怀疑的地方。语言模型擅长孤立的代码片段。但在现有系统里做正确改动，同时尊重约定、测试和依赖关系，仍然是最大的开放问题。
MiniMax M3 宣称为此优化。发布中提到的任务包括根据描述加代码库解决 GitHub issue、多文件重构并保持一致性、根据近期改动生成单元测试、执行使用多个工具的智能体流程。
我从简单的开始：让它给一个 React 表单加校验，包括组件、校验 schema 和测试的改动。回答可用。不完美——它用了一个项目里没有的校验库，错误消息里还混了英语和西班牙语。但改动结构是对的，省了时间。
然后我试了更野心的事：让它提议把业务逻辑从组件移到 custom hook。那里它以一种有趣的方式失败了。hook 能跑，但漏掉了一个依赖 DOM 事件的副作用。模型尊重了形式，没尊重行为。这种错误只有具备产品上下文的人才能抓住。
竞争没有睡觉
谈 M3 得放到地图里看。今天选代码模型，几个强选择：Claude 4 Sonnet/Opus 仍然是我长而谨慎的技术推理基准；GPT-4o / o3 指令遵循和工具使用非常强；Gemini 2.5 Pro 长上下文和多模态优势明显，200 万 token；DeepSeek-V3 编码和推理上性价比极高。
M3 想坐在 Gemini 和 Claude 的交叉点：长上下文加多模态加智能体。差别在于它来自中国，这有实际影响。访问和延迟取决于你所在的位置和用的 infra。合规和数据方面，如果在企业环境工作，需要确认数据在哪里处理。语言上，我的测试里英语和中文表现不错，西班牙语能用，但技术细节上的精致度不如 Claude 或 GPT-4o。
价格、API 与上手
MiniMax 通过 API 提供 M3。文档提到标准的 completions 和 chat 端点，支持工具使用和多模态输入。我不写具体价格，因为变化太快而且今天也没有验证；需要的话看 MiniMax Models 官方页面。
上手流程和其他供应商类似：创建 MiniMax 账号，生成 API key，用 curl 或对应语言 SDK 测试，然后在你真正的任务上测延迟和质量——不是在 benchmark 上。
我不建议一夜之间迁移整个项目。花一周时间在具体任务上测试 M3：重构、legacy 代码分析、测试生成、PR 审查。只有在那里你才能看出它真的改变了工作流，还是只是又一个模型。
我喜欢的点
百万 token 上下文不是小营销，对中型仓库来说它改变了你跟代码交互的方式。原生多模态比传统视觉流水线更有整合感。聚焦智能体和编码很诚实——不是想样样精通，而是瞄准技术工作。这也是基础模型竞争仍然开放的信号：市场不止两三家。
我担心的事
强宣称、少证据。宣传 benchmark 永远比真实体验画得美。西班牙语等非英语的质量，我的测试结果参差不齐，还需要更多时间判断。工具生态方面，Claude 有 Cursor，GPT-4o 有 GitHub Copilot，Gemini 有 Google 集成，MiniMax 在中国以外还在建这个生态。透明度上，架构、训练数据、独立评估的公开信息比 Anthropic、OpenAI、Google 少。
我目前的结论
M3 是一个认真的提案。不是小众模型，也不是实验。它直接瞄准软件工程师使用的核心：理解代码、做改动、对复杂系统进行推理。
但它也不是让其他一切都过时的革命。它是一个选项，长上下文和多模态是明确强项，生态和主市场外的成熟度存在实际弱点。
接下来几周我会继续用。如果有什么改变我的看法——好的或坏的——我会写更新。目前我的建议很简单：在相信任何 benchmark 之前，先用自己的代码试它。数字会卖东西，但代码不会撒谎。