GenUI 的头号工程难题：延迟

生成式 UI 体验上最大的短板不是"好不好看"，而是"够不够快"。当前的实现有时需要一分钟甚至更久才能生成出结果，对一个界面来说这是致命的。把 GenUI 做到生产可用，一大半工作都在和延迟搏斗。本文梳理三套落地手段：弹性流式渲染、组件目录式架构、以及防 UI 注入。

弹性流式渲染（Resilient Streaming）

对抗延迟的主流答案是渐进式 / 弹性流式渲染：不等模型把整块 JSON 吐完，而是一边接收、一边解析、一边渲染。各家的做法：

• A2UI 提供 Resilient Streaming：增量解析并"修复（heal）"LLM 还没吐完的输出，让客户端能在组件生成的同时就开始渲染，无需等待完整 JSON。
• Flutter 的 GenUI SDK 的路线图把降低"感知延迟"作为目标——随着 LLM 逐步生成，渐进式地渲染标准 UI 组件，而不是干等完整响应。
• LangGraph / LangSmith 允许在节点执行结束前就 stream UI 消息：通过 useStream() hook 的 onCustomEvent 回调，在 LLM 还在生成时就更新 UI 组件。

Google Cloud 还补充了两条性能建议：那一步额外的"推理/规划"会拖慢 Time to Interactive（TTI），所以一是用 JSONL 让界面能立刻开始渲染，二是用向量化缓存（语义缓存）——对相似的查询直接复用之前生成好的 UI 结构。

组件目录 / 编排者架构

把"自由生成 HTML"换成"从目录里挑组件"，是同时解决一致性与安全的关键一招。

在这种架构里，控制力被直接写进系统架构：LLM 永远不画像素、也不生成原始 UI 代码，它只通过 A2UI 这类协议通信。模型扮演编排者，从一个预先验证过的组件库里挑选具体组件，再由 SDK 正式组装、渲染。

目录（catalog）本身定义了整个系统的"词汇表"——它就是那批经过审批的 UI 组件、模式与交互模型。只要生成只能在这个词汇表里发生，每一个界面就天然是品牌安全、视觉一致的。这也呼应了上一篇讲的设计师角色转变：设计师交付的是"组件目录 + 护栏"，而不是一张张静态稿。

防 UI 注入：最小权限 UI

安全在 GenUI 里是头等大事。最危险的场景是 UI 注入——提示注入诱导模型去渲染恶意代码。务实的防御原则是最小权限 UI（Least Privilege UI）：

• 协议层传输的是数据，而不是代码（A2UI 正是这么设计的）。
• 客户端只渲染预先批准、经过审计的组件。

只要守住"模型不产代码、客户端不认未审计组件"这条线，提示注入即便突破了模型，也无法在界面上落地为可执行的恶意逻辑。

工具链速览

如果今天就要动手，下面这套组合是 2025–2026 的常见选择：

• Vercel AI SDK：提供流式 UI 与 tool-calling 模式，是构建 GenUI 应用的常用底座。
• shadcn/ui Registry：基于 Radix UI 无样式原语的组件注册表模式，常被 UI 生成器作为目标组件库。
• 结构化输出可靠性：用 Zod 在运行时校验 TypeScript schema、强制输出形状；用 Outlines 做带 JSON / 语法约束的结构化生成。

测试也要换思路

GenUI 的界面是非确定性的，传统的视觉回归测试很容易误报失败。应当转向概率性断言：只验证"预期的意图和功能组件存在、且可交互"，而不去断言它们的精确位置与像素级外观。

小结

GenUI 的工程化可以归纳成三句话：用弹性流式渲染把延迟藏起来，用组件目录 + 编排者把一致性和品牌安全管起来，用最小权限 UI把 UI 注入挡在门外。把这三件事做扎实，生成式 UI 才能从 demo 真正走进生产。