想象一下，你問 AI 要一個飲食記錄工具，它不再是回你一段文字建議，而是直接給你一個可以點擊添加、統計熱量的完整應用。人和 AI 的交互，正在從「讀文字」走向「用應用」。

Karpathy 早在 X 上反復說過這件事：「App Store 作為一組離散應用供用戶選擇的模式，正在成為一個日益過時的概念。未來在于利用 LLM 技術將 AI 原生傳感器和執行器整合到高度定制化的、即開即用的應用程序中。」

Anthropic Claude Code 團隊的 Thariq Shihipar 更是直接宣判：「HTML is the new markdown。我已經停止為幾乎所有工作編寫 Markdown 文件，改用 Claude Code 幫我生成 HTML。」他從信息密度、可讀性、分享成本、雙向交互和趣味性五個維度論證了 HTML 對 Markdown 的全面碾壓。

這些觀點并非小圈子的自嗨，而是引發了廣泛共鳴。但當所有人都在談論 "AI 應該輸出 HTML" 的時候，一個更深層的問題被忽略了：生成一個 HTML 頁面容易，生成一個真正可交互、邏輯正確、且符合現實世界規律的 HTML 應用，難得多。大模型生成這類交互應用的真實水平到底怎樣？沒有人量過。

來自螞蟻集團靈光 App 閃應用團隊的研究者做了這件事。他們提出了MiniAppBench，首個專門評測大模型生成「交互式 HTML 應用」能力的基準，結合配套的自動化評估系統 MiniAppEval，對全球 16 個頂尖模型進行了系統性測試。

結果讓人警醒：大模型的代碼能力，遠不足以生成真正能用的交互應用，最強模型通過率也僅 45% 左右，平均只有 17%。

論文以ICML 2026 Spotlight身份被接收：ICML 2026 有效投稿量共 23918 篇，全部接受稿件共 6352 篇（26.6%），Spotlight 僅 536 篇（2.2%）。

• 論文標題：MiniAppBench: Evaluating the Shift from Text to Interactive HTML Responses in LLM-Powered Assistants
• arXiv 地址：https://openreview.net/pdf?id=pwbLmew1aq
• 項目主頁：https://miniappbench.github.io/
• 代碼倉庫：https://github.com/MiniAppBench/miniappbench

3 個看點先讀

1.定義 AI 時代人機交互新范式：論文正式提出「MiniApp」概念，即由大模型依據用戶單條 Query 即時生成的定制化 HTML 交互應用。當 Markdown 已經無法承載越來越復雜的 AI 輸出，MiniApp 代表了從靜態文本到可交互應用的范式轉移。

2.全球最強模型集體「汗流浹背」：16 個模型評測，最高通過率僅 45.46%，平均僅 17%。在 Hard 難度任務上，幾乎所有模型通過率都跌到個位數。這不是一個飽和的 Benchmark。

3.用 AI Agent 當「人類測試員」：MiniAppEval 不靠固定腳本打分，不靠截圖比對，而是讓一個基于 LLM 的 Agent 模擬人類測試員去點擊、拖拽、輸入，從意圖、靜態、動態三個維度全方位測試，與真人打分相關性高達 0.85 以上。

01 從文本到交互：AI 人機交互的新范式

當大模型的輸出從「回答問題」變成「交付應用」，交互方式本身也在發生根本性的變化。

過去，你問模型一個問題，它回答一段文字，靜態的、一次性的，讀完就結束了。但現在，你可以對模型說「幫我做一個牛頓定律演示工具」，它就能給你一個真的能撥動質量滑塊、實時看到力學動畫的交互界面。你說「幫我記錄每周飲食」，它不是給你一個文字版的食譜建議，而是直接給你一個帶七天三餐表格、可以點擊添加、可以統計熱量的飲食記錄器。

這就是論文定義的MiniApp：由模型依據單條 Query 即時生成的定制化 HTML 交互應用。

從傳統文本輸出到 MiniApp 的范式轉移

為什么是 HTML？因為 HTML 天然具備四個特性：美觀的視覺呈現能力、豐富的交互邏輯支持、跨平臺即開即用、無需安裝部署。它不是大模型生成的中間產物，而是直接面向用戶的終端產品。

關鍵在于，MiniApp 不只是「好看的網頁」。論文明確指出，它有兩大核心屬性：

