MiniMax M3.1-Flash 深度实测：长上下文、代码修复、搜索与生图表现

先说结论：这轮 M3.1-Flash 实测最有说服力的表现，是在约 38 万字符的合成事件日志里准确找回分散记录并使用最后一条更正，以及在一个能稳定复现的 GridStack 开源缺陷上，经过较长推理后给出可应用、可测试的 TypeScript 修复。短板同样明确：一道要求 JSON-only 的算术题算对了金额，却仍输出 Markdown；网页搜索有官方结果，也混入拼写仿冒域名；复杂编码任务耗时较长，CLI 流式输出没有提供可核对的 token 用量。

这不是和其他模型同条件的排行榜，也不是对所有任务的统计结论。我固定一个开源仓库提交，先确认 bug 在基线上可复现，再让模型提出补丁并由项目构建、单测、完整测试和真实浏览器复测。以下把模型响应、CLI 搜索、生图路由和人工验证分别记账，避免把工具能力混成模型能力。

测试对象与方法

调用环境是 Windows、Node.js 24.20.0 和本机 mmx CLI 1.0.25，文本请求使用模型名 MiniMax-M3.1-Flash。一次非流式响应明确返回该模型标识，因此模型身份有直接回执。代码题选择 MIT 许可的 GridStack，固定在 提交 b05b79d，问题取自维护者仍标记为开放的 #2945 Flickering Scrollbar。

复现条件来自 issue 描述及维护者评论：在现有 demo/float.html 上启用 cellHeight: 'auto'，填入五个 widget，把网格底部调到浏览器视口底边附近。Windows Chrome 的 headful 实测在 1280×1016 临界视口、约 1.1 秒内记录到 30 次状态切换，垂直滚动条宽度在 0px 与 15px 间来回变化，auto cell height 和网格高度也跟着变化。没有先复现的问题，不应该拿“模型修复成功”做宣传；这次基线确实先复现了。

下图是固定提交上的项目界面。复现次数、视口尺寸、滚动条宽度和采样序列同时保存为机器可读 JSON，截图不是唯一证据。

文本：检索稳，格式仍要校验

指令测试给出 CNY 347.50 的三项比例分配，要求修正逐项四舍五入产生的一分钱偏差、另算 2.5% 平台费，并且只返回固定 JSON。模型金额和合计都正确：145.94、114.68、86.88，平台费 8.69，总支付 356.19；但它返回了项目符号、解释段落和 Markdown 加粗，未满足 JSON-only。该调用约 14.4 秒，回执为输入 174、输出 647 tokens。对聊天用户这不算大错，对直接解析 JSON 的自动化链路却是明确失败，工程上仍需 schema 校验和重试策略。

长上下文测试由我生成 1,200 条合成事件记录，在文件末尾插入目标记录的递进更正，要求模型读取三条分散记录并采用最终修订值。完整提示约 381,496 个字符，按粗略字符/token 比例约 95K tokens；这是估算，不是 tokenizer 计量。模型在约 8.46 秒内返回了所有目标字段、最终人数 481、更正编号及合计 1,882，和预设答案逐字段一致。这个结果支持“这条长上下文检索任务完成得好”，不能推出所有长文总结都可靠；该次流式 CLI 输出未附 usage 对象，因此我不报精确 token 消耗。

代码：真实 issue、基线、补丁、复测

模型第一次接到的编码任务正是 #2945。它返回的补丁在 onResize 中比较 window.innerWidth 与 document.documentElement.clientWidth：当窗口宽度未变、但 viewport client width 因纵向滚动条占位而改变时，不把这次宽度变化反馈到 cellHeight: 'auto' 的正方形高度计算；cellHeight: 'fill' 仍照常重算。其思路瞄准已复现的反馈环，而不是简单关掉 ResizeObserver 或强行隐藏全站滚动条。

