AI 场景面试题

状态	含义	UI 表现
`pending`	等待发送	输入框锁定
`sending`	请求已发出，等首个 chunk	loading 动画
`streaming`	正在接收流式内容	逐字显示 + 停止按钮
`done`	完整接收完成	显示操作按钮
`stopped`	用户主动停止	显示"已停止"+ 继续按钮
`error`	网络/接口报错	错误提示 + 重试按钮

追问

停止后能继续生成吗？→ 看产品设计，可以支持"继续"按钮，服务端从断点续写
多条消息并发？→ 每条消息独立维护状态，存在消息对象里

如何处理用户连续发送多条消息？

方案 1：锁定输入框，上一条未完成不允许发下一条（主流 AI 产品做法）
方案 2：队列化，自动排队串行执行
方案 3：取消上一条，发新一条（适合搜索补全，不适合对话）

推荐：对话场景用方案 1，体验最清晰，状态最简单

如何实现重新生成？

删除最后一条 AI 消息，保留用户消息
用相同的上下文重新发请求
注意：重新生成时要创建新的 AbortController，旧的已失效

如何做自动滚到底部？

streaming 阶段：每次新内容到来，判断用户是否在底部，是则自动滚，否则显示"新消息"提示
判断是否在底部：scrollHeight - scrollTop - clientHeight < 阈值（如 50px）
用户手动向上滚后停止自动滚，新消息完成后可以选择恢复

如何展示引用来源？

消息对象里存 sources: [{title, url, snippet}]
streaming 阶段先不展示，done 后在消息底部显示引用卡片
点击跳转原文，或展开 snippet 预览
如果引用是内部文档，需要校验用户权限再决定是否可点击

四、流式输出

AI 流式输出是什么？

模型逐 token 生成，服务端边生成边推送，前端边接收边渲染，而不是等全部生成完再返回。

好处：用户看到首字时间（TTFT）短，体验流畅，不需要等待

SSE 和 WebSocket 怎么选？

维度	SSE	WebSocket
方向	服务端 → 客户端单向	双向
协议	HTTP	WS
断线重连	浏览器原生支持	需手动实现
实现复杂度	低	高
适合场景	文字生成、流式问答	语音对话、实时协同

结论：90% AI 对话场景用 SSE 够了，只有需要双向实时通信才用 WebSocket

fetch ReadableStream 怎么处理流？

response.body 是 ReadableStream，通过 getReader() 逐块读取解码后追加到界面

核心步骤：发请求 → 获取 response.body.getReader() → 循环 reader.read() → 解码每个 chunk → 解析 data: 字段 → 追加到消息内容 → 收到 [DONE] 结束

注意：每个 chunk 可能包含多条 data:，也可能是半条，需要维护 buffer 处理边界

如何实现打字机效果？

方案 1：直接追加（最简单，chunk 到来时立刻显示）
方案 2：队列缓冲（把收到的字符放进队列，按固定间隔取出显示，视觉更平滑）
方案 2 的问题：网络快时字符积压，用户感知延迟；网络慢时队列空了会停顿

推荐：直接追加即可，配合节流渲染控制帧率

如何停止生成？AbortController 怎么用？

创建 AbortController，signal 传给 fetch
用户点停止：调 controller.abort()
catch 到 AbortError 时，把消息状态改为 stopped，不是 error
重新发送时创建新的 controller，旧的不能复用

追问

abort 后后端还在生成吗？→ 是的，前端 abort 只断开连接，后端需要自己处理超时或取消
如何区分停止和网络错误？→ error.name === 'AbortError' 是主动停止，其他是真正的错误

SSE 如何断线重连？

EventSource 原生自动重连，服务端带 id: 字段，客户端重连时带 Last-Event-ID
fetch + stream 手动实现：catch 网络错误后指数退避重试，带上已接收位置
状态流转：connected → disconnected → reconnecting → connected
最大重连次数：超过 3-5 次提示用户手动刷新
重连期间 UI：显示"重新连接中..."，不直接报错

流式 Markdown 渲染有什么坑？

问题

每个 chunk 触发全量重解析，文本越长越慢
代码块、表格在流式时是半成品，解析结果不稳定
频繁 DOM 更新导致卡顿

解决

