ZPedia｜Qwen 3.8 Max Preview实测：逼近顶级闭源上限，长任务稳定性略输K3

7 月 19 日，Qwen 团队毫无预热地抛出了一枚重磅炸弹：Qwen 3.8 即将发布，并将开放权重。

按照官方披露的信息，这一代模型的总参数规模达到 2.4 万亿。更引人注目的是 Qwen 对它的定位：与一线闭源旗舰正面竞争，并声称其能力「仅次于 Fable 5」。与此同时，Qwen3.8-Max-Preview 已经先一步进入 Token Plan、Qoder 和 QoderWork，开发者不必等待完整权重发布，就可以提前试用。

这是一份相当激进的宣言。

过去一年，前沿模型的竞争已经从谁的榜单分数更高，转向了更复杂的综合较量：模型能否稳定调用工具，能否理解真实网页和复杂状态，能否在长任务中保持约束，能否直接交付可运行的软件和媒体文件。单看参数规模，已经很难判断一个模型真正能做什么。

所以，我们没有打算复述发布文案，也不准备只用几道数学题替它排座次。这篇文章要回答的是一个更朴素的问题：Qwen 3.8 Max Preview 现在究竟能不能完成真实、复杂、可验收的工作？

在进入实测之前，先把这次发布中已经确认的事实、仍待验证的承诺，以及 2.4 万亿参数背后的实际意义拆开来看。

先把事实和口号分开

先把事实和口号分开。

截至目前，Qwen官方确认的核心信息并不算多：2.4T总参数规模；qwen3.8-max-preview已进入Token Plan、Qoder与QoderWork；后续将开放权重，但发布日期、许可证和最低部署要求均未公布；官方将提升方向概括为Coding与Cowork，覆盖全栈开发、数据分析和Office工作流等复杂长程任务。

这足以说明，Qwen 3.8是一款规模极大、推理预算极高、面向Agent场景设计的模型。但Qwen尚未公开完整模型卡、技术报告或统一评测表。

为了穿透宣传滤镜，我们选择用测试 K3 的同一套题目来检验它。逻辑非常简单：两者参数规模接近，且都将自己定位为顶级闭源模型的挑战者。

在此前对 K3 的评测中，我们设计了一套覆盖复杂软件工程、长程工具调用、多模态状态理解和最终产物交付的测试集。现在，同一套题目被原封不动地搬到了 Qwen 3.8 面前，约束条件、任务边界和评判标准完全一致。

Qwen 3.8 能否在统一条件下稳定完成复杂软件工程任务？能否在长时间工具调用后依然死守最初的约束？能否准确理解网页、截图、表格和文件之间的状态演变？又能否最终交付一个真正可以跑通、打开和检查的实体产物？这些问题的答案，远比再看一份厂商自测榜单更有价值。

实测Qwen 3.8

（一）复杂 UI 的视觉解析与代码重构

重建结果

第一题看起来像一道常规的前端题，实际上同时考察了视觉识别、页面拆解和工程交付。

我们向模型上传了一张 2000 × 1091 的 NASA Webb Images 页面截图，只发送了一句话：

你是一个资深的前端开发工程师。请仔细观察这张科普网站的截图，并将其转化为单文件的 HTML 代码。

没有告诉它页面名称，没有提供素材地址，也没有补充技术栈、响应式或“像素级复刻”之类的要求。模型必须自行识别截图中的信息层级，并决定如何在一个 HTML 文件里重新实现。

Qwen 3.8 Max Preview 顺利交付了一个可以直接打开的 index.html。页面不是把原截图塞进 里冒充复现，而是使用独立的 HTML、CSS、SVG 和 Canvas 重新搭建。

从结果来看，它准确识别出了 NASA 页面最关键的四层结构：顶部黑色全局导航、深灰色 Webb 二级导航、左文右栏的主体内容，以及底部横向天文图像。Webb Images 标题、整段介绍文字、两组共八个图片分类也全部保留，没有出现常见的错字、改写或凭空编造。

尤其是双层导航，模型不仅识别出了Explore、搜索框、NASA 标志、News & Events、Multimedia 和NASA+ LIVE，也完整还原了第二层的 Webb、News、Overview、Science、Observatory、Multimedia、Team 和 More。对一项只有截图输入的任务而言，这说明它的视觉文字提取和页面语义拆分都很稳。

页面中的 NASA 标志没有调用外部图片，而是用 SVG 重新绘制；底部天文图也没有依赖网络资源，而是用 Canvas 生成星空、星系核心和散落星体。这个选择让文件在断网环境下仍然能够完整显示，也说明模型确实理解了“单文件交付”的工程含义。

但它还没有达到像素级视觉复刻。模型知道页面由什么组成，却没有准确估计这些元素在目标分辨率中的绝对尺度；它完成了最显眼的桌面首屏，却没有继续检查窄屏和可访问性。这使 Case 1 的结论非常明确：Qwen 3.8 Max Preview 已经具备扎实的视觉到代码能力，第一版就能做到八成完成度，但距离闭源旗舰所追求的精细设计还原与产品级收尾，仍有一段肉眼可见的距离。

