当AI学会"动手"：Mind Lab研究团队让聊天机器人能直接生成可操作界面

这项由Mind Lab研究团队完成的研究成果以论文预印本形式发布于2026年5月，编号为arXiv:2605.24830，分类属于人机交互（cs.HC）领域。有兴趣深入了解的读者可以通过该编号在arXiv平台查询完整论文。

**对话框里的那堵墙**

假设你打算让AI助手帮你订一家晚餐餐厅。你告诉它"附近的意大利餐厅，两个人，预算适中"，然后它问你喜欢哪种意面，你再回答，它再问你几点去，你再回答，它再问你要靠窗还是靠墙……这种来来回回的文字交流，就像两个人隔着一扇毛玻璃门，只能一个字一个字地传纸条，效率极低，体验也谈不上愉快。

这堵墙的本质，是AI目前只会"说话"，不会"动手"——它只能输出文字，却没有办法直接给你一张表单让你勾选喜好、一个滑块让你调节预算、一个日历让你选日期。所有的信息收集都得靠反复对话来完成，既耗时又容易出错。

Mind Lab的研究团队提出了一个直接打破这堵墙的方案，他们把它叫做**Macaron-A2UI**。这个系统的核心思想是：让AI在回答你的同时，直接"画"出一个可以操作的小界面，让你通过点击、滑动、选择来完成信息输入，而不是继续打字聊天。这个小界面不是预先设计好的固定按钮，而是AI根据当前对话情境实时生成的，每次都不一样，完全贴合你当下的需求。

**一、聊天框里能长出界面？先搞清楚这件事到底有多难**

在深入了解这项研究之前，有必要理解研究团队面对的挑战到底有多棘手。

表面上看，让AI生成一个界面好像不难——AI不是已经能写代码了吗？直接让它写一段网页代码，渲染出来不就行了？实际上，这条路的问题多得出乎意料。生成网页代码意味着AI可以写出任何东西，包括潜在的危险脚本，安全风险难以控制；不同设备、不同客户端的渲染结果千差万别，同一段代码在手机上可能完全显示错误；更关键的是，生成的代码对不对、能不能用，很难自动检验。

Mind Lab团队选择了一条不同的路：他们采用了一个叫做**A2UI**的声明式协议（这个协议由A2UI项目于2025年发布，版本为v0.8）。用一个更直观的比方来理解这个选择：如果让AI自由写网页代码就像给一个厨师一间空厨房，告诉他"随便做，只要好吃"——结果可能五花八门，质量无法保证——那么A2UI协议就像是给厨师一套固定的厨具清单和标准化的食材库，他只能从这套工具里选，但只要选对了，出品一定是可以端上桌的。

在这个框架下，AI不直接生成代码，而是生成一串**结构化的"指令消息"**，客户端收到这些消息后，用预先设计好的组件库来渲染界面。A2UI协议定义了四种消息类型：第一种叫`beginRendering`，意思是"开始画一个新的界面"；第二种叫`surfaceUpdate`，意思是"更新现有界面上的某个部分"；第三种叫`dataModelUpdate`，意思是"更新界面背后的数据状态"；第四种叫`deleteSurface`，意思是"把这个界面撤掉"。AI的任务，就是在回复你的时候，一边说自然语言，一边生成这些指令消息。

然而，就连在这个有约束的框架里，要做好也面临三层难关。第一层是**协议有效性**：AI生成的指令消息得完全符合A2UI的规则，格式对、字段对、引用关系对，否则客户端根本没法渲染；第二层是**交互构建质量**：即使格式完全正确，选错了组件类型（比如本该用下拉选单却用了单选按钮）、界面内容和文字回答对不上，或者跨多轮对话的状态没有正确更新，都会让用户一头雾水；第三层是**用户体验**：界面结构完美、功能正确，但如果设计得让人看了头大，或者根本不需要界面的时候硬塞一个界面进来，那对用户来说反而是负担。这三层挑战，也正是评估体系的三个维度，后文会详细展开。

**二、从零到14245：一个训练数据集是怎么"炼"出来的**

