首個持續更新Visual Spec-to-App Benchmark發布

近年來，Coding Agent 正以前所未有的速度發展。從 Claude Code、OpenAI Codex 到 Cursor、Gemini CLI，大語言模型已經能夠自主完成編碼、調試、運行甚至部署整個 Web 應用，「AI 軟件工程師」正逐漸成為現實。然而，一個新的問題也隨之出現：

如果不給 AI 一個 GitHub Issue，而是給它一張 Figma 設計稿，它還能開發出一個真正可以交付的產品嗎？

過去幾年，SWE-bench、OpenHands 等 Benchmark 極大推動了 Coding Agent 的發展，但它們主要關注代碼倉庫維護和 GitHub Issue 修復。相比之下，真實的軟件開發通常始于一份產品需求（PRD）和一張 Figma 設計稿，需要開發者從零構建完整的 Web 應用。這意味著，Coding Agent 面臨的挑戰已經從 Code Generation 逐漸演進為 Product Generation。然而，目前仍然缺少一個能夠系統評測這一能力的公開 Benchmark。

為了解決這一問題，來自 University of Arizona、Zoom 與 Stony Brook University 的研究團隊推出了 VISTA（VIsual Spec-To-App Benchmark）, 首個面向 Visual Spec-to-Web-App Coding Agents 的端到端 Benchmark。

不同于傳統軟件工程 Benchmark，VISTA 不再要求 Agent 修復已有代碼，而是要求 Agent 根據產品需求、網頁設計稿以及 Figma 信息，從零開始構建一個完整、可運行、具有真實交互能力的 Web 應用。

圖 1：VISTA Online Leaderboard 持續評測 Claude、GPT、GLM、Gemini、Cursor 等主流 Coding Agent，并隨著模型與 Harness 的更新實時刷新排行榜。從產品質量、開發效率和成本等多個維度比較真實的軟件開發能力。

如果說過去大家關注的是「誰更會寫代碼」，那么今天，一個新的問題已經出現：誰更會開發產品？

VISTA Leaderboard 希望回答的，正是這個問題。從目前的排行榜來看，有三個值得關注的趨勢:

第一，Coding Agent 的競爭，已經從模型競爭演變為「模型 + Harness」的系統競爭。 排行榜上的評測對象不再只是 GPT、Claude 或 GLM，而是模型與開發 Harness 共同組成的完整 Agent。同一模型在不同 Harness 下可能表現不同，這說明工作流設計、工具調用和執行策略，已經成為影響軟件開發能力的重要因素。

第二，領先模型之間的差距正在縮小，但能力仍遠未達到「滿分」。 當前排名前列的 fable-5、Claude Opus 4.8、GPT-5.5 和 GLM-5.2 已經能夠根據產品需求和 Figma 設計完成完整 Web 應用開發，但最高綜合得分仍不足 0.3。這說明，盡管 Coding Agent 已經具備一定的軟件開發能力，但距離穩定完成真實產品開發仍有很大的提升空間。

第三，「最好」并不意味著「最快」或「最省」。 排行榜顯示，不同 Coding Agent 已經開始形成截然不同的工程風格。例如，目前排名第一的 fable-5 雖然取得了最高的綜合得分，但平均每個任務需要消耗約 75 萬 Tokens；相比之下，GLM-5.2 僅消耗約 30 萬 Tokens，約為前者的一半，而 GPT-5.5 的 Token 消耗進一步降至約 28 萬。不同模型在開發時間上也存在明顯差異，有些模型更傾向于反復迭代，以更高的計算開銷換取更好的產品質量；有些模型則更加注重開發效率，在有限成本下完成任務。

這也意味著，Coding Agent 的競爭正從「模型能力」逐漸演變為「工程能力」的競爭。未來的軟件工程 Benchmark，不應只有一張質量排行榜，更應該同時衡量質量（Quality）、效率（Speed）和成本（Cost），真正回答 AI 是否具備獨立開發產品的能力。

也正因為如此，VISTA 從一開始便被設計成持續更新（Living Benchmark）。隨著 Claude Code、Codex、Cursor、GLM、GPT、Gemini 等模型及 Harness 持續迭代，排行榜也將不斷刷新，持續記錄 Coding Agent 的能力演進，而不僅僅停留在論文中的一次性實驗結果。

論文目前已發布于 arXiv，項目網站、Benchmark、評測代碼以及在線 Leaderboard 已全部開源并且上線，并將持續測試最新模型，為社區提供一個開放、持續更新的軟件工程評測平臺。

