截图变代码：AI 修 UI 时为什么越修越乱

你有没有遇到过这种情况：家里水管漏了一个小地方，找人来修，结果修完之后发现另一头的开关坏了，或者墙上多了道裂缝。

明明只是想解决一个问题，结果引出了新问题。这种"拆东墙补西墙"的现象，最近被一群研究者在一个完全不同的领域里撞见了，那就是让 AI 看着一张网页截图，自动生成能还原这张截图的代码。

这件事听起来挺简单的，给 AI 一张图，让它写 HTML 和 CSS，渲染出来跟原图一样不就行了。问题是，AI 第一次写出来的代码往往有各种小毛病，某个按钮位置偏了，某段文字大小不对，某个区域的颜色不对。既然发现了问题，那就让 AI 自己看着渲染结果和目标图片的差异，自己改一改，一轮一轮迭代总能越改越好吧？

结果恰恰相反。

有研究者做了个实验，让 GPT-5.2 和 GPT-5.4 这两个模型自己迭代修改代码，改了 15 轮。你猜怎么着，在一个叫 Design2Code 的测试集上，GPT-5.2 全部 15 轮的结果都比第一次生成的还差，最后一轮的分数比起点低了 2.73 分。GPT-5.4 稍微好一点，第一轮涨了 0.76 分，但后面 10 轮里有 10 轮都掉到了起点以下。

这就有点反直觉了。我们一般会觉得，AI 有反馈、能看到错误、能针对性修改，怎么会越改越差？这正是这篇论文想搞清楚的事。

修复的连锁反应：为什么改一个地方会牵动全局

先说说这个问题的根源在哪。

普通的文字生成任务里，你改一句话，改动的就是那句话本身，影响范围很清楚。但网页代码不一样。

如果你去调整一个 CSS 规则，比如改了某个容器的宽度，这个改动很可能顺着页面的布局结构，牵连出一连串你没预料到的变化。父容器变了，子元素的排列跟着变；一个 flex 布局的比例调整了，旁边完全没碰过的元素也可能被挤到别的地方去。

论文把这个现象叫做视觉修复耦合*：视觉修复耦合是指，代码里一个局部的编辑，可能会通过布局、样式、组件之间的依赖关系，在渲染出来的画面上引发大范围、非局部的变化。

这就好比你在家里重新布置家具，想把沙发挪到窗边空出过道，结果沙发一挪，茶几没地方放了，只好把茶几塞到电视柜前面，电视柜又得往旁边挪，最后整个客厅的动线全变了。你原本只想解决"过道太窄"这一个问题，但因为家具之间存在空间上的相互制约，一动就是全局连锁反应。如果你不考虑这种连锁效应，直接按下逐个修复的念头去挪东西，很可能挪到最后客厅比原来还乱，这正是论文里展示的那张图（图1）里发生的事：AI 想把左上角的灰色条归位到正确的容器里，结果顺带把整个页面的缩放比例和灰条长度都改乱了，还连累了左下角容器的背景色。

论文里给出了具体数字支撑这个现象。他们统计了模型在两个基准测试上的迭代轨迹，发现无论是 GPT-5.2 还是 GPT-5.4，早期的改进都很小、很短暂，越往后修复带来的破坏就越明显，最终整体质量甚至跌破了最初生成的水平。

问题的关键不在于 AI 看不到错误，AI 其实能看出画面哪里不对。问题在于，一旦它决定要修一个地方，这个修复动作本身没有边界，容易牵一发动全身，把原本正确的区域也带偏了。

如果反馈本身缺乏结构：自由文本批评的局限

那有人可能会说，那让 AI 自己写一段批评意见，告诉自己哪里错了，这不就是反馈吗？

问题是，普通的自由文本反馈只回答了"哪里错了"这一半的问题，却没有回答另一半更重要的问题，那就是"改的时候不要碰哪里"。

这就好比你请了个装修师傅来修一处漏水，你只告诉他"这里漏水了，帮我修一下"，师傅可能会为了修这个漏水点，把周围一整片墙都敲开重新做防水。如果你事先划定"只修这个点，其他地方别动"，师傅的施工范围就会被限制住，不会节外生枝。自由文本反馈就像是那个只说了"这里漏水"却没有划定施工范围的委托，AI 拿到反馈后，往往会做出比预期更大幅度的改动，因为没有人告诉它这次只该改多大范围。

论文认为，真正有效的测试时反馈机制，得同时管住两件事：该改什么，和该保留什么。这需要一种结构化的、局部化的、并且能跨轮次持续存在的反馈形式，而不是每次都从零开始的、笼统的批评。

