想象一下，你問(wèn) AI 要一個(gè)飲食記錄工具，它不再是回你一段文字建議，而是直接給你一個(gè)可以點(diǎn)擊添加、統(tǒng)計(jì)熱量的完整應(yīng)用。人和 AI 的交互，正在從「讀文字」走向「用應(yīng)用」。

Karpathy 早在 X 上反復(fù)說(shuō)過(guò)這件事：「App Store 作為一組離散應(yīng)用供用戶選擇的模式，正在成為一個(gè)日益過(guò)時(shí)的概念。未來(lái)在于利用 LLM 技術(shù)將 AI 原生傳感器和執(zhí)行器整合到高度定制化的、即開即用的應(yīng)用程序中?！?/p>

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

這些觀點(diǎn)并非小圈子的自嗨，而是引發(fā)了廣泛共鳴。但當(dāng)所有人都在談?wù)?"AI 應(yīng)該輸出 HTML" 的時(shí)候，一個(gè)更深層的問(wèn)題被忽略了：生成一個(gè) HTML 頁(yè)面容易，生成一個(gè)真正可交互、邏輯正確、且符合現(xiàn)實(shí)世界規(guī)律的 HTML 應(yīng)用，難得多。大模型生成這類交互應(yīng)用的真實(shí)水平到底怎樣？沒(méi)有人量過(guò)。

來(lái)自螞蟻集團(tuán)靈光 App 閃應(yīng)用團(tuán)隊(duì)的研究者做了這件事。他們提出了MiniAppBench，首個(gè)專門評(píng)測(cè)大模型生成「交互式 HTML 應(yīng)用」能力的基準(zhǔn)，結(jié)合配套的自動(dòng)化評(píng)估系統(tǒng) MiniAppEval，對(duì)全球 16 個(gè)頂尖模型進(jìn)行了系統(tǒng)性測(cè)試。

結(jié)果讓人警醒：大模型的代碼能力，遠(yuǎn)不足以生成真正能用的交互應(yīng)用，最強(qiáng)模型通過(guò)率也僅 45% 左右，平均只有 17%。

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

• 論文標(biāo)題：MiniAppBench: Evaluating the Shift from Text to Interactive HTML Responses in LLM-Powered Assistants
• arXiv 地址：https://openreview.net/pdf?id=pwbLmew1aq
• 項(xiàng)目主頁(yè)：https://miniappbench.github.io/
• 代碼倉(cāng)庫(kù)：https://github.com/MiniAppBench/miniappbench

3 個(gè)看點(diǎn)先讀

1.定義 AI 時(shí)代人機(jī)交互新范式：論文正式提出「MiniApp」概念，即由大模型依據(jù)用戶單條 Query 即時(shí)生成的定制化 HTML 交互應(yīng)用。當(dāng) Markdown 已經(jīng)無(wú)法承載越來(lái)越復(fù)雜的 AI 輸出，MiniApp 代表了從靜態(tài)文本到可交互應(yīng)用的范式轉(zhuǎn)移。

2.全球最強(qiáng)模型集體「汗流浹背」：16 個(gè)模型評(píng)測(cè)，最高通過(guò)率僅 45.46%，平均僅 17%。在 Hard 難度任務(wù)上，幾乎所有模型通過(guò)率都跌到個(gè)位數(shù)。這不是一個(gè)飽和的 Benchmark。

3.用 AI Agent 當(dāng)「人類測(cè)試員」：MiniAppEval 不靠固定腳本打分，不靠截圖比對(duì)，而是讓一個(gè)基于 LLM 的 Agent 模擬人類測(cè)試員去點(diǎn)擊、拖拽、輸入，從意圖、靜態(tài)、動(dòng)態(tài)三個(gè)維度全方位測(cè)試，與真人打分相關(guān)性高達(dá) 0.85 以上。

01 從文本到交互：AI 人機(jī)交互的新范式

當(dāng)大模型的輸出從「回答問(wèn)題」變成「交付應(yīng)用」，交互方式本身也在發(fā)生根本性的變化。

