MiniMax M3 全维度上手拆解：1M 长上下文、原生多模态与前沿编码，一个开源模型怎么把活儿干完

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

先把结论摆在最前面：MiniMax M3 是一款在 2026 年 6 月 1 日正式亮相的国产旗舰大模型，它最大的看点不是某一项指标特别炸，而是把"超长上下文（最高 1M token）+ 原生多模态（能看图、看视频、还能操作电脑桌面）+ 前沿级编码与 Agent 能力"这三件以前只在头部闭源模型身上同时出现的事，第一次塞进了一个开源模型里。 它底层换了一套叫 MSA（MiniMax Sparse Attention）的稀疏注意力结构，所以在百万级长文本下还能跑得动、跑得快；配套的 MiniMax Code 则是一个会自己反思、自己返工、能连续干上好几天的智能体工具。对普通用户来说，最直接的感受是：一个模型就能同时啃下大文件、视频素材、前端开发这些原本需要换好几个工具才能搞定的活儿，而且成本控制得相当友好。

想看完整拆解，往下翻。下面我会从"上下文是什么"开始，一路把原理、架构、实测体验和上手方式都讲清楚，新手也能跟得上。我尽量不堆术语，遇到绕的地方就用生活里的例子打个比方，让你看完不光知道"它很强"，还能明白"它为什么强、强在哪、怎么用得上"。

一、先把话说在前面：M3 凭什么值得聊

选在六一这天发布，多少有点小心机——像是给一群"长不大的技术爱好者"递了份儿童节礼物。但抛开节日气氛，这次更新在我看来确实够分量。

过去一两年，行业里有个心照不宣的"前沿三件套"：能不能吃下超长上下文、是不是真正的多模态、编码和智能体能力到没到第一梯队。能把这三样同时跑通的，掰着指头数也就那么几个名字——基本都是刚发布没多久的头部闭源模型，比如 Opus 4.7、GPT-5.5、Gemini 3.1 Pro 这一档。

M3 的不同点在于：它是国内第一个把这三种能力凑齐的模型，同时也是目前唯一开源的那个。这句话听起来平平无奇，但我自己折腾这些工具久了，知道"开源"两个字的分量。打个比方：一个铁匠打出了一把同时兼顾锋利、韧性和坚固的好剑，他没有藏着掖着卖天价，而是把锻造图纸公开给所有人——这才是 M3 这次最值得记一笔的地方。

为了让没接触过的朋友有个整体印象，我先用一张表把这三种能力摆一摆，后面每一项再单独展开讲。

我把这篇拆解的重点放在"原理"和"怎么用"上，至于那些"用它能创造多大价值"之类的话，我尽量少说——工具好不好用，自己上手试一把比听人吹更靠谱。这也是我在源码七号站一贯的习惯：先把东西讲明白，结论交给你自己下。

可能有人会问：不就是把三个能力凑一块吗，至于这么大惊小怪？还真至于。这三样单拎出来，业内都有不少模型做得不错——专做长文本的、专做看图的、专做写代码的，各有各的强项。难的是把它们"长在同一个模型身上"，而且互不拖后腿。

难在哪？这三种能力对模型的底层要求其实是有冲突的。长上下文要求模型能廉价地处理海量信息，否则一长就崩；原生多模态要求从训练第一步就把文字和画面的理解打通，这是个伤筋动骨的工程；前沿编码和 Agent 则要求模型能长时间稳定地规划、执行、纠错。任何一项做到极致都不容易，三项要同时在一个模型里达到前沿水准、还要彼此配合得当，对架构设计和训练数据的要求是指数级上升的。所以过去能把这三样齐备的，基本只有少数几家闭源大厂。M3 这次把这道难题在开源世界里解了一遍，这才是它值得单独写一篇来聊的原因。

二、读懂"上下文"：1M 到底意味着什么

很多新手第一次听到"上下文窗口"会有点懵，所以这块我讲细一点。

