一份汇报材料做到第九版，改的只是一个数字。这类事在办公室里每天都在发生：让模型出一张进度看板或交底卡片，它给出一张图，图很好看，但你要改里面的工程量，就得把整张重出一遍；让它直接写网页代码，数字倒是能改，可它写的时候压根不知道标题会不会压住表格、色块会不会溢出边界。两头都不对，因为两类模型各自缺一半能力——写代码的看不见画布，画图的写不对数字。
微软这个月悄悄放到 Hugging Face 上的 AesCode，就是冲着这个缺口去的，而且给了一个比模型本身更值得带走的思路。
一、先把版式和内容拆成两件事
AesCode 有 8B 与 32B 两个尺寸，许可 Apache 2.0，主干是 Qwen3-VL。它只做一类东西：信息密集的可视化产物，幻灯片、海报、看板、报告，输出是完整的 HTML 文档与样式，不是图片。微软在模型卡里把问题说得很直白——代码模型的产出结构化、可编辑、可验证，但看不见版面、层级和颜色在画布上究竟怎么落；图像生成模型正好相反，版面好看，文字、数字和逻辑关系却经常画错。
难点在于把这两半拼起来时会互相污染。给一个现成的视觉语言模型塞一张参考图，它要么把参考图里编出来的内容一起抄进去，要么干脆不理会参考图的版式。AesCode 的解法是让参考图只管版式、不管内容：训练时每条提示都配一张由同一条提示生成的参考图，微软自己的训练流程里用图像模型出图、再用一个大模型把简短的想法扩成详细的内容提示。参考图没有任何内容权威，文字提示才是内容来源。为了让模型真的守住这条线，训练用了图结构化监督和相互解耦的跨模态奖励——32B 版本从 Qwen3-VL-32B-Instruct 起步，冷启动监督微调之后接 GDPO，一共七路奖励通道，其中最后一路是一个视觉语言评委，按每个样本的设计图打分。
二、让它回看自己的产物
真正的新东西在评分环节。候选输出会被放进一个屏蔽了外部请求的沙箱浏览器里渲染，然后从文档对象模型、计算样式、元素包围盒和截图几个层面打分，分数回过头当作训练信号。模型还被训练成使用真正的 HTML 表格结构和图表库规格，而不是用色块把表格画出来——这是为了让产出的图表保持可检查、可提取。
于是闭环变成：生成代码，渲染成图，把这张图喂回模型，模型看见自己画错了什么，再改。这套流程不挑模型，推理时代价也很低，任何智能体框架都能外挂上去。人不再需要充当那双眼睛，只在最后把关。
三、反直觉的那一条：训练时给的参考，推理时可以拿掉
微软公布的一组消融数字，是这份材料里最值得记住的部分。推理时把参考图去掉，AesCode-8B 的视觉分只掉 1.00 分；而它自己的主干模型在带参考的条件下视觉分是 44.72，去掉参考要掉 19.55 分，另一个对照模型掉 10.04 分。更关键的是，用带参考的奖励训练出来的模型，即使推理时完全不给参考，视觉分也从 25.17 升到了 69.71。
换句话讲，参考图教的东西没有留在输入里，而是被内化进了模型——模型不再需要那张图，它已经把“什么算排得好”变成了自己的判断。微软对这件事的表述是：视觉先验落进了策略本身，而不是留在输入端。如果你打算在自己的流程里省掉“生成参考图”这一步，这组数字说的是训练时也不该省。
分数本身要带着口径读。全部来自微软模型卡上 300 个信息图样本的自评，每个提示生成三次取平均、不作挑选：8B 总分 82.94，32B 总分 85.89，同表里带参考的 GPT-5.5 是 81.28、Claude Opus 4.8 是 80.39；8B 比它自己的主干高出 31.0 分，32B 高出 24.8 分。严重画布溢出在 8B 上的复发率是 4.3%，对照组是 34.7%。
四、一处没人过线的维度
这份评分表里有一栏叫样式，没有任何模型超过 60 分，最高的是 57.91，AesCode-8B 是 53.21。原因写在微软的定义里：只有当一件设计在交付前不需要再作任何视觉修改，这一栏才给分。也就是说，在“人会不会原样交付”这件事上，所有模型都还没及格。
其他限制也要一并写清。训练和评测数据没有放出，论文状态仍是待评审，模型没有发布任何通用推理基准，因此无法判断它除了排版之外还能干什么。部署上，8B 的半精度权重约 17.5 GB，官方示例的服务命令把上下文设为 24576 token、每提示最多两张图，单张 24 GB 的卡勉强够用但很紧；32B 建议按约 65 GB 显存规划，官方示例用四路张量并行。这个上下文长度只在单页信息图上验证过，而模型宣称面向的整套幻灯片场景并没有测过上下文压力。此外，目前找不到任何公开托管端点，要评估就得自己把权重跑起来，还得自备渲染环境——因为关于这个模型质量的所有说法，都是在沙箱浏览器里渲染之后得出的。
五、这件事对施工企业意味着什么
把上面几条翻译成一套能落地的做法，有三层。第一层是交付物的形态。安全交底卡片、周进度看板、方案汇报页、招标文件的排版，今天多数以图片或改不动的演示文稿流转，评审只能看像不像，改动留不下痕迹。换成结构化、可渲染的中间形态之后，改一个工程量只动一处，版本之间可以比对，评审看的是代码与渲染结果的双栏对照——出图只是顺带的结果，不再是成品本身。
第二层是把“好不好”拆成两半。文字是否完整、元素有没有越界、表格是不是真表格、数字与源台账是否一致，这些能程序化检查，应当进持续集成，每次生成自动跑；版式、层级、配色这类要人或模型来评，应当做成一张固定评分卡，并且定期拿一组不参与训练的比对结果去校准它，就像微软把外部评委的一致性当成指标那样。今天的多数流程里这两半混在一起，全靠肉眼，所以既慢也说不清差在哪。
第三层最容易被忽略，也最值钱：标准要内化，不要每次往提示词里塞。企业版式规范、制图标准、交底卡片的字段要求，现在普遍的做法是写成长文档，每次生成时贴进上下文，贴长了占窗口，贴短了又漏。AesCode 那组 25.17 到 69.71 的数字提示了另一条路——把规范做成一小批“参考—产出”成对样本和可计算的评分器，让模型在没有参考的情况下也达到要求。前提是三件事：企业模板本身先统一，否则学到的是各自的坏习惯；图表里的数字必须来自台账而不是模型自己生成，模型只保证表格结构是真的，不保证数字是真的；评分器的确定性那一半要能自动跑，否则评分卡会退化成主观打分。
六、两个可以直接做的小试验
第一个试验用来验证形态是否划算。挑三十份已经发出去的安全交底卡片，人工标出其中必须可改的字段，让模型输出结构化文件加一张渲染图，评审只看双栏对照，记录改一处要多久、有没有出现越界或压字。跑两周就能知道，这张卡片值不值得从图片换成可编辑的版面。
第二个试验用来验证评分卡。建一张两栏表，一半是确定性检查项——文字完整性、元素越界、表格是否为真表、数字与台账一致性，一半是人工评分项——版式、层级、配色。每次生成都过一遍，三个月后看“交付前无需任何修改”的比例有没有变化。这一栏对应的是那份评分表里没有模型及格过的样式维度，它不会因为你换了更强的模型就自动上去，只会因为标准被拆开、被量过、被反复训练才动。
来源与说明
[1]: microsoft/AesCode-8B 模型卡（定位、许可、评估口径与权重）—— Hugging Face / 2026-10 (https://huggingface.co/microsoft/AesCode-8B) [2]: microsoft/AesCode-32B 模型卡（32B 规格与评估口径）—— Hugging Face / 2026-10 (https://huggingface.co/microsoft/AesCode-32B) [3]: microsoft/AesCode 代码仓库（训练与推理流程、输入输出的预期格式）—— GitHub / 2026-10-08 (https://github.com/microsoft/AesCode) [4]: AesCode-8B shipped quietly（权重提交时点、许可、训练配置、评分表与参考图消融数字）—— OrcaRouter / 2026-10-12 (https://www.orcarouter.ai/blog/microsoft-aescode-8b-quiet-release) [5]: microsoft/AesCode 8B and 32B（微软对模型定位的原话与权重地址）—— Prismix / 2026-10-12 (https://prismix.dev/news/3c6f99ca1f06) [6]: Microsoft AesCode: Code Models That Finally See Their Own Canvas（渲染回看闭环的解读）—— Honoz / 2026-10-12 (https://honoz.com/microsoft-aescode-code-models-that-finally-see-their-own-canvas) [7]: AesCode 32B vs Muse Code（沙箱浏览器评分方式、七路奖励、画布溢出复发率与自评口径）—— OrcaRouter / 2026-10-12 (https://www.orcarouter.ai/blog/aescode-32b-vs-muse-code) [8]: AesCode-8B vs Qwen3-8B（显存与上下文要求、待评审状态、无托管端点与未测场景）—— OrcaRouter / 2026-10-12 (https://www.orcarouter.ai/blog/aescode-8b-vs-qwen-3-8) [9]: Daily AI News - October-12-2026（AesCode 的一句概述与同期条目）—— ArtificialIntNews / 2026-10-12 (https://artificialintnews.site/)