過(guò)去，你問(wèn)模型一個(gè)問(wèn)題，它回答一段文字，靜態(tài)的、一次性的，讀完就結(jié)束了。但現(xiàn)在，你可以對(duì)模型說(shuō)「幫我做一個(gè)牛頓定律演示工具」，它就能給你一個(gè)真的能撥動(dòng)質(zhì)量滑塊、實(shí)時(shí)看到力學(xué)動(dòng)畫的交互界面。你說(shuō)「幫我記錄每周飲食」，它不是給你一個(gè)文字版的食譜建議，而是直接給你一個(gè)帶七天三餐表格、可以點(diǎn)擊添加、可以統(tǒng)計(jì)熱量的飲食記錄器。

這就是論文定義的MiniApp：由模型依據(jù)單條 Query 即時(shí)生成的定制化 HTML 交互應(yīng)用。

從傳統(tǒng)文本輸出到 MiniApp 的范式轉(zhuǎn)移

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

關(guān)鍵在于，MiniApp 不只是「好看的網(wǎng)頁(yè)」。論文明確指出，它有兩大核心屬性：

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

前者考察的是模型對(duì)世界知識(shí)的理解深度，后者考察的是把理解轉(zhuǎn)化為可執(zhí)行代碼的工程能力。兩者缺一不可，而現(xiàn)有 Benchmark 對(duì)兩者都缺乏有效的評(píng)測(cè)手段。

02 現(xiàn)有 Benchmark 為什么量不了這件事

現(xiàn)有的代碼評(píng)測(cè)和 Web 評(píng)測(cè)，都很難覆蓋 MiniApp 的核心能力。

代碼類 Benchmark（HumanEval、MBPP、SWE-Bench 等）：測(cè)的是算法邏輯對(duì)不對(duì)、函數(shù)能不能過(guò)測(cè)試用例。代碼在這里是抽象的邏輯符號(hào)，跟執(zhí)行環(huán)境、用戶交互無(wú)關(guān)。一個(gè)能寫快排的模型，不代表它能理解「一周有七天」并把這種常識(shí)編碼進(jìn)交互邏輯。

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

已有的 Agent 評(píng)測(cè)（ArtifactsBench、WebDevJudge 等）：雖然開始關(guān)注交互性，但主要依賴 A/B 偏好對(duì)比或與參考實(shí)現(xiàn)的偏差打分。MiniApp 的本質(zhì)是開放式的：同一個(gè)需求可以有無(wú)數(shù)種合理的實(shí)現(xiàn)方式，不存在唯一的 Ground Truth。拿固定答案去評(píng)判開放式產(chǎn)出，要么太松放過(guò)錯(cuò)誤，要么太嚴(yán)誤殺合理方案。

MiniAppBench 要回答的問(wèn)題是：模型能不能理解用戶的隱含需求，并把它變成一個(gè)真正能用的、遵循現(xiàn)實(shí)世界原則的交互應(yīng)用？這個(gè)問(wèn)題，之前沒(méi)有任何 Benchmark 系統(tǒng)性地回答過(guò)。

03 MiniAppBench：從一千萬(wàn)條真實(shí)交互中蒸餾 500 道題

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

它的起點(diǎn)是大規(guī)模真實(shí)場(chǎng)景中積累的超過(guò) 1000 萬(wàn)條交互需求。研究者從中篩選出真正需要交互式應(yīng)用才能滿足的需求，經(jīng)過(guò)四階段流水線層層過(guò)濾，最終蒸餾出500 個(gè)高質(zhì)量任務(wù)，覆蓋 6 個(gè)領(lǐng)域、25 個(gè)細(xì)分類別、3 個(gè)難度級(jí)別。

MiniAppBench 數(shù)據(jù)集構(gòu)建流水線與統(tǒng)計(jì)概覽

Stage 1：識(shí)別原則驅(qū)動(dòng)的交互式需求。不是所有需求都適合變成 MiniApp。大量需求是純信息查詢、模糊不清、或者簡(jiǎn)單到不需要交互。研究團(tuán)隊(duì)從千萬(wàn)級(jí)數(shù)據(jù)中先經(jīng) LLM 篩選，再由人類專家逐條審核，確保每個(gè)需求都隱含了現(xiàn)實(shí)世界原則、且需要定制化交互來(lái)滿足。

