企业官网建设流程全解析

1. 十月AI前端岗面试的真实体感

十月份这波AI前端岗位的面试，我前前后后跟了将近三周，面了六家，也帮两个朋友做了模拟面，聊下来最大的感受就一句话：岗位变少了，但要求变刁了。以前你会个React、能写业务组件、懂点工程化，基本就能过一面；现在同样级别的岗位，面试官会追着问你“大模型流式输出在前端怎么接”“SSE和WebSocket在AI对话场景里你怎么选”“Token消耗在前端有没有做节流”。这些问题放在两年前，前端面试里根本不会出现。

所谓AI前端岗，并不是一个官方定义的职位名称，而是市场上对面向AI应用做前端开发这类岗位的统称。它可能叫“大模型应用前端工程师”“AI产品前端”“智能交互前端”，也可能就挂在普通前端JD里，但进去之后做的是对话界面、Agent编排面板、知识库管理后台、多模态输入输出这些活。核心关键词就几个：流式渲染、会话状态管理、多模态交互、Prompt工程的前端侧配合、性能与成本控制。

这篇文章适合谁看？如果你是在职前端想往AI方向靠，或者是刚毕业在投十月这批岗位，又或者你面了几家发现总在二面挂掉，那下面的内容应该能帮你把思路捋清楚。我不会讲什么“前端已死”这种情绪话，只讲我实际面到的东西、踩过的坑，以及我复盘出来的应对方法。

2. 岗位需求拆解：他们到底在面什么

2.1 从JD里抠出来的四个核心能力项

我把六家公司的JD和面试记录整理了一下，发现出现频率最高的能力项集中在四个方向。第一个是流式交互处理，几乎每家公司都问到了。具体包括：SSE连接怎么建立、断线怎么重连、流式数据怎么分片渲染、Markdown流式输出时代码块高亮怎么处理不闪烁。第二个是会话与上下文管理，比如多轮对话的历史记录怎么存、上下文窗口超限时前端怎么截断或摘要、多个会话之间怎么隔离状态。第三个是多模态输入输出，语音输入转文字、图片上传后的预览与压缩、文件解析进度展示，这些在传统前端里也有，但在AI场景下对实时性和容错要求更高。第四个是性能与成本意识，面试官会问你有没有在前端做Token估算、有没有对重复请求做缓存、流式输出时怎么避免频繁重渲染导致卡顿。

注意：很多候选人栽在“只答技术实现，不提成本”。AI前端和普通前端最大的区别之一，就是你的每一行代码都可能直接烧钱。面试官很在意你有没有这个意识。

2.2 不同规模团队的考察侧重点差异

我面的六家里，有两家是成熟业务线转AI方向，两家是创业团队，还有两家是内部创新项目。成熟业务线出来的面试官更看重工程稳定性和可维护性，他们会问你的流式方案怎么降级、怎么埋点监控、怎么保证多端一致。创业团队的面试官更看重上手速度和全栈意识，他们会问你有没有自己搭过Demo、对LangChain这类编排框架的前端侧接口熟不熟、能不能接受前后端一起写。内部创新项目则比较看重学习能力和技术判断力，他们会给一个模糊需求，比如“做一个能根据用户输入自动生成表格的界面”，然后看你现场怎么拆。

这里有个很实际的建议：面之前先判断对方团队处于什么阶段。成熟团队你就多聊工程化、监控、灰度；创业团队你就多聊快速验证、最小闭环、你做过什么Side Project。用同一套话术面所有公司，十月份这种竞争强度下基本没戏。

2.3 那些JD里不写但面试必问的隐藏项

有几个东西JD里一个字没提，但面试里反复出现。第一是对主流大模型API的基本认知，比如OpenAI的接口格式、国内几家平台的差异、流式返回的chunk结构长什么样。你不需要会调参训练，但至少要知道delta字段里有什么、finish_reason什么时候出现。第二是对前端框架底层渲染机制的理解，因为流式输出会高频触发setState，如果你不懂React的批处理机制或者Vue的响应式更新队列，写出来的对话界面就会卡。第三是对Markdown和代码高亮的处理经验，AI输出大量Markdown，流式过程中代码块可能只渲染了一半，怎么处理不报错、不闪烁，这是个很具体的工程问题。

我面第二家的时候，面试官直接让我在白板上写一个流式Markdown渲染的伪代码，重点不是代码本身，而是看我有没有考虑“未闭合代码块”的情况。这个细节我后面会展开讲。

3. 技术面核心考点与应对思路

3.1 流式输出：SSE、WebSocket还是Fetch Stream