2.1 上下文，就是模型的"短期记忆"

你可以把上下文（context）理解成模型在一次对话里能同时"看进眼里、记在脑子里"的内容总量，单位通常是 token——一个 token 大致相当于半个到一个汉字，或者英文里的一个词根。窗口越大，模型一次能装下的信息就越多。

这件事的影响是实打实的。假设你手上有一份一百多万字的资料，普通模型的窗口装不下，那就只能人工切成好几段分别投喂。问题在于：切开之后，前后内容的关联性就断了，模型读后半段时已经"忘了"前半段说过啥，整体理解效果自然打折扣。

而当窗口足够大，事情就变了。1M 上下文是长程 Agent、长程 Coding、长视频理解的基础设施——这句话不是客套，它是一切长任务能跑通的地基。我自己最常用的一个场景，就是在看一段一个多小时的长播客视频之前，先让模型把整段内容的话题脉络梳一遍，省得我从头熬到尾才发现没有我要的信息。这种"先扫一遍再决定要不要细看"的用法，没有长上下文根本玩不转。

再举个更贴近开发者的例子。我手头有个老项目，几十个文件、上万行代码外加一堆历史文档。以前想让模型帮我加个功能，我得先自己判断"哪几个文件相关"，挑出来贴过去——这一步特别费神，挑漏一个关键文件，模型就会给你一段看着对、实则跑不通的代码。换成窗口够大的模型之后，我可以把整个项目连代码带文档一次性丢进去，让它自己去找关联、改 bug、加功能，它不会做着做着"忘了前面说过啥"。这种从"我替模型筛信息"到"模型自己消化全局"的转变，体验上的差别是质变级的。

2.2 上下文为啥又慢又贵：先搞懂 KV 缓存

这里插一段新手科普，理解了它，后面 MSA 的妙处才品得出来。

模型在处理一段已经读过的文本时，会把每个 token 算出来的一组中间结果缓存下来，业内叫 KV 缓存（Key-Value Cache，你可以粗暴理解成模型给读过的每段话存的一份"记忆草稿"）。生成下一个字的时候，它要回头去翻这份草稿，看看该重点参考哪些内容。

问题就出在这份草稿会越攒越大。上下文越长，KV 缓存越大，模型每生成一个字要翻的东西就越多，显存也吃得越狠。所以一句话总结：上下文越长，模型往往越笨、越慢、越贵。 这就是为什么"长上下文"听起来美好，真正做到"长而且好用"却那么难——很多模型标了个大窗口，实际用满就卡得没法看。M3 这次真正下功夫的地方，恰恰是把"用满长上下文"这件事的成本压了下来。

2.3 短上下文的三个坑（我都踩过）

为了让你更有体感，我把短窗口模型最容易出问题的地方列一下：

• 割裂感：长文档被迫分段，模型在段与段之间会"失忆"，结论前后矛盾。
• 绕远路：有些模型为了凑信息，会反复去搜网页，看起来很忙，其实根本没真正读你给的素材。
• 半途而废：长任务做到一半，因为上下文塞满或者工具调用到上限就主动退出，还得你再开一轮对话续上。

这几个坑我是真踩过。所以当一个模型号称"1M 上下文"时，我第一反应不是兴奋，而是想看它"怎么做到的、是不是真能用满"。

这里还想多说一句给新手的提醒：上下文不是"越大越要塞满"。窗口大是好事，但你一股脑把无关材料全倒进去，反而会稀释模型的注意力，让它抓不住重点。我的习惯是——长素材尽管丢，但提问时把"我具体要什么"说清楚，给它一个明确的落点。窗口大负责"装得下"，你的清晰指令负责"找得准"，两者配合才有最好的效果。这跟人是一样的：给你一摞资料，你也得知道老板到底想要哪一页。

2.4 MSA：为什么长上下文这么难，又是怎么被解决的

