你有沒有遇到過這種事：讓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：論文歸納出六種失敗機制，包括資訊排版混亂、按鈕看起來能用實際沒連接邏輯、數據更新後依賴它的界面沒跟著變、需求被遺漏、界面和後台真實數據對不上，以及專業領域理解出錯，不同任務類型的主要病因也不一樣。