带着清单去修复：RubSE 的核心思路

基于上面这个洞察，研究者提出了一个叫 RubSE 的框架，全称是 Rubric-guided Self-Evolution，翻译过来大概是"评分标准引导的自我迭代"。

这个名字里的 Rubric* 是核心概念，Rubric 原本是教育评估里常用的评分细则，一份评分标准会把一个宽泛的评价目标拆解成一条条具体、可打勾的检查项。RubSE 把这个概念挪用到了 AI 修代码这件事上。

具体来说，RubSE 让 AI 每一轮不再是笼统地说"这个页面哪里不对"，而是生成一批结构化的"修复条目"，每一条都包含三样东西：一个标题，一个类型标签，一段具体描述"当前哪里不对，应该怎么改"。

这里有五种预设的类型标签，分别对应布局几何、间距密度、排版文字、视觉样式、完整性这五个维度，用来防止 AI 的注意力老是被最显眼的那个错误（比如一块特别刺眼的颜色）吸走，而忽略了其他同样重要但不那么抢眼的问题。

有了这批候选条目之后，RubSE 不会让 AI 一次性把它们全改了，而是设计了一套三步走的循环，分别叫 EVOLVE（生成）、SELECT（挑选）、HISTORY（记录）。

EVOLVE 这一步的任务是，看着目标截图、上一轮的代码和渲染结果，生成一批候选的修复条目。如果之前已经有历史记录了，EVOLVE 会被明确告知"这些问题已经处理过了，别再重复提"，这样能避免同一个问题被翻来覆去地提。

SELECT 这一步则是从这批候选条目里，挑出最优先、最值得这一轮去修的一条。这一步很关键，因为如果不做筛选，让 AI 一口气把所有问题都改了，等于又回到了"施工范围没有边界"的老路上，前面提到的连锁反应风险又会冒出来。

HISTORY 这一步，是把这一轮选中的那条修复条目存进历史记录里，供下一轮的 EVOLVE 参考，避免重复。

这三步合起来，就像是一个有经验的项目经理在管理一次连续多天的装修工程：每天早上先巡视一遍，列出今天能看到的所有问题清单（EVOLVE），从清单里挑一个今天最该优先处理、又不会牵连太广的活儿（SELECT），干完之后记在工作日志上（HISTORY），第二天巡视的时候就不会再把同一个问题重新列一遍。如果没有这个工作日志，工人可能今天修了东墙，明天又跑去重新审视东墙有没有修好，反而没空去看真正还没解决的西墙问题。这套机制保证了修复是有记忆、有优先级、有边界的，而不是每天都从头开始漫无目的地巡视。

论文里配了一张流程图（图3），演示了一个具体的例子：面对一个 Cookie 弹窗大小位置不对的问题，EVOLVE 阶段生成了好几条候选，包括顶部导航对齐、专辑封面比例、标题排版等等，SELECT 阶段挑出了"Cookie 弹窗尺寸与位置"这一条作为本轮最优先要修的目标，随后 AI 就针对性地调整弹窗的宽高和定位方式，改完之后把这条记录存进历史里。

实验结果：稳，而且能修得更深

研究者在 6 个视觉语言模型（包括 GPT-5.4、GPT-5.2、Claude-Sonnet-4.5，以及三个开源的 Qwen 系列模型）和 3 个 UI 转代码基准测试上做了大规模的对比实验。

先说结论，在 18 组模型和测试集的组合里，RubSE 在其中 15 组的第 10 轮迭代结果上，同时在综合评分和细分维度评分两个指标上都超过了普通的自我迭代方式，平均综合分数提升了 1.20 分，细分维度平均分提升了 0.11。如果看每条迭代轨迹里表现最好的那一轮，RubSE 在 14 组里都占优势，平均综合分提升了 1.13 分。

| 模型 | 方法 | UI2Code-Real 综合分 | Design2Code 综合分 | Design2Code-HARD 综合分 |

| GPT-5.4 | 直接生成 | 85.4 | 86.9 | 79.8 |

| GPT-5.4 | 普通自迭代（第10轮） | 85.6 | 85.8 | 78.0 |

| GPT-5.4 | RubSE（第10轮） | **87.9** | **87.8** | **80.3** |

| GPT-5.2 | 直接生成 | 81.6 | 86.4 | 82.7 |

| GPT-5.2 | 普通自迭代（第10轮） | 82.5 | 83.9 | 82.3 |

