前言
大家好，我是木斯佳。
相信很多人都感受到了，在AI浪潮的席卷之下，前端领域的门槛在变高，纯粹的"增删改查"岗位正在肉眼可见地减少。曾经热闹非凡的面经分享，如今也沉寂了许多。但我们都知道，市场的潮水退去，留下的才是真正在踏实准备、努力沉淀的人。学习的需求，从未消失，只是变得更加务实和深入。
这个专栏的初衷很简单：拒绝过时的、流水线式的PDF引流贴，专注于收集和整理当下最新、最真实的前端面试资料。我会在每一份面经和八股文的基础上，尝试从面试官的角度去拆解问题背后的逻辑，而不仅仅是提供一份静态的背诵答案。无论你是校招还是社招，目标是中大厂还是新兴团队，只要是真实发生、有价值的面试经历，我都会在这个专栏里为你沉淀下来。专栏快速地址
温馨提示：市面上的面经鱼龙混杂，甄别真伪、把握时效，是我们对抗内卷最有效的武器。
面经原文内容
📍面试公司：腾讯云智
🕐面试时间：近期
💻面试岗位：前端一面（30分钟，无手撕）
📝面试体验：全是AI相关，感觉要凉
❓面试问题：
- prompt一般怎么设计
- 向量数据库在进行切片的时候，切片大小怎么设计
- 切片方式一般会基于语义还是token，这两种怎么做
- 一般的大模型的上下文长度是多大，你用的小米是多大
- 上下文压缩一般怎么做，如何保证语义化
- 大文件上传、页面关闭如何兜底
- HTTP2的多路复用底层是怎么做的，为什么能保证消息不串联
- 驱动工程是什么意思，如何设计一个agent让他符合驱动工程
- 那上下文工程呢？
来源：牛客网 前端已死_
💡 木木有话说（刷前先看）
哈哈哈，新时代AI前端岗，适合有AI项目经验、准备冲击AI应用方向前端岗位的同学研读。
📝 腾讯云智前端一面·深度解析
🎯 面试整体画像
| 维度 | 特征 |
|---|---|
| 面试风格 | AI应用专项型 + RAG链路深挖型 + 工程化追问型 |
| 难度评级 | ⭐⭐⭐（三星，RAG切片策略、驱动工程较深） |
| 考察重心 | Prompt设计、向量化切片、上下文压缩、大文件上传、HTTP2、Agent工程 |
| 特殊之处 | 全AI相关，无传统前端八股 |
🔍 逐题深度解析
一、Prompt一般怎么设计
回答思路：Prompt设计直接影响LLM输出质量，核心是"清晰、结构化、有约束"。
设计原则：
- 角色设定：明确身份（"你是一个专业的代码审查专家"）
- 任务描述：清晰说明要做什么（"请检查以下代码的内存泄漏问题"）
- 输出格式：指定返回结构（JSON、Markdown、纯文本）
- 约束条件：限制输出长度、禁止内容
- 示例（Few-shot）：提供输入输出示例
- 思维链（Chain-of-Thought）：要求分步推理
text
# 好的Prompt示例
你是一个前端性能优化专家。
任务：分析以下代码的性能问题，并提出优化建议。
代码：
[代码块]
输出格式：
{
"issues": ["问题1", "问题2"],
"suggestions": ["建议1", "建议2"],
"priority": "high/medium/low"
}
要求：
- 只输出JSON
- 不要额外解释二、向量数据库切片大小怎么设计
回答思路：切片大小影响检索精度和上下文长度，需权衡。
设计考量：
| 维度 | 小切片（100-300字符） | 大切片（500-1000字符） |
|---|---|---|
| 检索精度 | 高（更精准匹配） | 低（包含噪声多） |
| 上下文完整性 | 低（语义可能断裂） | 高（信息完整） |
| Token消耗 | 低 | 高 |
| 推荐值 | 128-256（代码） | 500-800（文档） |
最佳实践：
- 通用文档：512字符 + 50字符重叠
- 代码：按函数/类切分，不固定大小
- 结构化文档：按标题/段落切分
三、切片方式：基于语义 vs 基于token
| 方式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 基于token | 按固定token数切分 | 简单可控 | 可能切断语义（句子、代码块） |
| 基于语义 | 按句子、段落、代码块边界切分 | 保持语义完整 | 切片大小不均，实现复杂 |
基于token的做法：
python
def chunk_by_tokens(text, max_tokens=500):
tokens = tokenizer.encode(text)
chunks = [tokens[i:i+max_tokens] for i in range(0, len(tokens), max_tokens - 50)]
return [tokenizer.decode(chunk) for chunk in chunks]基于语义的做法：
python
def chunk_by_semantic(text, max_chars=800):
# 优先按段落分割
paragraphs = text.split('\n\n')
chunks = []
current = ''
for para in paragraphs:
if len(current + para) > max_chars:
chunks.append(current)
current = para
else:
current += '\n\n' + para
if current:
chunks.append(current)
return chunks四、大模型上下文长度（以小米为例）
| 模型 | 上下文长度 |
|---|---|
| GPT-4 | 8K-128K（Turbo 128K） |
| GPT-4o | 128K |
| Claude 3 | 200K |
| 小米MiLM | 约32K-128K（具体需查最新文档） |
回答建议：如实说明你用的模型和长度，如果不确定可以说"我主要用的是GPT-4 128K版本，小米模型我记得大约是32K"。
五、上下文压缩如何保证语义化
回答思路：上下文压缩是在token超限时，用摘要替代原始消息。
常见方法：
- 摘要压缩：调用LLM对历史对话生成摘要
- 关键信息提取：只保留实体、事件、决策，丢弃冗余描述
- 滑动窗口：保留最近N条消息，丢弃更早的
- 混合策略：最近消息保留原文，更早的生成摘要
保证语义化的技巧：
- 提示词明确要求："请保留原始对话中的关键实体、已做出的决策、待解决的问题"
- 评估摘要质量：人工抽查或使用ROUGE等指标
- 设置重要消息标记：用户标记为"重要"的消息不压缩
python
def compress_context(messages, max_tokens=8000):
tokens = estimate_tokens(messages)
if tokens <= max_tokens:
return messages
# 保留系统消息 + 最近6条
system = [m for m in messages if m['role'] == 'system']
recent = messages[-6:]
to_compress = messages[1:-6] if len(messages) > 7 else []
if to_compress:
summary = llm.summarize(to_compress) # 调用LLM生成摘要
return system + [{'role': 'system', 'content': f'历史摘要：{summary}'}] + recent
return system + recent六、大文件上传、页面关闭如何兜底
回答思路 ：核心是断点续传 + 本地持久化。
兜底方案：
- IndexedDB存储分片信息：上传过程中，将已上传分片索引、文件hash存到IndexedDB
- 监听页面关闭事件 ：
beforeunload时保存上传进度 - 恢复上传：页面重新打开时，读取存储的上传进度，继续上传
- Web Worker：将上传任务移到Worker线程，避免被页面关闭影响
javascript
// 保存上传进度
window.addEventListener('beforeunload', () => {
localStorage.setItem('upload_progress', JSON.stringify({
fileId: currentFileId,
uploadedChunks: uploadedIndices,
totalChunks: totalChunks
}))
})
// 恢复上传
function resumeUpload() {
const saved = localStorage.getItem('upload_progress')
if (saved) {
const { fileId, uploadedChunks, totalChunks } = JSON.parse(saved)
// 从断点继续上传
uploadRemainingChunks(fileId, uploadedChunks, totalChunks)
}
}七、HTTP2多路复用底层原理
回答思路：参考之前面经的HTTP2帧结构。
核心 ：HTTP2将请求/响应拆分成帧（Frame） ，每个帧带有唯一的流ID（Stream ID）。
保证消息不串联的机制：
- 每个请求分配独立Stream ID
- 同一流的所有帧携带相同Stream ID
- 接收端根据Stream ID重组数据
- 不同流的帧可以交错传输，互不干扰
text
HTTP/2帧结构：
+----------------------------------+
| Length (24) | Type (8) | Flags (8) |
+----------------------------------+
| Stream ID (31) | ... |
+----------------------------------+八~九：驱动工程（Drive Engineering）与上下文工程
驱动工程（Drive Engineering） ：指设计Agent时的目标驱动 和反馈驱动机制。
如何设计符合驱动工程的Agent：
- 目标分解：将复杂任务拆解成子目标
- 反馈循环：Agent执行后收集结果，反馈到下一步决策
- 奖励函数：定义成功/失败的标准，引导Agent行为
- 可观测性：记录Agent的思考和行动轨迹，便于调优
上下文工程：管理Agent的对话上下文、记忆、工具调用结果。
核心设计：
- 短期记忆：当前对话消息（滑动窗口）
- 长期记忆：向量数据库存储历史关键信息
- 工作记忆：当前任务的中间结果
- 工具结果缓存：避免重复调用相同工具
📚 知识点速查表
| 知识点 | 核心要点 |
|---|---|
| Prompt设计 | 角色设定、任务描述、输出格式、约束、Few-shot、CoT |
| 切片大小 | 通用500-800字符，代码按函数切分，128-512可 |
| 语义切片 vs token切片 | 语义保完整，token可控；可混合使用 |
| 上下文压缩 | 摘要压缩、滑动窗口、关键信息提取 |
| 大文件兜底 | IndexedDB存储进度、beforeunload保存、断点续传 |
| HTTP2多路复用 | 帧+Stream ID，接收端重组 |
| 驱动工程 | 目标驱动、反馈循环、奖励函数、可观测性 |
| 上下文工程 | 短期/长期/工作记忆、工具结果缓存 |
📌 最后一句：
腾讯云智这场一面，是一场"AI工程化"的专项面试。从Prompt设计、向量切片策略，到上下文压缩、大文件兜底，再到驱动工程、上下文工程，面试官围绕RAG和Agent链路层层追问。候选人感慨"为什么全是AI相关"，但这正说明AI应用开发已渗透到前端领域------未来的前端，不仅要会写UI，更要懂AI链路、能调Prompt、会设计Agent。 能答好这套题，说明你已经站在了AI前端的前沿。