[!info] related notes

• 所属 MOC: 前端工程化 MOC, 前端基础 MOC
• 相关概念: AI 聊天与流式 UI, frontend-streaming-response-patterns, ai-chat-performance-optimization, ai-product-frontend-reliability, ai-frontend-monitoring-metrics
• 稳定性: ai-product-frontend-reliability, ai-output-uncertainty-and-ux

AI 对话页面实现

适用范围

这篇笔记关注的是前端如何实现一个可用的 AI 对话页面，而不是讨论模型训练或提示词设计本身。

一句话定义

AI 对话页面的核心，不是把文本显示出来，而是围绕流式响应、消息状态、异常恢复和长内容渲染建立稳定交互。

一个最小实现骨架

1. 用户发送输入并创建一条本地消息
2. 创建 assistant 占位消息，状态设为 generating
3. 用 EventSource 或 fetch 消费约定的流协议；fetch 可读取 SSE，二者不是同一层的替代协议
4. 按协议边界解析事件，再合并文本更新；网络 chunk 不一定对应完整事件或 token
5. 将事件绑定会话、run 与消息 ID，避免切换会话或重新生成后旧事件写入新消息
6. 收到约定的完成事件后切到 success；连接 EOF 本身不证明业务完成，异常断流需查询状态或标记待恢复

页面通常要管理哪些状态

• 会话列表和当前会话
• 消息数组和消息顺序
• 输入中、生成中、等待取消确认、完成、失败、中止；连接状态与任务状态分开管理
• 自动滚动和用户手动滚动的冲突
• 重新生成、停止生成、继续追问

推荐拆分的前端模块

• ChatInput：输入和发送控制
• MessageList：列表虚拟化与滚动管理
• MessageItem：用户消息 / assistant 消息渲染
• StreamingController：接收 chunk、取消、中止、重试
• MarkdownRenderer：markdown、代码块、引用来源展示

最容易踩的坑

• 每个 token 都触发一次全列表重渲染
• 把前端 Abort 当成后端任务已取消；取消请求需后端确认，已完成副作用不会自动撤销
• 失败后没有恢复入口，或盲目重试创建重复任务；重新生成和恢复同一 run 应区分
• markdown 和代码高亮反复重算；渲染模型内容还要遵守 HTML / URL 安全策略，不能直接信任生成内容

一个实用检查清单

• 是否支持停止生成
• 是否支持重试和重新生成
• 是否能区分连接丢失、任务失败、取消请求与已确认取消
• 是否控制了流式更新频率
• 是否对长列表和长文本做了性能保护

最短记忆方式

先把流接稳，再把状态管清，再把性能和异常兜好。

Related notes

• AI MOC