我检查后把模型测试移入仓库实际会收集的 spec/ 路径，并补上恢复浏览器属性、清理 DOM 的收尾。新增测试分别覆盖滚动条出现、消失时保留 auto cell height，以及真实窗口尺寸变化时恢复方格计算。固定提交上的 core 构建通过；最终完整测试为核心 13 个文件 447 项、React 1 个文件 9 项全部通过，lint 只有仓库已有的两条 React Hook 依赖警告。

随后用更新后的 bundle 在同一台 Chrome、同一窗口宽度和临界高度扫描 23 个视口尺寸。补丁后没有出现宽度在 0/15px 间往复，1016px 捕获点保持 15px 滚动条、8 行、网格高 843px，浏览器无 console error。它证明这个复现路径被压住了，但还不等于覆盖所有操作系统、缩放级别、嵌套网格或未来浏览器行为；修复仍需维护者 review。

网页搜索：能发现线索，不替你核验

通过 mmx CLI 的 search query 分别检索模型定价和 GridStack issue，两次各返回 10 条。模型查询中找到 MiniMax 官方定价文档；项目查询也能找到目标 issue，但结果同时出现低相关页面和一个写成 guthub.com 的近似域名。这个域名不是 GitHub，不能因为标题看起来正确就直接引用。我的处理方式是把搜索当 discovery，再逐条访问一手页面、比对规范域名和仓库源码。搜索省的是找入口的时间，不是事实核验的责任。

生图：可做说明图，不是文本模型成绩

我另外调用 mmx image generate 生成 1280×720 的 dashboard 主题插画，固定 seed 26026 并开启“AI生成”水印。画面能用于文章头图或气氛说明，没有乱码字样，但它是抽象示意，不是 GridStack 的真实产品截图，也没有参与代码修复。CLI 文档将这条路径标为 image-01 / image-01-live；因此不能把图片质量记成 M3.1-Flash 文本能力。

价格、优点和边界

截至 2026-10-27 核对的 MiniMax 官方 API 定价页，M3.1-Flash 标示输入每百万 tokens 0.15 美元、输出 0.60 美元、缓存读取 0.015 美元；具体账单仍以账户、区域和服务等级为准。本文没有可用于核算代码任务的完整 usage，因此不拿 4.9K 字符 diff 反推费用。高 thinking 预算可能换来更完整的代码分析，也可能造成几分钟等待甚至耗尽非流式输出上限；选型时应把耗时、可恢复流式输出、JSON 约束和 token 预算一并压测。

• 适合继续评估：需要在一份很长的材料里定位少量事实、能接受较长推理时间，并且有人审查代码 diff 的团队。
• 接入前要补：结构化响应做 schema 校验；搜索链接做域名 allowlist；复杂编码任务记录 stop reason、耗时、usage 和补丁；配套回归测试及浏览器复测。
• 不应据此下结论：一次长文检索正确不能代表通用准确率；一个 bug 修好不代表普遍软件工程能力；CLI 搜索和图片路由也不能算作 M3.1 文本模型独立表现。

测评结论：这次 M3.1-Flash 在长上下文定点提取和 #2945 的代码分析上交出了可复现、可测试的正面结果；严格机器格式输出有一次失败，搜索结果需要人工筛查，编码 final 等待明显偏长且用量回执不完整。我的判断是“值得在有人审阅、工具链能校验的场景中试用”，而不是无监督合并代码或直接信任搜索答案。评测环境、完整响应、源代码差异、截图和测试日志已归档，读者可以按固定提交复跑。

参考资料与复现入口

• MiniMax 官方定价；文本 API 文档；图片生成 API 文档。
• GridStack README；固定提交的 MIT 许可证；项目测试说明。
• Issue #2945；基线源码。
• 本文测试记录：请求与响应、完整 diff、core/React 测试日志、基线及补丁后截图均存于本机 runtime/minimax-m3-flash-review/。文章中的 GridStack 界面图由固定版本 demo 运行截图；插画则单独标记为 AI 生成。

测试日期：2026-10-26 至 2026-10-27。模型由 MiniMax 服务提供；测试方案、代码核验、回归测试和本文结论由 AIHotTool 测评流程完成。本文不构成对其他模型或所有生产场景的保证。