想象一下，你问 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 AssistantsarXiv 地址：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 分钟就能在本地启动测试：

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 量出了起跑线上的真实差距，也为这条赛道画出了第一个清晰的刻度。