• 原則遵循（Principle Adherence）：模型必須捕捉并構建用戶 Query 中隱含的現實世界原則。比如「一周飲食記錄」隱含了「一周有七天、一天有三餐」；「水蒸發演示」隱含了粒子運動速度隨溫度升高的物理定律。
• 定制化交互（Customized Interaction）：應用結構和行為需要根據用戶意圖動態合成，而非套用固定模板。

前者考察的是模型對世界知識的理解深度，后者考察的是把理解轉化為可執行代碼的工程能力。兩者缺一不可，而現有 Benchmark 對兩者都缺乏有效的評測手段。

02 現有 Benchmark 為什么量不了這件事

現有的代碼評測和 Web 評測，都很難覆蓋 MiniApp 的核心能力。

代碼類 Benchmark（HumanEval、MBPP、SWE-Bench 等）：測的是算法邏輯對不對、函數能不能過測試用例。代碼在這里是抽象的邏輯符號，跟執行環境、用戶交互無關。一個能寫快排的模型，不代表它能理解「一周有七天」并把這種常識編碼進交互邏輯。

Web 生成類 Benchmark（Pix2Code、FullFront、WebGenBench 等）：測的是視覺還原度和布局一致性。能不能把設計稿還原成 HTML/CSS，跟能不能生成一個功能正確的交互應用，完全是兩回事。前者是「畫得像」，后者是「用得對」。

已有的 Agent 評測（ArtifactsBench、WebDevJudge 等）：雖然開始關注交互性，但主要依賴 A/B 偏好對比或與參考實現的偏差打分。MiniApp 的本質是開放式的：同一個需求可以有無數種合理的實現方式，不存在唯一的 Ground Truth。拿固定答案去評判開放式產出，要么太松放過錯誤，要么太嚴誤殺合理方案。

MiniAppBench 要回答的問題是：模型能不能理解用戶的隱含需求，并把它變成一個真正能用的、遵循現實世界原則的交互應用？這個問題，之前沒有任何 Benchmark 系統性地回答過。

03 MiniAppBench：從一千萬條真實交互中蒸餾 500 道題

MiniAppBench 的數據不是拍腦袋想的，也不是用模板批量生成的。

它的起點是大規模真實場景中積累的超過 1000 萬條交互需求。研究者從中篩選出真正需要交互式應用才能滿足的需求，經過四階段流水線層層過濾，最終蒸餾出500 個高質量任務，覆蓋 6 個領域、25 個細分類別、3 個難度級別。

MiniAppBench 數據集構建流水線與統計概覽

Stage 1：識別原則驅動的交互式需求。不是所有需求都適合變成 MiniApp。大量需求是純信息查詢、模糊不清、或者簡單到不需要交互。研究團隊從千萬級數據中先經 LLM 篩選，再由人類專家逐條審核，確保每個需求都隱含了現實世界原則、且需要定制化交互來滿足。

Stage 2：擴展覆蓋面，保留核心意圖。在 1123 條高質量種子需求的基礎上，通過 LLM 擴展生成變體，覆蓋更多領域和難度，同時嚴格保留原始需求的主題和意圖。擴展后的需求同樣經過人工審核，確保擴展過程沒有偏離原始意圖。

Stage 3：錨定可驗證的評測參考（Eval-Ref）。這是 MiniAppBench 區別于其他開放式評測的關鍵一步。對每個需求，研究者生成了一份結構化的評測參考，列出意圖、靜態實現和動態交互中需要驗證的關鍵檢查點。比如「水蒸發演示」的 Eval-Ref 會明確指出需要檢查蒸發是否遵循物理定律、粒子是否有加速逸出行為。但這份參考不是唯一的評判標準，而是輔助評估 Agent 定位潛在問題的指南針。

Stage 4：平衡難度與領域覆蓋。最終分層抽樣選出 500 個任務，難度分布為 30% Easy / 40% Mid / 30% Hard，六個領域分別為：Science（科學）、Games（游戲）、Tools（工具）、Humanities（人文）、Visualization（可視化）、Lifestyle（生活），每個領域下又有 3-5 個細分類別。

6 個領域各有側重：Science 考的是物理定律和公式能不能正確實現；Games 考的是游戲邏輯和交互完備性；Tools 考的是魯棒性和邊界處理；Humanities 考的是知識落地和用戶驅動的探索；Visualization 考的是視覺編碼和精確映射；Lifestyle 考的是生活常識和個性化約束。

