试过让 AI 在 App 里"生成界面"的人，应该都被同一件事折磨过：慢。一次 Generative UI 请求，模型要读取上下文、理解业务数据、调用工具、生成 A2UI JSON，再由 Flutter 把 JSON 转成 Widget 渲染，哪怕模型再快，用户也要等上几十秒甚至分钟级别。知乎这个速度放在任何消费级 App 里，基本等于判死刑。
今天（8 月 20 日），Flutter 官方放出的一个新思路，直接把解题角度换掉了：如果界面在用户打开 App 之前就有足够信息可以生成，那为什么不让 AI 提前生成？这个玩法叫 Async A2UI，官方还配了一个完整案例 Commis（餐饮团队管理 App）。先看它怎么玩，再说我认为上生产前必须想明白的三个坑。
先补课：A2UI 和 GenUI 到底是什么
没跟上的朋友快速补个背景。A2UI 是 Google 开源的一个协议，思路很朴素：AI 不输出文字也不输出代码，而是输出一段"描述界面"的声明式 JSON，客户端收到后，用自家组件目录（Catalog）里预先注册好的组件把它渲染出来。它的定位是 Agent 和 UI 运行时之间的协议层，不绑定具体框架，可以用在 Flutter、React Native、Vue 等各种场景。知乎这么设计的原因也很实在：AI 生成的界面要跨过信任边界进入你的 App，传数据比传可执行代码安全得多，安全性像数据一样可控，表达力又逼近代码。GitHub
Flutter GenUI 则是 A2UI 在 Flutter 端的官方运行时 SDK，负责把 AI 输出的 UI 指令解析成可渲染、可交互的 Flutter Widget。官方仓库里那句话说得很直白：GenUI 生成的不是代码，而是运行时基于你项目里的 widget catalog 生成界面。GitHub
这条路线不是 Flutter 一家在看。A2UI 官方仓库目前已经拿到 1.6 万+ star，社区实现排着队进场：哔哩哔哩技术团队基于 A2UI 协议自研了 Vue 渲染器和 Agent 完整工具链，用在商业广告业务的 AI 助手里。知乎还有 AGenUI 这类项目直接做 iOS、Android、鸿蒙的原生渲染器。GitHub至于 A2UI 和 AG-UI 两大协议该怎么选，社区从 7 月一直吵到现在，后面细说。
为什么"提前生成"比"提速"更聪明
常规优化思路是让模型更快、生成更并行，但那只是把天花板抬高一点。Async A2UI 换了个问题：不是生成慢，而是生成的时机不对。
Commis 案例里，餐饮任务（哪天有活动、几点、备多少人的餐）存在 Firestore 里。以前的流程是用户打开页面后现场生成；现在改成：Firestore 里的任务一旦变化，直接触发后台 Cloud Function，AI 预先生成对应的 A2UI，结果写回 Firestore。知乎等用户真正打开 App，Flutter 客户端直接把已经生成好的界面读出来渲染，等待时间归零。
实现上有个很巧的地方：它没有另做一套"缓存渲染器"，从 Firestore 读出来的缓存字符串被直接塞回 GenUI 原有的 Transport 管道——这条管道平时接收的是模型流式输出的文本 chunk，现在只是换成接收一段"昨天生成好的" chunk。对运行时来说，这段 A2UI 是 AI 刚吐出来的、服务器昨天生成的、本地 SQLite 里存了一周的，甚至开发者手写的测试数据，只要协议合法，渲染流程完全一样。
这意味着 A2UI 的角色变了：它不再只是 LLM 实时输出过程中短暂存在的中间消息，而变成一种可以保存、传输、恢复、重新播放的 UI 数据。知乎createSurface、updateComponents、updateDataModel、deleteSurface 这些消息，本质上是一连串对 UI 状态的操作，把消息流重放一遍就能恢复界面，已经有点 UI Event Log 的味道。顺着这个思路还有不少想象空间：比如"缓存初始界面 + 实时增量更新"，AI 提前生成大头，用户打开即见，后续小改动再实时生成；再比如按用户预生成的个性化活动页、节日问候界面，都是"录播"天然比"直播"划算的场景。
但上生产前的三个坑，是真坎
官方案例是方向演示，真要落到生产，三个工程问题绕不过去。
第一，缓存失效。界面是提前生成的，数据变了而缓存 UI 没来得及重生成，用户打开看到的就是过期画面。这是物化视图的老问题，但 UI 比数据更敏感：数字错了还能解释，界面错了就是肉眼可见的事故。触发重生成的时机、过期的兜底策略，官方案例目前只给了最简单的形态。
第二，版本漂移，这个更隐蔽。App 发新版本后，客户端的 Widget Catalog 变了，服务器早前生成的 A2UI 可能引用的是旧组件 schema，新客户端直接不认识。知乎也就是说，UI 缓存必须带上版本号、依赖组件目录、有效期这类完整元数据，一段裸 JSON 肯定不够。
第三，状态耦合。Commis 案例里，缓存的 A2UI 不只交给渲染器，还会作为上下文交给 Agent——模型得知道"现在屏幕上有什么界面"，才能接着改。比如用户说"把这个活动改到下周一"，模型得先知道这个活动对应哪块 UI。Generative UI 的 UI State 从此要成为 Agent State 的一部分，两边还必须对得上。知乎这套往下演进，多半要长出 snapshot、revision、checkpoint 之类机制，复杂度才刚刚开始。
谁现在值得上手，谁可以再等等
最后给我的判断。
现在就可以上手玩的：做 AI 助手、客服对话类 App 的，以及 App 里有大量"可预期界面"的——活动页、个性化推荐、预约确认、报告摘要，Async A2UI 都值得试一把，场景越可预期，预生成收益越大。组件库维护者也值得盯着看：Catalog 会变成 AI 时代的新"API"，注册哪些组件、schema 怎么写，直接决定 AI 能生成出什么界面。官方还配了一个叫 Composer 的可视化工具，用自然语言就能让 Gemini 生成、修改 A2UI 界面，左边实时渲染、右边看 JSON，是理解这套协议最快的入口。a2ui.org
建议再等等的：界面强依赖实时交互（你根本猜不到用户下一眼想看什么），或者金融、合规这类高频变动场景，实时生成本身都还没成熟，预生成更谈不上。另外协议还在演进期，当前生产版本是 v0.9.1，v1.0 还处于候选阶段。知乎
值得继续盯的信号：GenUI 包的版本迭代——最新的 0.10.0 新增了 a2ui_core 包，还支持了 A2UI 客户端函数，agent 可以指示客户端执行验证、派生值这类小任务，省掉往返通信。知乎AI 生成 UI 这条线，官方一直在悄悄加码。
最后留一个社区还在吵的话题：有人认为 A2UI 的创新不是让 AI 画界面，而是把渲染权还给客户端，顺着这个逻辑，真正值得做的是在系统内部维护一层可编程读写的 UI 表示层，别把自己绑死在某个具体协议上。知乎也有人觉得协议层的标准化本身才是最大价值。AI 动态 UI 这场仗，才刚刚开始。
你觉得"AI 生成界面"该走直播路线还是录播路线？评论区聊聊。
