当 AI 遇上前端框架：从 Vercel AI SDK 到智能 UI 的工程实践

本文不聊概念，只聊工程。从 RSC 流式渲染到边缘推理，看前端开发者如何真正把 AI 集成到产品里。

一、为什么前端框架开始「长出」AI 能力

2024 年以前，前端调用 AI 的模式很原始：fetch('/api/chat') → 等响应 → 渲染。用户盯着 loading 旋转，体验和传统表单提交没什么区别。

转折点来自两个方向：

• 流式传输（Streaming） 成为标准：SSE/WebSocket 让 token 逐个到达，前端需要逐帧渲染
• 服务端组件（RSC） 让数据获取可以在服务端完成，客户端只收到 HTML 片段

React Server Components、Solid Start、Svelte 5 的 runes——这些框架的演进方向恰好和 AI 的流式需求对齐了。

二、Vercel AI SDK：流式渲染的标准答案

Vercel AI SDK（ai npm 包）是目前前端集成 AI 最成熟的方案。核心就三个概念：

1. useChat — 聊天界面的 10 行方案

useChat 内部连接 SSE 端点，逐 token 更新状态，自动处理 abort controller、错误重试、rate limiting。你写 10 行代码，它替你处理了 300 行的边界情况。

2. streamUI — 让 AI 动态生成组件

不只是文字流到屏幕上——AI 可以直接返回 React 组件。用户问「苹果的股价呢」，AI 不是回一段文字，而是渲染一个实时数据卡片。

3. StreamingReactResponse — Next.js 原生集成

配合 RSC，流式响应可以直接在服务端渲染成 HTML 片段推送到客户端，零 JS 负担。

三、各框架的 AI 集成思路

Solid.js：细粒度响应式，流式更新只变更文字节点，O(1) 而非 O(n) diff。

Vue 3：组合式 API + Suspense，让 AI 组件加载态优雅处理。

Svelte 5：Runes 让流式代码最简洁，零虚拟 DOM 开销。

每个框架都在用自己哲学解决同一个问题：如何把异步的 token 流变成流畅的用户界面。

四、工程问题：你迟早会踩的坑

1. 流式中断与重连：客户端 visibilitychange 触发重连带 lastEventId，服务端 KV 缓存流历史
2. Token 计费与缓存：KV 缓存 embedding hash → response，RSC 可缓存整个组件渲染结果
3. 边缘推理 vs 中心推理：前端的瓶颈不在渲染，在到推理服务的网络延迟。边缘跑小模型 + HTTP/3 减少握手
4. Markdown 流式渲染：不完整 chunk 导致渲染错误，需软修复代码块、表格、标题

五、架构总览

完整链路：浏览器 → SSE/RSC Stream → Edge Runtime（Vercel AI SDK）→ Model Router（快问 Edge 小模型，复杂走 Data Center 大模型）→ LLM API

关键设计：AI 的输出不是终点，而是 UI 的起点。streamText 出文字，streamUI 出组件，generateObject 出结构化数据。

六、未来趋势

1. AI 组件即服务：AI 直接返回编译好的组件代码
2. 本地小模型 + 云端大模型：8B 参数模型很快能在浏览器跑
3. 框架级 AI 原语：Next.js 15、Nuxt 4、SvelteKit 2 内置 AI streaming 支持

前端开发者的核心竞争力，正在从「写 CSS 动画」转向「写 AI 集成架构」。不是要你训练模型，而是要你理解流式、理解边缘计算、理解如何让 AI 的输出变成用户能交互的界面。

这才是前端 + AI 的技术深水区。