微软在 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 分，说明「设计是否无需返工即可交付」仍是全行业未解的难题，距离完全替代人工设计尚有距离。