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