这里就得聊到 M3 这次的底层创新了：它用了一套全新的注意力架构 MSA（MiniMax Sparse Attention）。

要讲清楚 MSA 解决了什么，得先说说传统注意力的"先天毛病"。大模型里的注意力机制，默认是"全注意力"：处理一段文本时，每个 token 都要和前面所有 token 两两算一遍关系。文本长度记作 (n)，这个计算量大致按 (O(n^2)) 的速度膨胀。换句话说，长度翻一倍，算力开销翻四倍。窗口拉到百万级别，全注意力基本就被这个平方级复杂度拖死了——又慢、又贵、还容易"看花眼"。

稀疏注意力的思路，是通过增加一个初筛阶段来避免复杂度爆炸。打个不太严谨但好懂的比方：

你期末复习，不会把整本教材从头到尾重读一遍，而是先翻目录、挑重点章节、过一遍错题本，有针对性地复习。MSA 干的就是这件事——先快速扫一遍上下文里哪些块值得重点看，再对这些块做精确处理。

那 MSA 跟别的稀疏方案比好在哪？官方给的说法是两点。第一，与 DSA、MoBA 等方案相比，MSA 能更精确地为 KV 分块，实现更高的有效上下文覆盖。这里的 KV 你可以粗暴理解成模型给每段内容存的"记忆索引"，分块分得准，命中重点的概率就高。第二，它在算子层直接做了优化，每块只读一次、访存连续，比开源的 Flash-Sparse-Attention、flash-moba 快 4 倍以上。

落到数字上，效果挺夸张：在 100 万上下文下，M3 每个 token 的计算量只有上代模型的 1/20；prefilling 阶段（首次处理长文本）加速超过 9 倍，decoding 阶段超过 15 倍。而且关键是，在多个对照实验里，MSA 的绝大部分能力和全注意力打平——既省了算力，又没怎么掉精度，这才是它真正聪明的地方。

下面这张流程图，是我自己画来帮理解的，把"全注意力"和"MSA 稀疏注意力"的差别摊开看：

flowchart TD
    A[输入超长上下文] --> B{选哪种注意力}
    B -->|全注意力| C[每个token两两计算]
    C --> D["复杂度 O(n^2) 暴涨\n又慢又贵"]
    B -->|MSA 稀疏注意力| E[初筛: 快速扫一遍\n挑出值得看的KV块]
    E --> F[精确处理: 只算命中的块\n每块只读一次]
    F --> G["计算量大幅下降\n长上下文真正可用"]

我看官方介绍时，里头还有不少"算子层优化、KV outer gather Q"这类专业术语，老实讲细节我也没全啃透。但核心逻辑抓住就够了：通过结构创新，把上下文从一个"装不下的累赘"变成了一个可以持续放大的维度。 上下文窗口一直是大模型的兵家必争之地，往后只会越来越大，因为它是模型好不好用的技术基座，直接决定了天花板在哪。

顺便把刚才提到的两个加速数字讲明白点，免得你看着"prefilling 加速 9 倍、decoding 加速 15 倍"一头雾水。模型干活其实分两步：第一步是把你给的长文本一口气读进去、建立理解，这叫 prefilling（预填充）；第二步是一个字一个字往外蹦答案，这叫 decoding（解码）。读进去那步快了 9 倍，意味着你丢一份超长文档进去，它不用让你干等半天才开口；往外蹦答案那步快了 15 倍，意味着长篇回答也不会越写越卡。这两步都提速，整体体验才是真的顺。

我自己用下来还总结了一个朴素的判断标准：看一个模型长上下文是不是"真能用"，别只盯着窗口标多大，要看它在窗口快塞满时还稳不稳、卡不卡。 很多模型前面几轮聊得挺好，上下文一长就开始丢三落四、答非所问，那种"虚标"的长窗口意义不大。MSA 这套设计的价值，恰恰是让那个标称的 1M 不只是个好看的数字，而是真能在长任务里扛住。官方也明确说了，API 最高支持 1M token 上下文窗口，并保障至少 512K token 可用——这种"保底可用"的承诺，比单纯飙峰值更让我安心。