| GPT-5.2 | RubSE（第10轮） | **85.0** | **87.2** | **84.4** |

这张表只截取了两个代表性模型的部分数据，但趋势很明显：普通自迭代在 Design2Code 这个测试集上，第 10 轮的分数居然比直接生成还低（GPT-5.4 是 85.8 对 86.9，GPT-5.2 是 83.9 对 86.4），说明前面提到的那种越改越乱的现象在真实实验里是普遍存在的。而 RubSE 在同样的第 10 轮，分数不但没跌，反而比直接生成还要高。

论文还专门做了一个人工评估，找了 60 个样本，让人来盲评 RubSE 和普通自迭代谁的最终效果更好。结果显示，无论是 GPT-5.2 还是 GPT-5.4，人类评审都明显更偏向 RubSE 的输出，而且这个偏好在统计上是显著的（p 值小于 0.01）。这说明前面那些分数上的提升，不是评分模型自说自话，普通人也能看出差别。

有意思的是，在开源模型这边，情况稍微复杂一点。三个 Qwen 模型里有两个（Qwen3.5-9B 和 Qwen3.6-35B-A3B）非常稳定地从 RubSE 中受益，但 Qwen3-VL-32B-Instruct 出现了不一致的表现，在某些测试集上普通自迭代反而更好。这不是一个可以忽略的小瑕疵，论文对此专门做了追查，后面会讲到。

崩溃与恢复：一次修复失控之后，AI 还能爬回来吗

除了看最终分数，研究者还追踪了一个更细腻的指标，叫轨迹崩溃*和恢复率*。

轨迹崩溃指的是相邻两轮之间，综合评分骤降 8 分以上，同时细分维度评分骤降 0.35 以上，这种断崖式下跌。恢复率则是指，一旦发生了这种崩溃，后面的迭代能不能把状态拉回到崩溃之前的水平（允许 2 分以内、0.10 以内的误差）。

这就像是走钢丝的人突然踩空摔了一跤，重点不只是他有没有摔下去，还有他摔了之后能不能重新站起来接着走完剩下的路。

数据显示，在三个前沿闭源模型（GPT-5.4、GPT-5.2、Claude-Sonnet-4.5）上，RubSE 把平均崩溃率从 18.9% 降到了 12.8%，其中两个模型的恢复率也从平均 20.7% 提高到了 32.8%。也就是说，对这些能力更强的模型来说，RubSE 不仅让它们更少地"踩空"，一旦踩空了也更容易爬起来。

而在开源的 Qwen 模型上，效果没那么一致，平均崩溃率反而从 14.8% 微微升到了 18.1%，但平均恢复率从 23.5% 提升到了 30.2%。研究者进一步画出了"恢复需要几轮"的分布图，发现无论是开源还是闭源模型，用了 RubSE 之后，需要的恢复轮数普遍更集中在早期，也就是说即便出了问题，也能更快地被纠正回来。

强模型的经验，能不能喂给弱模型

这一部分的实验设计挺巧妙的。研究者想知道，如果让 GPT-5.4 这个最强的模型去生成和挑选修复条目，但让真正动手改代码的还是能力较弱的 Qwen 模型，会发生什么。

结果是，在 UI2Code-Real 这个测试集上，三个 Qwen 模型只要用上了 GPT-5.4 生成的修复条目，表现都比它们自己生成条目时更强、更稳定，尤其是在早期几轮的提升更明显。

研究者进一步分析了这两种条目在内容上的差异，发现了一个挺扎实的规律。Qwen 自己写的条目，往往更偏向具体的技术细节，直接点名某个 CSS 属性、某个像素值、某种颜色，统计下来，Qwen 生成的条目里有 70% 在 Design2Code 数据集上提到了具体的 CSS/HTML 名词，还有 35% 到 46% 会给出具体的数字或颜色值。而 GPT-5.4 生成的条目，更多是从整体结构和视觉关系的角度描述问题，比如页面布局、比例关系、层级关系，涉及全局结构的比例达到了 89% 到 91%，而且用词更倾向于给出明确的行动指令（占比 77% 到 82%）。

这就好比同样是找人来修车，一个新手技工告诉你"火花塞第三缸间隙不对，调到 0.8 毫米"，这个建议很精确，但视野局限在一个具体零件上；而一个经验丰富的老师傅会说"你这车怠速抖动是发动机悬置老化引起的整体共振，得从悬置系统入手"，这个判断站得更高，指向的是结构性的根源问题。如果只让新手技工自己诊断，他能修好眼前这个具体故障，但可能修一处漏一处；而如果能借用老师傅的诊断思路，即便动手拧螺丝的还是新手，方向也不会跑偏。这正是 GPT-5.4 生成的条目能帮到弱一些的 Qwen 模型的原因，它提供的不是零散的补丁建议，而是更接近问题本质的结构性诊断。

