国产模型全面进入 Flash 大乱斗？Pro 集体熄火！
DS 最近更新了 Flash，MiniMax 也更新了 Flash，再加上之前的 GLM5.3 Flash，还有 Qwen3.8 Flash，还有 MiMo 2.6 Flash。
一大堆 Flash！
Flash 的好处是又快又便宜（理论上），也是大家最常用的模型。
所以我觉得有必要来统一测试一波，看看这些 Flash 的能力怎么样，时间和 tokens 消耗怎么样。
大家可以根据结果，按需选择对应的模型！
我冒着极大的风险让 Opus5.5 帮我设计了一套测评方案。
然后我随便找了一个题目来测试，没想到所有国产 Flash 全部失败，我都开始怀疑是不是我的问题了。
我赶紧让 GPT、Gemini、Claude 也跑了一次！
GPT 也是全系列失败，Gemini 4 和 Claude Sonnet5.5 成功搞定！
还好有人搞定了，否则我都认为是我的问题了！
这充分体现了：真理掌握在少数人（模型）手里。
设计这个测试系统的过程也很有意思。
刚开始，Opus5.5 通过模拟测试对它们进行了打分，评价都不算低，认为它们都完成了核心功能。
然后，我随便一测发现所有结果都可用。 为了定位问题设定评判标准搞了很久。
整个过程还是花了不少时间和 tokens 的！
下面我就给大家完整地分享一下测试方案和测试结果！
这篇文章作为这个系列开篇，会写得比较全面和比较长！
这个系列和以往的测试不同，不是为了测试尖端能力，而是尽量用中等难度的常见任务去测试不同模型的性价比。
重点关注是否能够完成，花了多少时间，花了多少 tokens！
同时会尽量采用规范化的评价体系！
希望对大家选高频模型有帮助！
下面我就一步一步来介绍了！
想看截图和结果，可以直接拉到后面的章节。
1、为什么测 Flash 模型
这个其实上面提到过一些了。
Flash（轻量快速）档的模型，便宜、快，是日常写代码、跑智能体最常用的那一档。 而且测试成本比较可控！
但“便宜”到底牺牲了什么？光看榜单分数看不出来，所以我决定把它们拉到同一条起跑线上，让它们真刀真枪干一场。
这次参赛的五位选手：
| 选手 | 模型 |
|---|---|
| DeepSeek | DeepSeek V4.1 Flash |
| 智谱 | GLM 5.3 Flash |
| MiniMax | MiniMax M3.1 Flash（free 版） |
| 小米Mimo | MiMo V2.6 Flash |
| 通义千问 | Qwen3.8 Flash |
应该覆盖了国内主流的 Flash 模型了吧！
2、怎么测
我以前基本都是用各家的智能体和模型来测试的。但是这种方式非常麻烦，不适合批量测试。到处去订阅和充值也要成本。
我观察了一下，发现 OpenCode 的 Go 套餐里，刚好所有模型都有。
所以，我就决定直接用这个第三方智能体来跑了，这样也算公平吧！
关于怎么测，我主要是分以下几个点来说吧。
统一环境：
五个模型全部通过 OpenCode Go 套餐调用，用的都是 OpenCode 内置的 build 智能体：能读写文件、能跑命令、能自己开浏览器验证。全程开启自动授权，无人干预，模型自己决定怎么做、什么时候收工。
互相隔离：
每个模型在独立的临时目录里干活，看不到别人的代码。
全程记录：
自动统计耗时、步数、工具调用和 tokens；每个模型完整的对话、思考过程、每一次命令和输出都存了下来，可以逐步回放，方便查清“它为什么这么写”。
客观检查 + 人工评审：
页面在无头浏览器里打开，检查报错、截图；
正式题的评分由 Claude Opus 5.5 逐个读代码、看截图后给出，分完成度、代码质量、页面效果三项，按 4:3:3 加权得综合分。
Claude 在设置这个机制的时候非常机智，它自动找了 OpenCode 里的 K3 来做裁判。
然后把我一半的配额给刷完了。
我赶紧制止它，直接让它自己来评判。又省钱，又靠谱！
今夕是何年？Opus5.5 随便用，K3 却不敢用了。
根据上面的原则，我们设计出了这样一个目录结构：
article 是放文章的
bench 就是我们的测试脚本
t0 是热身题目
t1 就是我们的正经测试题目了。
Agents.md 和 Claude.md 是给智能体看的。
Readme.md 是给人看的！
这个方案包含了非常详细的内容：
比如如何启动，有哪些参数，目录和文件格式，运行流程，产出文件，指标和评分口径……等等，非常多细节！
一个题目跑完之后大概是这个样子：
自动生成文字版和网页版报告！
打开其中一个模型目录之后：
对应的目录里完整地记录了：运行日志、截图、最终代码等信息！
细节很多，再说就要把大家绕晕了，我收一收！
直接开测！
3、热身题
以前展示 AI 编程出现频率最高的题目叫：todolist！ 哈哈哈
所以，我们也用这个热身。
先用一道简单题跑通流程：单文件实现一个待办清单，要能增删改、筛选、本地保存、切换明暗主题。
结果五家全部通过 8 项功能检查，分数挤在 9.2～9.7 之间，拉不开差距（热身题的分数由 Kimi K3 自动评出）。
任务清单这种题目是所有模型重点优化的基础能力，看不出差距，再正常不过了。
4、正式题
热身完成，就可以进入正题了。 这次出的题目，也是有讲究的。 我当时用 Opus 4.7~4.8 制作坦克大战 3D 版的时候遇到一个问题。 当时需要接入两个手柄，但是我发现手柄的管理很容易出现问题，后来发现这里面有一个“幽灵插槽”的坑。当时 Claude 也没有一次搞定，反复研究后才勉强解决了。
基于这个场景，我完善了一下这个题目。
这个题目的目标是：画一个“能接真手柄”的 PS 手柄。
核心需求：
帮我在网页上画 PS 手柄，然后支持真实的手柄接入，按相应的按钮，会做出对应的反应。
要考虑到多手柄接入，我最多会接入四个手柄。
1、网页制作漂亮，匹配主题，有设计感
2、手柄轮廓和样式要高度还原
3、要考虑幽灵插槽的问题，能分清楚不同的手柄。
我的要求主要是 3 点：网页要好看，手柄要画得像，要能用！
你们觉得这个要求是高是低？会不会太简单，或者太难？
浏览器的手柄接口还是有不少坑的：
- 幽灵插槽：手柄拔掉或重连后，浏览器的手柄列表里可能残留一个“已断开”的旧条目，真手柄反而跑到了别的位置；
- 同型号手柄：两个 DualSense 的设备名一模一样，靠名字是分不出来的；
- 型号识别：PS5 的 DualSense 和 PS4 的 DS4 设备名不同，要从厂商号、产品号里认出来。
题目大概就介绍这些了。中间是漫长的等待和不停优化测试系统！
5、成绩单
实际过程中有很多波折，我先不展开！
我们先来看一下成绩单：
| 排名 | 模型 | 运行状态 | 耗时 | 总 tokens | 输出 tokens | 完成度 | 代码 | 页面 | 综合 | 初评 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | DeepSeek V4.1 Flash | 中途异常退出（代码已完成） | 约 7 分钟 | 86 万 | 3.1 万 | 5 | 6.5 | 9.5 | 6.80 | 9.15 |
| 2 | MiniMax M3.1 Flash | 25 分钟超时 | 25 分钟 | 512 万 | 5.5 万 | 4.5 | 5.5 | 9 | 6.15 | 7.75 |
| 3 | MiMo V2.6 Flash | 25 分钟超时 | 25 分钟 | 165 万 | 3.0 万 | 4.5 | 5 | 8 | 5.70 | 7.65 |
| 4 | Qwen3.8 Flash | 正常完成 | 13 分钟 | 182 万 | 4.2 万 | 4 | 4.5 | 8 | 5.35 | 6.40 |
| 5 | GLM 5.3 Flash | 正常完成 | 4 分钟 | 21 万 | 1.1 万 | 3 | 5 | 8 | 5.10 | 8.35 |
这个结果还是挺让我意外的！ 这可能高难度和中等难度下的差别吧！
这里面大部分是由 Opus5.5 记录和评判的！
重点关注下初评和综合差别！
初评是模拟测试的结果，其他评分是我们真实测试之后更新的成绩！
这一波 DS 出息了，拿到了第一名。
MiniMax 也出息了，拿到了第二名。
其他选手全都不及格！
MiniMax 这一分主要是 UI 上获得的，否则它也不及格。
UI 也是 Opus 评论的，看来“凤雏”得到了 Opus 的“蒸传”，获得了老师的认可！
我记得当时蒸得最猛的一个就是它了。
6、逐个点评
你们可能会很好奇，为什么评分是这样的？ 我也很好奇，下面就看看具体的评价吧！
我要郑重声明，好坏都是 Opus 说的！
包括下面的完整评论都是我们一起探讨之后，Opus5.5 写的。我只是反馈了一些真实测试情况。
所以一些地方的文笔，或者程度，和我认为的会有差异，也没有我写的那么“刺激”！
大家只要看真实的截图和存在的问题就可以了！
下面会配上截图进行具体的评论，能看到图和网页，以及具体的问题！
DeepSeek V4.1 Flash：
模拟场景里最完整，真机上同样没过！
DeepSeek 做了一个“DualSense（PS5） 输入实验室”风格的控制台：左边是一个白壳黑面板的 DualSense，还原度是五家里最高的；右边是 4 个玩家槽位和实时输入流。
在模拟场景里，它把三个坑都处理对了：
- 型号识别：4 个手柄接入后，列表里清楚标出哪两个是 DualSense、哪两个是 DualShock 4，还带厂商号、产品号；
- 同型号区分：两个 DualSense 被正确分到 P1、P3，互不串台；
- 幽灵插槽：专门做了一个“GHOST GUARD”面板，残留条目被单独隔离显示，真手柄正确成为 P1，按下的 ○ 准确亮起。
真机问题：它按浏览器列表的顺序先到先得地分座位。真机上两个座位被键盘接收器占掉，4 个手柄里排在后面的两个没有座位，按什么都没反应。
其他扣分点：同一时间只画当前激活的那个手柄；DS4 接入时也是用 DualSense 的外形画的。
MiniMax M3.1 Flash：
颜值天花板，可惜认错了手柄！
单看画面，MiniMax 的 DualSense 是最好看的：白色外壳、立体摇杆、柔和阴影，质感最接近实物。
但上图暴露了一个硬伤：
P2、P4 接的是 PS4 的 DS4，却被画成了带 ABXY 键的 Xbox 风格手柄。
原因藏在代码里：
它把设备名里的符号全部去掉，再去找 “054c09cc”（索尼厂商号 + DS4 产品号）。
可 Chrome 给出的设备名格式是 Vendor: 054c Product: 09cc，去掉符号后两个编号中间还夹着 “product”，永远匹配不上。
也就是说，接上真的 DS4，也会是这个结果。
真机问题：
和 DeepSeek 一样按顺序分槽，4 个手柄里有两个被挤到槽位之外。
另外，它在 25 分钟里反复重画手柄外形（改了 34 次文件），直到超时也没停下来，tokens 用量是全场最高的 512 万。
MiMo V2.6 Flash：
思路最接近正确答案，却写死了 4 个位置
MiMo 一打开页面先弹出一个“启用游戏手柄检测”的遮罩，必须点一下才进入主界面。点进去之后，除了手柄图，还有按键矩阵、四个轴的数值条、设备信息面板，信息量是五家里最丰富的。
它处理幽灵插槽的思路其实最接近正确答案：新设备先显示“待确认”，收到真实按键才算接入。
真机问题：
它只看浏览器列表里的前 4 个位置（0～3 号）。真机上有两个手柄排在 4、5 号，页面会弹出“检测到手柄 · 槽 4”的提示，但永远不会去读它们的按键。
其他扣分点：
玩家编号直接用浏览器给的插槽号；同型号手柄的“短码”完全一样；25 分钟超时时还在调整外观。
Qwen3.8 Flash：
用名字区分手柄，同名设备必然串台
Qwen 画的 DualSense 外形不错，四宫格布局也清爽。但它在最关键的第 3 条要求上走错了方向：它把设备名当作“序列号”来区分手柄。
问题是，同型号手柄的设备名完全一样。
4 个手柄接入后，P3 显示的是“idx 0”，实际读的是 P1 的那个手柄。幽灵插槽场景里，它也绑到了残留条目上，真手柄按下的 ○ 毫无反应。
真机问题：
真机上 4 个手柄经映射后名字一模一样，结果两个槽读的是键盘接收器，另两个槽读的是同一个手柄。4 个手柄里只有 1 个能用。
Qwen 花了 13 分钟、38 步、182 万 tokens，自测了很多轮，却没有发现这些问题。
GLM 5.3 Flash：
最快最省，但手柄一按就“冻住”。
GLM 只用了 4 分钟、21 万 tokens，效率最高。2×2 四宫格同时画 4 个手柄，幽灵条目逐帧过滤，拔掉的手柄还能“保留槽位”等待重连。第一轮它排第二。
真机问题：
它在接入手柄时把手柄对象存下来，之后每一帧都读这个旧对象。可 Chrome 的手柄对象是“快照”，旧快照不会随按键变化。
结果是：
只要用真机，无论接几个手柄、接在哪个位置，按键都没有任何反应。
这是五家里唯一一个在最简单的单手柄场景下也会失效的。
其他扣分点：
设备名正则太贪婪，DualSense 和 DS4 都被替换成了 “Gamepad”；通知会一直往下堆，挡住页面内容。
说实话，这个测试结果，我和预期完全不一样。
这就是真实场景下，不同模型的不同反应。 这个东西看基准和排名都很难看出来。
我（Jarvis）说两句：结论就是模拟全过，真机全躺，SVG 手柄都还差点意思！
7、真机翻车
模拟全过，一接手柄全挂！
这是最有意思的点，Claude 模拟完，说全部正确。 我其实是不相信的。
因为这个坑之前 Opus 4.8 就踩过。国产 Flash 全部正确，让我难以置信。我感觉肯定有问题，这是我测评这么久的“直觉”！
然后我掏出四个手柄，一个一个打开测试。
结果很统一：手柄一连上，4 个槽位全亮；但是我按手柄按键，页面上都没反应。
现在问题已经很明显了，接下来的问题是，这个问题的本质是什么？
为了弄清原因，我临时写了一个诊断页，只读取浏览器给出的原始数据，不做任何处理。在 Chrome 里接上 4 个手柄，先静止，再逐个按键、转摇杆，记录每个条目的反应：
| 位置 | 设备名 | 实测 |
|---|---|---|
| 0 | Keychron Link（键盘接收器） | 已连接，全程零输入 |
| 1 | Keychron Link（同一个接收器的另一个接口） | 已连接，全程零输入 |
| 2 | Xbox 360 Controller (XInput STANDARD GAMEPAD) | 手柄 C |
| 3 | Xbox 360 Controller (XInput STANDARD GAMEPAD) | 手柄 B |
| 4 | Xbox 360 Controller (XInput STANDARD GAMEPAD) | 手柄 D |
| 5 | Xbox 360 Controller (XInput STANDARD GAMEPAD) | 手柄 A |
几个和直觉不一样的事实：
- 列表有 8 个位置，不是 4 个。
- 键盘接收器也会被当成“手柄”。 它们占着 0 号和 1 号，显示为已连接，却永远不会有输入。这才是这台电脑上真正的“幽灵”。
- 4 个 PS 手柄的名字一模一样。 手柄映射工具把它们都转成了 Xbox 360 手柄，设备名里的索尼厂商号也一起消失了，靠名字根本分不出谁是谁。
- “有没有更新”也不可靠。 4 个手柄的数据时间戳总是同步跳动，不管有没有人在按，所以靠时间戳也判断不出哪个手柄正在被使用。
于是，4 个真手柄被挤到了 2～5 号，前两个位置被两个永远不会动的设备占着。
也就是当我拿 5 号手柄测试的时候，所有网页都对不上，也就是没有任何反应。
根据这个测试数据，就可以定位到它们失败的本质原因了。
| 模型 | 失效原因 | 4 个手柄里能用的 |
|---|---|---|
| DeepSeek | 按列表顺序先到先得：0～3 号（接收器 ×2 + 手柄 C、B）占满 4 个座位 | 2 个（B、C） |
| MiniMax | 同上 | 2 个（B、C） |
| MiMo | 只看 0～3 号，4、5 号的设备永远不读 | 2 个（B、C） |
| Qwen | 按名字绑定，同名设备全部读到第一个：两个座位读 0 号接收器，两个座位读 2 号 | 1 个（C，且同时出现在两个座位上） |
| GLM | 存了旧快照，按键永远不更新；同时也是先到先得 | 0 个 |
所以 “4 个槽位全亮”，亮的是两个键盘接收器和排在前面的两个手柄。
排在 4、5 号的两个手柄，在这些页面里根本没有座位。
最后我再给一个参考对比表：
| 作品 | 场景 3（单手柄按键） | 场景 7 | 场景 8（真机复现） |
|---|---|---|---|
| DeepSeek / MiniMax / MiMo / Qwen | ✓ | ✓ | ✗ |
| GLM | ✗ | ✗ | ✗ |
| Claude Sonnet 5.5（对照） | ✓ | ✓ | ✓ |
| Gemini（对照） | ✓ | ✓ | ✓ |
从这个表中可以看到，Sonnet 和 Gemini 在关键点上全对了！
它们两位的核心思路几乎一样，只有一句话：设备不按顺序入座，按了键才入座。 （这句话要好好悟，这是高一个级别的智慧）
这里不得不夸一下 G4：
我“美豆哥”这个手柄画得是真漂亮！ 而且它还在左侧画出了方向指示和力度指示，非常全面。
唯一美中不足的是页面内容有点拥挤的感觉！
Sonnet 的界面效果也还可以，但是差点意思：
Sonnet 界面的优点是简洁，保持了家族特有的特性，绝对不搞没必要的东西！
另外，Sonnet 的脑子要比 G4 好很多：
同样在完成基础任务的情况下，Sonnet 的完成度明显更高，考虑得更细，应对异常状况的措施更完善。
本来我是准备测一下 Opus 5.5 的，但是我不敢测太多，我怕同一个问题测太多，又判定我有啥问题。
整个对比下来，差距不在会不会调用接口，而在有没有意识到“浏览器给的列表是不可信的”。
国产五家都默认“列表里的就是真手柄”，然后去解决“怎么排座位”；Sonnet 和 Gemini 先解决的是“哪个才是真手柄”。
8、结论：
我们先抛开所有的模型基准和以往的名声，仅针对这个问题而言。
主要结论如下：
- 综合第一：DeepSeek V4.1 Flash。还原度、型号识别、幽灵残留处理都是五家里最好的，只差“按键才入座”这一步，改动量很小。
- 视觉担当：MiniMax M3.1 Flash。UI 质感最好，但型号识别有 bug，也同样缺少对占位设备的处理。
- MiMo V2.6 Flash：思路离正确答案最近，可惜写死了 4 个位置，收尾能力也欠缺。
- Qwen3.8 Flash：用设备名区分手柄，这个方向本身就是错的。
- GLM 5.3 Flash：速度和成本最优，但“保存旧快照”这个 bug 让它在真机上完全不可用。好在修复只需要一行：每帧重新读取手柄列表。
对于这类和硬件、浏览器环境打交道的任务，目前的国产 Flash 模型还是差点意思！
今天这个题目，如果测试对象是国内外所有模型，那么这个题目设计得非常成功，成功区分出了两个档次。
但是就国产 Flash 模型来说，这个题目可能稍微有一点点超纲。
因为他们的结果其实都是不可用的！
如果我手柄槽位刚好落在了 4 号和 5 号位置，那就是永远都用不了。
另外还有一个问题，就是这种批量的测试以及纯 AI 的评价，也是很容易出现问题的，这个边界设计、评判标准、异常处理，都是问题。
这也是为什么我平时都是手动测试、人工评价，不做榜单。
但人工评价就是比较累，而且可能带有主观性。所以还是要把握一个平衡，看能不能把题目设计得更好。
留个彩蛋：
上面只是一轮测试，接下来我又测了三轮，又遇到了各种问题！
最后又优化一下测评系统，做了一个多轮汇总报告！
整体来说，测试很漫长，稳定性堪忧，但是真实测试，总是会比各种基准直观得多！
最后，征集一下测试题目吧，大家有哪些常见的场景需要测试？