04 MiniAppEval：讓 AI Agent 當「人類測試員」

評測開放式交互應用，最棘手的問題是：沒有標準答案。

同一個「飲食記錄器」，你可以做成表格式的，也可以做成卡片式的，交互方式千差萬別，但都可能滿足用戶需求。用固定腳本？覆蓋不了開放式實現。用截圖對比？看不出交互邏輯對不對。用 A/B 偏好？過于主觀，且依賴參考實現。

MiniAppEval 的思路是：讓一個 LLM Agent 模擬人類測試員，去真的操作這個應用。

具體來說，MiniAppEval 通過 Playwright 驅動無頭瀏覽器，讓 Agent 像人一樣點擊按鈕、輸入文本、拖拽滑塊，同時實時捕獲 DOM 狀態、控制臺日志和源碼。Agent 會根據評測參考的指引，系統性地探索應用的功能和邊界，而不是按固定腳本走一遍。

評測從三個維度展開：

Intention 維度：應用是否真正滿足了用戶的意圖？你說「做一個飲食記錄器」，它確實是一個飲食記錄器，而不是一個通用的備忘錄。

Static 維度：靜態實現是否正確？頁面結構是否合理、代碼是否語法正確、必要的元素是否齊全、可訪問性是否達標。比如天氣儀表盤應該有溫度、濕度、位置字段，不管交互與否這些信息都要在。

Dynamic 維度：動態交互是否正常？這是最關鍵的一環。多步操作后狀態是否一致？因果邏輯是否成立？邊界輸入是否崩潰？比如「添加任務→標記完成→驗證從活躍列表消失」這條鏈路能不能跑通？輸入空字符串或無效日期會不會崩？水蒸發演示里粒子運動是否遵循物理定律？

三個維度各給一個 0-1 的分數，最終通過條件采用木桶原則：三個維度都 ≥ 0.8 才算通過。一個應用如果視覺很好但交互全崩，或者功能齊全但違背物理常識，都不能通過。

消融實驗也驗證了三個組件（Eval-Ref / Code 審查 / Playwright 動態測試）缺一不可的必要性：去掉 Eval-Ref，召回率暴跌 38.89 個百分點；去掉 Code 審查，精度暴跌 51.14 個百分點；去掉 Agent 動態測試，精度只剩 12.90%，說明大量交互問題只有「真的點一下」才能發現。

更關鍵的是，MiniAppEval 與人類專家評判的一致性很高：實驗顯示平均 F1 達到 92.4%，跨評估者一致性 κ = 0.89。論文還引入了雙盲評估來緩解 Agent 對圖形類查詢的確認偏差，進一步提升了對純視覺任務的判斷準確性。

05 評測結果：全球最強模型的「不及格」成績單

16 個模型，500 個任務，結果擺在面前：

16 個模型在 MiniAppBench 上的通過率排名

全部模型的平均通過率只有 17.05%。即使是最強的 GPT-5.2，也只拿到 45.46%。

這組數字背后有幾個值得細看的信息：

開源閉源差距巨大，但遠未飽和。開源最佳 GLM-4.7 通過率僅 18.31%，而閉源最佳 GPT-5.2 達到 45.46%，差距懸殊。這也說明 MiniAppBench 不是一個已經飽和的測試，而是一片真正有區分度的戰場。

難度上升，全線崩潰。頭部模型在 Easy 任務上能拿到不錯的分數（GPT-5.2 74.71%、GPT-5.1 74.71%、Claude-Sonnet-4-5 68.22%），看起來還行；但一到 Hard 任務，普遍腰斬甚至跌到個位數：GPT-5.2 跌至 18.64%，Claude-Opus-4-5 跌至 22.33%，GPT-5.1 僅剩 3.49%。多數模型在 Hard 任務上幾乎全軍覆沒，多個模型通過率為 0。這說明當任務需要同時處理復雜交互邏輯、領域特定知識和現實世界原則時，現有模型的能力天花板非常明顯。

Science 和 Tools 是最難啃的骨頭。按領域看，Visualization 和 Lifestyle 通過率相對較高（多個模型超過 30%），因為這類任務目標明確、常識約束相對簡單。但 Science 和 Tools 領域表現普遍低迷：Science 需要嚴格遵循物理定律和科學公式，Tools 需要魯棒的邏輯處理和邊界條件管理，這些對當前模型來說仍是硬挑戰。