三、原生多模态：让模型直接"看懂"画面

讲完长上下文，再说第二件兵器：原生多模态。

3.1 "看不见画面"的模型，到底差在哪

绝大多数模型其实只有文本能力，纯靠文字交流。想让它理解一段视频，传统做法是先把视频里的语音转成文字（业内叫转写），再把文字喂给模型。

这套流程有个致命短板：画面信息全丢了。 一段没有配音的视频——比如一段纯靠肢体动作和走位展开的体育集锦——你把它转成文字几乎是空的，模型自然两眼一抹黑。就算有配音，画面里的图表、字幕、人物表情、镜头切换这些信息，转写也带不进去。

我自己做过一个对照小实验：拿一段没有任何旁白、纯靠画面叙事的短视频，让只有文本能力的工具去理解。结果它只能靠网页搜索拼凑出一个"大概讲了啥"的模糊结论，根本没法逐秒精准描述画面里发生了什么。这就是文本模型的天花板。

3.2 原生多模态 vs"后期拼接"

那 M3 是怎么做的？答案是原生多模态。它支持图片和视频的输入，还能操作电脑桌面。更关键的是"原生"二字。

很多模型的多模态是"缝合"出来的：先用海量文本把语言能力练好，再外挂一个视觉模块去看图。这种方式我习惯叫它"后期贴图层"——能用，但文字和画面的理解是两套体系，对不齐。

M3 走的是另一条路。它从训练的第 0 步开始就是文本、图片、视频一起喂进去练的，重构了整套数据管线，把预训练数据规模扩到了百万亿（100T）token 量级，让文本和视觉的语义空间高度对齐。用官方一句挺到位的话讲，多模态是刻在模型骨子里的原生能力，而不是后期贴上去的浅表图层。

这里还有个细节我觉得值得新手记一下：训练里有一类叫 interleaved data（交错数据） 的东西特别重要。这类文本和图像在序列里交替自然排列的数据，对模型性能的提升比一般认为的更关键，对训练数据规模的扩展也很重要。说人话就是——不是简单地"给一堆图 + 给一堆字"，而是让图文像人类阅读时那样穿插出现，模型才能真正学会"看着画面理解文字、读着文字脑补画面"。

3.3 原生多模态能干嘛：几个落地方向

原生看得见画面，配上 Agent 工具，能解锁的场景一下子就多了。我梳理了几个最实用的方向：

• 长视频/长音频理解：直接把链接或文件丢进去，让它总结脉络、提取要点，不用自己先扒字幕。
• 看图写前端：给一张设计草图，让它照着结构去实现网页布局。人类可能看不懂你随手画的草图，但模型往往能 get 到。
• 模拟真人操作电脑：因为能看见屏幕画面，配合 Agent 就能模拟人去点鼠标、填表单，做程序的交互界面测试这类活儿。

第三点其实就是这两年很热的"Computer Use（电脑操作）"能力的根基——模型得先"看得见"，才谈得上"动得了"。这一块我放到后面 MiniMax Code 那节再细说，那才是它真正发力的地方。莫潇羽这边的体会是：多模态从"能看图"进化到"能照着图干活"，中间这一步的含金量，比参数表上的分数高多了。

3.4 多模态成绩与更多用法：不只是"会看图"

前面提到的"交错数据"可能还是有点抽象，我举个生活化的例子你就懂了。你翻一本图文菜谱，文字写"把面糊倒进模具"，旁边正好配一张倒面糊的照片——文字和图是咬合在一起的，你看一眼图就明白文字在说什么。交错数据训练，就是让模型从海量这种"图文咬合"的材料里学习，而不是把一堆图和一堆字分开硬塞。这样练出来的模型，理解图文混排内容时才不别扭。