Stage 2：擴(kuò)展覆蓋面，保留核心意圖。在 1123 條高質(zhì)量種子需求的基礎(chǔ)上，通過(guò) LLM 擴(kuò)展生成變體，覆蓋更多領(lǐng)域和難度，同時(shí)嚴(yán)格保留原始需求的主題和意圖。擴(kuò)展后的需求同樣經(jīng)過(guò)人工審核，確保擴(kuò)展過(guò)程沒(méi)有偏離原始意圖。

Stage 3：錨定可驗(yàn)證的評(píng)測(cè)參考（Eval-Ref）。這是 MiniAppBench 區(qū)別于其他開放式評(píng)測(cè)的關(guān)鍵一步。對(duì)每個(gè)需求，研究者生成了一份結(jié)構(gòu)化的評(píng)測(cè)參考，列出意圖、靜態(tài)實(shí)現(xiàn)和動(dòng)態(tài)交互中需要驗(yàn)證的關(guān)鍵檢查點(diǎn)。比如「水蒸發(fā)演示」的 Eval-Ref 會(huì)明確指出需要檢查蒸發(fā)是否遵循物理定律、粒子是否有加速逸出行為。但這份參考不是唯一的評(píng)判標(biāo)準(zhǔn)，而是輔助評(píng)估 Agent 定位潛在問(wèn)題的指南針。

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

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

04 MiniAppEval：讓 AI Agent 當(dāng)「人類測(cè)試員」

評(píng)測(cè)開放式交互應(yīng)用，最棘手的問(wèn)題是：沒(méi)有標(biāo)準(zhǔn)答案。

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

MiniAppEval 的思路是：讓一個(gè) LLM Agent 模擬人類測(cè)試員，去真的操作這個(gè)應(yīng)用。

具體來(lái)說(shuō)，MiniAppEval 通過(guò) Playwright 驅(qū)動(dòng)無(wú)頭瀏覽器，讓 Agent 像人一樣點(diǎn)擊按鈕、輸入文本、拖拽滑塊，同時(shí)實(shí)時(shí)捕獲 DOM 狀態(tài)、控制臺(tái)日志和源碼。Agent 會(huì)根據(jù)評(píng)測(cè)參考的指引，系統(tǒng)性地探索應(yīng)用的功能和邊界，而不是按固定腳本走一遍。

評(píng)測(cè)從三個(gè)維度展開：

Intention 維度：應(yīng)用是否真正滿足了用戶的意圖？你說(shuō)「做一個(gè)飲食記錄器」，它確實(shí)是一個(gè)飲食記錄器，而不是一個(gè)通用的備忘錄。

Static 維度：靜態(tài)實(shí)現(xiàn)是否正確？頁(yè)面結(jié)構(gòu)是否合理、代碼是否語(yǔ)法正確、必要的元素是否齊全、可訪問(wèn)性是否達(dá)標(biāo)。比如天氣儀表盤應(yīng)該有溫度、濕度、位置字段，不管交互與否這些信息都要在。

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

三個(gè)維度各給一個(gè) 0-1 的分?jǐn)?shù)，最終通過(guò)條件采用木桶原則：三個(gè)維度都 ≥ 0.8 才算通過(guò)。一個(gè)應(yīng)用如果視覺很好但交互全崩，或者功能齊全但違背物理常識(shí)，都不能通過(guò)。

消融實(shí)驗(yàn)也驗(yàn)證了三個(gè)組件（Eval-Ref / Code 審查 / Playwright 動(dòng)態(tài)測(cè)試）缺一不可的必要性：去掉 Eval-Ref，召回率暴跌 38.89 個(gè)百分點(diǎn)；去掉 Code 審查，精度暴跌 51.14 個(gè)百分點(diǎn)；去掉 Agent 動(dòng)態(tài)測(cè)試，精度只剩 12.90%，說(shuō)明大量交互問(wèn)題只有「真的點(diǎn)一下」才能發(fā)現(xiàn)。

更關(guān)鍵的是，MiniAppEval 與人類專家評(píng)判的一致性很高：實(shí)驗(yàn)顯示平均 F1 達(dá)到 92.4%，跨評(píng)估者一致性 κ = 0.89。論文還引入了雙盲評(píng)估來(lái)緩解 Agent 對(duì)圖形類查詢的確認(rèn)偏差，進(jìn)一步提升了對(duì)純視覺任務(wù)的判斷準(zhǔn)確性。

