微軟在 Hugging Face 上釋出了 AesCode-32B，一個 33B 引數的多模態程式碼生成模型，採用 Apache-2.0 許可，基座為 Qwen3-VL-32B-Instruct。它的目標不是生成一張靜態圖片，而是把提示詞和可選的參考圖轉成資訊豐富的視覺產物——幻燈片、海報、儀表盤、報告——並以 HTML/CSS 形式輸出，保持結構化、可編輯、可驗證。
這一任務的核心難點在於：程式碼模型「看不見」佈局、層級和顏色在畫布上如何組合，而影像生成器雖然視覺表現力強，卻常在文字、數字和邏輯關係上出錯。AesCode 的做法是，用同一提示詞生成一張影像作為美學參考，同時嚴格遵循提示詞的內容要求。但僅靠參考圖並不夠，現成的視覺語言模型可能照搬參考圖中的幻覺內容，或忽略其佈局。為此，AesCode 通過圖結構監督和解耦跨模態獎勵，把語義要求與視覺線索分開處理。
訓練上，AesCode-32B 從 Qwen3-VL-32B-Instruct 出發，先做冷啟動 SFT，再用 GDPO 在七個獎勵通道上進行強化學習。它是該系列已釋出的兩個檢查點中較大的一個，也是綜合基準成績的領先者。同系列還有 microsoft/AesCode-8B。
評測在 300 個資訊圖樣本上進行。規則項取 Text、Bound、Chart 三項程式化檢查的平均，視覺項取 Content、Layout、Style 三個清單維度的平均，綜合為兩者均值。每個提示詞生成三次取平均，不做挑選。結果顯示，AesCode-32B 在參考圖條件下綜合得分 85.89，規則項 94.33；其視覺項較參考圖條件下的 Qwen3-VL-32B 基座提升 22.4 分，綜合提升 24.8 分。作為對比，GPT-5.5 規則項為 85.90，Claude Opus 4.8 為 88.04。
兩個細分結果值得注意。Table/Chart 項 90.37 領先所有模型，原因在於要求表格使用 HTML table 結構、圖表使用 ECharts 規範，把解空間約束到可執行、可直接驗證的實現上。Boundary 項 97.27 則反映畫布溢位的顯著減少：嚴重邊界失敗在 300 個樣本中僅復發 4.3%，而 GPT-5.5 為 34.7%。不過，Style 是所有系統共同的天花板——它只在設計無需進一步視覺修改即可交付時才給分，沒有任何模型超過 60。
使用方面，模型沿用 Qwen3-VL 的對話介面，需要 transformers >= 4.57。使用者提供詳細的內容提示詞，並在可用時附上參考圖以指導佈局和風格。權重為 bf16，僅引數就需約 65 GB 加速器記憶體。官方建議用 vLLM 做批次推理，每個提示詞允許兩張圖片，並給出了 `--tensor-parallel-size 4`、`--limit-mm-per-prompt image=2`、`--max-model-len 24576` 等引數。報告成績使用溫度 0.8、top-p 0.95、最多 12000 輸出 token、24576 token 上下文。
模型輸出完整 HTML 文件，表格用 HTML table 結構、圖表用 ECharts 規範，便於直接檢查和驗證。參考圖是可選的：參考圖條件下的訓練把視覺規劃內化到策略中。在 AesCode-8B 上實測，推理時不提供參考圖僅損失 1.00 視覺分，而 Qwen3-VL-8B-Instruct 基座損失 19.55 分，GPT-5.5 損失 10.04 分。當然，提供參考圖時質量仍然最高。倉庫還提供了訓練提示詞模板，以及把簡短想法轉成模型所需提示詞與參考圖對的流水線。
訓練細節上，冷啟動 SFT 使用 3000 條演示、學習率 1e-5；強化學習階段在 7408 個提示詞上跑 520 步 GDPO，採用 verl 的 FSDP-vLLM 混合引擎。
從產業視角看，AesCode 的意義在於把多模態生成從「畫素級輸出」推向「程式碼級輸出」。對關注 AI 應用的投資者而言，這類模型若成熟，可能改變辦公軟體、設計工具和前端開發的工作流——生成的不再是不可編輯的圖片，而是可直接修改、可程式化校驗的 HTML/CSS。它同時是微軟在開源多模態程式碼模型上的一次佈局，與 Qwen 基座的結合也顯示出開源生態中「基座+垂直強化」的分工模式。不過，Style 項無人突破 60 分，說明「設計是否無需返工即可交付」仍是全行業未解的難題，距離完全替代人工設計尚有距離。