Vue、React、Next.js:如何为 AI 应用设计前端交互?
码海寻道 · 大模型、智能体与 RAG 工程组件系列第 42 篇

AI 应用的前端不是把一个输入框和 Markdown 输出拼在一起。它还要处理流式文本、工具调用、引用来源、任务进度、错误重试、取消生成和多轮会话。Vue、React 和 Next.js 都能实现,关键是先设计交互状态和后端协议。
一、AI 页面有哪些状态?
text
idle
→ submitting
→ retrieving
→ generating
→ completed
↘ failed
↘ cancelled
知识库上传还要有:
text
uploaded → parsing → embedding → indexing → ready
不要只用一个 loading=true 覆盖所有阶段,否则用户无法知道系统是在检索、生成还是卡住。
二、聊天界面的核心状态
ts
type Message = {
id: string
role: 'user' | 'assistant' | 'tool'
content: string
citations?: Citation[]
status: 'streaming' | 'done' | 'error'
}
type ChatState = {
messages: Message[]
activeRunId?: string
phase: 'idle' | 'retrieving' | 'generating' | 'done' | 'error'
error?: string
}
把 phase、消息内容和引用分开,方便局部更新和重试。
三、Vue、React 和 Next.js 的定位
Vue
适合渐进式开发和组件化界面。可以用 Composition API 抽离 useChat、useUpload 和 useJobProgress 等逻辑。
React
适合复杂组件组合和生态集成。聊天消息、流式事件和任务状态可以通过 hooks、Context 或状态库管理。
Next.js
基于 React,提供路由、服务端组件、服务端渲染和流式页面能力,适合希望前后端协作在同一应用中的团队。但不要因此绕过独立后端的鉴权和业务边界。
选型优先考虑团队熟悉度、现有系统、部署方式和组件生态,不要把框架名称当成 AI 能力本身。
四、流式消息如何更新界面?
服务端发送事件:
text
event: message_start
data: {"run_id":"run-001"}
event: token
data: {"text":"你好"}
event: citation
data: {"document_id":"doc-001","page":3}
event: done
data: {"run_id":"run-001"}
前端收到 token 时只追加当前助手消息,收到 citation 时更新引用列表,收到 done 时把状态改为完成。不要每个 Token 都重建整棵消息列表。
前后端应先约定事件 Schema,例如 message_start、token、citation、tool_start、tool_end、error、done,每个事件带 run_id、event_id 和可选时间戳。这样前端可以丢弃重复事件、处理乱序保护,并在断线后根据事件 ID 或查询接口恢复状态,而不是把一段文本当作唯一协议。
五、引用和工具调用应该可见
AI 应用需要让用户知道答案来自哪里:
- 引用文档标题和页码;
- 展开原文片段;
- 显示当前阶段;
- 工具调用涉及外部系统时显示动作;
- 写操作前显示确认卡片。
引用卡片只展示服务端返回的文档标题、页码、片段和权限允许的链接,不能让模型自行拼接下载地址。工具调用应显示"正在查询""已完成"或"需要确认"等状态,避免把内部参数、密钥和异常堆栈暴露给浏览器。
"模型正在思考"不如"正在检索知识库""正在读取订单信息"更可解释。
六、上传页面如何设计?
text
选择文件
↓
上传进度
↓
解析进度
↓
切分和向量化进度
↓
可搜索
上传进度和解析进度不是同一件事。文件已经上传完成,不代表知识库马上可以检索。前端应根据 job_id 查询后端状态,并允许失败任务重试。
七、取消和重试
生成中应提供"停止生成"按钮,前端发送取消请求后立即更新界面,同时等待服务端确认:
text
用户点击停止
↓
POST /runs/{run_id}/cancel
↓
前端显示 cancelling
↓
服务端释放模型流和工具任务
↓
状态变为 cancelled
网络断开后,不能默认把任务判定为失败。应通过 run_id 查询服务端最终状态,并支持重新连接或加载历史结果。
重试应携带原始 run_id 或新的幂等键,并明确是"继续未完成任务"还是"重新生成答案"。如果服务端已经完成但响应丢失,前端应先查询运行记录,不能直接再次发起一次可能重复扣费的请求。
八、状态管理怎么选?
小页面可以使用组件状态和自定义 hooks/composables;跨页面共享会话、任务和权限时,再引入 Pinia、Redux 或其他状态管理方案。
状态管理不等于服务端事实来源。消息最终状态、任务状态和权限仍应以 API 返回为准,前端乐观更新需要能够回滚。
九、前端安全边界
- 不把模型 API Key 放在浏览器;
- 不相信前端传来的 tenant_id 和 permission;
- Markdown 渲染要防止 XSS;
- 文件下载链接使用短时授权地址;
- 处理 SSE/WebSocket 的鉴权和断线重连;
- 不在浏览器保存不必要的敏感对话;
- 对用户展示的引用经过服务端权限过滤。
同时要使用安全的 Markdown 渲染策略,过滤脚本、危险链接和不可信 HTML;文件上传限制类型、大小和上传目标,不能相信文件名扩展名。前端隐藏按钮不等于完成授权,所有操作仍要由服务端重新鉴权。
十、结语
AI 前端的核心是状态和反馈:让用户知道请求是否提交、知识是否检索、答案是否生成、来源在哪里、任务能否重试。Vue、React 和 Next.js 都可以实现,真正决定体验的是前后端协议和状态设计。
下一篇将专门介绍 SSE:为什么聊天应用要实时返回,以及如何处理断线、心跳和最终结果。
参考资料
本文为"码海寻道"原创技术文章。前端框架与路由能力会持续更新,正式实现请结合目标版本和部署架构验证。