• Paper：https://arxiv.org/abs/2605.26144
• GitHub：https://github.com/kaboider/VISTA_Bench
• Project Website & Leaderboard：https://kaboider.github.io/VIS_APP/

VISTA：一個面向真實產品開發的 Benchmark

圖 2：VISTA 整體框架。給定產品需求、視覺設計以及 Figma 信息，Coding Agent 從零開始完成整個 Web Application 的開發，并通過統一評測框架驗證最終產品質量。

如果說傳統 Benchmark 更關注「修改代碼」，那么 VISTA 更關注另一件事情：AI 是否真的能夠開發一個完整的軟件產品

因此，VISTA 并沒有把任務定義為代碼補全，也沒有讓 Agent 修復已有倉庫，而是直接從產品設計開始。對于每一個任務，Agent 都需要根據產品需求、網頁截圖以及 Figma 設計，自主理解頁面布局、分析組件層次、選擇開發框架，并最終實現一個能夠運行的多頁面 Web Application。與傳統 Design-to-Code 工作相比，VISTA 不只是要求生成一個靜態頁面，而是要求 Agent 完成一次完整的軟件開發流程：理解需求、檢查上下文、實現頁面與交互邏輯、啟動應用，并在運行失敗時完成調試與修復。整個 Benchmark 更加貼近現實中的軟件開發，而不是理想化的網頁生成任務。

VISTA 主要圍繞三個目標展開。

首先，它關注真實的軟件開發流程。Agent 不只是生成 HTML，而是需要完成頁面導航、狀態管理、交互邏輯以及應用部署等完整開發任務。

其次，它強調 Visual Spec 驅動的軟件開發。除了自然語言需求之外，Benchmark 同時提供網頁截圖以及經過裁剪的 Figma 結構信息，使 Agent 能夠真正理解產品設計，而不僅僅依賴文本描述。

更重要的是，VISTA 被設計成一個可持續更新的 Benchmark。Coding Agent 正以極快的速度迭代，傳統論文中的實驗結果往往只能代表某一個時間點。為了持續追蹤模型能力的發展，VISTA 將長期維護在線 Leaderboard，隨著 Claude Code、OpenAI Codex、Cursor、Gemini 等模型及其 Harness 的更新持續刷新評測結果，而不是停留在一組靜態實驗數據。

構建真實世界的軟件開發 Benchmark

圖 3：VISTA Benchmark 覆蓋 10 類真實 Web 應用，共包含 128 個頁面、3253 個交互組件以及 458 個視覺錨點。

一個 Benchmark 是否可信，很大程度取決于它的數據。對于 Coding Agent 而言，直接利用互聯網網頁構建 Benchmark 并不是一個理想選擇。HTML、CSS 和 JavaScript 早已廣泛存在于大語言模型的訓練數據中，如果直接采用真實網頁，很容易受到數據污染（Data Contamination）的影響，使模型表現被高估。因此，VISTA 并沒有從網頁出發，而是選擇以 Figma 設計稿作為整個 Benchmark 的起點，將 Figma 渲染截圖和結構化 JSON 共同作為 Ground Truth。

整個 Benchmark 覆蓋 10 類典型 Web 應用，包括新聞、房產、招聘、論壇、旅行預訂、聊天、云存儲、電商、項目管理和音樂流媒體，共包含 128 個頁面。為了保證評測質量，研究團隊進一步裁剪原始 Figma JSON，僅保留頁面布局、組件層級、文本標簽以及交互目標等與開發密切相關的信息。同時，對所有頁面進行了細粒度人工標注，共標注 3253 個可交互組件 和 458 個視覺錨點（Visual Anchors），為后續評測提供統一、穩定的參考。

相比傳統網頁數據集，VISTA 更關注一個問題：Agent 是否真正理解了產品設計，而不僅僅是生成了一段網頁代碼。

五種輸入條件，模擬真實開發流程

圖 4：VISTA 設計了五種 Prompt Conditions，從純文本需求逐步增加頁面截圖和 Figma 結構信息，并分別評測固定技術棧與自由技術棧兩種開發模式。

現實中的軟件開發，并不存在統一的輸入形式。有時開發者只有一份 PRD (Product Requirements Document) ，有時只有設計稿，也有時會直接拿到完整的 Figma 文件。為了盡可能貼近這些真實場景，VISTA 從設計信息和開發自由度兩個維度設計了五種 Prompt Conditions。

