你有没有想过一个问题：写代码的人,到底是怎么知道代码写对了没有?
答案其实很朴素。他们会运行这个程序,点点按钮,看看效果,如果不对劲就回去改代码,改完再运行一遍看看。这个过程循环往复,直到屏幕上显示的东西和脑子里想的一样。
这件事听起来理所当然,但放到AI身上,却变成了一道没人真正解决过的难题。
现在的AI编程助手,比如大家熟悉的那些代码生成工具,它们确实很会写代码,改bug,跑测试。但这些工具基本上是"瞎子程序员"：它们能读代码、能执行命令、能看到报错信息,但它们从来不会真正打开一个运行起来的软件,用鼠标点一点,看看界面长什么样。
另一边,还有一类叫"电脑使用智能体"的AI,它们恰好相反。这类AI能看懂屏幕截图,能用鼠标键盘操作软件界面,像人一样点来点去,但它们通常不负责改代码。
计算机使用智能体:一种能够通过观察屏幕截图、使用鼠标和键盘来操作电脑软件的AI系统,类似人类用眼睛看界面、用手操作软件的方式。
这两类AI,一个是"只会敲代码不看界面的程序员",一个是"只会看界面点按钮但不懂代码的用户"。而真实世界里,写软件的人同时具备这两种能力,他们一边改代码一边运行软件查看效果,这两件事是拧在一起、不分先后的。
卡内基梅隆大学、南加州大学等几所高校的研究者们,就是盯上了这个空白。他们做了一个叫CUA-SWE的东西,试图把"改代码"和"用软件"这两件事,第一次真正捏合在同一个任务里,让AI既能读代码又能看屏幕,然后看看它们到底能不能像真正的程序员一样把活干好。
一个具体到有点好笑的例子
论文里举了个例子,我觉得特别能说明问题。
想象一个平台跳跃游戏,角色跳到一个平台上,结果直接穿模掉下去了。如果你只是打开截图看一眼,画面可能看起来完全正常,角色站得好好的。
但如果你真的去玩这个游戏,按下跳跃键,看着角色落地的瞬间,你才会发现:哦,原来角色落地那一刻其实是穿透了平台的,只是渲染的时候正好卡在了一个看起来正常的帧上。
这种bug,光看代码看不出来,光看一张静态截图也看不出来,必须得实际操作,观察动态过程,才能把这个现象和代码里负责碰撞检测的那部分逻辑对应起来。改完代码之后,还得再跳一次,再看一次落地瞬间,确认问题真的解决了,同时确认正常移动没有被改坏。
这就是整篇论文想说的核心矛盾:软件开发不是一个单向的"写代码然后交卷"的过程,而是一个"改代码,运行,观察,再改代码"的循环。AI要想真正胜任这个工作,就得具备在这个循环里穿梭的能力。
当年轻司机只会看说明书却从没摸过方向盘,你会放心让他上路吗?代码正确性的检验离不开实际运行观察,这跟开车离不开实际路感是一个道理。如果不让AI实际操作软件、只让它改代码交差,那它永远不知道自己改出来的东西在用户眼里到底是什么样子,这正是过去那些编程AI评测体系的盲区所在。
CUA-SWE到底长什么样
这套系统的核心,是给AI准备一个"既能改代码又能用软件"的环境,然后出题考它。
研究者设计了105个任务,横跨四个软件开发领域:网页开发、游戏开发、移动应用开发,以及运维(DevOps)。每个任务都包含一个可以编辑的代码仓库,还有一个真实运行着的软件,AI可以在这个软件里点来点去、截图观察。
每个任务还配了一套独立的、不受AI控制的"裁判程序",专门用来判断AI交上来的代码到底对不对。这个裁判会把AI改过的代码放到一个干净的环境里重新跑一遍,运行一系列预先设计好的交互测试,检查两件事:AI要求修复的功能是不是真修好了,原来能正常工作的功能有没有被改坏。
这个设计特别关键,因为它意味着AI不能靠"自己说自己修好了"来蒙混过关,必须拿出真正能跑通的代码。
为了做个对照实验,研究者设置了两种访问权限。第一种叫"纯代码模式",AI只能读代码、改文件、跑命令行,看不到任何图形界面的截图,也不能用鼠标点东西。第二种叫"混合CUA模式",在纯代码模式的基础上,额外给AI开放了截图观察和鼠标键盘操作的权限。
这两种模式面对的是完全相同的题目,唯一的区别就是能不能"睁眼看软件"。这就给研究者提供了一把尺子,可以精确衡量"看得见软件"这件事到底能给AI的工作表现带来多大差别。
四个考场里到底在考什么
网页开发那部分,题目涉及界面布局、元素选中、拖拽操作这些视觉相关的细节。比如一个图表在某种布局下显示不全,边缘被切掉了,AI得想办法把图表尺寸算对,让它刚好塞进容器里。
游戏开发那部分,考的是时序和物理状态,比如角色跳跃的力度、碰撞检测的精确时机、动画播放是否连贯。前面提到的那个穿模bug,就出自这个领域。
运维部分有点意思,它考的不是界面好不好看,而是AI能不能通过观察一个服务对外展示的状态,反推出背后该怎么配置。比如有个任务是关于"仪表盘数值更新方式"的,AI得通过主动发送信号、观察服务怎么响应,才能搞清楚这个服务到底是"每次累加"还是"每次覆盖"这两种工作模式里的哪一种,然后才能把代码写对。
移动应用部分,很多题目要求AI理解一张"导入进来的图纸"或者"收到的资料",再把这些视觉信息转换成代码逻辑。比如有个任务给了一张机械齿轮组的装配图,AI得看懂图上画的齿轮之间谁带动谁,然后在代码里把这种联动关系真正实现出来,还得保证用户能正常编辑角度、撤销操作、保存重新加载。
这四个领域的设计思路其实有一条共同的线索:不管是网页布局、游戏物理、服务状态,还是机械图纸,AI要解决的问题,其答案往往不写在代码注释里,而是"长"在那个正在运行的软件表现出来的样子里。你光读代码,读不出图纸上两个齿轮该怎么咬合,你得去看那张图。
任务的两种"出题方式"
研究者还给每道题打了个标签,区分任务信息到底藏在哪里。
一类叫"源码指定型",意思是题目要求和实现细节,光靠读代码和执行程序就能搞清楚,不一定非要用图形界面。另一类叫"依赖应用材料型",意思是任务里有些关键信息,只存在于那个运行中的软件界面或者外部资料里,代码本身不会告诉你答案。
源码指定型:题目的全部要求都能从文字说明和可读的源代码里找到,运行程序主要是用来验证和调试,而不是获取新信息。
依赖应用材料型:题目里有一部分必要信息,只能通过观察运行中的应用界面、或者查看导入的图纸资料等视觉材料才能获取,单看代码拿不到完整答案。
统计下来,105道题里有58道属于"依赖应用材料型",还有5道游戏类题目虽然信息来自代码里带的素材,但那些素材是以图片形式存在的,纯代码模式的AI根本看不到。这个标签体系很重要,因为它决定了后面实验结果该怎么解读:如果一个AI在"源码指定型"题目上开不开图形界面表现差不多,但在"依赖应用材料型"题目上开了图形界面后成绩暴涨,那就能很干净地说明,图形界面提供的的确是代码里没有的信息,而不只是锦上添花。
成绩单出来了,差距有点吓人
研究者找来了市面上能叫得上名字的几家顶尖AI模型,包括GPT系列、Claude系列和Grok系列的最新版本,一共九个模型,外加两套完整的编程助手工具(Codex和Claude Code),全部拉到这个考场里考一遍。
最亮眼的成绩属于一个叫GPT-6-Astra的模型。在开启图形界面权限的混合模式下,它在四个领域的平均任务成功率达到了59.9%,比排名第二的GPT-5.6-Sol高出将近18个百分点。而且它在每一个单独的领域里都拿到了最高分:网页66.7%,游戏37.9%,运维80%,移动55%。
但真正值得细品的,不是谁考得最高,而是"开没开图形界面"这件事本身带来的差距。
同一个模型,同一道题目,纯代码模式下只能拿到约11.3%的平均成功率,一旦打开图形界面,成绩直接飙到59.9%,整整多了48.6个百分点。这不是个例,而是几乎每个被测试的模型都呈现出的规律:Claude-Fable-5涨了29.1个百分点,Grok-4.6涨了31.7个百分点,就连表现相对较弱的GPT-5.6-Luna也涨了12.8个百分点。
这个数字意味着什么?意味着如果你只给AI一副"耳朵"(代码执行反馈),它基本上是在盲打,十道题里连两道都做不对。但只要给它一双"眼睛",让它能看见软件实际运行的样子,它立刻就能把成功率提升到五六成的水平。
这就像让一个厨师盲做菜一样。他能照着菜谱放调料、控制火候时间,但永远没法尝一口判断咸淡、看一眼判断火候是不是过了。即使每一步操作都严格照着流程来,最后端上桌的菜可能还是不对味,因为菜谱文字永远没法完整传达"色香味"这种只有亲身感知才能判断的信息。如果不让AI实际"尝一尝"软件运行的味道,它就只能凭空猜测自己改的代码到底效果如何。
把数据拆开看,差距出在哪
研究者没有满足于看总分,而是把那58道"依赖应用材料型"题目单独拎出来分析。
结果非常清晰:在"源码指定型"的题目上,打不打开图形界面,成绩几乎没有变化,网页领域甚至是0个百分点的差距。但在"依赖应用材料型"的题目上,打开图形界面能带来高达42到48个百分点的巨大提升,具体到网页领域是42个百分点,运维领域是48.1个百分点,移动领域是38.8个百分点。
这个对比特别有说服力,因为它排除了一种可能的质疑,也就是"是不是AI只要多一个工具就能表现更好,跟这个工具到底是不是图形界面没关系"。如果真是这样,那在源码指定型题目上也应该看到提升,但事实是没有。这就把功劳明确地归到了"看见软件的能力"本身,而不是"多了一个额外的工具"这种泛泛的解释。
研究者还细挖了一些具体案例。比如有一个关于网页嵌套选择的任务,GPT-6-Astra先修好了拖拽改变大小的bug,然后它没有就此停手,而是真的去试了试把图形元素拖出容器边界会发生什么。结果发现,拖出去之后选中状态丢失了,这是个之前没发现的新问题。它接着去改代码,扩大了"点击检测"的判断范围,再重新试一遍,确认两个问题都解决了才提交。
而对比组里的另一个模型,虽然也修好了拖拽改变大小的问题,但它没有像GPT-6-Astra那样主动去试边界情况,结果提交的代码里选中状态丢失这个bug根本没被发现,自然也没被修。
这个细节挺耐人寻味的。它说明"看得见软件"这件事,不只是帮AI完成某个具体步骤,更重要的是让它有机会"顺手"发现自己制造的新问题,这是纯代码模式完全没法提供的反馈闭环。好比你修好了家里漏水的水管,如果从不打开水龙头试一试,你永远不会知道修好的同时是不是把水压搞小了。
那些还没被攻克的难题
不过这篇论文也挺坦诚的,没有一味唱赞歌。
有几类任务,即使开着图形界面,所有测试过的AI都没能完全解决。比如一个叫"核心弹珠"的游戏任务,涉及多个弹珠挂件之间精确的碰撞时序和状态记忆,没有任何一个模型在单次尝试里完全通过。GPT-6-Astra修对了碰撞角度的计算逻辑,但在"等待中的射击动作该什么时候被提升为正式动作"、"碰撞被拒绝之后占用的位置要不要清空"这些细节上,还是栽了跟头。
移动端那9道关于甘特图(一种项目排期表)排班计划的题目,在单次尝试里全军覆没,无一通过。这些题目要求AI理解墙上挂着的手绘排期图里,每个工序之间复杂的先后依赖关系,然后在代码里精确还原出来。研究者仔细复查了GPT-6-Astra提交的某一份答案,发现它把工序的开始时间和持续时间基本摸对了,但在两条依赖关系的起止点和一个延迟量上出了错,导致整体排期图还是不对。有意思的是,它写的自测代码里也包含了同样的错误理解,说明它压根没意识到自己理解错了,而是一路错到底、测试代码也跟着一起错。
这暴露出一个有意思的现象:看得见界面,不代表看得准、看得全。复杂的视觉信息,尤其是涉及大量元素之间相互关系的那种(比如排期图里九个工序互相牵扯),对AI来说依然是个硬骨头。
这里研究者还做了个"再给AI两次机会"的实验,也就是同一道题让AI连续尝试三次,只要有一次通过就算过关。结果显示,多试几次确实能把通过率往上拉一截,比如游戏领域GPT-6-Astra从首次尝试的37.9%涨到了三次尝试后的62.1%。但更值得注意的是另一个数字:在游戏领域里,GPT-6-Astra有34.5%的题目是三次尝试全部通过的,这个数字代表的是"稳定可靠"的真实水平,而对比组的GPT-5.6-Sol这个数字只有3.4%。
这个区分很重要,因为它提醒我们,"能做对"和"每次都能做对"是两件事。前者看的是潜力上限,后者看的是实际能不能信得过。
效率这件事也值得聊聊
论文里还有个挺有意思的发现,跟"花多少工夫"有关。
研究者统计了AI完成任务时发出的"响应次数"(可以理解为AI来回操作、思考的轮次)。结果发现,GPT-6-Astra不仅成绩最好,它完成任务花的响应次数反而是相对较少的。在那些GPT-6-Astra和另外两个对比模型都成功解决的网页任务里,GPT-6-Astra在83.3%的情况下用的响应次数比Grok-4.6少,在72.2%的情况下比Claude-Opus-5少。
这意味着什么?意味着"看得多"不等于"看得准"。有些AI可能需要反复截图、反复试探才能摸到门道,而表现更好的模型往往是"看一眼就知道该往哪改",不需要大量试错。
研究者还专门对比了"修复成功"和"修复失败"两组任务里,AI到底截了多少张图、点了多少次鼠标。结果发现一个反直觉的现象:在网页领域里,GPT-6-Astra成功完成的任务,平均只用了7.5次截图和6次操作,而失败的任务反而用了19次截图和17.5次操作,操作次数几乎是成功案例的三倍。
这个现象挺值得琢磨的。它暗示着,一旦AI陷入"看不懂、瞎试探"的状态,它反而会疯狂截图、疯狂点击,想靠蛮力撞出一个正确答案,但往往撞不出来。真正厉害的修复,反而是干净利落的,看一眼问题所在,改对地方,验证一下,收工。这跟我们生活中的经验其实挺像的:一个真正懂行的维修师傅,上门看一眼就知道哪里坏了,动作利索;而一个没把握的新手,可能要拆开反复检查好几遍,忙活半天还没找到病根。
研究者还专门回去复查了一批失败案例和成功案例的详细过程记录,想搞清楚AI到底是在哪个环节栽的跟头。他们把开发过程拆成了五个可能出问题的阶段:有没有去看该看的东西(观察阶段)、看到了有没有理解对(解读阶段)、理解对了有没有诊断准问题根源(诊断阶段)、诊断准了代码有没有改对(实现阶段)、改完之后有没有认真验证(验证阶段)。
统计下来,在84个被详细复查的失败案例里,"验证阶段出问题"占了82个,是所有环节里出错比例最高的。这说明很多时候AI不是不会修bug,而是修完之后没有回头认真检查,或者检查的时候用的还是旧版本的软件,根本没刷新。这就跟我们写完一篇稿子,检查错别字的时候眼睛扫过去却没真正读进脑子里一样,看似检查了,其实啥也没查出来。
针对这个发现,研究者还量化了一下"认真验证"到底值不值。他们定义了一个叫"最终编辑后重新验证"的行为,也就是AI在做完最后一次代码修改之后,有没有真的重新跑一遍软件、做一遍相关操作、看一眼结果再提交。数据显示,在网页领域里,做了这个动作的任务成功率是45.8%,没做的只有5.7%,差了整整8倍。在移动领域更夸张,做了的成功率83.7%,没做的只有10.6%。
这个数字的说服力在于,它把一个听起来很"正确但空洞"的建议(认真检查很重要),变成了一个有血有肉的统计事实:认不认真检查,直接决定了你的任务成功率是百分之四十几还是百分之五。
训练AI学会这套本事
论文的后半部分,研究者还做了一个小规模的实验,想看看能不能让AI通过学习这些"正确范例"来提升自己的能力。
他们用一个参数规模不算特别大的模型(Qwen3.8-27B),拿那些经过验证的、正确的修复过程当作训练素材,进行了一轮监督微调。
监督微调:一种让AI模型学习特定任务的训练方式,做法是给模型展示大量"正确答案"的例子,让它模仿这些例子的行为模式,从而在类似任务上表现得更好。
结果显示,训练前这个模型在网页任务上的通过率只有11.1%,训练之后涨到了33.3%,差不多翻了三倍。这个结果虽然规模不大,但释放出一个积极的信号:这套"既要改代码又要看软件"的能力,是可以通过针对性训练学会的,不是什么天生注定的玄学。
研究者还提到,他们接下来想做的是一种更进阶的训练方式,让AI通过"自己尝试、拿到对错反馈、再调整"的方式自我提升,而不只是单纯模仿范例。这条路还在路上,目前完成的只是第一步的监督微调实验。
这套体系能带来什么改变
读完这篇论文,我最大的感受是,它其实在悄悄纠正一个过去被忽略的评价标准。
过去我们评价一个编程AI厉不厉害,往往是看它能不能让代码跑通测试用例,能不能解决GitHub上真实的issue。但这篇论文提醒我们,这套标准漏掉了一大块真实世界的工作内容:那些藏在界面里、藏在图纸里、藏在服务实际响应里的信息,代码本身根本不会告诉你。
举个更贴近生活的例子。假如你请一个装修师傅来改造房子,他只拿到一张设计图纸就开始施工,从头到尾不进屋看一眼实际效果,等施工结束了才第一次打开门走进去检查。这种工作方式听起来就让人不安,因为再精确的图纸也无法完全预料实际空间里光线、色彩、动线这些只有亲眼看到才能判断的东西。CUA-SWE这篇论文做的事情,某种程度上就是在逼着AI开发者正视这件事:写软件从来不是闭眼画图纸,而是边画边进屋瞅。
数据本身也挺说明问题的。48.6个百分点的提升幅度,放在任何一个评测体系里都算得上是颠覆性的数字了。这不是优化了10%、20%这种渐进式的进步,而是直接把及格线以下的表现拉到了接近及格线以上两倍的水平。这说明"能不能看见软件"这件事,可能是当前AI编程能力里一个被严重低估的短板,而不是一个可有可无的加分项。
Q&A
Q1:CUA-SWE是什么?
A:CUA-SWE是由卡内基梅隆大学等机构研究者提出的一套基准测试和开发环境,专门用来考察AI能不能像真正的程序员一样,一边读写代码一边运行软件、观察屏幕截图,并最终用独立的自动化测试来验证AI改的代码对不对。
Q2:为什么给AI开图形界面权限会让成绩提升这么多?
A:因为很多任务要求的信息根本不在代码里,而是藏在运行中的软件界面、导入的图纸或者服务实际响应里,AI光读代码看不到这些信息。实验数据显示,开启图形界面后平均成功率从11.3%提升到59.9%,提升了48.6个百分点,尤其是在那些信息依赖应用材料的任务上提升最明显。
Q3:AI在这套测试里最容易在哪个环节出问题?
A:研究者详细复查后发现,"验证阶段"出问题的比例最高,在84个失败案例里有82个都存在验证不到位的情况,也就是AI改完代码后没有认真用图形界面重新检查效果。数据显示,认真做最终验证的任务成功率能达到45.8%到83.7%,而没做验证的只有5.7%到10.6%。
