AI能记住你上一句话，却记不住你上一次改的界面

你有没有遇到过这种事：让AI帮你做一个网页，做出来还不错，然后你说"能不能加个筛选功能"，它加上了，但你之前要的那个排序功能突然消失了。你再说"筛选加回来那个也保留",它这次两个都有了，可是配色又变了,原来选好的深色模式没了。

这不是段子，这是一群研究者在纽约大学上海分校做的正经研究里发现的普遍现象。他们给这个现象起了个名字，叫做EvoGenUI,也就是"演化式生成界面"

生成式UI*：让大语言模型直接生成可交互网页界面的技术,比如仪表盘、表单、对比视图这类东西,现在被越来越多的AI助手当作直接回复用户的一种方式,而不只是回复一段文字。

这些界面听起来挺酷的，AI不再只是说话，它开始"造东西"给你用。问题是,现实里没人只提一次要求就完事。你会不断地改主意,加功能,调样式,这时候AI面对的就不再是"生成一个东西"这么简单的任务了，而是要在一堆已经存在的代码和历史要求之间反复横跳，还得保证每次改动之后，那个东西还能正常运行。

这篇论文要问的问题很直接：AI在这种反复修改的场景里，到底能不能保持靠谱？

答案让人有点意外。即便是表现最好的模型，单次回合的正确率能到74.9%，可如果你从头到尾观察一个完整的五轮对话，它能全须全尾走完的概率只有37.3%。

这个数字差距意味着什么？

意味着即使AI每一步单独看都做得还不错，但只要连续改五次，出问题的概率就会大幅累积，最后能全程无bug的情况反而是少数。这就像开车,每个路口单独看闯红灯概率都很低，但开一百个路口下来，出事故的概率就完全是另一回事了。

这篇论文的价值不在于告诉你"AI还不够聪明"，而在于它系统性地拆解了到底哪里出问题、为什么出问题、以及怎么去衡量这种"多轮维护能力"。这套评估体系叫EvoGenUI-Bench，接下来我们一步步看它是怎么设计的。

问题到底难在哪

先说清楚一件事，为什么这个问题以前没被认真对待过。

在这篇论文之前，市面上评估AI生成界面能力的基准测试，基本都是"一锤子买卖"的模式：给一个需求，AI生成一个页面，看这个页面做得好不好，结束。这种测试方式测的是AI的"创作能力"，但完全没测它的"维护能力"。

这就好比考驾照只考直线加速，不考路口转弯、并线、倒车入库。你确实能测出这辆车跑得快不快，但完全测不出司机在复杂路况下能不能开得稳。而现实中的AI助手场景，恰恰全是复杂路况：用户会不断补充要求、修改想法、甚至前后矛盾地提要求。

论文里提到几个相关的先行研究，比如FronTalk研究的是多轮前端开发中的文字和视觉反馈问题，发现一个核心症结是AI会"遗忘或覆盖之前的功能"。还有SlopCodeBench发现，AI做迭代式代码扩展的时候，虽然能满足中间检查点的要求，但整体代码结构会不断劣化，越改越乱。这些研究已经隐约摸到了问题的边缘，但都没有做出一套完整的、可执行的评估体系去系统衡量这件事。

EvoGenUI-Bench要做的就是把这件事做完整。

它设计了150个任务，每个任务都是五轮连续对话，总共750轮交互。这些任务分成三类：信息展示类、可交互操作类、以及工具接入的外部状态类。

信息展示类*：考察AI能不能把大量信息组织得清晰易读，比如仪表盘、对比表这种以"看"为主的界面。

可交互操作类*：考察带有本地状态的可执行界面，比如一个有输入框、按钮、会根据用户操作变化的小应用。

工具接入类*：考察那些需要读取、写入、同步外部系统状态的界面，比如需要调用后端API查数据、下单、修改记录的场景，这类最贴近真实世界的复杂应用。

这三类任务的验证要求密度差别很大。信息展示类平均每轮只有3条隐藏验证要求，可交互类是5.9条，而工具接入类高达11.9条。这个数字差距本身就说明了工具接入类任务的复杂程度远超前两者，因为它不仅要管界面好不好看、逻辑对不对，还要管界面和后台真实数据是不是同步的。