这是十月份面试里出现频率最高的问题，没有之一。面试官通常会先问你“AI对话的流式输出你用什么方案”，然后根据你的回答往下追。我把三种主流方案的对比整理成表格，方便你直接对照记忆。

我实际面试时的回答思路是这样的：先说我默认选SSE，因为AI对话绝大多数是服务端单向推文本，SSE的自动重连和事件ID机制能省很多事。然后补一句，如果涉及语音实时对话或者需要客户端频繁发中断信号，我会切到WebSocket。最后提一下Fetch Stream适合那种一次性请求、不需要长连接的场景，比如流式生成表格数据。这样答下来，面试官会觉得你不是背答案，而是真的做过选型。

实操心得：SSE在HTTP/1.1下每个域名只能开6个连接，如果你页面上同时有多个流式请求，记得做连接池或者排队。这个点我在面第三家的时候被追问过，答出来之后面试官明显态度好了很多。

3.2 会话状态管理：前端到底该存多少东西

AI前端的会话状态比普通应用复杂得多。普通应用可能就存个用户信息和列表数据，AI前端要存：当前会话ID、历史消息数组、每条消息的流式状态、上下文Token计数、模型参数配置、附件列表。面试官常问的是“你怎么设计这个状态结构”和“上下文超了怎么办”。

我的做法是把状态分成三层。第一层是会话元数据，包括会话ID、标题、创建时间、模型名称，这些存在全局状态里，用Zustand或者Pinia管理。第二层是消息列表，每条消息包含角色、内容、状态（加载中/完成/出错）、Token数，这个用数组存，流式更新时只改最后一条。第三层是临时输入状态，比如用户正在打的字、待发送的附件，这些放在组件本地状态里，不往全局塞。

上下文超限的处理，面试官想听的不是“截断”两个字，而是你的策略。我一般会说：前端会维护一个Token估算函数，按字符数粗算，中文大概1.5字符一个Token，英文4字符一个Token。当累计超过模型窗口的80%时，触发摘要逻辑，把最早的两轮对话发给后端做摘要，用摘要替换原始消息。如果后端没这个能力，前端就做滑动窗口，保留最近N轮，但会在界面上提示用户“较早的对话已折叠”。

3.3 多模态交互：语音、图片、文件的处理链路

十月份面到多模态的岗位明显变多了。语音输入这块，面试官会问你怎么做VAD（语音活动检测）、怎么处理打断、识别结果怎么和文本输入框联动。我的经验是，前端做VAD一般用AudioContext的AnalyserNode算音量阈值，超过阈值开始录音，静默超过800毫秒自动停止。打断逻辑要小心，用户说话时如果AI正在流式输出，要立刻发中断信号并停止渲染。

图片和文件处理相对常规，但AI场景下有几个特殊点。图片上传前要压缩，因为多模态模型对图片尺寸有限制，前端用Canvas做等比缩放，一般压到最长边1024像素、质量0.8就够了。文件解析进度展示要用流式读取，大文件不能一次性读进内存。还有一个容易忽略的点：附件的生命周期管理。用户上传的图片在会话结束后要不要删？前端要不要缓存？这些面试官不一定会问，但如果你主动提，会显得很有产品意识。

3.4 性能优化：流式渲染下的重渲染难题

流式输出每秒可能触发几十次状态更新，如果每次更新都导致整个消息列表重渲染，页面很快就会卡死。面试官常问“你怎么优化流式渲染性能”，我一般从三个层面答。

组件层面，把消息列表拆成独立的MessageItem组件，用React.memo或者Vue的computed做缓存，只有正在流式更新的那条消息会重渲染。数据层面，流式chunk不要每个都setState，而是用一个缓冲区累积，每100毫秒或者每积累50个字符才触发一次更新。渲染层面，Markdown解析和代码高亮是重操作，放到Web Worker里做，主线程只负责把解析好的HTML插进去。

注意：Web Worker里不能直接操作DOM，所以解析结果要传回主线程再渲染。另外Worker的通信也有开销，chunk太小反而更慢，我实测下来200毫秒一批比较平衡。

4. 实操复现：一个最小AI对话界面的关键实现

4.1 项目初始化与依赖选择

这一节我带你从零搭一个能跑的最小AI对话界面，重点不是功能多全，而是把上面说的流式、状态、渲染这几个核心点串起来。技术栈我选React + TypeScript + Vite，状态管理用Zustand，Markdown渲染用react-markdown加remark-gfm，代码高亮用shiki。为什么选Shiki不选Highlight.js？因为Shiki基于TextMate语法，高亮更准，而且支持流式场景下的增量渲染，虽然包大一点，但AI场景下代码展示质量很重要。

初始化命令很简单：