要训练一个能生成好界面的AI，首先得有大量的训练样本——也就是大量的"好的示范"。这就像培养一个有品味的厨师，光靠说教没用，得让他看大量优秀菜品的做法。

但问题是，市面上根本不存在这样的训练数据。没有人专门收集过"对话+对应的A2UI界面"这样的配对数据集。研究团队必须从头构建一个。

他们的解决思路是从已有的对话数据集出发，把这些纯文字对话"改造"成带有A2UI界面的对话。他们选择了四个来源各异的对话数据集：**MultiWOZ 2.2**，一个涵盖酒店、餐厅、出行等场景的多领域任务型对话数据集；**SGD（Schema-Guided Dialogue）**，一个覆盖更多服务领域的任务型对话数据集；**ESConv**，一个情感支持类对话数据集；以及**AnnoMI**，一个动机访谈（帮助人们建立改变决心的心理干预）类对话数据集。这四个来源的组合，让训练数据既有实用任务场景，也有温情感性场景，覆盖面相当广。

数据构建的核心流程可以理解为一条"改装流水线"。原始对话先经过**规范化处理**，把各种数据集特有的格式统一成一种标准格式，同时整理成严格的"用户-助手-用户-助手"交替形式。然后，系统会把数据集原有的标注（比如槽位信息、意图标签、情感支持策略）翻译成一种统一的"中间表示"，比如"这个助手回合需要收集用户的偏好信息，可以用选择组件来实现"。

接下来，针对不同类型的数据，团队采用了不同的转换策略。对于MultiWOZ和SGD这两个任务型数据集，转换主要靠**规则驱动**：因为这些数据集的标注已经明确说明了哪些信息需要收集、有哪些可选项，所以可以用一套确定性的规则直接生成对应的A2UI组件，LLM主要负责把界面里的文字改写得更自然。对于ESConv和AnnoMI这两个情感类数据集，数据集本身的标注并没有直接说明该生成什么界面，所以团队使用了一个**两阶段LLM流程**：第一阶段是"编辑（Editor）"，负责在全局视角下规划整段对话，决定哪些轮次应该生成界面、应该是什么类型的交互；第二阶段是"作者（Author）"，负责具体生成每个被选中轮次的界面内容，包括组件的文字、选项的语义、布局的组织方式。这种分工让"要不要生成界面"和"怎么生成界面"两个决策相互独立，各自处理得更精准。

所有生成出来的界面数据，都必须通过一条**四级验证流水线**才能进入最终数据集。第一级验证检查JSON格式是否正确可解析；第二级验证检查字段结构是否符合A2UI协议规范，组件类型、枚举值是否合法；第三级验证检查数据绑定是否正确，字段和值的类型是否匹配；第四级验证做轻量级的语义一致性检查，确保界面的结构和预期的交互语义相符。如果某个样本验证失败，系统会把错误信息反馈给LLM，让它修改后重试，最多重试三次。

结果相当理想：91.3%的界面样本在第一次生成时就通过了验证，再加上重试修复的部分，最终**99.2%的界面样本都能正确渲染**，只有85个样本在三次尝试后仍然失败。

为了弥补一些低频组件（比如日期选择器、滑块、标签页等）在数据中出现太少的问题，团队还专门做了**针对性增强**：额外生成了4165个重点覆盖这些组件的样本，占最终数据集的29.2%。这就像在厨师培训课程里，发现学生练得不够多的菜式，专门安排额外练习，而不是把所有菜式都加倍练习。

最终数据集包含**14245个助手回合样本**，涵盖10210个含有A2UI界面的"有界面回合"和4035个纯文字的"无界面回合"，整体界面生成比例为71.7%。任务型数据（MultiWOZ和SGD）的界面比例约为80%，情感类数据（ESConv和AnnoMI）约为50%，这个差异非常自然——情感对话中，有时候纯粹表达关怀、共情的文字比跳出一个选择框更合适。

**三、考卷长什么样：A2UI-Bench评测体系详解**

