Image-to-Code: 视觉反馈与强化学习方向论文调研
围绕"生成—渲染—视觉反馈—优化"闭环范式的最新研究进展 | 2025.05 – 2026.07
调研动机
单纯的"生成—截图—点评—修改"流水线已不够新颖。当前前沿工作已沿多个维度推进：迭代视觉优化+RL (UI2CodeN)、多视口多交互状态的 browser trace (HTMLCure)、视觉缺陷归因到代码语句 (Visual-SDPO)、浏览器 Agent 自动探索和测试生成 (WebCompass)、以及纯图像学习的验证非对称性 (RRVF)。
本调研覆盖 7 篇核心论文，按技术路线分类整理，重点关注各工作的创新点、方法差异及尚未覆盖的研究空白。
RL + 视觉反馈
RRVF
UI2CodeN
MSRL
RLRF
浏览器交互式评估
HTMLCure
WebCompass
缺陷归因/Credit
Visual-SDPO
MSRL
Benchmark/评测
WebCompass
HTMLCure
2025.05
RLRF — SVG 渲染反馈 RL 首次提出
2025.11
UI2CodeN — 迭代视觉优化 + RVPO 相对偏好 RL
2026.04
WebCompass — Agent-as-a-Judge + 浏览器 MCP 探索
2026.06
Visual-SDPO — 视觉缺陷到代码语句的归因
2026.06
HTMLCure — 多视口交互状态 browser trace + 修复引擎
2026.07
RRVF — 纯图像学习，验证非对称性原理
2026 (ICLR)
MSRL — 多粒度 reward + 课程训练突破 SFT 瓶颈
强化学习 (GRPO)
视觉反馈
Chart + Web
核心洞察 — 验证非对称性 (Asymmetry of Verification): 验证渲染结果是否匹配源图像，远比从图像生成代码简单。这种不对称性天然提供了 RL 的奖励信号，使模型能仅从原始图像学习，无需配对文本监督。
RRVF 提出一个闭环框架：Reasoning（推理生成代码）→ Rendering（渲染为图像）→ Visual Feedback（与源图像比较得到奖励），通过 GRPO 算法端到端优化。支持多轮自我修正。最终模型甚至超越了用于生成训练期视觉反馈的更强 MLLM。
方法详情 & 实验结果
方法框架
- Reasoning 阶段: MLLM 对输入图像进行深度视觉推理，生成结构化代码（如 matplotlib/HTML）
- Rendering 阶段: 将生成的代码渲染为可视化输出
- Visual Feedback 阶段: 将渲染输出与源图像对比，计算视觉相似度作为奖励
- RL 优化: 使用 GRPO (Group Relative Policy Optimization) 算法优化策略
- 支持多轮迭代 self-correction
关键特点
- 完全摆脱 image-text paired supervision
- 奖励来源仅为视觉比较，无需人工标注
- "学生超越老师" — 训练后模型超越提供反馈的更强 MLLM
评估任务
- 数据图表 (data charts) → matplotlib 代码
- 网页界面 (web interfaces) → HTML/CSS 代码
主要结论
- 优于同等规模的开源 MLLM
- 优于 SFT baseline
- 泛化能力更强
与其他工作的对比
- vs UI2CodeN: RRVF 不需要任何文本监督，UI2CodeN 仍需 SFT 预训练阶段
- vs Visual-SDPO: RRVF 使用全局视觉奖励，Visual-SDPO 做细粒度代码归因
- vs MSRL: 二者都用 GRPO，但 RRVF 针对通用场景 (chart+web)，MSRL 专注 chart
RVPO (偏好RL)
迭代视觉优化
渲染反馈
核心创新 — Relative Visual Policy Optimization (RVPO): 不对渲染结果打绝对分，而是对多个候选渲染结果做相对排序。这解决了视觉评估器噪声大的问题，提供更可靠的 RL 训练信号。
将 UI-to-code 从单次生成重新定义为闭环迭代优化问题。模型生成 → 渲染 → 视觉检查 → 基于反馈修改，与真实UI开发流程对齐。训练管线包含三阶段：持续预训练、SFT、RVPO。9B 参数的开源模型在 drafting/polishing/editing 三个任务上超越更大模型。
方法详情 & 实验结果
核心问题
- 大多数方法将 UI-to-code 视为 single-pass generation，与真实开发流程（本质上是迭代的）不匹配
- 视觉目标不可微分，且绝对评分噪声大
RVPO 方法
- 对同一输入生成多个候选代码
- 渲染所有候选，得到多个视觉输出
- 对视觉输出做相对排序而非绝对评分
- 用相对偏好信号做 preference-based RL
三阶段训练
- Stage 1 — Continual Pre-training: 扩展视觉理解能力
- Stage 2 — SFT: 监督微调建立基础能力
- Stage 3 — RVPO: 偏好 RL 持续优化
评测结果
- 9B 模型在 UI drafting、polishing、editing benchmarks 上达到 SOTA
- 超越更大参数量的模型
- 通过迭代视觉优化持续提升性能
关键对比：绝对评分 vs 相对排序
| 维度 | 绝对评分 | 相对排序 (RVPO) |
|---|
| 噪声敏感性 | 高 — 评估器对单一样本打分不稳定 | 低 — 同一评估器比较多个候选更一致 |
| 标定难度 | 需要校准评分尺度 | 只需判断好坏顺序 |
| 信号质量 | 噪声可能误导 RL | 相对信号更鲁棒 |
| 计算开销 | 每个样本独立评分 | 需要生成多个候选并排序 |
浏览器交互评估
多视口/多状态
SFT 数据生成
核心创新 — 超越静态截图: LLM 生成的 HTML "render once, then fail under scroll, hover, click, resize, or gameplay"。HTMLCure 通过浏览器执行页面在多个视口和交互状态下的完整轨迹，记录确定性 browser evidence，并用 VLM 分析关键帧而非孤立截图。
HTMLCure 是一个 browser experience 框架：(1) 在多种视口和交互状态下执行页面并录制轨迹；(2) 用 state-guided repair engine 诊断问题、选择修复策略、验证修复结果；(3) 将通过质量检查的页面导出为 SFT 数据。从 97K prompt corpus 出发，最终产出 40K refined SFT 数据集。
方法详情 & 实验结果
Browser Evaluation 流程
- 跨多种视口 (desktop, tablet, mobile) 执行页面
- 记录多种交互状态 (scroll, hover, click, resize, gameplay)
- 收集确定性 browser evidence（非概率性判断）
- 给 VLM 提供 curated keyframes（精选关键帧）而非孤立截图
State-Guided Repair Engine
- Diagnose: 分析失败状态
- Select repair family: 根据失败类型选择修复策略
- Rerun: 验证修复候选
- Export: 通过测试的页面导出为训练数据
数据规模
- Seed data → 63,703 quality-cleared pages
- 97K prompt corpus → 40K refined SFT dataset
实验结果
- HTMLBench-400: HTMLCure-27B-Refined 得分 50.6, deterministic test pass 45.2%
- 可比 Kimi-K2.6 和 GPT-5.4 等强基线
- MiniAppBench: 平均 81.2, 比原始 27B SFT 提升 15.3 分
关键区别：静态截图 vs Browser Trace
| 维度 | 传统静态截图 | HTMLCure Browser Trace |
|---|
| 覆盖范围 | 仅初始渲染状态 | scroll, hover, click, resize, gameplay |
| 视口 | 通常单一视口 | 多视口 (desktop/tablet/mobile) |
| 交互问题 | 无法发现 | 可检测交互后的 bug |
| 证据类型 | 像素比较 | 确定性 browser evidence |
| VLM 输入 | 孤立截图 | Curated keyframes from trajectory |
| 修复能力 | 通用反馈 | State-specific repair families |
arXiv:2606.10334
2026.06
GRPO + 自蒸馏
视觉缺陷归因
Chart + Web + Slides
核心创新 — Visual-Grounded Code Credit Weighting: 将检测到的视觉缺陷（重叠元素、裁剪文字、对齐破坏、低对比度、溢出等）追溯到导致该缺陷的具体代码语句，并在蒸馏时对这些语句增大学习信号。这使得监督变得空间定向而非均匀分布。
Visual-SDPO 是一个 self-distillation policy optimization 框架：权重共享的 teacher 接收渲染后的视觉反馈作为 privileged context，将知识蒸馏给 coding student。关键在于 credit weighting — 找到"谁的代码导致了视觉 bug"。基于 Qwen3-VL-8B，在 ChartMimic、Design2Code、AeSlides 上均超过 zero-shot base 10+ 分。
方法详情 & 实验结果
Self-Distillation 框架
- Teacher: 接收 rendered visual feedback 作为 privileged context
- Student: 仅接收原始输入（无渲染反馈）
- Teacher 和 Student 共享权重 (self-distillation)
- 训练时 teacher 有"上帝视角"（可以看到渲染结果和缺陷），推理时无额外开销
Visual-Grounded Code Credit Weighting
- 检测渲染输出中的视觉缺陷
- 将缺陷追溯到对应的代码 elements
- 映射 element → 代码语句
- 对这些语句增大 distillation signal
- 结果: 空间定向 (spatially targeted) vs 均匀监督
互补目标
- Sequence-level GRPO: 奖励可执行、高质量的 rollouts
- 失败样本也可学: 将 execution errors 作为 privileged context 传给 teacher
实验 (backbone: Qwen3-VL-8B-Instruct)
- ChartMimic: +10 abs pts over zero-shot base
- Design2Code: +10 abs pts over zero-shot base
- AeSlides: +10 abs pts over zero-shot base
- Over GRPO: +2.4 pts, 训练步数更少，推理无额外开销
缺陷归因的技术路径
检测到的视觉缺陷类型
- Overlapping elements (重叠元素)
- Clipped text (文字裁剪)
- Broken alignment (对齐破坏)
- Low contrast (低对比度)
- Overflow (溢出)
归因流程
Visual defect → Affected DOM element → Responsible code statement → Amplified training signal
为什么重要
传统 RL/RLHF 的 reward 是 sequence-level 的，模型需要自行学习"哪句代码该改"。Visual-SDPO 直接告诉模型问题出在哪，显著加速收敛。
arXiv:2604.18224
2026.04
评测基准
浏览器 Agent
多模态 (Text/Image/Video)
核心创新 — Agent-as-a-Judge: 不依赖人工测试用例，而是让 Agent 自主在真实浏览器中执行生成的网站，通过 MCP (Model Context Protocol) 探索交互行为，迭代合成有针对性的测试用例，近似人类验收测试。
WebCompass 是覆盖 Web 工程全生命周期 (generation, editing, repair) 的多模态评测基准。输入支持 text/image/video 三种模态，评测引入 Agent-as-a-Judge 范式自动探索和生成测试。关键发现：aesthetics 是最持久的瓶颈（尤其开源模型），Vue 持续具有挑战性。
方法详情 & 实验发现
评测设计
- 3 种输入模态: Text, Image, Video
- 3 种任务类型: Generation, Editing, Repair
- 7 种任务组合
- 难度分级: Easy / Medium / Hard
- 覆盖 15 种生成域、16 种编辑操作、11 种修复缺陷类型
Agent-as-a-Judge (Generation 任务)
- 在真实浏览器中自动执行生成的网站
- 通过 MCP 协议探索交互行为
- 迭代合成有针对性的测试用例
- 近似人类验收测试流程
Checklist-Guided LLM-as-Judge (Editing/Repair 任务)
- 根据 checklist 逐项验证编辑/修复是否正确
Human-in-the-Loop Curation
关键发现
- 闭源模型仍然更强
- Aesthetics 是最持久的瓶颈，尤其对开源模型
- Vue 框架持续具有挑战性
- React 和 Vanilla HTML 表现因任务类型而异
Agent-as-a-Judge vs 传统评测
| 维度 | 传统评测 (像素比较/人工用例) | Agent-as-a-Judge |
|---|
| 测试用例来源 | 人工编写/预定义 | Agent 自动合成 |
| 交互覆盖 | 有限预定义场景 | 自主探索发现 |
| 扩展性 | 人工成本随规模线性增长 | 自动扩展 |
| 漏检风险 | 只能检查已知问题 | 可发现未预见的交互 bug |
| 与人类对齐 | 取决于用例设计者 | 模拟人类验收测试 |
arXiv:2508.13587
ICLR 2026
多粒度 Reward
文本+视觉反馈
Chart 专用
核心贡献 — 多粒度奖励系统 + 课程训练: Rule-based textual rewards 验证代码细节 + Model-based visual rewards 评估渲染结构相似度。通过两阶段课程训练（先 text-based, 后 vision-based）突破 SFT 性能瓶颈。
MSRL 系统性地揭示了 Chart-to-code 任务中 SFT 的性能天花板，并通过多模态结构化 RL 突破。3M chart-code pairs (来自 arXiv 真实数据)，多粒度奖励（文本 + 视觉），课程式训练。ChartMimic +6.2%，ReachQA +9.9%，超越所有现有方法。
方法详情 & 实验结果
数据集
- 3M chart-code pairs — 来自 arXiv 论文中的真实 tables
- 解决合成数据集的 diversity 局限
- 当前 chart 领域最大训练语料
多粒度奖励系统
- Textual-level (rule-based): 验证代码细节（语法、结构完整性等）
- Visual-level (model-based): 渲染结果与 ground-truth chart 的结构相似度
课程训练策略
- Stage 1: 仅用 textual rewards 优化（建立代码基本正确性）
- Stage 2: 引入 visual rewards（提升视觉保真度）
- 渐进式，避免 visual rewards 噪声在早期干扰训练
实验结果
- ChartMimic: high-level metrics +6.2%
- ReachQA: +9.9%
- 超越所有现有 chart-to-code 方法
- 与 advanced closed-source models 竞争力相当
arXiv:2505.20793
2025.05
渲染反馈 RL
SVG
视觉保真度
核心问题 — 训练时从不观察渲染结果: 现有 VLM 方法生成 SVG 时从未在训练中看到渲染后的图像。RLRF 用渲染反馈弥合这一 gap：生成 SVG → 渲染 → 与原图比较 → 计算奖励 → RL 优化。
RLRF 将 SVG 生成建模为 VLM 的代码生成任务，通过渲染反馈的 RL 来优化。由于 autoregressive SVG 代码的可微分渲染器尚不可用，RLRF 使用 evaluative feedback（奖励信号）而非梯度反向传播。显著优于 SFT，生成更精确、高效、语义连贯的 SVG。
方法详情
方法流程
- 输入: 目标图像
- 生成: VLM 自回归生成 SVG 代码 (roll-outs)
- 渲染: SVG → 图像
- 奖励计算: 渲染图 vs 原始图像的视觉保真度
- RL 优化: 用奖励信号优化生成策略
为什么需要 RL 而非梯度
- Autoregressive SVG code generation 是离散的
- Differentiable rendering for autoregressive SVG 尚不可用
- RL 通过 evaluative feedback 绕过不可微问题
改善的问题
- 解决 SFT 的 common failure modes
- 更精确 (precise) 的 SVG
- 更高效 (efficient) — 更少的 path elements
- 更好的结构理解 (structural understanding)
- 更强泛化 (generalization)
| 论文 |
RL 算法 |
反馈来源 |
粒度 |
应用领域 |
是否需要 text 监督 |
关键区别 |
| RRVF |
GRPO |
视觉对比 |
Sequence-level |
Chart + Web |
否 (纯图像) |
验证非对称性原理 |
| UI2CodeN |
RVPO (偏好RL) |
相对视觉排序 |
Candidate-level |
UI (通用) |
是 (SFT 阶段) |
相对排序替代绝对评分 |
| HTMLCure |
无 RL (SFT) |
Browser trace |
State-level |
Interactive HTML |
是 |
多视口多交互状态 |
| Visual-SDPO |
GRPO + Self-Distill |
视觉缺陷归因 |
Statement-level |
Chart + Web + Slides |
是 (base model) |
缺陷→代码语句归因 |
| WebCompass |
无 (Benchmark) |
Agent 自动探索 |
Test-case-level |
Full Web lifecycle |
N/A |
Agent-as-a-Judge |
| MSRL |
多粒度 RL |
Text + Visual |
Multi-granularity |
Chart |
是 (SFT 阶段) |
课程训练策略 |
| RLRF |
RL (rendering feedback) |
渲染对比 |
Sequence-level |
SVG |
是 (SFT 阶段) |
SVG 专用，不可微绕路 |
尚未被覆盖的研究空白 / 潜在机会
- 交互性 + RL 的结合: HTMLCure 做了 browser trace 但只用于 SFT 数据生成，尚未将交互状态反馈直接嵌入 RL 训练循环
- 细粒度归因 + 浏览器交互: Visual-SDPO 的归因在静态渲染上，未考虑交互状态下的缺陷归因
- Agent 自动测试 → RL reward: WebCompass 的 Agent-as-Judge 可作为更丰富的 reward signal，目前仅用于评测
- Diff-guided 修改: 现有工作多为"重新生成"范式，少有基于 diff 的精准修改（只改错误部分）
- 跨模态一致性: 多数工作关注视觉保真度，较少关注代码质量（可维护性、语义性、accessibility）
- 长程交互的 reward 稀疏问题: 复杂页面可能需要多步交互才能暴露 bug，如何设计 dense reward？
- 真实场景的 responsive 设计: 仅 HTMLCure 考虑了多视口，其他工作基本在单一分辨率评估
对我们项目的启示
1. 超越静态截图对比: 至少需要考虑多视口 (HTMLCure) 或交互状态，单一截图评估不够全面。
2. Diff-guided 是差异化方向: 现有工作几乎都是"全量重新生成"，基于 diff 的精准修改是我们可以占据的独特位置。
3. 归因机制有价值: Visual-SDPO 证明了缺陷→代码归因能加速训练，这与 diff-guided 修改高度契合。
4. Agent 循环可整合更多信号: 结合 WebCompass 的 Agent 探索 + HTMLCure 的 browser trace + Visual-SDPO 的归因，形成更完整的反馈闭环。