前端 AI 相关面试题

20分钟阅读

主要是根据 JD，字节，腾讯，美团的面经总结，按我的简历写法（这篇100% 原题，来不及看大知识库可以看这个。（具体举例我就按我这边辅导所用 ai 项目去举例子。

前端 + AI / Agent 面试通用备战手册

适用对象： 前端 / 全栈 / AI 应用 / Agent 方向实习、校招、暑期面试。

核心目标： 不是帮你“背项目”，而是帮你针对常见面经里的 AI / Agent / SSE / RAG / Prompt / AI Coding 问题，准备一套更通用、更稳妥、可迁移到不同项目上的回答框架。

1. 总原则：AI 面试怎么答最稳

AI / Agent 面试最怕两件事：

  1. 术语很多，但落不到工程实现

  2. 把 demo 说成完整平台，被追问时接不住

所以建议所有回答都尽量按下面结构来：

标准答题结构

  1. 背景：为什么会有这个需求

  2. 目标：要解决什么问题

  3. 方案：为什么选这个技术

  4. 实现：核心链路怎么跑

  5. 难点：哪里最容易出问题

  6. 权衡：为什么不用别的方案

  7. 扩展：如果继续做，会怎么升级

万能保命句

  • 这个点我更偏工程实现角度理解。

  • 我当前真实做过的是 A、B、C，D 是我延伸了解的部分。

  • 如果继续往完整 Agent 方向扩展，我会再补 E、F、G。

2. AI / Agent 方向自我介绍怎么带

30 秒版本

我最近除了前端基础能力，也在关注 AI 应用落地，重点关注的是流式输出、RAG、工具调用和 AI Coding 这些和前端工程结合比较深的方向。我更感兴趣的不是只接一个模型接口，而是怎么把 AI 能力做成稳定、可交互、可观测的产品体验。

1 分钟版本

我最近在准备和实践 AI 应用相关的内容，主要关注三个方向：

  1. 流式交互体验：比如 SSE 输出、增量渲染、中断与重试；

  2. AI 能力工程化：比如把模型、知识库、工具调用做成可复用模块；

  3. Agent 相关概念和系统设计：比如 RAG、MCP、Tool、Skill 这些概念如何分层，以及它们怎么落到真实工程里。

所以如果有 AI 前端、AI 应用或 Agent 相关的岗位，我会比较感兴趣。

3. 高频概念题：通用回答模板

你理解的 AI Agent 是什么？

标准回答：

我理解 Agent 不是单纯的大模型对话，而是让模型在目标驱动下，结合上下文、工具和执行策略，去完成一类任务的系统。

它通常包含几层：

  • 模型层：负责理解、推理和生成

  • 工具层：提供搜索、数据库、HTTP、代码执行等外部能力

  • 记忆 / 上下文层：保存用户信息、历史消息、外部知识

  • 规划 / 执行层：决定下一步做什么

  • 观测 / 安全层：记录过程、限制权限、处理失败

一句话：

Agent = 模型 + 工具 + 上下文 + 执行策略，而不只是聊天接口。

你理解的 AI 应用和 Agent 有什么区别？

标准回答：

AI 应用是更大的概念，只要产品中用到了模型能力，都可以叫 AI 应用；而 Agent 更强调：

  • 有明确目标

  • 可以调用工具

  • 能根据上下文自主决定下一步动作

  • 更像一个“执行任务的系统”

所以不是所有 AI 应用都是 Agent，但很多 Agent 一定属于 AI 应用。

RAG 的作用是什么？

标准回答：

RAG 的核心作用是：

在模型生成前，把和问题相关的外部知识先检索出来，作为上下文提供给模型，从而减少幻觉、增强时效性和领域准确性。

它适合：

  • 企业私有知识问答

  • 文档问答

  • 时效性较强的信息场景

  • 需要“有依据回答”的场景

一句话：

RAG 不是替代模型，而是给模型补外部知识。

MCP 是什么？

标准回答：

MCP 可以理解成一种让模型或 AI 应用标准化访问外部工具和上下文的接口 / 协议思路。它重点解决的是：

  • 工具怎么接进来

  • 上下文怎么暴露给模型

  • 调用方式怎么标准化

一句话：

MCP 主要解决“连接问题”，也就是模型怎么接入外部世界。

Tool 和 Skill 有什么区别？

标准回答：

Tool 是具体能力单元，比如搜索、发请求、查数据库；Skill 更偏程序性知识或 SOP，强调在某类任务里应该怎么组合和使用这些工具。

可以简单理解成：

  • Tool：能做什么

  • Skill：怎么做事

Agent Skills 是什么？

标准回答：

Agent Skills 更像一套标准化的程序性知识封装，它不是单次工具调用，而是指导 Agent 在特定场景下如何按步骤完成任务的操作手册或 SOP。

