4月16日至18日，QCon全球软件开发大会·2026北京站在北京成功举办。本届大会汇聚了来自阿里、腾讯、百度、华为、蚂蚁、字节跳动、小米等一线科技企业的技术专家，带来多项AI 技术真实落地案例，系统性分享前沿洞察与实战干货。
在本次会议上，生成式UI（Generative UI） 成为"下一代交互架构：LUI与GUI的融合"专题中非常受关注的技术方向之一。来自OpenTiny团队的高级开发工程师林瑞虹，带来了一场题为《生成式UI：AI交互新模式探索》的硬核分享，与现场技术同行共同探讨了生成式UI的技术原理、落地扩展、度量体系以及标准化方向。
本次分享带你一文读懂------生成式UI究竟是什么？它能解决什么问题？我们离"界面隐形、意图直达"还有多远？
看点回顾：
林瑞虹老师的分享从一个关键问题开始：为什么纯文本对话越来越难以承载复杂任务？通过与传统文本交互的逐一对比，她揭示了生成式UI在信息降维、操作效率和体验个性化上的独特价值。
01 痛点：纯文本对话，到底卡在哪？
传统的AI文本对话，大多还是"你问我答、长文本刷屏"。用户需要从大段文字中自己"挖矿"------提取关键数字、理解操作步骤、再手动输入指令......
这种体验在复杂任务面前，问题暴露无遗：
- 信息密度低： 一份销售数据，AI输出几百字描述，远不如一张柱状图来得直观
- 交互断裂： 看完 → 理解 → 手动输入 → 发送，多轮操作效率极低
- 工具调用门槛高： 用户需要自己理解参数格式、组织输入，AI成了"高高在上的顾问"
生成式UI的答案很简单：让AI直接"画"出界面。 
02 生成式UI：从"对话"到"界面即交互"
生成式UI的核心机制是：在对话过程中，动态生成并实时渲染表单、按钮、图表、卡片等可视化组件。用户直接操作界面，操作结果即时回传模型，实现交互与对话的无缝融合。
分享中用三个关键词概括它的价值：
- 信息降维： 复杂数据 → 柱状图/饼图，一眼看懂趋势
- 直观高效： 点击代替输入，多轮选择变成一键确认
- 千人千面： 告别"预制"界面，根据偏好实时调整配色、布局、文案
OpenTiny开源的 GenUI SDK 正是这一理念的落地实践。它支持Vue/Angular双框架渲染，开箱即用，目前已开放体验：
GitHub：github.com/opentiny/ge...
那么，生成式UI究竟是如何实现的？又该如何真正落地到业务中？带着这些问题，瑞虹老师将分享引向更深一层------围绕GenUI SDK，详解生成式UI的原理机制与场景扩展能力。
03 原理揭秘：结构化输出 + 流式渲染 + 缓冲保护区
要让AI稳定地"画"出界面，背后有三项关键机制：
1️⃣ 结构化输出
大模型不再输出纯文本，而是输出JSON格式的UI声明（类似低代码协议）。前端拿到这份声明，就知道该画什么组件、放在哪、有什么交互。
2️⃣ 流式增量渲染
大模型的输出是"流式"的。GenUI采用diff-patch机制，接收到部分信息就立即渲染，不用等全部生成完。用户感知到的就是内容一点点"长"出来，体验流畅，内存占用也更低。
3️⃣ 缓冲保护区
大模型偶尔会输出不完整或错误的片段。缓冲区会拦截这些"脏数据"，等下一轮稳定更新再推送，避免界面闪烁或崩溃。
04 场景落地：不止是卡片，更是完整应用
生成式UI要想真正赋能业务，必须具备三大扩展能力：
🧩 物料可定制扩展
企业可以将自己的品牌组件库（比如华为云的拓扑图组件、内部系统的搜索框）接入系统。AI生成UI时会优先使用这些定制物料，确保视觉统一、业务适配。
🔄 交互上下文扩展
跳出"对话框内"的限制。卡片点击可以触发页面其他模块的功能，甚至可以没有对话框------纯界面操作也能驱动AI下一步动作。实现方式是通过通用Action上下文工具，在系统提示词中告诉模型有哪些Action可用。
📱 生成式MiniApp
最令人兴奋的方向之一：通过多轮对话，让AI生成完整的小程序。从需求收集 → 规格文档 → 代码生成 → 局部修改，全流程AI驱动。支持多页嵌套、路由、API调用，甚至可以将已有小程序作为模版实时内嵌。
现场还分享了操作协议的优化经验：相比标准的RFC 6902 JSON Patch（依赖数组下标，大模型容易写错），采用带ID的变体协议，通过唯一标识定位元素，大幅提升生成正确率。 
技术原理再先进，终究要回到真实业务中接受检验。OpenTiny团队在产品演进过程中收到了部分用户反馈，瑞虹老师在大会上也不回避这些问题，坦诚地指出了当前生成式UI在实际落地中的几大局限。
05 挑战与度量：如何让生成式UI"可用"又"好用"？
当前的问题：
- 大模型输出不稳定，有时候会"画歪"
- 长内容生成速度慢，用户等不及
- 系统提示词费Token，成本高
- 换一个模型，输出格式可能就变了
为此，OpenTiny团队借鉴大模型成熟的TTFT/TPOT指标体系，提出了生成式UI的两类度量指标：
⏱️ 性能指标
- 首屏反馈时间：用户提交到看到第一个有效UI的时间。替代传统"三秒原则"，决定第一印象
- 渐进式渲染效率：后续组件逐步呈现的节奏，衡量流畅度
优化策略：优先输出骨架屏、简化组件配置、压缩系统提示词、总结历史对话......
📊 信息表达能力指标
- UI可用度 ：生成的界面是否真的能完成任务（完整性、功能性、信息充分性）。兜底方案： Zod校验 + 二次确认
- Token效率 ：单位Token传递了多少有用信息。优化方案： 渐进式披露、使用快速排版组件、避免大模型复述长数据
场景局限性及解法
| 场景 | 问题 | 解法 |
|---|---|---|
| 长数据列表 | 逐行输出太慢 | 内置数据推送 / 编程式API调用 |
| 超复杂界面 | 一次生成失败 | 任务拆分 + 多轮迭代 + 片段引用 |
| 重复生成 | 浪费Token | 预生成常见UI，叠加微调 |
在梳理完生成式UI的局限性与度量体系之后，一个更深层的问题浮出水面：当各家框架纷纷涌现，技术路径各成一派，我们该如何统一语言、协同演进？瑞虹老师顺势将话题引向了生成式UI领域的标准化之争。
06 标准化之争：只支持原生HTML，还是允许业务组件？
目前业界有多个生成式UI框架（a2ui、cosui、agui、GenUI SDK......），它们技术流派不同：
- 源码生成型（如灵光闪应用）：直接输出HTML/Vue/React，灵活但难约束
- 声明式UI（如GenUI SDK、a2ui）：输出JSON协议，可控性强
- 数据驱动型（如agui）：界面预定义，只更新数据，安全但灵活性低
而标准化讨论中，一个核心争议点是：协议是否只支持原生HTML元素（或一个固定子集）？
林瑞虹老师用"业务高级搜索框 "为例------它包含多条件筛选、动态加载、联动交互，如果只能用原生HTML，AI几乎不可能一次生成正确。支持自定义业务组件扩展，是生成式UI走向真实业务的必由之路。
在标准化之争的讨论之后，瑞虹老师的分享也进入了尾声。从痛点剖析到原理拆解，从场景落地到度量优化，再到协议的求同存异------生成式UI的技术图景已逐渐清晰。
07 总结与展望
生成式UI正在重新定义人机交互的边界。它让AI从"会说话"进化到"会画界面、会操作、会协作"。
虽然仍有内容正确性、生成速度、成本等挑战，但通过结构化输出、流式渲染、缓冲保护、物料定制、合理的度量与兜底策略 ，生成式UI已经具备了走向生产环境的潜力。
OpenTiny GenUI SDK将持续深耕这一方向，并保持开源开放。未来，我们期待生成式UI让界面真正"隐形"------用户只关心意图，界面自动适配，服务零距离直达。
关于 OpenTiny NEXT
OpenTiny NEXT 是一套企业智能前端开发解决方案，以生成式 UI 和 WebMCP 两大核心技术为基础，对现有传统的 TinyVue 组件库、TinyEngine 低代码引擎等产品进行智能化升级，构建出面向 Agent 应用的前端 NEXT-SDKs、AI Extension、TinyRobot智能助手、GenUI等新产品，实现AI理解用户意图自主完成任务，加速企业应用的智能化改造。
欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～
OpenTiny 官网：opentiny.design
GenUI SDK 代码仓库：github.com/opentiny/ge... （欢迎star ⭐）
如果你也想要共建，可以进入代码仓库，找到 good first issue标签，一起参与开源贡献~如果你有任何问题，欢迎在评论区留言交流！