有了训练数据，还需要有标准化的考卷来评判模型好不好。研究团队专门构建了一个叫**A2UI-Bench**的评测基准，共包含300道题，由三类任务组成。

第一类叫**原子任务（Atomic tasks）**，是单轮、单意图的评测：给定一段对话背景和当前用户的一句话，模型产出一条助手回复，可能包含文字和A2UI界面，也可能只有文字。这类任务考察的是最基本的能力：该不该生成界面，以及生成什么界面。

第二类叫**深度任务（Depth tasks）**，是多轮一致性的评测：每道题包含同一段对话的连续几个回合，评测系统会把模型自己上一轮生成的输出当作下一轮的历史，让模型继续生成。这考察的是模型能否在对话推进过程中保持状态连贯，比如能否正确更新之前的界面、能否记住用户已经选择了什么。

第三类叫**宽度任务（Width tasks）**，是单轮但多意图的评测：一个用户请求里包含好几个不同的信息需求，跨越多个场景或服务，模型需要在一个回复里把它们都组织进来，既不能漏掉，也不能把界面做得让人眼花缭乱。

考卷本身还特别包含了"不该生成界面"的反例——当用户只是在聊天、表达情绪或者提问时，模型不应该莫名其妙地弹出一个表单，这种情况叫`no_ui_chat`。能正确识别这种情况并保持纯文字回复，也是评测的一部分。

评分体系分为**语言侧**和**视觉侧**两个大维度。

语言侧评分有三个层次，可以理解为从基础到高阶的递进关系。最基础的**L1层**衡量协议正确性，通过五个自动化维度来打分：JSON能不能正确解析（L1-1）、结构是否符合A2UI的规范（L1-2）、引用关系是否完整（L1-3）、必填字段是否齐全（L1-4）、字段值的格式是否正确（L1-5）。L1有一个"可靠性门槛"逻辑：如果JSON本身就解析不了，五个子维度全部得零分；如果解析成功但有结构性错误，只有L1-1得分，其余四个为零；只有完全通过结构检查，才按照发现的警告问题来扣分。

中间层的**L2层**衡量任务构建质量，由LLM充当裁判来打分，包含五个维度：触发决策是否恰当（L2-1，即该不该在这个时机生成界面）、组件类型与交互意图是否匹配（L2-2，比如选择类任务该用选择组件而不是文字罗列）、界面内容是否与文字回复一致（L2-3，界面里出现的选项必须在文字里有对应说明）、数据状态管理是否合理（L2-4，动态收集的信息应该正确写入数据模型）、交互组件是否有完整的动作回路（L2-5，有可点击的组件就必须有对应的动作定义）。

最高层的**L3层**衡量用户体验质量，同样由LLM评判，包含三个维度：界面相比纯文字有没有带来实质价值（L3-1，如果界面只是把文字重新排版了一遍，那就是无效的）、文字到界面的过渡是否自然（L3-2，界面出现的时机和方式是否让用户感觉顺畅）、单次交互的认知负荷是否可控（L3-3，一个界面里塞太多东西、选项太多，都会让用户头大）。

视觉侧评分则是真正把模型生成的A2UI消息通过Flutter Web渲染成实际界面，截图后交给视觉语言模型（VLM）来评判，从视觉完整性（V1，界面有没有溢出、裁剪、布局错乱等问题）、任务对齐度（V2，视觉界面是否真的匹配任务需求）和操作清晰度（V3，用户看了界面能不能一眼知道该怎么操作）三个维度打分。

这套评测体系的设计思路，正是对应了前面说的三层挑战：L1对应协议有效性，L2对应交互构建质量，L3和视觉侧评分对应用户体验。

**四、怎么训练：两阶段食谱**

数据集有了，考卷有了，接下来是训练过程。研究团队设计了一个**两阶段训练方案**，两个阶段各有分工，互相配合。

理解这个方案，可以用学厨的过程来类比。第一阶段是学基本功：照着食谱一步步练，把刀工、火候、调味的基本操作练扎实。第二阶段是打比赛：参加烹饪竞赛，每次出菜都有专业评委打分，根据评分反复调整，把真正受欢迎的做法找出来。

