把 AI 调用封装成状态机
AI 请求不是一次普通的 fetch：它可能流式返回、可能超时、可能被用户中断、可能部分失败。用简单布尔值管理这些状态，界面很快就会失控。
建议把一次 AI 任务建模为状态机：idle、loading、streaming、success、error、cancelled，每个状态都有对应的界面表达。
界面要表达过程
生成中显示进度和可取消入口；流式阶段渲染增量并允许停止；成功后给出编辑、重试、复制；失败时说明原因并保留上下文。
用户最怕的不是慢，而是不知道发生了什么。
- loading：显示任务说明，而不是无限转圈
- streaming：增量渲染，支持停止
- success：结果可编辑、可复制、可重试
- error：说明原因，保留输入，不丢上下文
把生成结果当作用户资产
AI 生成的内容应该进入应用的数据模型，可以保存、修改、分享、删除，而不是只活在对话里。前端要把「生成内容」和「对话记录」分开管理。
这样用户可以安心反复生成，不会担心成果丢失。
性能与体验的平衡
首屏不加载大模型 SDK；流式解析放在 Web Worker；长列表虚拟化。AI 功能可以很重，但页面本身必须轻。
前端做得好，AI 能力才能真正变成产品体验。
让加载状态可解释
AI 任务进行中，不要只显示一个转圈图标。告诉用户系统正在做什么：正在检索资料、正在理解问题、正在生成回答。
可解释的加载状态能显著降低焦虑，也让用户明白为什么有时候要等更久。
重试的幂等设计
用户点击重试，可能因为网络抖动实际发送了两次请求。服务端要为 AI 任务生成任务 ID，重复请求直接返回第一次的结果，避免重复生成、重复扣费。
前端也要区分「重试」和「重新生成」：重试是恢复同一任务，重新生成是发起新任务，两者的 UI 文案和请求行为应该不同。
幂等是 AI 应用容易忽略、却直接影响成本和体验的工程细节。
前端错误码设计
前端不应只拿到「请求失败」，而应该拿到结构化错误码：超时、限流、模型拒绝、内容违规、参数错误，各有各的提示和恢复动作。
错误码表要写进前后端共享的文档，前端根据错误码渲染对应文案，而不是把后端错误信息直接抛给用户。
好的错误码体系，让前端、客服、工程能用同一套语言描述问题。