一方面，輸入從純文本需求逐步增加頁面截圖和 Figma 結構信息，讓 Agent 獲得越來越豐富的產品上下文；另一方面，Benchmark 同時評測固定技術棧和自由技術棧兩種開發模式，以分析開發約束對 Agent 表現的影響。

這種設計不僅能夠比較不同 Coding Agent 的整體能力，還能夠回答幾個更加細粒度的問題：

• 頁面截圖究竟能帶來多少幫助？
• Figma 的結構信息是否真正有價值？
• 技術棧約束是否會影響 Agent 的開發能力？

相比傳統 Benchmark 的單一測試設置，VISTA 更希望系統地刻畫不同開發條件下 Agent 的能力邊界。

不只是「長得像」，更要「真正能用」

現有不少網頁生成 Benchmark 主要依賴瀏覽器 Agent 或大語言模型判斷生成結果，雖然擴展性較好，但在復雜 UI 場景中容易受到模型本身影響，難以穩定評估真實的軟件質量。

VISTA 采用了一種更加直接的思路：DOM-Grounded Evaluation。Evaluator 可以同時衡量兩件事：生成的界面是否保留了參考結構，以及匹配上的元素是否實現了預期行為。Evaluation 分成以下四步：

第一步，坐標對齊。 每個參考稿都標注了關鍵交互目標，包含一個包圍框和一個預期交互類型 (導航、文本輸入、開關、外鏈、彈窗等)。由于生成的應用會平移、縮放或重排布局，評估器先用高置信度的語義錨點估計一個逐軸仿射變換，把參考稿坐標映射到渲染頁面坐標系上。

第二步，DOM 元素匹配 (定位)。 Evaluator 在真實瀏覽器里渲染應用，把每個參考頁面映射到對應的實現 URL, 再把標注目標匹配到頁面上可見的可交互 DOM 候選元素。這一步本身就是一個結構一致性度量：只有當預期組件確實以真實 DOM 元素存在、且對齊后出現在參考位置附近時，才能拿到高定位分。它因此能懲罰那些純圖像指標容易漏掉的失敗：視覺上看著合理卻不可交互的 "畫出來的按鈕"、缺失的控件、錯位的組件、塌陷的頁面結構。

第三步，行為專項檢查。 定位之后，Evaluator 對匹配上的 DOM 元素跑針對具體交互類型的檢查，覆蓋前端狀態變化、導航 / 路由行為，以及任務需要時的后端或類數據庫狀態更新。

相乘的設計意味著一個交互必須「位置對并且行為對」才能得分。

VISTA 的 DOM-Grounded Evaluator 結構保證每個交互都會得到定位（Localization）和行為（Behavior）兩個分數，并共同決定最終得分。這意味著，一個組件只有位置正確且功能正確，才能獲得高分；如果只是「畫出了一個按鈕」，卻無法點擊，或者頁面布局正確卻交互失效，都無法通過評測。

因此相比只關注視覺相似度，VISTA 的評測思路回答了一個更接近真實開發的問題：Agent 開發出來的網站，究竟能不能真正交付給用戶使用？

不只是「做得好」，還要「做得快、做得省」

圖 5：VISTA 除了評估最終產品質量，還持續統計不同 Coding Agent 的開發成本（Tokens）與開發時間（Wall-clock Time），幫助全面評估真實的軟件工程能力。

對于真實的軟件開發而言，最終效果只是評價標準之一。一個優秀的軟件工程師，不僅需要做得好（Quality），還需要做得快（Speed）、做得省（Cost）

Coding Agent 同樣如此。因此，除了最終產品質量，VISTA 還持續統計每個 Agent 完成任務所消耗的Token實際開發時間（Wall-clock Time），幫助開發者從工程角度全面評估不同模型。

從目前的評測結果來看，不同模型之間展現出明顯不同的開發策略。例如，Claude Code harness+Fable-5 整體保持了較高的產品質量，但通常會消耗更多 Token，并花費更長時間完成開發；Claude Code harness+GLM-5.2 在開發速度和 Token 消耗之間取得了較好的平衡；Codex+ GPT-5.5 則以相對較低的 Token 消耗獲得了接近領先模型的性能，體現出較高的開發效率。

這些結果說明，未來評價 Coding Agent，不應只有一張排行榜。

不同模型正在形成各自不同的工程風格：有的追求最高質量，有的強調開發效率，也有的更加注重成本控制。

