前言
大家好，我是木斯佳。
相信很多人都感受到了，在AI浪潮的席卷之下，前端领域的门槛在变高，纯粹的“增删改查”岗位正在肉眼可见地减少。曾经热闹非凡的面经分享，如今也沉寂了许多。但我们都知道，市场的潮水退去，留下的才是真正在踏实准备、努力沉淀的人。学习的需求，从未消失，只是变得更加务实和深入。
这个专栏的初衷很简单：拒绝过时的、流水线式的PDF引流贴，专注于收集和整理当下最新、最真实的前端面试资料。我会在每一份面经和八股文的基础上，尝试从面试官的角度去拆解问题背后的逻辑，而不仅仅是提供一份静态的背诵答案。无论你是校招还是社招，目标是中大厂还是新兴团队，只要是真实发生、有价值的面试经历，我都会在这个专栏里为你沉淀下来。专栏快速地址
温馨提示：市面上的面经鱼龙混杂，甄别真伪、把握时效，是我们对抗内卷最有效的武器。
面经原文内容
📍面试公司：腾讯PCG-腾讯视频
🕐面试时间：近期
💻面试岗位：前端暑期二战一面
❓面试问题：
- 什么是闭包，什么时候会用到
- 电商项目中，如何将FCP从3.3优化到1.8
- WebP与PNG、JPG图片格式区别
- SSE跟WebSocket的区别
- 流式对话中响应中断如何处理
- Agent中react模式是怎样的
- Skills、MCP、CLI三者区别与优缺点
- 什么是状态机，语音输入为什么要用状态机
- 封装组件需要遵循哪些原则
- AI聊天对话框如何实现，怎么承接SSE流式返回
- AI流式输出图片、PDF、富文本、Markdown、交互组件如何统一渲染
- 用户个人知识库搭建与完整使用流程
- 文档上传后解析、分块、向量化、入库、检索全流程
- 自研知识库和普通桌面AI上传文档问答区别、项目初衷
- Monorepo大仓与传统单层单体架构优缺点对比
- Monorepo和微前端是不是同一个东西，区别是什么
- 业界主流大仓、模块化工程方案有哪些
- 为什么需要微前端，解决什么痛点
- 常见微前端框架及各自特点
- 微前端适用场景与优缺点
- 对Harness Engineering的理解
- Agent人机等待、表单确认、对话交互闭环实现深度
来源：牛客网 暑期实习必拿offer
💡木木有话说（刷前先看）
腾讯PCG这场二面，是一份“AI应用+工程化”深度结合的面经。问题覆盖：性能优化（FCP从3.3到1.8）、AI对话（SSE中断、Agent ReAct模式、Skills/MCP/CLI）、知识库RAG全流程、Monorepo与微前端对比、组件封装原则……每一题都是生产级AI应用的实战问题。面试官显然对AI工程化落地有很深的理解，这份面经适合已经有一定AI项目经验、准备冲击大厂AI方向的同学反复研读。
📝 腾讯PCG前端暑期二战一面·深度解析
🎯面试整体画像
| 维度 | 特征 |
|---|---|
| 面试风格 | AI工程化深挖型 + 实战落地型 + 架构对比型 |
| 难度评级 | ⭐⭐⭐⭐（四-五星，AI+RAG+微前端+工程化全面覆盖） |
| 考察重心 | AI对话（SSE/中断/统一渲染）、知识库RAG、Agent模式、工程化（Monorepo/微前端） |
| 特殊之处 | 问题高度集成，每道题都是生产级AI应用的真实场景 |
🔍逐题深度解析
二、电商项目中，如何将FCP从3.3优化到1.8
回答思路：FCP（First Contentful Paint）是首屏内容绘制时间，优化需从资源加载、渲染路径入手。
具体优化措施：
| 优化方向 | 具体手段 | 预期收益 |
|---|---|---|
| 关键CSS内联 | 首屏CSS内联到<head>，非关键CSS异步加载 | 减少1次RTT |
| 资源预加载 | <link rel="preload">预加载关键字体、图片 | 提前加载 |
| 图片优化 | WebP格式、响应式图片、懒加载 | 减少传输体积 |
| 字体优化 | font-display: swap，避免字体闪烁 | 提升感知速度 |
| 减少阻塞 | async/defer加载JS，避免阻塞渲染 | 加快首次绘制 |
| CDN加速 | 静态资源走CDN，就近访问 | 减少延迟 |
<!-- 关键优化示例 --><head><!-- 内联关键CSS --><style>/* 首屏样式 */</style><!-- 预加载关键资源 --><linkrel="preload"href="/font.woff2"as="font"crossorigin><!-- 非关键JS异步加载 --><scriptsrc="non-critical.js"async></script></head>三、WebP与PNG、JPG图片格式区别
| 格式 | 特点 | 适用场景 | 压缩类型 | 透明度 | 动画 |
|---|---|---|---|---|---|
| JPG/JPEG | 有损压缩，体积小 | 照片、复杂图像 | 有损 | ❌ | ❌ |
| PNG | 无损压缩，支持透明 | Logo、截图、需要透明的图 | 无损 | ✅ | ❌ |
| WebP | 有损/无损可选，体积比JPG小25-35% | 现代Web通用 | 两者兼有 | ✅ | ✅ |
选型建议：
- 照片/大图 → WebP（兼容性降级JPG）
- Logo/图标 → PNG或WebP
- 需要动画 → WebP或GIF
<picture><sourcesrcset="image.webp"type="image/webp"><imgsrc="image.jpg"alt="fallback"></picture>六、Agent中ReAct模式是怎样的
回答思路：ReAct =Reasoning + Acting，是Agent的核心推理模式。
工作流程：
- Thought（思考）：模型分析当前状态，推理下一步做什么
- Action（行动）：执行具体操作（调用工具、搜索、计算）
- Observation（观察）：获取行动结果
- 循环：将Observation纳入上下文，重复Thought→Action→Observation，直到任务完成
# ReAct伪代码whilenottask_complete:thought=llm.think(state)# 思考action=execute_tool(thought)# 行动state=observe(action)# 观察示例：问“今天北京天气”
- Thought：需要查询天气，调用天气API
- Action：
get_weather(city='北京') - Observation：返回“25°C，晴”
- 最终回答：“今天北京25°C，晴朗”
七、Skills、MCP、CLI三者区别与优缺点
| 概念 | 定义 | 优点 | 缺点 |
|---|---|---|---|
| Skill | 预定义能力单元，封装特定任务的Prompt+工具 | 开箱即用、易组合 | 灵活性低、需预先开发 |
| MCP | 模型上下文协议，标准化Agent与工具交互 | 跨平台、可扩展 | 相对较新、生态待完善 |
| CLI | 命令行工具，Agent可通过shell执行命令 | 功能强大、系统级操作 | 安全风险高、输出需解析 |
适用场景：
- Skill：固定任务（代码审查、生成测试）
- MCP：需要工具生态集成的场景
- CLI：服务器运维、文件处理
八、什么是状态机，语音输入为什么要用状态机
定义：状态机由状态、事件、转换组成，在特定状态下接收事件，执行动作并迁移到新状态。
语音输入中的应用：
- 状态定义：空闲、录音中、识别中、识别完成
- 事件：用户点击、语音开始、语音结束、超时
- 避免竞态：录音中再次点击停止，需根据当前状态决定行为
// 语音输入状态机示例conststates={idle:{onStart:()=>toListening},listening:{onStop:()=>toRecognizing,onTimeout:()=>toIdle},recognizing:{onComplete:(text)=>toIdle,onError:()=>toIdle}}九、封装组件需要遵循哪些原则
回答思路：参考之前面经的组件设计原则。
核心原则：
- 单一职责：一个组件只做一件事
- 开闭原则：对扩展开放，对修改关闭（使用props/插槽）
- 组合优于继承：通过组合构建复杂组件
- 高内聚低耦合：组件内部紧密，组件间独立
- 可测试性：依赖可注入，便于单元测试
- 命名清晰：组件名、props名语义明确
十一、AI流式输出图片、PDF、富文本、Markdown、交互组件如何统一渲染
回答思路：核心是消息类型系统 + 自定义渲染器。
设计方案：
- 消息结构：定义统一的消息格式，包含
type和content
// 消息类型枚举constMessageType={TEXT:'text',MARKDOWN:'markdown',IMAGE:'image',PDF:'pdf',COMPONENT:'component'// 交互组件}// 消息结构{id:'msg_123',type:MessageType.MARKDOWN,content:'# 标题\n内容...',metadata:{language:'zh'}}- 流式接收：通过SSE接收chunk，根据
type路由到不同渲染器 - 渲染器注册表：
constrenderers={[MessageType.TEXT]:TextRenderer,[MessageType.MARKDOWN]:MarkdownRenderer,[MessageType.IMAGE]:ImageRenderer,[MessageType.PDF]:PDFRenderer,[MessageType.COMPONENT]:ComponentRenderer}functionMessageRenderer({message}){constRenderer=renderers[message.type]return<Renderer content={message.content}/>}- 增量渲染：Markdown需处理代码块截断问题，图片需显示加载进度
十二、用户个人知识库搭建与完整使用流程
回答思路：从数据采集到检索生成的全链路。
完整流程：
- 文档上传：用户上传PDF、Word、Markdown等
- 文档解析：提取文本内容（pdf.js、mammoth）
- 智能分块：按语义/段落切分，保留重叠
- 向量化：调用Embedding模型生成向量
- 存储：向量存入向量数据库（Pinecone、Milvus），原文存入对象存储
- 查询检索：用户提问 → 向量化 → 相似度检索 → 召回Top-K文档
- 上下文构建：将召回文档与问题组合成Prompt
- 生成回答：LLM生成答案，附上引用来源
十三、文档上传后解析、分块、向量化、入库、检索全流程
回答思路：这是RAG系统的核心链路。
详细流程：
| 阶段 | 动作 | 技术方案 |
|---|---|---|
| 解析 | 提取文本内容 | pdf.js、mammoth、unstructured |
| 分块 | 语义/固定大小切分 | 按段落、标题、500字符+50重叠 |
| 向量化 | 文本→向量 | OpenAI Embedding、BGE、text2vec |
| 入库 | 存储向量+元数据 | Pinecone、Milvus、Qdrant |
| 检索 | 相似度搜索 | 余弦相似度、HNSW索引 |
# 伪代码defprocess_document(file):# 1. 解析text=parse_document(file)# 2. 分块chunks=chunk_text(text,size=500,overlap=50)# 3. 向量化vectors=embed(chunks)# 4. 入库vector_db.insert(vectors,metadata=chunks)十五、Monorepo大仓与传统单层单体架构优缺点对比
| 维度 | Monorepo | 单仓单体 |
|---|---|---|
| 代码复用 | 容易（本地软链接） | 困难（需npm发布） |
| 依赖管理 | 统一版本，减少冲突 | 各自管理，版本碎片化 |
| 构建效率 | 增量构建，只构建变更 | 全量构建 |
| 权限管理 | 较难（需CODEOWNERS） | 独立仓库，权限清晰 |
| 工具链 | 统一配置 | 各自维护 |
| CI/CD | 智能选择受影响项目 | 全量流水线 |
十六、Monorepo和微前端是不是同一个东西，区别是什么
答案：不是同一个东西。
| 维度 | Monorepo | 微前端 |
|---|---|---|
| 解决维度 | 代码仓库管理 | 应用架构 |
| 关注点 | 依赖管理、构建优化 | 多团队独立部署、技术栈无关 |
| 运行时 | 无影响 | 运行时加载子应用 |
| 典型工具 | pnpm、Turborepo、Nx | qiankun、Micro-App、Module Federation |
关系：Monorepo是开发时的代码组织方式，微前端是运行时的应用架构。两者可以结合使用：用Monorepo管理微前端的多个子应用。
十七、业界主流大仓、模块化工程方案
| 工具 | 特点 | 适用场景 |
|---|---|---|
| pnpm workspace | 硬链接，节省磁盘 | 中小型Monorepo |
| Turborepo | 智能缓存、增量构建 | 大型Monorepo |
| Nx | 依赖图可视化、插件生态 | 企业级 |
| Lerna | 版本管理、发布流程 | npm包管理 |
| Rush | 微软出品，严格规范 | 超大型项目 |
十八、为什么需要微前端，解决什么痛点
痛点：
- 巨石应用：代码臃肿，构建慢，难以维护
- 多团队协作：技术栈冲突，部署互相影响
- 遗留系统迁移：无法一次性重写
微前端解决的痛点：
- 技术栈无关：各子应用可用不同框架
- 独立开发部署：子应用独立发布，互不影响
- 增量升级：遗留系统逐步替换
- 团队自治：各团队负责自己的子应用
十九、常见微前端框架及各自特点
| 框架 | 特点 | 适用场景 |
|---|---|---|
| qiankun | 基于single-spa，JS沙箱、样式隔离 | 主流选择，蚂蚁出品 |
| Micro-App | 京东出品，Web Component方案 | 技术栈无关 |
| Module Federation | Webpack 5原生支持，运行时共享模块 | Webpack项目 |
| 无界 | 腾讯出品，WebComponent+iframe | 极致隔离 |
二十、微前端适用场景与优缺点
适用场景：
- 大型B端应用（多个子系统）
- 遗留系统渐进式重构
- 多团队独立交付
优点：
- 技术栈灵活
- 独立部署，故障隔离
- 团队自治
缺点：
- 运行时开销（加载子应用）
- 样式全局污染风险
- 公共依赖重复加载
- 调试复杂度增加
二十一、对Harness Engineering的理解
回答思路：Harness Engineering（“驾驭式工程”或“制动工程”）指在快速迭代中控制风险、保证稳定性的工程实践。
核心内涵：
- 渐进式发布：灰度、金丝雀、A/B测试
- 可观测性：监控、告警、链路追踪
- 混沌工程：主动注入故障，验证系统韧性
- 安全护栏：权限控制、审计日志、变更管控
在前端的体现：
- 灰度发布（按用户/地域）
- 实时监控（错误率、性能指标）
- 快速回滚机制
- 特性开关（Feature Flag）
二十二、Agent人机等待、表单确认、对话交互闭环实现深度
回答思路：Agent在需要用户确认或输入信息时，需设计人机协作的交互闭环。
实现要点：
- 等待态：Agent主动询问，展示等待UI（进度指示）
- 表单确认：Agent返回结构化要求，前端渲染动态表单
- 交互闭环：用户确认 → 数据回传Agent → Agent继续执行 → 返回结果
// 表单确认示例constagentResponse={type:'confirm',fields:[{name:'amount',type:'number',label:'金额'},{name:'reason',type:'text',label:'理由'}],prompt:'请确认以下信息'}// 前端渲染表单 → 用户提交 → 继续对话深度设计：
- 支持多轮确认
- 中断后可恢复
- 超时处理
📚知识点速查表
| 知识点 | 核心要点 |
|---|---|
| FCP优化 | 内联CSS、预加载、WebP、CDN、减少阻塞 |
| WebP vs PNG/JPG | WebP体积小25-35%，支持透明/动画 |
| ReAct模式 | Thought→Action→Observation循环 |
| Skills/MCP/CLI | Skill预定义、MCP协议、CLI命令行 |
| 状态机 | 状态+事件+转换，语音输入避免竞态 |
| 组件封装原则 | 单一职责、开闭、组合、高内聚低耦合 |
| 统一渲染 | 消息类型系统+渲染器注册表 |
| 知识库RAG | 解析→分块→向量化→入库→检索→生成 |
| Monorepo vs 微前端 | 开发时/运行时，不同维度 |
| 微前端 | 技术栈无关、独立部署、渐进迁移 |
| Harness Engineering | 风险控制、渐进发布、可观测性 |
| Agent交互闭环 | 等待态、动态表单、确认回传 |
📌 最后一句：
腾讯PCG这场二面，是一场“AI工程化”的深度对话。从ReAct模式、Skills/MCP/CLI，到知识库RAG全流程、Monorepo与微前端对比，再到Agent交互闭环。能从容应对这套题，说明你已经具备了AI应用开发的工程架构能力，这正是当前前端领域最稀缺的技能之一。
)