**第一阶段叫监督微调（SFT）**。研究团队在Qwen3-30B-A3B-Instruct-2507和Qwen3-235B-A22B-Instruct-2507这两个基础模型上（数字代表参数规模，大致可以理解为模型的"大脑容量"），以及一个额外的GLM-5.1模型上，用前面构建的14245个训练样本来训练。每个训练样本是一个"对话上下文→目标回复"的配对，目标回复永远遵循同样的JSON格式：`{"text_response": "...", "a2ui": [...]}`。训练时，模型看到上下文，生成回复，只计算最后那条助手回复的预测误差，然后用这个误差来调整模型参数。通过大量这样的训练，模型学会了基本的格式规范和文本-界面联合生成能力。

为了效率，这个阶段采用了一种叫**LoRA**的"轻量级微调"技术。这就像不是把整本教科书重新印刷，而是在书的空白处加注释——只更新模型中一小部分低秩参数，而不是全量调整所有参数，大大降低了计算成本。LoRA的秩（rank）设为16，批量大小为32，学习率为万分之一，训练一个完整轮次。

**第二阶段叫GRPO强化学习**，全称是Group Relative Policy Optimization（分组相对策略优化）。这个阶段从SFT训练出来的模型出发，进一步优化。其工作方式是：对于每一个训练提示，同时生成8个不同的候选回复，然后用一个奖励函数给每个回复打分，计算每个回复和这8个候选平均分之间的差距，鼓励模型在同一个问题上生成得比平均水平更好的回复。

奖励函数的设计紧紧围绕A2UI的实际使用质量：首先有"硬门槛"，如果JSON格式错误、该生成界面时没生成、协议验证失败或者有会导致渲染崩溃的结构错误，直接得零分；通过硬门槛的回复，才按照结构质量分（SL1，对应L1维度）、任务构建质量分（SL2，对应L2维度）和用户体验分（SL3，对应L3维度）的加权组合来计算奖励，权重分别是0.2、0.4和0.4。

GRPO训练了50步，学习率为万分之三，每次采样温度为1.0，用于打分的LLM裁判是openai/gpt-5.1。

**五、实验结果：数字背后的故事**

现在来看看这套方案的效果到底如何。

研究团队把自己的模型（统称Macaron-A2UI系列，30B规模的叫Tall，235B规模的叫Grande，基于GLM-5.1的754B规模的叫Venti）和多个当前最强的前沿大模型进行了对比。这些基准模型包括GPT-5.4、Gemini-3.1-Pro、DeepSeek-V3.1、Qwen3-235B-A22B-Instruct等，并且区分了两种评测条件：不告诉模型完整的A2UI规范（"轻提示"条件）和把完整的A2UI规范塞进提示词里（"重提示"条件）。

先看轻提示条件下的对比，也就是只告诉模型A2UI的基本概念，但不提供详细规范。没有经过专门训练的前沿大模型表现出奇地差：GPT-4o-mini整体得分只有25.5，DeepSeek-V3.1只有21.9，GPT-5.4只有23.9。所有的L1、L2、L3分数都很低，说明光靠"聪明"，没有专门训练，这些模型根本没办法稳定地生成符合A2UI规范的界面。

反观Macaron-A2UI系列，效果相当显著。以30B规模的模型为例：基础模型（没有任何微调）整体得分19.8，经过SFT之后提升到37.2，再经过GRPO强化学习之后进一步提升到58.8，L1分数从0.90一路攀升到4.11。235B规模的模型进步更为明显：从基础模型的21.6，经SFT升至63.6，再经GRPO升至74.2。最终，基于GLM-5.1的Macaron-A2UI-Venti以75.6的整体得分成为表现最强的模型。

再看重提示条件下的上界对比。当把完整的A2UI规范塞进提示词时，前沿大模型确实变强了很多：DeepSeek-V3.1达到63.8，Gemini-3.1-Pro达到71.0，GPT-5.4达到74.1。但Macaron-A2UI-Grande（74.2）和Macaron-A2UI-Venti（75.6）在**不依赖完整规范的情况下**，已经超越了所有重提示基准——这意味着能力被真正内化到模型里，不需要每次推理时都携带大量的规范说明。