成绩上也能印证它的多模态不是花架子。在文档理解类基准 OmniDocBench 上，M3 的得分超过了 Gemini 3.1 Pro；在面向自主 Agent 的端到端评测 Claw-Eval 上拿到最高分；在考验自主浏览与信息检索的 BrowseComp 上，M3 以 83.5 分超过了 Opus 4.7 的 79.3。这几个分数我是从官方公开资料里核实过的，不是道听途说。

落地用法上，除了前面说的三个方向，我还试过几个挺实用的：把一份扫描版的图文资料丢进去让它结构化提取、把一段会议录像让它按画面切片做要点、把几张界面截图给它让它对照着排查 UI 问题。这些活儿放在"只会读文字"的模型上要么做不了，要么得先人工把信息翻译成文字，费时费力还容易漏。原生多模态把这道"翻译"工序直接省了——你给它什么形态的素材，它就用什么形态去理解，这种顺畅感用过就回不去了。

往深里说一层，原生多模态对内容工作者的意义，其实是把"理解"和"创作"打通了。以前的流程是割裂的：你用一个工具看懂素材，再换一个工具去做东西，中间的信息在搬运时总会损耗。而当一个模型既能看懂你给的画面，又能据此直接产出图文成品，整条链路就闭环了。前面那个做交互页面的例子最能说明问题——别的工具是去网上找图来凑，M3 是看懂需求后直接生成贴合的素材。这一字之差，背后是"拼凑"和"理解后创造"的本质区别。我做了这么多年内容，深知"在多个工具间反复横跳"才是最磨人的隐形成本，能把它砍掉的工具，价值往往被低估。

四、前沿编码与 Agent：从"写代码"到"会协作"

第三件兵器，也是 M3 这次重点打磨的：编码与 Agent 能力。

4.1 先看一眼成绩单（公开基准）

从海外媒体的评价和实际体感看，M3 在编程上相比上一代 M2.7 是质的提升。我把官方公开的几个权威基准分数整理成表，方便你有个量化的概念——这些都是公开评测，不是我瞎编的：

横向比较上，官方的说法是：在衡量 Coding 能力的 SWE-Bench Pro 上，M3 超过 GPT-5.5 和 Gemini 3.1 Pro，接近 Opus 4.7；在综合评估 SVG 生成的 SVG-Bench 上，M3 超过 Opus 4.7。多模态侧也不弱，在 OmniDocBench 上 M3 超过 Gemini 3.1 Pro，在面向自主 Agent 的 Claw-Eval 上拿到最高分。这个站位，已经是实打实的第一梯队水准了。

4.2 比分数更重要的，是"会不会协作"

不过我得泼一句冷水：现在光看 Coding 跑分，越来越不能反映真实体验了。这一点官方自己也讲得很坦诚。

问题出在哪？当前大多数代码 Agent 的训练和评测，都建立在单轮任务（single-turn task）的假设上。但真实开发根本不是这样。我们用的时候，往往是在同一个会话里反复折腾：先提个需求，看一眼结果不满意，再补充澄清、调整方案、交叉派活，根据中间产物一轮轮迭代。用户会在同一个 Session 里持续协作，而不是一锤子买卖。

为了把"跑分"和"真实手感"之间的差距补上，官方专门搭了一套交互式用户模拟器框架，模拟真实开发者协作时的行为模式，让模型在训练和评测阶段就接触到接近生产环境的交互场景。这个框架能模拟需求补充、方案讨论、反馈修正、连续任务切换、复杂项目迭代等等，目的就是让 Agent 别只会被动执行指令，而是能主动跟人配合着把活儿干完。

用一段伪代码描述这种"多轮协作"的循环，可能比文字更直观：

## 这不是真实接口，只是帮你理解"多轮协作"长啥样
session = start_session(context=whole_project)   # 整个项目一次性进窗口