（二）复杂业务逻辑与动态数据可视化计算

我们给模型提供了 28 条多模型 API 运行记录、一份 AstraOps 品牌规范和一个 SVG 标志，要求它实现一个单文件、完全离线的运营驾驶舱。题目不只要求页面好看，还明确规定了五项核心指标的统计口径、四类数据图表、三级筛选联动、异常检测规则、明细表排序和成本情景模拟器。

Qwen 3.8 Max Preview 最终交付了一个 1203 行的单文件 HTML。所有数据、样式、SVG 图表和交互逻辑都内嵌在文件中，没有使用 React、第三方图表库、CDN 或网络请求。

我们直接调用其内嵌计算逻辑对原始数据进行校验，默认视图的五项结果与标准答案完全一致。

页面完整实现了题目要求的四类图表：每日模型请求量使用堆叠柱状图，成功率使用多折线图并绘制 97% 警戒线，成本—质量关系使用气泡散点图，请求量占比则使用环形图。

这些图表全部由原生 SVG 生成。柱体、折线节点、气泡和环形扇区都来自当前筛选后的数据，并提供模型颜色、坐标、数值标签和悬停提示。散点图中的横坐标确实按“总成本 ÷ 总请求量 × 1000”计算，纵坐标则是请求量加权质量分，气泡半径与请求量关联；并不是在一个固定坐标上摆四个装饰圆点。

Case 2 是 Qwen 3.8 Max Preview 第一次真正让人感到超出预期的地方。面对一份带有明确业务口径的结构化需求，它没有把主要精力浪费在华丽装饰上，而是先建立统一的数据状态，再让指标、图表、异常和模拟器共同消费这份状态。除了时间筛选窗口的一个边界问题，首轮交付已经接近可以进入代码评审的内部工具原型。

（三）复杂规则驱动的建筑疏散仿真

第三题把难度再次提高。

这一次，模型需要根据一个 24 × 16 的建筑网格和一份仿真规则，构建包含 12 名人员、4 扇防火门、2 个出口和 1 个烟雾源的交互式疏散沙盘。人员速度不同，出口容量不同，烟雾会按固定周期扩散，D4 会在 12 秒时自动关闭。系统还必须处理寻路、碰撞等待、出口排队、烟雾暴露、受困与恢复路径。

这类题非常适合识别模型是否在演戏。一个页面可以用 CSS 动画让小圆点看起来在移动，也可以预先写死 12 条轨迹，但只要用户提前关门或切换播放速度，伪仿真就会立刻露馅。

Qwen 3.8 Max Preview 交付的是一个 724 行单文件 HTML。源码中没有写死轨迹，也没有使用随机移动，而是建立了网格、门、人员、烟雾、出口和计划事件的独立状态，并以 0.5 秒为固定逻辑步长逐步推进。

我们首先在初始门状态下调用页面自己的 A* 寻路逻辑，检查 12 名人员到最近出口的路径长度。十二个结果与验收基准完全一致。这意味着墙体展开、门格位置、两个出口坐标和四方向移动规则都没有解释错误。路径搜索使用普通格代价 1、烟雾格代价 8，并以到两个出口的最小曼哈顿距离作为启发函数。每个逻辑步都会根据当前门状态和烟雾区域重新规划，而不是在开始时生成一条永不改变的路线。

Case 3 的意义在于要求 Qwen 同时维护空间、时间、人员、烟雾、门和出口六类相互影响的状态，而模型在首轮交付中通过了最关键的数值基准和事件边界。相比 Case 1 的视觉复刻，这更接近大模型在真实工程中的价值：它未必把每个细节都收到产品级，却能够从一份自然语言规则出发，建立一个可运行、可解释、还能被严格验证的系统。

（四）网页 3D 魔方

第四题要求模型从零实现一个真正可玩的 3×3×3 网页魔方：不仅要有 26 个立体块体和分层旋转动画，还要正确维护六面转动、算法队列、撤销重做、25 步确定性打乱、逆序复原以及供隐藏测试调用的 cubeTestAPI。

从运行记录来看，Qwen 3.8 Max Preview 对任务难点理解得相当深入。它主动检查了动画速度、prefers-reduced-motion、applyAlgorithm() 的默认参数、非法算法的原子拒绝、打乱种子的确定性、撤销重做历史以及animate:false 下的 Promise 语义。它甚至已经开始考虑如何提取魔方引擎脚本并运行契约测试，说明其设计思路并没有停留在画一个“看起来像魔方”的界面。

但这一次，过程没有转化成结果。在完成 HTML 写入和正式测试之前，任务出现Internal error: terminated bug。

（五）从结构化数据到成片

最后一题要求模型根据两条异常事件和一组恢复数据，直接生成一支可以播放的 MP4。

这一次 Qwen 成功完成了最终交付。生成的 astraops-incident-review.mp4 为 1920 × 1080、30fps、15 秒，共 450 帧，采用 H.264 编码和 16:9 画幅。视频没有使用真人、机房或无关素材，而是以 AstraOps 的深色网格、数据卡片、折线和流动节点构成完整的动态图形叙事。