怎么去"审判"一个AI生成的界面

光有任务还不够，你得有办法判断AI做得对不对。这才是这篇论文真正下功夫的地方。

以前很多评测方法要么是让另一个AI看看代码写得像不像样，要么就是简单跑几个自动化测试脚本。这篇论文认为这两种方式都不够，因为生成式界面这个东西太特殊了，它同时涉及视觉呈现、代码逻辑、交互行为、还有AI嘴上说的话，这四个层面得同时对得上号才算真正合格。

于是他们搭了一套完整的执行流水线。每次AI返回代码之后，系统会真的把这个界面放进浏览器里跑起来，用Playwright*：一种自动化浏览器操作工具，可以模拟真实用户点击、输入等交互行为这类工具去实际点一点、点一点按钮、填一填表单，看它到底能不能用。

这个过程会收集好几种证据：屏幕截图看长得怎么样，DOM*：网页的文档对象模型，简单理解就是网页的结构化"骨架"数据看代码结构对不对，交互轨迹记录AI操作界面时发生了什么，还有运行日志和工具调用记录看后台数据有没有被正确处理。

有了这些证据之后，评估者会打三个维度的分：呈现质量、执行完整性、还有一致性。

呈现质量看的是界面美不美观、清不清楚，有没有把信息摆得乱七八糟。执行完整性看的是这一轮请求的功能是不是真的实现了，而且之前几轮要求的功能有没有被破坏。一致性看的是AI说的话、生成的代码、界面上显示的内容、还有工具调用的结果，这几个东西是不是相互印证、没有矛盾的。

这套打分方式解决了一个很关键的问题，就是"看起来能用"和"真的能用"之间的巨大鸿沟。举个论文里的实际案例，有个界面里有个"运行阵风测试"的按钮，界面上的数值确实会因为你点击而变化，看起来很正常。但研究者实际操作后发现，无论你怎么调整参数，最后输出的仿真结果永远是同一组数字，100%的超调量，10秒的调节时间，一模一样。这说明这个按钮是假的交互，界面表面在动，底层逻辑压根没跟着变。

如果只靠截图判断，你根本发现不了这个问题，因为截图上的数字看起来都挺正常的。只有真的去点、去操作、去对比操作前后的结果，才能揪出这种"金玉其外"的假交互。这也是为什么这套评测体系要花这么大力气去真实执行界面，而不是简单地读读代码就下结论。

这就好比你去买一辆二手车，光看外观和内饰完全没法判断发动机是不是有问题，你得真的把车开出去跑一圈，踩踩刹车、试试转向，才能知道这车到底靠不靠谱。如果只靠"看着挺新"就买下来，等真正上路才发现刹车不灵，那时候已经晚了。生成式界面的评测也是同一个道理，代码写得再漂亮，不实际跑一遍你永远不知道里面藏着什么坑。

三个新指标，量出AI到底靠不靠谱

光靠单轮打分还不够说明问题，因为这篇论文关心的核心问题是"多轮维护能力"。为此他们设计了三个指标，一起来看看这几个数字到底在量什么。

第一个叫Turn Pass，也就是单轮通过率，这个好理解，就是每一轮请求单独看，AI做对了没有。

第二个叫TP@5，这是五轮全部通过的比例。一个任务有五轮对话，只有全部五轮都合格，这个任务才算真正成功。这个指标才是真正反映"从头到尾靠不靠谱"的核心数字。

第三个叫APR，全称是相邻回合保持率*：Adjacent Pass Retention，衡量的是"如果这一轮通过了，下一轮还能不能继续通过"这个概率。它专门衡量的是那种"好不容易做对了，结果一改就崩"的现象。

这三个指标搭配起来看才有意思。表现最好的模型Claude-Opus-4.7，单轮通过率能到74.9%，这数字看着挺唬人的。可是五轮全通过的比例，也就是TP@5，只有37.3%。这中间的差距接近一半，说明单看某一轮的表现完全不能代表这个AI能不能撑完一整个真实的多轮对话。