推理開銷與性能正相關，但性價比差異顯著。Token 消耗量與通過率的相關系數為 0.84，推理時間與通過率的相關系數為 0.74，更強的模型確實需要更多算力。但同樣是通過率 40% 出頭的水平，不同模型的 Token 消耗可以相差數倍，GPT-5.2 和 Gemini-3-Pro-Preview 在相近性能下消耗更少 Token，而部分模型在同等能力下推理時間明顯更長。這意味著單純堆算力并非唯一路徑，模型架構和訓練策略的優化同樣關鍵。

06 這件事意味著什么

MiniAppBench 不只是又一個 Benchmark。它提出的是一個更根本的問題：當大模型的輸出從靜態文本走向可交互的應用，我們該如何評估它的真實能力？

傳統的代碼評測測的是「邏輯對不對」，Web 評測測的是「畫得像不像」，但 MiniAppBench 測的是「做出來的東西能不能用」。它把評估從代碼層面拉到了應用層面，從「能跑」拉到了「好用」。

這個轉變有幾個值得注意的信號：

第一，交互式應用生成正在成為大模型能力的下一個前沿。從文本到代碼到交互應用，輸出形態的復雜度在指數級增長。Karpathy 預言「動態 App 替代靜態 App Store」，Anthropic 的 Claude Code 團隊已經把「HTML 替代 Markdown」變成日常實踐。當行業共識已經向交互式輸出傾斜，卻沒有人量過模型到底能不能做好這件事。MiniAppBench 填補的正是這個空白。

第二，當前模型在原則遵循上的短板可能比想象中更嚴重。即使是最強的 GPT-5.2 也只有 45.46% 的通過率，這個天花板不是靠更多訓練數據就能輕松突破的：它涉及模型對世界知識的深度理解、對隱含約束的自動推理、以及對復雜交互邏輯的工程實現。這三件事缺一不可，而 MiniAppBench 第一次把它們放在同一個框架下度量。

第三，評估方法論本身也需要進化。固定測試用例覆蓋不了開放式生成，截圖對比看不懂交互邏輯，A/B 偏好過于主觀。MiniAppEval 展示了一種可行路徑：用 LLM Agent 模擬人類測試員，結合靜態代碼審查和動態瀏覽器操作，從意圖、靜態、動態三個維度系統性評估。這套方法論不僅適用于 MiniApp，對任何開放式代碼生成場景都有參考價值。

第四，開源模型的空間很大，但距離還很遠。MiniAppBench 的數據清晰表明，開源最佳 GLM-4.7 僅 18.31%，與閉源最佳 GPT-5.2 的 45.46% 差距超過一倍，而多數開源模型通過率在個位數。這意味著在交互應用生成這個方向上，開源社區還有大量工作要做。

07 開箱即用：5 分鐘本地跑分

https://github.com/MiniAppBench/miniappbench

MiniAppBench 已經完全開源，配套提供了端到端的評測腳手架。只需要一個 OpenAI 格式的 API Key，5 分鐘就能在本地啟動測試：

# 2 句命令安裝環境pip install -r requirements.txtplaywright install chromium# 1 句命令跑評測python -m examples.pipeline --query-file data/query_validation_100.json --index 1

結語

大模型正在從「把話說對」走向「把應用做對」。MiniAppBench 揭示了一個不容回避的事實：在交互應用生成這個更貼近真實使用場景的維度上，即便是最強的模型也只是勉強及格。17% 的平均通過率意味著，每生成 6 個交互應用，只有約 1 個能真正滿足用戶需求。

但這也意味著，這里有巨大的提升空間。當模型的交互應用生成能力從 45% 走向 90% 以上，人機交互的形態將徹底改變：每個人都可以用自然語言定制自己需要的工具，而不需要等待 App Store 里的某個開發者恰好做了你想要的東西。

從靜態文本到可交互的 HTML 應用，不只是輸出格式的變化，而是大模型與人類協作方式的根本性轉變。當 AI 不再只是回答問題，而是直接交付一個能用的應用，人機交互才真正進入下一個時代。MiniAppBench 量出了起跑線上的真實差距，也為這條賽道畫出了第一個清晰的刻度。