节流渲染：50-100ms 批量更新一次，用 requestAnimationFrame 控制
分区渲染：已完成的段落不再重渲染，只更新最后未完成的部分
代码块补全：流式阶段对未闭合代码块做临时补全，done 后再做完整渲染
XSS 防护：用 DOMPurify 对渲染结果过滤，防止 AI 输出恶意 HTML

五、RAG 知识库问答

什么是 RAG？

Retrieval-Augmented Generation：检索增强生成。先检索相关文档，再把文档作为上下文让模型回答，而不是让模型凭记忆回答。

解决的问题：模型训练数据有截止日期、不知道企业内部信息、容易幻觉

流程：用户提问 → 向量检索相关文档片段 → 把片段拼进 prompt → 模型基于文档回答 → 展示引用来源

RAG 系统前端需要做什么？

文件上传界面（支持 PDF、Word、TXT 等）
上传进度和处理状态展示（上传 → 解析 → 切片 → 向量化 → 就绪）
对话时展示引用来源（哪个文档、哪一段）
权限控制：用户只能检索自己有权限的文档
知识库管理：文档列表、删除、更新

文档切片是什么？为什么要切片？

把长文档切成小块（chunk），每块几百 token，分别向量化存储。

原因：向量化是对文本整体做语义映射，太长的文本语义会模糊；切片后检索精度更高

切片策略：按段落、按句子、固定长度 + 重叠（overlap，避免语义被切断）

向量数据库有什么用？

存储文档 embedding（向量），支持高效的语义相似度检索。

传统数据库：关键词匹配（精确但语义理解弱）
向量数据库：语义匹配（"汽车"能检索到"轿车""车辆"相关内容）
常见方案：Pinecone、Qdrant、Weaviate、pgvector（PostgreSQL 插件）

如何减少 AI 幻觉？

RAG 提供真实文档作为依据，让模型"有据可查"
System prompt 约束：不确定时回答"我不知道"，不要编造
Temperature 调低：减少随机性
前端展示引用来源：让用户自己验证答案是否来自文档
对检索结果做相似度阈值过滤：低于阈值的不作为上下文

如何处理企业内部权限？多租户如何隔离？

文档上传时打上用户/租户/权限标签
检索时加过滤条件：只检索当前用户有权限的文档
不能只在前端过滤：后端检索接口必须校验权限，防止绕过
多租户隔离：不同租户的向量数据存在不同 namespace 或 collection，物理隔离

六、Function Calling / Tool Calling

什么是 Function Calling？

模型不直接执行操作，而是生成结构化的调用参数（JSON），由应用程序校验权限后执行，结果再回传给模型。

流程：用户提问 → 模型判断需要调用工具 → 生成 {name: 'getOrder', args: {orderId: '123'}} → 前端/后端执行 → 把结果传回模型 → 模型基于结果回答

核心：模型只是"建议"调用，控制权在应用程序，不是模型直接操作数据库

前端如何展示工具调用过程？

工具调用是中间过程，用户需要看到"AI 在做什么"，而不是一段时间后突然出现结果。

状态展示

正在查询：🔍 正在查询订单 #123...
查询成功：✅ 已获取订单信息
查询失败：❌ 查询失败，稍后重试
需要确认：⚠️ AI 想要删除文件，是否允许？

设计原则：过程可见、结果可溯、危险操作需用户二次确认

哪些工具调用需要用户二次确认？

删除操作（文件、记录）
写入/修改操作（发邮件、提交订单、修改配置）
涉及费用的操作（购买、充值）
涉及权限的操作（分享、授权）

原则：读操作可以自动执行，写操作和不可逆操作要用户确认

如何避免 AI 越权调用工具？

工具定义时明确每个工具的权限范围
后端执行工具前校验当前用户是否有权限
前端不能信任模型的调用参数，必须在执行前做参数验证
敏感操作加审计日志：谁、什么时间、调用了什么工具、参数是什么

七、AI 应用安全、权限与体验

AI 应用有哪些安全风险？

风险	说明	防御
Prompt Injection	用户构造恶意输入操控模型行为	System prompt 约束 + 输入过滤
XSS	AI 输出含恶意 HTML/JS	DOMPurify 过滤渲染内容
越权访问	通过 AI 获取无权限的数据	后端检索时校验权限
敏感信息泄露	AI 回复包含其他用户数据	严格隔离检索范围
API Key 泄露	前端代码暴露 Key	必须走服务端中转，不在前端存 Key