论文里还做了个很聪明的对照实验。如果假设五轮之间完全独立，互不影响，那按照每一轮单独的通过率去计算，理论上应该得到的TP@5应该是多少？结果发现实际观测到的TP@5全都明显高于这个"假设独立"算出来的理论值。这说明什么？说明一旦某个任务某一轮翻车了，后面几轮大概率也会跟着翻车，失败是会"传染"的，而不是每一轮都从零开始独立判断。这背后的原因很可能是有些任务本身就比较难，一旦第一步没打好基础，后面越改越乱。

再看APR这个指标，能看出更细腻的东西。Gemini-3.1-Pro这个模型整体单轮通过率只有23.6%，看起来表现平平，可是它的APR在信息展示类任务上能到70.3%，可交互类任务上能到79.6%。这说明什么？

说明这个模型不太容易"一步做对"，但只要它侥幸做对了一次，它接下来大概率能把这个正确状态保持住，不容易半路崩掉。这就好比一个学生考试及格率不高，但只要他哪次考及格了，接下来几次大概率也能维持及格线，他不是运气差，是起步慢但一旦上道了就比较稳。这种细节，如果只看单一的总分是完全看不出来的，必须靠这套多层次的指标体系才能挖出来。

工具接入类任务的表现最能说明问题的严重性。经过条件筛选之后，也就是只看"上一轮通过了"的这些情况，工具接入类的APR只有52.4%，明显低于信息展示类的71.1%和可交互类的68.7%。这意味着即便AI已经把一个涉及外部系统的界面做对了，接下来只要用户再提一个新要求，超过四成的概率这个界面就会崩掉。

论文还做了个很扎实的追溯分析，专门去看那些"上一轮通过、这一轮失败"的案例，到底是哪里出的错。他们人工审查了110个这样的失败案例，发现其中52.7%是因为AI破坏了之前已经做好的功能，也就是俗称的"改了新的、忘了旧的"；剩下的47.3%是新要求本身没实现，但至少没破坏原来的东西。这个52.7%这个数字挺扎心的，说明超过一半的翻车不是新任务太难，而是AI压根没管住之前辛辛苦苦做出来的那些功能。

六种失败机制，各有各的病因

光知道"会失败"还不够，这篇论文更进一步，把2750个失败案例逐一分类，归纳出六种具体的失败机制。这部分内容才是真正有诊断价值的地方。

信息架构问题*：内容组织混乱、可读性差、布局重叠或被裁切，是最常见的问题之一，一共出现了859次。

衍生状态传播问题*：界面上的从属数据在底层状态变化后没有跟着更新，出现了586次，前面提到的那个PID控制器仿真数值卡死的案例就属于这一类。

功能绑定问题*：界面上有个按钮或控件看起来能用，但实际上没有连接到任何真实逻辑，出现了460次。

需求拆解问题*：用户提出的多个要求里有些被漏掉了，一共出现410次。

外部状态同步问题*：界面显示的内容和后台真实数据对不上，出现289次。

领域表达问题*：AI对这个专业领域的理解出现偏差，用错了表达方式，出现146次相对最少。

这六种问题在三类任务里的分布很不一样。信息展示类的问题几乎全都集中在信息架构上，占比高达84.5%，说明这类任务的核心难点确实就是"排版"这件事。可交互类任务里，衍生状态传播和功能绑定加起来占了半壁江山，说明这类任务真正的坑在于"看起来能动但其实没动"。工具接入类任务的问题分布则铺得很开，六种问题都有相当比例出现，尤其是外部状态同步问题在这里占比明显高于其他两类。

这个分布规律挺有启发性的。它告诉我们，不同类型的任务需要用不同的证据去诊断问题。你想找信息架构的毛病，看截图就够了，肉眼就能看出文字挤在一起看不清。可你想找衍生状态传播的毛病，光看截图完全没用，你得实际操作一遍，对比操作前后数据变没变，这就需要交互轨迹和源代码的对比。你想找外部状态同步的问题，那就得去看运行日志，看界面发出的请求和后台返回的数据到底吻不吻合。

