视觉反馈 / 视觉验证
按应用场景组织 · 迭代积累而非 related work这里整理我们迭代中读到的、用“渲染 → 看 → 反馈 → 改”这套思路的论文工作，按它们被用在哪些应用 / 产物上来组织（web/UI、chart、矢量图、文档/幻灯、交互状态），而不是做一份 related-work 综述。原因：我们关心的“多模态验证作为 loop 级能力”比这些工作更前沿——它们大多是具体任务上的训练 / 评测方法，技术上看似相邻，但出发点和目标不同。每张卡片保留一句核心洞察、可展开细节，以及和我们的不同。
| 应用 / 产物 | 代表工作 | 它们在验证这一环做了什么 |
|---|---|---|
| Web / UI 代码 | RRVF · UI2Code^N · WebCompass | 渲染截图 vs 目标做奖励 / 相对排序 / Agent 自动探索测试 |
| Chart / 数据图 | RRVF · MSRL · Visual-SDPO | 渲染图的结构相似度、多粒度（文本+视觉）奖励、缺陷归因到语句 |
| 矢量图 SVG | RLRF | 用渲染反馈绕开不可微，提升视觉保真 |
| 文档 / 幻灯 / PDF | PaperFit · Visual-SDPO（AeSlides） | PDF/幻灯页面渲染后的视觉缺陷诊断、源码修复、再渲染验收 |
| 交互 / 浏览器状态 | HTMLCure · WebCompass | 多视口多交互状态 browser trace、关键帧、Agent-as-a-Judge |
Web / UI 代码
闭环：Reasoning → Rendering → Visual Feedback（与源图像比较得奖励），GRPO 端到端优化，支持多轮自我修正；最终甚至超越提供反馈的更强 MLLM。覆盖 chart-to-code 与 web screenshot-to-code。
方法详情 & 和我们的不同
方法
- 奖励仅来自视觉比较，摆脱 image-text paired supervision
- GRPO；多轮 self-correction
和我们的不同
- RRVF 把视觉反馈做成训练信号服务 image-to-code；我们把验证当作 loop 级通用能力，image-to-code 只是代表性 instance
- 我们更关注 verifier 的位置、可替换性、false-accept 风险与 actionable feedback，而非训练出一个更强生成器
把 UI-to-code 从单次生成重定义为闭环迭代（生成→渲染→视觉检查→改）；三阶段训练（持续预训练 / SFT / RVPO）；9B 开源模型在 drafting/polishing/editing 超越更大模型。
方法详情 & 和我们的不同
RVPO
- 同一输入多候选并渲染，对视觉输出相对排序而非绝对评分
和我们的不同
- 它的“视觉检查”内嵌在 RL 训练里；我们关心验证作为 loop 组件、可被多种 backend（MLLM / subagent / 确定性工具）承担
- “相对排序更鲁棒”对我们设计 verifier 输出（pass/score/evidence）有借鉴价值
覆盖 Web 工程全生命周期（生成/编辑/修复）的多模态评测，输入支持 text/image/video。关键发现：aesthetics 是最持久瓶颈（尤其开源模型），Vue 持续具挑战。
方法详情 & 和我们的不同
和我们的不同
- WebCompass 是评测基准，Agent-as-Judge 仅用于打分；我们想把这种“Agent 探索 + 验证”作为 loop 内可指导下一轮 revision 的反馈源
- 它的“在真实浏览器里自动合成测试”非常贴合我们的 state-consistency / trajectory 场景族
Chart / 数据图
3M chart-code pairs（来自 arXiv 真实数据），ChartMimic +6.2%、ReachQA +9.9%。
方法详情 & 和我们的不同
和我们的不同
- MSRL 的“多粒度”是奖励设计；我们把它读作一个提示：验证应同时用文本/结构证据与视觉证据，对应我们 multimodal unit tests 的不同 check 类型
权重共享 teacher 接收渲染后视觉反馈作 privileged context，蒸馏给 student；基于 Qwen3-VL-8B，在 ChartMimic/Design2Code/AeSlides 超 zero-shot 10+ 分，推理无额外开销。
方法详情 & 和我们的不同
归因流程
- Visual defect → 受影响 DOM element → 责任代码语句 → 放大信号
和我们的不同
- 它把“缺陷→代码”用于训练蒸馏；我们把缺陷定位作为 verifier 的 actionable / localizable feedback 直接喂回下一轮 revision——同一机制，不同用途
矢量图 SVG
SVG 生成建模为 VLM 代码生成，因 autoregressive SVG 可微渲染器不可用，改用 evaluative feedback（奖励）而非梯度，显著优于 SFT。
和我们的不同
- RLRF 证明“渲染后才看得见的错误”必须靠渲染反馈才能抓——这正是我们主张“execution feedback 不够、需要 multimodal verification”的一个具体例证
文档 / 幻灯 / PDF
对我们来说，PaperFit 是一个具体应用而不是最终边界：它证明 multimodal verification 可以帮助 agent 在既有 LaTeX 项目上继续推进，而不是从零生成或单纯复刻。详细 survey 笔记：paperfit-2026-vision-in-the-loop-typesetting.md。
方法详情 & 和我们的不同
方法
- 融合源码、编译日志、PDF 元信息和页面图像，形成结构化缺陷记录
- 用受约束修复策略保护学术内容，避免伪修复
- 每次编辑后重新编译、渲染和检查，捕捉非局部排版连锁影响
和我们的不同
- PaperFit 专注 scientific document typesetting；我们想把这种 loop 抽象成 coding agent 的通用 multimodal verification 能力
- 它给了我们一个很好的 existing-system continuation 样例：从已有系统出发，用 rendered observation 指导下一步源代码修改
交互 / 浏览器状态
多视口多交互状态执行并录制轨迹 → state-guided repair engine 诊断/选策略/验证 → 通过质检的页面导出为 SFT 数据（97K→40K）。
方法详情 & 和我们的不同
Browser Evaluation
- desktop/tablet/mobile，scroll/hover/click/resize/gameplay；给 VLM curated keyframes
和我们的不同
- HTMLCure 的 browser trace 仅用于生成 SFT 数据；我们想把这种交互状态证据作为 verifier 在 loop 内的输入（对应 state-consistency 场景族），且不局限于训练
- “单一截图不够、要多视口多状态”直接支撑我们的 evidence-aware 原则
从这些工作沉淀给我们的设计点
1. 渲染后才暴露的错误是真问题：RLRF / HTMLCure 共同说明 execution feedback 覆盖不到的视觉错误必须靠“看”才能抓——这是我们 thesis 的现成例证。
2. 缺陷定位 = 好反馈：Visual-SDPO 的“缺陷→代码语句”机制，对我们 verifier 的 actionable / localizable feedback 直接可借。
3. 相对判断比绝对打分稳：UI2Code^N 的 RVPO 提示我们 verifier 输出设计可引入相对/排序信号降噪。
4. Agent 探索可当反馈源：WebCompass 的 Agent-as-Judge 不必只用于评测，可作为 loop 内验证。
5. 我们的差异：这些都是具体任务的训练/评测；我们把 verification 抬成通用 loop 级能力，强调可替换 backend、false-accept 风险与可审计 oracle。