npm create vite@latest ai-chat-demo -- --template react-ts cd ai-chat-demo npm install zustand react-markdown remark-gfm shiki

装完之后先把目录结构定下来。我习惯分四个目录：components放UI组件，stores放状态，services放API调用和流式处理，utils放Token估算和Markdown预处理。这个结构不复杂，但后面扩展多模态的时候会很清晰。

4.2 SSE流式请求的封装与中断处理

流式请求我封装成一个streamChat函数，接收消息列表和回调。核心是用fetch加ReadableStream，而不是EventSource，因为EventSource只能发GET请求，没法带复杂的消息体。代码大概长这样：

async function streamChat( messages: Message[], onChunk: (text: string) => void, onDone: () => void, signal: AbortSignal ) { const response = await fetch('/api/chat', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages, stream: true }), signal, }); const reader = response.body?.getReader(); const decoder = new TextDecoder(); let buffer = ''; while (true) { const { done, value } = await reader!.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n'); buffer = lines.pop() || ''; for (const line of lines) { if (line.startsWith('data: ')) { const data = line.slice(6); if (data === '[DONE]') { onDone(); return; } try { const json = JSON.parse(data); onChunk(json.choices[0].delta.content || ''); } catch { /* 忽略不完整分片 */ } } } } onDone(); }

这里有几个细节值得说。buffer的作用是处理跨chunk的分片，因为网络传输不保证每个chunk正好是一行。decoder.decode要传{ stream: true }，否则中文会被截断成乱码。中断用AbortController，用户点停止按钮时调controller.abort()，fetch会抛异常，在catch里把消息状态改成“已停止”就行。

实操心得：有些服务端会在流结束时发一个data: [DONE]，有些直接关连接。你的代码要两种都兼容，不能只等[DONE]。我面第四家的时候，面试官就问我“如果服务端不发DONE你怎么判断结束”，答案就是靠reader.read()返回的done为true。

4.3 流式Markdown渲染的防闪烁处理

流式Markdown最烦人的问题是代码块闪烁。因为Markdown解析器每次拿到不完整的文本，可能把```当成普通文本，下一次又识别成代码块，DOM结构一变，高亮就闪。我的处理办法是在渲染前做一次预处理，检测未闭合的代码块，临时补上闭合标记，渲染完再把标记去掉。

具体做法是写一个normalizeMarkdown函数，用正则统计出现的次数，如果是奇数，就在末尾补一个。同时检测未闭合的行内代码，补上反引号。这样传给react-markdown的文本始终是结构完整的，渲染出来不会跳。代码高亮用Shiki的话，建议把高亮结果缓存起来，相同代码块不要重复高亮。

还有一个细节是自动滚动。流式输出时用户可能正在往上翻历史消息，如果你强制滚到底部，体验很差。我的做法是监听滚动位置，如果用户距离底部小于50像素，才自动滚动；否则显示一个“有新消息”的按钮，点击再滚。

4.4 Token估算与上下文截断的前端实现

Token估算不需要很精确，前端只要做到量级正确就行。我写了一个简单函数：

function estimateTokens(text: string): number { const chineseChars = (text.match(/[\u4e00-\u9fa5]/g) || []).length; const otherChars = text.length - chineseChars; return Math.ceil(chineseChars * 1.5 + otherChars / 4); }

中文按1.5字符一个Token，英文按4字符一个Token，这个比例是我实测下来比较接近的。上下文截断的逻辑是：从最早的消息开始累加Token，超过阈值就把最早的两条合并成一条摘要消息，摘要内容用“前文摘要：”开头，保留关键信息。如果后端支持摘要接口就调后端，不支持就前端简单截断，但要在UI上给用户提示。

注意：截断的时候不要把System Prompt截掉，那个通常放在最前面，要单独保留。另外工具调用的消息格式比较特殊，截断时要么整条保留，要么整条删除，不能拆开。

5. 面试现场：那些让我卡壳的问题和复盘

5.1 被问到“你怎么保证流式输出的顺序”

这个问题我在第二面的时候被问到了，当时答得不太好。面试官问的是：如果用户快速连续发了两条消息，或者网络抖动导致chunk乱序，你怎么保证渲染顺序正确。我当时的回答是“服务端会保证顺序”，但面试官明显不满意。后来我复盘，正确的答法应该是：前端给每个请求分配一个自增的requestId，chunk里带上这个ID，渲染时只处理当前活跃请求的chunk，旧请求的chunk直接丢弃。同时用AbortController在发新请求前取消旧请求，双保险。

5.2 被问到“前端怎么做Prompt模板管理”

这个问题出现在一家做Agent平台的公司。他们问的是：用户可以在界面上配置Prompt模板，前端怎么管理这些模板的版本、变量替换和预览。我当时的思路是：模板存成JSON，包含id、name、content、variables字段，变量用{{var}}占位，渲染时用正则替换。版本管理用简单的数组存历史版本，预览就是替换变量后渲染Markdown。面试官追问“如果模板里有嵌套变量怎么办”，这个我确实没做过，只能老实说没遇到，但会考虑递归解析或者限制嵌套层级。

5.3 被问到“AI返回的内容有敏感信息怎么处理”

这个问题比较敏感，但面试官问的是技术实现，不是政策。我的回答是：前端不做内容审核，但可以做展示层的过滤，比如检测到特定格式的字符串就替换成占位符，同时把原始内容上报给后端做异步审核。另外流式渲染时，如果某个chunk触发了过滤规则，要立刻中断流并替换已渲染的内容。这个问题的关键是表明你知道前端审核不可靠，真正的审核要在服务端做。

5.4 常见问题速查表

6. 十月面试的节奏把控与心态调整

6.1 投递节奏：别把鸡蛋放一个篮子

十月份岗位少，但竞争的人多，我的建议是分批投递。第一批投两三家你不太想去的，用来练手和收集问题；第二批投你最想去的，这时候你已经知道会被问什么了；第三批投保底的。千万别一上来就投最想去的，我有个朋友就是十月第一周投了心仪公司，一面被流式问题问懵了，后面再投其他家心态一直受影响。

6.2 面试中的沟通技巧：先给结论再展开

AI前端的问题往往很开放，面试官想听的是你的思考过程。我的习惯是先用一句话给结论，比如“我默认选SSE”，然后再展开为什么。这样面试官知道你的立场，后面追问也有方向。最怕的是绕了半天没说选什么，面试官会认为你缺乏判断力。

6.3 被问倒时的应对：诚实加推导

遇到不会的问题，别硬编。我一般会说“这个场景我没实际做过，但我会从X和Y两个角度考虑”，然后现场推导。面试官其实不指望你什么都会，他们看的是你遇到未知问题时的分析能力。我在第五家被问到“流式场景下怎么做A/B测试”，我确实没做过，就从流量分桶、指标采集、渲染差异三个角度推了一遍，最后也过了。

6.4 面试后的复盘方法

每次面完，我会花20分钟把被问到的问题记下来，按“答得好”“答得一般”“完全不会”分类。答得一般的去查资料补上，完全不会的看是不是高频问题，是的话重点准备。十月份我一共整理了47个问题，最后发现真正高频的就那12个，把这12个吃透，后面的面试就从容多了。

7. 一些没人明说但很重要的经验

7.1 作品集比简历更有说服力

十月份我面的一家，面试官直接说“你简历上写做过AI对话，不如给我看看你的Demo”。幸好我提前部署了一个简单的对话页面，虽然功能不多，但流式、Markdown渲染、中断都有。面试官看完之后问的问题明显更具体，也更信任我的经验。如果你还没作品，花一个周末搭一个，不用很完整，但核心链路要跑通。

7.2 对模型API的基本认知是加分项

不需要你会训练模型，但要知道主流API的请求格式、流式返回结构、常见错误码。我在面试里提了一句“不同平台的chunk结构不一样，有的用delta.content，有的用text，前端要做适配层”，面试官马上接话说“对，我们就是做了个适配层”。这种共鸣会让面试氛围好很多。

7.3 别忽视软技能：跨团队协作的沟通成本

AI前端往往要和算法、后端、产品三方协作。面试官会问“如果算法说这个需求做不了你怎么沟通”，我的回答是：先搞清楚是模型能力限制还是工程限制，如果是模型限制，看能不能通过Prompt或者后处理绕过；如果是工程限制，看能不能降级或者分阶段做。关键是别把问题直接抛回给产品，要带着方案去沟通。

7.4 持续学习的具体路径

AI前端变化很快，我的学习路径是：每周看一次主流模型平台的更新日志，每月读一篇前端流式渲染相关的技术文章，每季度自己动手做一个新Demo。不用贪多，但要保持手感。十月份面试里有个面试官问我“最近在学什么”，我说在研究中端流式渲染和Web Worker的结合，他明显很感兴趣，后面聊了很久。

这个方向后续还可以往Agent编排界面、多模态实时交互、端侧模型推理这些方向扩展。我目前在做的一个小项目是把语音输入和流式输出串起来，做一个能实时打断的语音对话Demo，踩了不少坑，等跑通了再整理出来。如果你也在准备这个方向的面试，建议先把流式渲染和状态管理这两个点吃透，其他的都是在这两个基础上的延伸。