五个关键时间点全部出现了规定内容：片头展示 AstraOps 标志和“AI 服务异常复盘”；Kestrel-R1 阶段准确呈现 4,200ms、95.50%、+49.35% 和“严重”；Nova-Pro 阶段呈现 3,350ms、97.00%、+27.66% 和“警告”，没有把恰好 97% 错写成低于阈值；恢复阶段则正确展示 2,448→2,006ms、-18.05%、98.07→98.69% 和 +0.61 个百分点。结尾以“让每一次异常都可解释”和 Detect · Explain · Recover 完成收束。

视频并非四张静态页面的简单硬切。异常阶段的延迟折线会随时间上升，恢复阶段的延迟与成功率曲线分别向改善方向运动，卡片、节点和数据线承担了镜头衔接。所有文字和数字都是程序化绘制，因此停留期间没有生成式视频常见的跳字、融化和标志变形。

主要问题出在对比度。片头日期、部分指标卡、恢复阶段的旧值以及结尾英文使用了较低透明度，在深色背景上显得过暗。Case 5 证明 Qwen 3.8 Max Preview 的交付边界并不局限于网页和代码。它能够读取结构化事件，组织时间轴，再通过程序化渲染输出符合规格的最终媒体文件。虽然视觉精修还没有达到专业动效团队的水平，但从一份 JSON到一支可直接播放的复盘视频，这已经是一个完整而有效的生产闭环。

结论

成功交付的四项任务表明 Qwen 3.8 Max Preview 能够理解视觉输入，建立数据产品，维护复杂仿真状态，并把结构化信息转化为最终媒体文件。尤其是 Case 2 和 Case 3，模型不仅做出了正确的界面，还通过了加权指标、时间边界、路径规划和烟雾扩散等确定性校验。这类能力比一张公开榜单更接近开发者真正需要的生产力。

它最突出的优势，是对复杂需求的结构化拆解能力。面对长提示词时，Qwen 通常能够识别哪些内容属于数据层、状态层、表现层和测试契约，并将它们组织到同一个交付物中。Case 2 的统一筛选状态、Case 3 的固定时间步与动态重规划、Case 5 的数据驱动时间轴，都体现了这一点。

它的第二个优势，是首轮交付的完整度。除 Case 4 外，其余任务都不是代码片段或半成品说明，而是可以直接打开、运行或播放的文件。模型也表现出较强的离线工程意识：使用原生 SVG、Canvas、CSS 和本地编码链路完成任务，没有依赖外部框架掩盖实现难度。

但短板同样明确。

它最突出的优势，是对复杂需求的结构化拆解能力。面对长提示词时，Qwen 通常能够识别哪些内容属于数据层、状态层、表现层和测试契约，并将它们组织到同一个交付物中。Case 2 的统一筛选状态、Case 3 的固定时间步与动态重规划、Case 5 的数据驱动时间轴，都体现了这一点。

它的第二个优势，是首轮交付的完整度。除 Case 4 外，其余任务都不是代码片段或半成品说明，而是可以直接打开、运行或播放的文件。模型也表现出较强的离线工程意识：使用原生 SVG、Canvas、CSS 和本地编码链路完成任务，没有依赖外部框架掩盖实现难度。

但短板同样明确。

第一是视觉精修。Qwen 能判断页面由哪些元素构成，却不总能准确估计绝对尺度、留白和信息对比度。Case 1 的整体缩小和 Case 5 的暗色文字都属于同一种问题：结构正确，最后一轮设计校准不足。

第二是边界收尾。Case 2 的时间筛选会丢失成本环比基线，Case 3 的复杂占位依赖存在理论风险，Canvas 人员选择也没有完整的键盘通道。这些问题不会破坏默认演示，却可能在真实用户和复杂输入下出现。

第三，也是最重要的一点，是长任务稳定性。Case 4 中，模型已经分析到 API 默认值、算法原子性、动画 Promise 和隐藏契约测试，却在交付前因内部错误终止。对于开发者而言，一次没有落盘的中断足以抵消大量高质量推理。模型能力的上限很高，但能否稳定走到终点，仍然决定了它是否可以被放心放进无人值守的工作流。

它的能力上限已经进入前沿第一梯队，优秀案例甚至接近可投入代码评审的水平；但视觉精修、极端边界和长任务成功率，仍然决定了它距离最可靠的旗舰模型还有多远。

至于 2.4 万亿参数的开放权重版本能否保持同样能力、推理成本是否可控、社区能否真正部署，以及这次中断是偶发事件还是稳定性信号，都需要等权重、技术报告和更多独立复测出现后才能回答。

但有一点已经可以确认：Qwen 3.8 Max Preview 不是只靠参数规模制造声量。至少在这组测试中，它确实交出了几份足以让闭源旗舰认真对待的作品。

Ref:

https://explainx.ai/blog/qwen-3-8-max-preview-open-weight-token-plan-july-2026

作者： Wang Shijie