05 評(píng)測(cè)結(jié)果：全球最強(qiáng)模型的「不及格」成績(jī)單

16 個(gè)模型，500 個(gè)任務(wù)，結(jié)果擺在面前：

16 個(gè)模型在 MiniAppBench 上的通過(guò)率排名

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

這組數(shù)字背后有幾個(gè)值得細(xì)看的信息：

開源閉源差距巨大，但遠(yuǎn)未飽和。開源最佳 GLM-4.7 通過(guò)率僅 18.31%，而閉源最佳 GPT-5.2 達(dá)到 45.46%，差距懸殊。這也說(shuō)明 MiniAppBench 不是一個(gè)已經(jīng)飽和的測(cè)試，而是一片真正有區(qū)分度的戰(zhàn)場(chǎng)。

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

Science 和 Tools 是最難啃的骨頭。按領(lǐng)域看，Visualization 和 Lifestyle 通過(guò)率相對(duì)較高（多個(gè)模型超過(guò) 30%），因?yàn)檫@類任務(wù)目標(biāo)明確、常識(shí)約束相對(duì)簡(jiǎn)單。但 Science 和 Tools 領(lǐng)域表現(xiàn)普遍低迷：Science 需要嚴(yán)格遵循物理定律和科學(xué)公式，Tools 需要魯棒的邏輯處理和邊界條件管理，這些對(duì)當(dāng)前模型來(lái)說(shuō)仍是硬挑戰(zhàn)。

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

06 這件事意味著什么

MiniAppBench 不只是又一個(gè) Benchmark。它提出的是一個(gè)更根本的問(wèn)題：當(dāng)大模型的輸出從靜態(tài)文本走向可交互的應(yīng)用，我們?cè)撊绾卧u(píng)估它的真實(shí)能力？

傳統(tǒng)的代碼評(píng)測(cè)測(cè)的是「邏輯對(duì)不對(duì)」，Web 評(píng)測(cè)測(cè)的是「畫得像不像」，但 MiniAppBench 測(cè)的是「做出來(lái)的東西能不能用」。它把評(píng)估從代碼層面拉到了應(yīng)用層面，從「能跑」拉到了「好用」。

這個(gè)轉(zhuǎn)變有幾個(gè)值得注意的信號(hào)：

第一，交互式應(yīng)用生成正在成為大模型能力的下一個(gè)前沿。從文本到代碼到交互應(yīng)用，輸出形態(tài)的復(fù)雜度在指數(shù)級(jí)增長(zhǎng)。Karpathy 預(yù)言「動(dòng)態(tài) App 替代靜態(tài) App Store」，Anthropic 的 Claude Code 團(tuán)隊(duì)已經(jīng)把「HTML 替代 Markdown」變成日常實(shí)踐。當(dāng)行業(yè)共識(shí)已經(jīng)向交互式輸出傾斜，卻沒(méi)有人量過(guò)模型到底能不能做好這件事。MiniAppBench 填補(bǔ)的正是這個(gè)空白。

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

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

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

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

https://github.com/MiniAppBench/miniappbench

MiniAppBench 已經(jīng)完全開源，配套提供了端到端的評(píng)測(cè)腳手架。只需要一個(gè) OpenAI 格式的 API Key，5 分鐘就能在本地啟動(dòng)測(cè)試：

# 2 句命令安裝環(huán)境pip install -r requirements.txtplaywright install chromium# 1 句命令跑評(píng)測(cè)python -m examples.pipeline --query-file data/query_validation_100.json --index 1

結(jié)語(yǔ)

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

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

從靜態(tài)文本到可交互的 HTML 應(yīng)用，不只是輸出格式的變化，而是大模型與人類協(xié)作方式的根本性轉(zhuǎn)變。當(dāng) AI 不再只是回答問(wèn)題，而是直接交付一個(gè)能用的應(yīng)用，人機(jī)交互才真正進(jìn)入下一個(gè)時(shí)代。MiniAppBench 量出了起跑線上的真實(shí)差距，也為這條賽道畫出了第一個(gè)清晰的刻度。