再回头看前面提到的 Qwen3-VL-32B-Instruct 表现不稳定的那个例外，研究者也顺藤摸瓜查出了原因。这个模型在自己生成候选条目的时候，明显偏爱"间距密度"这一类局部调整型的问题，而对"完整性"这类涉及缺失或多余组件的问题关注不足，SELECT 这一步也没能完全纠正这个偏差。换句话说，不是这个方法框架本身失效了，而是这个模型自身生成候选条目的能力有偏科，一旦换成用 GPT-5.4 生成的条目，这个模型的表现立刻就追上来了，明显超过了普通自迭代。这说明整套框架的效果，某种程度上依赖于负责出题的那个模型的诊断水平。

这套方法的代价：多花多少钱和多少时间

任何一个多一道工序的方法，都得回答一个现实问题，那就是值不值这个成本。

论文给出了具体的核算。用 GPT-5.4 跑闭源 API 的场景下，RubSE 因为每一轮要多打两次模型调用（生成候选、挑选目标），输入 token 用量涨到了普通自迭代的 3.16 倍，但因为这两次调用输出都比较短，输出 token 只涨了 1.21 倍，折算下来总费用是普通方式的 1.60 倍。

用开源的 Qwen3.5-9B 模型本地部署的场景下，情况就轻松多了，因为本地推理的耗时主要花在逐字生成那段长长的 HTML 代码上，而生成候选条目和挑选目标这两步产出的文本很短，几乎不怎么占用额外时间，实测下来每轮推理时间只比普通方式多了 2.5%。

这个成本核算挺实在的，闭源场景下多花六成的钱，换来的是更稳定、更少走弯路的迭代过程，而且很多时候即便你多跑几轮普通自迭代，也未必能追上 RubSE 少跑几轮达到的效果，算总账反而可能更省。开源场景下这笔账就更划算了，几乎没有额外负担却拿到了实打实的提升。

写在后面

这篇论文最让我意外的地方，不是 RubSE 这套方法本身多精巧，而是那个前置的发现：让 AI 自己看着错误反复修改，居然会把结果越改越差，而且是在 GPT-5.4 这种顶尖模型上也会发生。

这个结论其实是在提醒我们，"给 AI 反馈让它自我改进"这件事，听起来天经地义，但反馈的质量和结构远比我们想象中重要。一个没有边界的批评，可能比不给反馈还糟糕，因为它会诱导模型去做过度修改。这种现象恐怕不只存在于网页代码生成里，任何一个各部分之间存在耦合关系的复杂产出物，比如一段结构化的长文章、一个多模块的软件系统，可能都会遇到类似的"修一处坏一处"的陷阱。

另外一个让我觉得挺有意思的细节是，强模型生成的修复建议能有效迁移给弱模型使用，而且迁移之后的效果差异，根源在于建议本身的抽象层级不同。这让我想到，人类专家的经验传承，某种程度上也是这样，真正值钱的往往不是具体的操作步骤，而是那种能看到问题本质、给出结构性诊断的判断力。

论文里没有解决的一个问题是，如果换成规模更大、结构更复杂的真实网站，或者换成除了网页之外的其他代码生成场景，这套评分条目式的框架还能不能保持同样的稳定性，这大概是留给后续研究的一道题。

Q&A

Q1：RubSE 是什么？

A：RubSE 是一种让 AI 生成网页代码时自我修改和迭代的框架，核心做法是用结构化的"评分条目"（rubric）来指导每一轮修改，而不是让 AI 凭自由文本批评随意大改，从而避免改一处坏一处的连锁问题。

Q2：为什么 AI 自己迭代改代码反而会越改越差？

A：因为网页代码存在视觉修复耦合现象，改动一处 CSS 或布局，很可能通过依赖关系牵连出画面上其他区域的意外变化，实验显示某些模型连续迭代 15 轮后，效果甚至比第一次生成还差。

Q3：强模型生成的修复建议真的能帮到能力较弱的模型吗？

A：能。实验发现让 GPT-5.4 生成修复建议、交给能力较弱的 Qwen 模型去实际修改代码，效果比 Qwen 自己生成建议时更好更稳定，原因是强模型给出的建议更偏向结构性问题，而弱模型自己的建议往往局限在具体的 CSS 细节上。