摘要：在软件工程界，自动化修复 bug 一直是个“老大难”的话题。尤其是那些带有截图的视觉问题，更是让现有的修复系统抓耳挠腮。因为你根本无法指望一个只看文本的模型，去理解图片里按钮错位、图表异常这些“肉眼可见”的问题。

在软件工程界，自动化修复 bug 一直是个“老大难”的话题。尤其是那些带有截图的视觉问题，更是让现有的修复系统抓耳挠腮。因为你根本无法指望一个只看文本的模型，去理解图片里按钮错位、图表异常这些“肉眼可见”的问题。

但最近，一支来自慕尼黑工业大学的研究团队，靠着一项叫 GUIRepair 的新方案，成功登顶了 SWE-bench Multimodal（SWE-bench M）排行榜第一。这一成绩，不只是技术上的突破，更意味着自动修复视觉软件问题，正在从“没人管”走向“能解决”。

为什么视觉问题这么难修？因为看不见就修不好

传统的自动程序修复（APR）系统，解决的是纯文字 + 源代码的 bug，比如某个函数报错、某段逻辑有漏洞。你给模型一段 issue 报告，它从代码里“找病灶”然后“开药方”。这类修复，在 SWE-bench 等基准测试中已经表现不错。

但问题来了：现实开发中，尤其是前端工程和 GUI 应用，截图才是 bug 的主战场。比如：

这些问题，别说模型，就连人类开发者如果只看文字都很难定位。截图常常才是“最直接的线索”。

然而，现有 APR 系统几乎都不看图，而 GUI Testing 社区虽然研究 UI 错误的发现，也不管修复。两边像是“鸡同鸭讲”，中间隔着一条鸿沟。

GUIRepair 的出现，就是为了解这个“看得见却修不了”的难题。

GUIRepair：把“图”翻译成“代码”，再把“代码”翻译回“图”

GUIRepair 的核心理念一句话总结：Seeing is Fixing（看见，才能修好）。

它不是简单让语言模型“看看图”，而是搭建了两个关键组件，完成图像和代码之间的双向桥接：

用户上传截图，模型分析图里异常 UI 元素，比如按钮错位、图表缺失。然后，它不是直接修，而是还原出导致该视觉异常的相关代码。也就是说：

“看到这个问题，是不是某段样式代码写错了？”

这样，模型就有了修复所需的上下文。

模型修改完代码后，并不急着提交，而是先把修改后的代码“跑一遍”，生成新截图。再通过图像比对，看视觉问题是否真的消失。就像一个开发者修完 bug 会打开网页看看变化一样：

“修了这段代码，页面是不是终于正常了？”

这两个模块相辅相成，形成了跨模态的闭环修复流程：
从图像理解问题 → 从代码验证修复效果。

修了多少？效率如何？GUIRepair 实验成绩一览

GUIRepair 在 SWE-bench Multimodal 基准上进行了全面测试。这个基准数据集来自真实开源项目（如 bpmn-js、openlayers 等），包含 517 个多模态 issue 实例，都带截图 + 代码 + 文字描述，难度非常高。

这意味着，GUIRepair 不只是“能修”，而且修得比谁都好。

意义不止于“第一名”，而是打开了一个新世界

GUIRepair 的价值，绝不仅仅是排行榜上的第一。

过去十年，APR 社区一直专注于文本 + 代码的修复；GUI Testing 社区一直专注于发现视觉 bug；而 GUIRepair 第一次把这两件事连了起来：

这不仅提升了修复准确率，也拓宽了自动化软件工程的边界。

正如论文标题所说：“Seeing is Fixing”。
当模型能“看懂”问题，它就有可能“改对”问题。

被忽视的视觉 bug，如今终于有人在修了

大多数前端开发者都经历过被截图 bug 折磨的时刻：
按钮位置不对、页面样式乱套、图表显示异常……
这些问题曾是自动修复系统的盲区。

GUIRepair 的出现，正在悄悄改写这段历史。

它让我们看到 —— 自动化程序修复，不再只是文本的游戏；
它也提醒我们 —— 在多模态的世界里，修复，必须从“看懂”开始。

或许这只是一个起点，但这条路，值得所有软件工程研究者和实践者继续走下去。

来源：亓钦