while not user.satisfied:
    plan   = agent.make_plan(user.request)       # 先规划，别上来就闷头写
    result = agent.execute(plan)                 # 执行：写代码 / 调工具 / 跑测试
    agent.self_check(result)                      # 自己先验一遍，不交付带bug的东西
    feedback = user.review(result)               # 你来看结果、提意见
    user.request = agent.refine(feedback)        # 根据反馈调整下一轮

我的理解是：下一代 Agent Coding 比的不只是代码生成，更是长期协作能力、规划能力，以及人和 Agent 的协同效率。M3 把这条路线上的关键数据做了规模化，目标不是榜单好看，而是在真实研发流程里当个靠谱搭档。这个方向我是认同的——毕竟代码写得再快，如果不能跟人对齐意图，返工成本反而更高。

4.3 三个"长跑"任务：看它能扛多久

跑分之外，最能说明问题的，是它在几个超长任务上的表现。官方公开了几个内部实测，我挑三个最有代表性的，用大白话讲给你听，你就明白"长程自主能力"到底是个什么概念。

第一个，独立复现一篇学术论文。 这事难在哪？它需要三种能力同时在线、还得在一条长线程里不掉链子：看懂论文里的曲线图、公式、数据要靠多模态；论文加代码加实验日志一次性进窗口要靠长上下文；真正动手把实验跑通则要靠编码和 Agent 能力。M3 自主跑了接近 12 个小时，全程产出 18 次代码提交、23 张实验图表，最后把核心实验都跑通了，连原论文讨论的一些细微效应都复现了出来。一个模型连轴转半天、自己规划自己验证，这种续航在以前是难以想象的。

第二个，优化一段底层算子代码。 这类活儿是出了名的硬骨头，资深工程师集中攻关通常都得花上一两周。官方给 M3 的起点很苛刻：只有一份任务说明、一个评估脚本、一个跑都跑不起来的代码骨架，没有任何现成的高性能参考实现可抄。也就是说，它没法靠模仿走捷径，只能从基本原理出发自己摸索。结果在大约 24 小时的连续执行里，它完成了 147 次性能测试提交、近 2000 次工具调用，把硬件峰值利用率从最初的 7.6% 一路推到了 71.3%，整体提速 9 倍多。

这里有个细节我特别在意：大多数模型在前 30 次提交内没新进展就主动"摆烂退出"了，而 M3 的最优解出现在第 145 次提交——在那之前它经历了好几个"怎么调都不见效"的平台期，却仍然在换着方向继续试。这种"不轻易放弃"的劲头，对长任务来说太关键了。背后其实也有 MSA 的功劳：多次工具调用产生的上下文是高密度、高度结构化的，长上下文的注意力分配机制在这种场景下起了大作用。

第三个，让它自己去"训"模型。 前两个任务好歹目标明确、反馈清晰，但真实研究往往没这么清楚的指引。官方干脆给了 M3 几个只完成预训练、啥下游能力都没有的基础模型，要求它在 12 小时内自主走完"合成数据 → 训练 → 评测 → 迭代"的全流程，全程无人干预——合成什么数据、用什么训练策略、根据评测结果怎么调下一轮，全得它自己拿主意。最终它的得分在所有参赛模型里排第三，仅次于 Opus 4.7 和 GPT-5.5，明显领先其余选手。

把这三个任务放一起看，我的结论很简单：M3 真正的杀手锏不是"写得快"，而是"扛得久"。 短任务大家差距没那么大，可一旦任务拉长到需要连续几小时、几百次试错、还得自己判断方向，能稳住不崩的模型就没几个了。这恰恰是 Agent 时代最稀缺的能力。