比如：

  • 先检索资料

  • 再筛选可信来源

  • 然后调用某个工具生成结构化结果

  • 最后按固定模板输出

所以它更像“任务方法论”，不是一个单独工具。

4. SSE 高频问题：通用答法

这是面试里特别常见的一组。

为什么 AI 场景常用 SSE？

标准回答：

因为 AI 文本生成本质上更像服务端持续向前端推送内容，SSE 在这种单向流式输出场景里非常合适。

优点主要有三点：

  1. 基于 HTTP，接入和调试简单

  2. 单向 server push 足够满足文本流场景

  3. 很适合增量输出、任务进度和通知流

如果是高频双向实时通信，比如多人协作、在线状态同步，那 WebSocket 更合适。

SSE 和 WebSocket 的区别？

标准回答：

核心区别在三个方面：

  1. 方向：SSE 单向，WebSocket 双向

  2. 协议复杂度：SSE 更轻，WebSocket 更强

  3. 适用场景：SSE 更适合 AI 输出流、日志流、任务进度流；WebSocket 更适合 IM、协同编辑、多人实时互动

一句话：

AI 输出流更偏 server push，所以 SSE 常常足够；需要复杂双向通信时才更偏向 WebSocket。

流式输出怎么实现？

标准回答：

典型做法是前后端配合：

后端侧

  1. 调用模型流式接口

  2. 按 chunk 读取增量内容

  3. 把内容包装成 SSE 消息返回前端

  4. 最后发送 done / error 事件

前端侧

  1. 用 fetch + ReadableStream 或 EventSource 读取响应

  2. 用 TextDecoder 解码字节流

  3. 按 SSE 协议边界解析事件

  4. 根据 text / done / error 等不同类型更新 UI

一句话：

后端负责把模型流转成标准 SSE，前端负责增量解析和渲染。

每个 chunk 都是完整 JSON 吗？

标准回答：

不一定。底层网络传输是按字节流切的，一个 chunk 可能只是一条消息的一部分，所以不能把底层 chunk 直接当成完整 JSON 解析。

更稳妥的做法是：

  1. 先做流式解码

  2. 再按 SSE 消息边界拆分

  3. 最后对完整 data 做 JSON parse

这个点很容易被问，答出来会显得你对流式边界问题理解比较到位。

怎么中断 SSE？

标准回答：

如果是 fetch 请求，一般配合 AbortController；如果是原生 EventSource，可以调用 close()。

更完整的方案通常是：

  • 前端取消请求

  • 后端感知连接关闭

  • 如果后端有任务执行器，还要支持真正的服务端取消

怎么做断流重连？

标准回答：

要分场景：

  • 通知流 / 事件流：可以直接做重连和游标续传

  • AI 对话流：通常不能简单断了就接着播，要结合会话 ID、消息 ID、历史缓存决定是重试整次请求，还是恢复已生成内容

所以更专业的答法不是“断了就自动重连”，而是：

先区分这个流是否具备可恢复语义，再决定重连策略。

打字机效果频率怎么控制？

标准回答：

如果追求最低延迟，通常按流到达节奏直接渲染；如果希望有更平滑的“打字机效果”，可以加一层 buffer，把内容先缓存，再用 setInterval 或 requestAnimationFrame 按固定节奏消费。

这样做的本质是：

把模型返回节奏和 UI 展示节奏解耦。

5. AI Coding / Prompt Engineering 高频问题

提示词怎么设计？

标准回答：

我会把 prompt 拆成三层：

  1. 角色层：你是谁

  2. 任务层：你要完成什么

  3. 约束层：输出格式、禁止事项、边界条件

如果是代码生成，我会额外强调：

  • 先理解上下文再改

  • 尽量复用现有结构

  • 不要擅自引入新依赖

  • 输出要符合项目风格

一句话：

prompt 的目标不是把模型“管死”，而是减少歧义、提高结果可用性。

提示词设计太严格，会不会限制模型发挥？

标准回答：

会，所以要分任务类型。

  • 确定性任务：比如修 bug、补表单、写接口层，我会写得更明确，因为目标是稳定和可控

  • 探索性任务：比如方案设计、重构思路、技术选型，我会只约束目标和边界，给模型更大发挥空间

一句话：

确定性任务重约束，探索性任务重引导。

AI 生成的代码有没有 review？怎么 review？

标准回答：

一定要 review，而且我觉得 review 是 AI Coding 最重要的一步。

我一般从四层看：

  1. 功能是否真的满足需求

  2. 是否符合现有数据流、目录结构、命名风格

  3. 复杂度是否合理，有没有过度抽象

  4. 有没有性能、边界、类型和异常风险

如果是 UI 代码，我还会额外看：

  • 交互状态是否完整

  • loading / empty / error 是否有覆盖

  • 样式和现有设计体系是否一致