因此，VISTA 希望提供的不只是一個「誰最好」的排行榜，而是一份更加完整的 AI Software Engineer Report，幫助研究者從質量（Quality）、速度（Speed）、成本（Cost）以及后續的開發流程（Workflow）等多個維度，理解不同 Coding Agent 的真實能力。

不僅評測結果，也分析 Agent 如何開發

圖 6：VISTA 對不同 Coding Agent 的開發流程進行分析，比較上下文檢查、代碼編寫、驗證以及錯誤恢復等行為模式。

除了最終得分，VISTA 還進一步分析了 Coding Agent 的開發過程。

研究團隊將每一次開發過程拆解為上下文檢查（Inspect）、代碼編寫（Write）、結果驗證（Verify）、錯誤恢復（Failure Recovery）等多個階段，從而觀察不同模型在軟件開發過程中的行為差異。

分析發現，不同模型雖然都遵循「先理解、再開發、最后驗證」這一整體流程，但在開發策略上存在明顯區別。例如，Claude 系列模型更傾向于反復檢查上下文，并在失敗后重新診斷問題，再繼續開發；GPT 系列模型則采用更加多樣化的修復路徑，在驗證和錯誤恢復之間切換更加頻繁。這些分析不僅揭示了不同 Coding Agent 的工作風格，也為未來 Agent Workflow 的優化提供了新的研究視角。

相比只關注最終分數，VISTA 希望進一步回答：優秀的 Coding Agent，究竟是如何完成軟件開發的？

一個持續演進的 Benchmark

不同于許多論文發布后便停止維護的 Benchmark，VISTA 更希望成為一個長期演進（Living Benchmark）

未來，團隊將持續引入最新模型、最新 Harness 和新的應用場景，不斷更新在線 Leaderboard，與社區共同記錄 Coding Agent 的能力演進。

從產品需求理解，到視覺設計解析；從網頁生成，到交互驗證；再到開發流程分析，VISTA 將「看圖寫網頁」拆解為視覺理解、頁面定位、交互行為Agent Workflow等多個維度，希望為 AI 驅動的軟件工程研究提供一個更加真實、開放且可復現的評測平臺。

隨著 Coding Agent 從「寫代碼」逐漸邁向「開發產品」，軟件工程 Benchmark 也需要從代碼評測（Code-Centric Evaluation）走向產品評測（Product-Centric Evaluation）。

我們相信，未來評測一個 Coding Agent，不應只問「它會不會寫代碼」，更應該問：它能不能真正交付一個產品。VISTA 希望成為回答這一問題的一個起點。

關于團隊

本工作由University of Arizona、Zoom 與 Stony Brook University合作完成。團隊長期從事 AI Agent、大語言模型、多智能體系統等方向研究，近期重點關注AI for Software Engineering、Coding Agent 的評測、優化與應用，希望推動更加開放、可復現的軟件工程 Benchmark 建設。

作者介紹

第一作者：

Junjia Guo，University of Arizona Electrical and Computer Engineering 博士生（導師：Jingdi Chen），研究方向包括 Agentic AI、大語言模型（LLM）和視覺語言模型（VLM）。主要負責 VISTA Benchmark 構建、評測框架設計及 Online Leaderboard 系統開發。

其他作者：

Yuhang Yao，Zoom 高級研究工程師，研究方向包括可信多智能體網絡和大語言模型后訓練（Post-training），卡內基梅隆大學博士，長期從事生產級 LLM Agent 系統研發。

個人主頁：https://yuhangyao.com/

Jiawei Zhou，Stony Brook University 助理教授，研究方向包括自然語言處理、機器學習、大語言模型、AI Agent、推理規劃、多模態及 AI 評測。

個人主頁：https://joezhouai.com/

Jingdi Chen，University of Arizona Electrical and Computer Engineering 助理教授，ANNIE Research Group 負責人，研究方向包括 AI Agent、多智能體強化學習、軟件工程、網絡優化、網絡安全、可解釋 AI、大語言模型 / 視覺語言模型（LLM/VLM）及 量子計算與人工智能交叉研究。

個人主頁：https://jingdichen.com/info

平臺建設

Zimeng Pan，Google 軟件工程師，卡內基梅隆大學碩士，參與 VISTA Benchmark 模型測試、Online Leaderboard 持續更新。

Chang Li，University of Arizona ANNIE Research Group Research Intern（導師：Jingdi Chen），參與 Coding Agent 模型測試、Benchmark 實驗運行、評測數據整理及 Online Leaderboard 平臺維護，支持 VISTA Benchmark 的持續更新。