顺便说个看基准分数的小心得，免得你被各种榜单绕晕。第一，要看清测试用的"脚手架"是什么——同一个模型，配不同的执行框架，分数能差出一截，所以跨模型比分数时得确认大家用的是不是同一套环境。第二，单轮跑分高不代表实际好用，前面讲过真实使用是多轮协作，这一点榜单往往体现不出来。第三，分数只是参考，最终还得自己拿真实任务去试。我列那张成绩单，是想给你一个"它大概在什么段位"的概念，而不是让你拿着分数去较真到小数点后一位。说到底，模型好不好用是个体感问题，跑分是地图，真正的路还得自己走一遍。

五、上手实测：我自己折腾的几个场景

光说原理太干，我把自己实际跑过的几类任务整理出来，配着 MiniMax Code 一起用（它是专门为 M3 打造、和 M3 一起训练的智能体工具，配合度比通用工具更高，交互界面也更顺手）。下面这些都是我自己折腾下来的真实体感，case 我做了泛化处理，你换成自己的素材一样适用。

5.1 场景一：长视频"先扫后看"

第一个我最常用：把一段一个多小时的长视频丢给它，让它先帮我看看都聊了哪些话题，再决定要不要逐段细看。

这里有个细节挺有意思，能看出它的"应变能力"。我没下载视频，直接把链接发过去了：

1. 它一开始想直接拿 URL 在线分析，结果撞上了网站的反爬机制。
2. 于是改策略，先把视频下载到本地——下下来才发现视频太长，本地处理不动。
3. 它又换了个思路，重新解析链接并借助 CDN 来加速分析。
4. 最后成功把一个多小时的内容全扒下来，总结归纳后交付给我。

整个过程它自己在那"碰壁—换招—再碰壁—再换招"，没怎么用我操心。作为对照，同样的任务我拿一个只有文本能力的工具去跑，它要么直接触发单条消息的工具调用上限、得再开一轮对话，要么干脆全程在反复搜网页、压根没启动过任何视频分析——追问之下，它也承认结论是靠网页搜出来的，而不是真看了视频。这就是有没有原生多模态的差距。

5.2 场景二：纯画面视频的逐秒理解

第二个场景更能拉开差距：一段没有任何配音、纯靠画面叙事的短视频。这种素材转成文字几乎是空的，只能靠"看"。

我把链接发过去，一开始它也被反爬挡了一下，只给了点网页层面的信息。我纠正它"先下载下来再理解画面内容"，它就成功完成了任务，能比较精准地描述画面里逐段发生了什么。而拿文本工具跑同样的活儿，结果就只能根据网页信息加搜索，拼出一个"大概内容"，做不到逐秒还原。

这个对比让我对"原生多模态"有了更具体的体感：它不是参数表上多一行的噱头，而是真能改变你处理素材的方式。

我还顺手测了它对画面里文字的识别——把一张信息密集、排版有点乱的图丢进去，让它把里头的要点结构化提取出来。它处理得相当利索，连图里的小字和表格关系都没怎么漏。这背后靠的是它在文档理解上的底子。对经常要从截图、扫描件里扒信息的人来说，这个能力使用频率其实特别高，只是平时容易被"看视频"这种更吸睛的功能盖过去。

5.3 场景三：照着草图做交互前端页面

第三个是我个人最喜欢的：让它照着我手画的草图，做一个可交互的前端页面——一个卡通形象的眼睛会一直盯着鼠标光标移动。

我那张草图，说实话人类不一定看得懂，但我赌它能 get 到，结果确实做出来了。第一版有个小瑕疵：形象眼睛里的高光没跟着眼球一起动，看着有点出戏。这其实跟编码能力没关系，多半是图片素材本身的问题，后来修一版、把高光处理掉，就自然多了。

最让我意外的是一个细节：同样的需求，我也拿别的国产模型跑过对照——有的整个脑袋都跟着鼠标在飘，有的虽然实现了但带点 Bug。但它们和 M3 最大的区别在于：别的模型大多是用 SVG 现画一个形象，或者去网上找张图来凑，而 M3 是真的帮我现场生成了一张图片素材。 这意味着它能把"编码 + 多模态生图"串起来用，照着草图的结构完成