这就好比医生看病，不同的症状要用不同的检查手段。皮肤上的问题肉眼一看就知道，但心脏的问题你得做心电图，肠胃的问题可能得做胃镜。如果医生固执地只用一种检查手段去应对所有症状，那大部分病都查不出来。这套评测体系正是意识到了这一点，才专门搭建了一套多重证据并行收集的机制，而不是偷懒地只看一张截图就下结论。如果这套体系只靠截图判断一切，那衍生状态传播和外部状态同步这两类问题基本全都会漏检，因为这些问题在静态画面上根本看不出破绽。

论文还做了个消融实验来验证这个观点。他们把评估者能看到的证据一样样拿掉，测试准确率会怎么变化。结果发现，去掉交互轨迹之后，准确率从87.5%直接暴跌到55.0%，掉了32.5个百分点，是所有单项证据里影响最大的。这说明交互轨迹这个证据来源，对于识别那些"看起来正常实际是坏的"的问题至关重要，光靠代码和截图根本不够。

时间越往后，翻车概率越高

论文还发现一个很有意思的规律。如果你把五轮对话按顺序拆开看，第一轮和第二轮的通过率差不多，但从第三轮开始，通过率就明显往下掉。整体的通过率在第三轮跌到39.4%，第四轮跌到35.1%。

这个下降在工具接入类任务上尤其明显，第二轮通过率还有39.5%，到第三轮直接砸到18.5%，第四轮更是只剩14.0%。

这个现象背后的道理其实挺直白的。随着对话轮数增加，AI要同时兼顾的历史要求越来越多，它得一边满足新提出的要求，一边还得记住之前所有还有效的要求不能破坏。这就像叠积木，前两层好叠，越往上叠，你手上要同时稳住的积木块越多，稍不留神就塌一块下来。如果不做多轮评测，只测第一轮或者只测某个孤立的场景，你根本发现不了这种"越改越乱"的累积性问题，因为单看任何一轮可能都还行，问题是攒到后面集中爆发的。

写在后面

读完这篇论文，最触动我的其实不是那些百分比数字，而是那个110个失败案例的人工追溯分析。研究者们没有满足于"APR只有52.4%"这样一个笼统结论，而是真的一个个案例去看，去区分到底是"忘了旧的"还是"没做好新的"。这种较真的态度让我意识到，一个看似简单的失败率背后，其实藏着完全不同的病因，而这些病因需要用不同的方法去治。

还有一点值得单独说说，就是那个"看起来能用但其实是假的"的PID控制器案例。界面上的滑块确实在动，数字确实在变，可仿真结果纹丝不动。这种失败特别隐蔽，因为如果你只是随手截个图看一眼，完全发现不了任何异常。这让我想到，我们平时判断一个软件产品"好不好用"，是不是也经常停留在"看起来挺顺畅"这个层面，而没有真的去戳一戳它的每个功能是不是真的连着后端逻辑。这篇论文提醒我，评判一个系统靠不靠谱，光靠"看"是远远不够的，你得真的去"用"。

这篇论文目前还没有解决的问题是，它用的是确定性的模拟工具环境，为的是保证实验可复现。可真实世界里的工具调用会遇到网络延迟、权限失败、服务中断这些乱七八糟的情况，这些论文里都没涉及。也就是说，就算一个AI在这套基准测试里表现完美，真拿到生产环境里跑，还会遇到一堆这套测试完全没覆盖到的新麻烦。这大概会是接下来的研究者们需要继续啃的骨头。

Q&A

Q1：EvoGenUI-Bench是什么？

A：EvoGenUI-Bench是一套评估大语言模型多轮生成和维护可交互网页界面能力的基准测试，包含150个五轮对话任务共750轮交互，覆盖信息展示、可交互操作、工具接入外部状态三类场景。

Q2：为什么AI单轮做得好，但整个多轮对话经常失败？

A：因为每一轮的小失误会累积，论文里表现最好的模型单轮通过率有74.9%，但完整走完五轮全部合格的比例只有37.3%，说明单轮正确不代表整体流程可靠，失败还会在后续轮次里传染。

Q3：AI生成界面最常见的失败原因有哪些？

A：论文归纳出六种失败机制，包括信息排版混乱、按钮看起来能用实际没连接逻辑、数据更新后依赖它的界面没跟着变、需求被遗漏、界面和后台真实数据对不上，以及专业领域理解出错，不同任务类型的主要病因也不一样。