从任务类型分解来看，Macaron-A2UI-235B在原子任务（单轮单意图）上得分4.38，在宽度任务（单轮多意图）上得分3.96，都是所有模型中最高的；在深度任务（多轮一致性）上得分3.14，排第二，略低于GPT-5.4的3.34。这说明强化学习主要强化了模型把对话意图精准转化为界面的能力，而跨多轮保持状态一致性仍然是一个相对更难攻克的问题。

从四个数据集领域的表现来看，Macaron-A2UI-235B在MultiWOZ、SGD、ESConv、AnnoMI上的得分都落在3.82到3.84这个极窄的区间内，显示出强劲的跨领域泛化能力，无论是订餐订房这样的实用场景，还是情感支持这样的感性场景，表现都相当稳定。

强化学习训练过程中奖励的变化轨迹也颇为耐人寻味。L1奖励（协议正确性）在训练早期就快速攀升，而L2奖励（任务构建质量）和L3奖励（用户体验）则是缓慢而稳定地提升。这个模式很直观：告诉模型"格式不对得零分"这样的硬规则，模型学得很快；但"界面是否真的对用户有帮助""过渡是否自然"这类更抽象的品质，需要更多训练才能慢慢习得。

对于235B的大模型，L2和L3奖励在整个训练过程中都持续稳定提升，说明在协议能力稳定之后，更大的模型还能继续打磨任务构建和用户体验。30B的小模型则有所不同：L2奖励仍在提升，但L3奖励几乎保持平坦，说明用户体验这个最抽象的维度对小模型来说是最难突破的天花板。

**六、界面背后的组件库和自动渲染系统**

为了支撑视觉侧的评估，研究团队还专门搭建了一个真实可用的渲染系统，用Flutter Web框架实现，能把AI生成的A2UI消息真正渲染成用户可以看到的界面并截图。

这套系统支持的组件库叫Macaron设计目录，共包含23种组件，按照功能分为四大类。第一类是**交互组件**，包括SelectionList（纵向选择列表，支持多选、有最小最大选择数限制）、SelectionGrid（网格选择，适合图文并排的选项）、SelectionWrap（横向流式排列的标签式多选，适合关键词选择）、OrderedSelectionList（有序选择列表，选择顺序会以数字徽章显示）、ActionSelectionList（单选即触发动作的列表）、DropdownSelection（下拉选单）、DateTimeInput（日期/时间选择器）、PasswordKeypad（六位数字键盘，输满自动提交）、TickSlider（离散刻度滑块，比如评分或进度选择）和Button（三种视觉风格的可点击按钮）。第二类是**导航与覆盖层组件**，包括Tabs（胶囊式标签切换，带动画效果）、Carousel（横向翻页展示）和FullScreenModal（全屏弹层）。第三类是**展示组件**，包括Label（支持27种样式组合的文字）、MarkdownView（能渲染Markdown格式的富文本）、LinearProgress（横向进度条）、CircularProgress（环形进度指示）、Image（网络或本地图片，四种尺寸预设）、Icon（支持线性和填充两种风格的图标，来自一个自定义图标库）和OrderedDisplayList（带固定编号的静态列表）。第四类是**布局组件**，包括Card（圆角背景卡片）、Column（纵向排列容器）、Row（横向排列容器）和Divider（分隔线）。

渲染流程的工作方式是：AI生成的A2UI消息序列被传入渲染器，渲染器按顺序处理每条消息，逐步构建和更新界面的组件树，而不是每次都从头重建。这种增量式更新的设计，对实际产品的响应速度非常重要。

视觉评估时，系统会用Playwright工具控制Chromium浏览器，访问渲染页面，等待渲染完成的信号，然后截图，再自动裁剪掉多余的空白边缘，得到实际内容区域的截图。对于多轮对话的深度任务，每一轮都会独立生成一张截图来评估，确保中间某轮的视觉问题不会被最后一轮的"幸运正确"所掩盖。