AI 生成代码后，数据应该补在哪里？

标准回答：

这个问题本质是在看你有没有理解项目数据流。

判断维度一般有三个：

  1. 这是局部状态还是全局状态

  2. 这是展示态、交互态还是业务态

  3. 项目原有数据入口在哪里，比如 store、context、service、hooks 或 page loader

所以更好的回答不是“在哪里方便就补哪里”，而是：

补数据的位置要服从项目原有的数据流架构。

6. RAG 高频问题：通用答法

做一个 RAG，大概要怎么做？

标准回答：

一般分为两段：离线建库和在线问答。

离线建库

  1. 导入文档

  2. 文档解析

  3. 文本清洗

  4. 分块切片

  5. 生成 embedding

  6. 存入向量库 / 检索存储

在线问答

  1. 用户输入问题

  2. query 向量化

  3. 检索相关 chunk

  4. 组装上下文 prompt

  5. 调用模型生成答案

  6. 返回答案和引用来源

RAG 的难点是什么？

标准回答：

我觉得主要有四个：

  1. 文档解析质量：原始内容干不干净

  2. 切片策略：切太大和切太碎都不好

  3. 检索质量：召回结果直接决定上限

  4. 工程链路完整性：权限、更新、去重、引用展示、错误处理都要补齐

RAG 有什么局限？

标准回答：

RAG 不是万能的，常见局限包括：

  • 检索错了，生成也会错

  • 分块策略不好会丢上下文

  • 长文档仍然受上下文窗口限制

  • 并不是所有任务都需要检索增强

  • 工程成本其实不低

一句话：

RAG 的上限，很大程度取决于检索质量，而不只是模型本身。

7. 系统设计题：如果让你做一个 AI 客服 / AI 对话系统

前端侧怎么上手？

标准回答：

如果我负责前端，我会从四层切入：

  1. 交互层：消息列表、输入框、流式输出、中断、重试、引用展示

  2. 状态层：会话状态、历史消息、streaming 状态、错误状态

  3. 协议层：和后端约定消息协议，比如 text / done / error / tool / reference

  4. 可用性层：自动滚动、断流处理、markdown 渲染、用户上翻时暂停跟随

一句话：

前端不只是把文本显示出来，而是把 AI 的不确定输出包装成稳定的产品体验。

如果后端也让你做？

标准回答：

我会按分层设计：

  • 模型接入层

  • 会话管理层

  • RAG / 知识增强层

  • 工具调用层

  • SSE / API 接口层

  • 观测与安全层

核心是把系统拆成可维护的模块，而不是所有逻辑都堆在聊天接口里。

8. 前端如何提升 AI 结果可用性

这是非常加分的一题。

标准回答：

前端不能让模型变聪明，但可以让结果更稳定、更可用。

我会考虑这些机制：

  1. 展示引用依据：提升可解释性

  2. 结构化渲染：优先展示结构化结果而不是纯文本堆砌

  3. 重试 / 重新生成：给用户补救手段

  4. 空态与错误兜底：避免坏结果直接暴露给用户

  5. 分层展示：先主内容，再引用、工具结果、扩展信息

  6. 可控交互：支持停止、继续、回看历史、复制、反馈

一句话：

前端不能保证模型正确，但可以显著提升结果的稳定性、可解释性和用户体验。

9. 面试中的避坑表达

不建议轻易说

  • 完整 Agent 平台

  • 完整 MCP 平台

  • 动态 Skill Loader

  • 多路召回 RAG

  • Token 级渲染

  • 前后端统一 Zod 校验体系

更稳的表达

  • AI 应用 / AI Workflow / AI 交互系统

  • 参考 MCP 思想的工具接入机制

  • 基础版 / 工程化版 RAG

  • SSE 增量渲染

  • 工具封装 / 工具调用单元

10. 万能答法（bushi）

模板 1：我没完全做过，但我知道怎么答

这个点我当前不敢说自己做得特别完整，但我理解它的核心是 A、B、C。如果让我从工程上落地，我会优先处理 D、E、F 这几个问题。

模板 2：我做过工程接入，但不是底层研究

这个问题我更偏工程实践视角，不敢说在算法原理上研究得特别深。但从系统实现角度，我会重点关注输入输出协议、边界处理、状态管理和可观测性。

模板 3：区分“做过”和“了解过”

这部分我自己实际做过的是 A、B，C 是我在项目中顺带补充了解的延伸内容，我可以分别展开讲。

AI / Agent 面试里，真正拉开差距的，不是你知道多少名词，而是你能不能把这条线讲顺：

需求背景 -> 架构分层 -> 协议设计 -> 前后端协作 -> 交互体验 -> 风险控制 -> 可扩展方向

只要你能把这条线讲顺，就算不是拿某一个固定项目举例，也能把很多问题回答得比较稳。