截图转代码这事的两个极端都让人难受：多模态模型看一眼截图就吐 JSX，文本和色值一错一个准；完全结构化的 pipeline 把细节钉死，但输出被固定 schema 框住，编排成本不低。WidgetGen（arXiv 2608.12611，ECCV2026 MUCG Workshop）占的是中间地带——只对最容易出错的那几个低层信号做证据采集，高层布局推理留给模型自由发挥。我的判断：方向对，但评估协议和“轻量”这个词得拆开看。它不靠刷数字，它把“生成 vs 结构”这个二元对立给拆了。
评测条件先交代，否则后面的数字全是裸数字：六个多模态模型、1,000 个 held-out widgets、视觉重建指标（面积、可读性、风格）、提交时间 2026 年 8 月 12 日 21:49:22 UTC。“widget 级别”这个限定本身就是个问题。widget 是最小可复用单元，布局复杂度、文本密度、视觉多样性都被压在一个很窄的范围里。在这么窄的体系里说 held-out，只能说明这些 widget 的设计分布没被训练集直接看过，但“没见过的边缘设计长什么样”这套协议测不出来。把 widget 级别的评估结论迁移到整页截图，保质期很短——你就是拿我的尺子去量你的桌子。
| 方案 | 低层细节控制 | 高层布局自由度 | 编排开销 | 输出约束 |
|---|---|---|---|---|
| 直接多模态生成 | 弱（可见文本/色值易幻觉） | 高 | 无 | 无 |
| 结构化 pipeline（如 Widget2Code） | 强 | 低 | 高 | 固定 schema 框死 |
| WidgetGen（选择性证据驱动） | 中（只锚文本/颜色） | 高 | 低 | 无固定 schema |
这张表的核心在中间列：WidgetGen 赌的是低层细节的错误可以被显式证据压下去，而高层布局的模糊性不因为少了 schema 就失控。这不是空赌——我横评里反复讲过，模型在生成任务里的错误分布不均匀，大量错位集中在少数几类低层信号上。文本内容和色值就是 UI 生成里的双高错误源：文本因为 token 序列建模天生容易漏字错字，色值因为 RGB 空间里的微小偏移在视觉上被放大。WidgetGen 的设计说白了：你只需要在这两个地方给硬证据，别的地方就不用那么死。
论文没公开实现细节，我根据摘要和常见做法还原骨架，不一定和官方实现完全一致，但足够说明它的取舍：
# 从论文描述重建的 WidgetGen pipeline 示意（非官方实现）
# 输入：widget 截图
evidence_text = OCR(screenshot) # 可见文本证据
evidence_colors = extract_colors(screenshot) # 颜色证据
layout = layout_reasoning(evidence_text, evidence_colors) # 高级布局推理
if has_chart(screenshot):
chart_evidence = chart_reasoning(screenshot) # 可选图表推理
layout = merge(layout, chart_evidence)
jsx = direct_generate(layout, screenshot) # 直接产生可执行 JSX
关键判断点是那个 has_chart 分支。不是所有 widget 都有图表，图表推理只在必要时触发。这个“选择性”本身是中性的工程决策——对没有图表的 widget，不引入额外推理开销；对有图表的 widget，给一个专门的推理通道来处理这类的高错误率。比统一套重型结构聪明，但也就是“按需加约束”的工程化表达，算不上概念创新。真正的贡献是：把这个设计选择做成了一套能被评估和复现的 baseline。
论文说在多数视觉重建指标上超过直接提示和结构化 Widget2Code 流程，面积、可读性、风格三项一致提升。“多数”这个措辞我读了两遍——它没说全部。剩下的指标是什么？在哪类 widget 子集上掉了？没有原始数据，不敢断定。但“一致提升”只用在三个维度上，本身就是在收着说。六个模型的多样性也要打问号：如果里面有三四个是同家族相邻版本，“六个多模态模型”听起来就比实际情况壮观。摘要没列模型清单，可能是 workshop 篇幅限制，但你要拿它当强基线引用，没交代完整的地方就得如实标记。
微调实验让我最不舒服。他们把重建得到的 image-code 对拿来微调六个开源的 Qwen 系列模型，声称所有报告指标都提升。这不是数据飞轮，这是数据自证。用模型自己生成的输出当训练数据去训练同一个模型，在训练分布和测试分布高度重合的时候，所有指标提升几乎是必然的。真正有区分度的是分布外泛化——这批微调过的模型面对没见过的 widget 形态表现如何，摘要里看不到。这个批评收着说：如果训练集和测试集的切分干净、held-out 真的没被微调数据污染，那结果有说服力；如果切分没讲清，那“所有指标提升”至少有一大半是评估协议的功劳，不是模型的。
这篇真正有用的东西就一句话：低层细节的错误率靠证据锚定就能压，高层布局的模糊性靠自由度比靠约束更稳。接受了这个区分，你会发现过去很多做法都在不同程度实践这个模式，只是没人把它拆成一个明确的、可评估的框架。WidgetGen 做了，然后用六个模型和一个 held-out 集把它固定成了基线。这就是它的全部贡献，也够了。
场景化建议。如果你在做 UI 组件库重建、设计系统自动代码化，或有大量 widget 级截图要批量转可执行 JSX，这条选择性证据驱动的路径值得自己搭一遍：OCR 和颜色提取有现成工具，布局推理给模型，整体编排不复杂。如果你在做整页截图生成、跨页面布局、或要处理非标准高度自定义的 UI 设计，它作为一个轻量基线还不够——widget 级别的评估撑不住那种复杂度。
补一句公正补丁：结构化 pipeline 没死，只是在不需要重型约束的场景里显得过于昂贵。真正复杂、需要强制输出结构的设计系统，schema 依然是唯一硬约束。WidgetGen 的价值在“没必要重”的那一档——更轻，但保真度不掉。这个结论是当前版本下的，下一版如果作者发布完整实现和模型清单，我会重跑评估；哪个开源仓库照这个思路做了生产可用实现，我也盯着。