值得一提的是，视觉评估还专门设置了一个"渲染前检查"门槛，会提前用七条确定性规则检测那些能通过格式验证但实际上会导致渲染崩溃的问题。比如，TickSlider滑块不能直接放在Row（横排容器）里，因为这会触发Flutter布局引擎的无限宽度崩溃；一个回复里只能有一个surfaceId（界面ID）；按钮的动作上下文必须是JSON数组而不是字典；等等。通不过这些检查的样本，会被排除出视觉评估，并且在L2和L3分数上受到惩罚。

**说到底，这项研究意味着什么**

归根结底，Macaron-A2UI做成的事情，是把AI助手从一个"只会说话的顾问"变成了一个"能动手帮你填表格的助手"。这个变化看似微小，但对实际使用体验的改变可能是质的飞跃。

更深层的意义在于，这项研究验证了一种方法论：生成界面这种能力，不需要每次在提示词里塞入大量规范说明，也不需要一个额外的"界面生成模块"，而是可以通过训练真正内化到语言模型里，成为模型自然对话能力的一部分。这就好比一个厨师，不用每次做菜前都翻看厚厚的菜谱，因为那些食材搭配和火候控制已经成了肌肉记忆。

当然，这项研究也坦诚地列出了自身的局限。A2UI协议目前还是0.8版本，仍在演进中，意味着训练好的模型可能需要随协议更新而跟进调整。在复杂多轮交互和用户体验细节方面，模型（尤其是30B规模）仍有明显的提升空间。此外，推理时同时生成文字、验证结构、渲染界面，对响应延迟也会带来一定压力，这在实时对话产品中是需要认真考量的工程挑战。

研究团队已经开放了模型权重、评测基准和评测协议，这对整个领域的后续研究是相当实质性的贡献。下一个值得关注的方向，是如何让这套系统变得更高效、更通用、更省token，以及如何支持更复杂、更长的多轮交互场景。

如果这项研究让你产生了浓厚兴趣，可以通过arXiv编号2605.24830找到原论文，题目是《Macaron-A2UI: A Model for Generative UI in Personal Agents》，发布于2026年5月。

---

**Q&A**

Q1：A2UI协议和普通网页代码生成有什么区别，为什么要用A2UI而不是直接让AI写HTML？

A：A2UI是一种声明式协议，AI只负责生成结构化的指令消息，实际界面由客户端用预先设计好的组件库来渲染。直接生成HTML代码的问题有三个：安全风险难以控制（任意代码可能包含危险脚本）、不同设备渲染结果差异大、生成结果正确与否很难自动检验。A2UI把AI可以"说什么"限制在一个明确的组件清单里，既安全，又便于自动验证，还能跨平台统一渲染。

Q2：Macaron-A2UI的训练数据是从哪里来的，为什么要用四个不同的数据集？

A：训练数据来自四个现有的对话数据集：MultiWOZ 2.2和SGD是任务型对话（订餐、订房等场景），ESConv是情感支持对话，AnnoMI是动机访谈对话。选择这四个是为了让训练数据覆盖尽可能多的对话类型——既有实用任务场景，也有情感和心理支持场景。研究团队把这些纯文字对话通过规则和LLM的混合方式转换成了带有A2UI界面的对话，共得到14245个训练样本。

Q3：Macaron-A2UI在评测中比GPT-5.4表现好，是因为模型本身更聪明，还是因为专门训练过？

A：主要是因为专门训练过。在没有A2UI规范说明的轻提示条件下，GPT-5.4的整体得分只有23.9，DeepSeek-V3.1只有21.9，而经过SFT加强化学习的Macaron-A2UI-Venti达到75.6。即使给GPT-5.4提供完整的A2UI规范说明，它也只能达到74.1。这说明通过专门的数据和两阶段训练，可以把生成界面的能力真正内化到模型里，不依赖冗长的规范提示也能稳定工作，而未经训练的通用大模型在这项任务上表现很差。