1. 十月求职季的AI前端面试现状拆解
十月这个时间节点，在招聘市场里向来是个微妙的存在。一边是秋招进入中后段，补录和急招的岗位开始释放；另一边是不少团队在年中调整后重新梳理HC，赶在年底前把人头落定。AI前端这个方向，今年尤其热闹——大模型能力下放到业务侧之后，几乎每个有点规模的产品团队都在琢磨怎么把AI能力塞进自己的前端交互里。于是“AI前端”从一个模糊的概念，变成了实打实的岗位需求。
但问题也恰恰出在这里。岗位需求是新的，面试标准却还没完全沉淀下来。很多面试官自己也是边摸索边招人，JD上写着“熟悉AI应用开发”，实际面试时问的东西可能横跨传统前端、工程化、模型调用、交互设计甚至产品思维。这就导致一个很尴尬的局面：如果你按照传统前端面试那套“老实”打法去准备，大概率会吃亏。
我说的“老实”，具体指什么？就是那种老老实实背八股、老老实实只答问题本身、老老实实等着面试官一步步引导的面试方式。在传统前端岗，这套打法未必出彩，但至少不会出大错。可在AI前端岗，这套打法会让你显得“不够懂行”——因为面试官期待的，是一个能主动理解AI能力边界、能判断什么该在前端做什么该在后端做、能对交互体验有自己想法的人，而不是一个只会调API的页面仔。
这篇文章想聊的，就是怎么在十月这波AI前端面试里，把“老实”收一收，用更贴近岗位真实需求的方式去展示自己。我会从面试考察逻辑、技术准备重点、项目讲述方式、常见追问陷阱几个角度展开，尽量把每个环节背后的“为什么”讲清楚。适合正在准备AI前端方向面试的朋友，也适合想了解这个岗位到底在招什么人的前端从业者。
2. AI前端岗到底在考察什么
2.1 岗位画像：不是“前端+AI”这么简单
很多人看到“AI前端”四个字，第一反应是“前端技术加上会调大模型接口”。这个理解不能说错，但太浅了。我聊过几个正在招这类岗位的团队负责人，他们给出的画像其实更具体：需要一个人能站在前端视角，去解决AI能力落地到用户界面时产生的各种问题。
这些问题包括但不限于：流式输出的渲染性能怎么保证、用户输入的不确定性怎么在前端做预处理、模型返回的结构化数据怎么优雅地映射到组件、多轮对话的状态怎么管理、AI生成内容的加载态和错误态怎么设计、以及最关键的——哪些AI能力适合放在前端做，哪些必须走服务端。
你看，这里面纯“调接口”的部分其实很少，更多的是工程判断和交互设计。所以面试官在筛选人的时候，会特别在意你有没有“端侧AI落地”的思考习惯。如果你只是说“我用axios调了个接口，把返回的文本渲染出来”，那基本就凉了一半。
2.2 面试官的三层考察逻辑
我把AI前端面试的考察点拆成三层，方便你对照准备。
第一层是基础能力层，包括JavaScript/TypeScript功底、框架使用（React或Vue至少精通一个）、工程化配置、性能优化常识。这层和传统前端面试重叠度很高，但有个细节差异：AI前端岗会更看重你对异步编程和状态管理的理解，因为流式响应和多轮对话本质上就是复杂的异步状态问题。
第二层是AI交互层，这是区分普通前端和AI前端的关键。面试官会看你是否理解大模型交互的基本范式，比如流式输出（SSE或WebSocket）、Token概念、上下文窗口限制、Prompt在前端怎么组织、以及如何处理模型的不确定性输出。这层不要求你懂模型训练，但要求你懂模型“用起来”是什么感觉。
第三层是产品思维层，也是最容易被忽视的。面试官可能会问“如果模型返回很慢，你怎么设计加载体验”“如果用户输入了敏感内容，前端要不要拦”“多轮对话里用户想修改之前的某句话，你怎么实现”。这些问题没有标准答案，考的是你有没有站在用户和业务角度想过问题。
2.3 为什么“老实”打法会吃亏
传统前端面试里，面试官问“说说事件循环”，你答清楚宏任务微任务就够了。但AI前端面试里，面试官问“流式输出怎么实现”，如果你只答“用EventSource”，他接着会问“那如果用户中途取消呢”“如果网络断了怎么重连”“如果返回的chunk是半个JSON呢”。这些追问不是刁难，而是真实业务里一定会遇到的问题。
“老实”打法的核心问题是：你只回答了被问到的，没有展示你思考过的。面试官没法从你的回答里判断你有没有实际落地经验，只能默认你没有。所以你需要主动往前多走一步，在回答里自然带出你考虑过的边界情况和解决方案。这不是让你吹牛，而是让你把真实做过的思考展示出来。
3. 技术准备的重点偏移
3.1 流式交互：必须吃透的核心场景
流式输出是AI前端最典型的交互场景，几乎每轮面试都会涉及。你需要准备到什么程度？我建议至少能讲清楚三种实现方式的差异和适用场景。
第一种是SSE（Server-Sent Events），这是目前最常用的方案。它的优势是协议简单、浏览器原生支持、自动重连。但缺点是单向通信，只能服务端推客户端，而且默认不支持POST请求体（虽然可以用一些技巧绕过）。面试时如果你能说出“SSE基于HTTP长连接，服务端设置Content-Type为text/event-stream，前端用EventSource接收”，这算及格。如果能补充“EventSource默认只支持GET，如果参数复杂需要改用fetch加ReadableStream手动解析”，这就加分了。
第二种是WebSocket，适合需要双向通信的场景，比如用户可以在模型输出过程中随时打断或补充信息。但WebSocket的连接管理和心跳维护成本更高，不是所有场景都需要。
第三种是fetch加ReadableStream，这是目前比较灵活的方案，可以发POST请求，可以手动控制读取节奏。缺点是兼容性和错误处理需要自己兜底。
我建议你在面试时主动对比这几种方案，并说明你在项目里为什么选了某一种。比如“我们当时需要传比较长的上下文，GET的URL长度限制扛不住，所以选了fetch流式读取，自己解析SSE格式的数据”。这种回答能直接体现你的工程判断。
3.2 状态管理：多轮对话的复杂度被低估了
多轮对话的状态管理，是另一个高频考察点。很多人觉得不就是把历史消息存数组里吗？但真实场景要复杂得多。
你需要考虑：消息的数据结构怎么设计（role、content、status、timestamp、tokenCount等字段）、流式输出过程中消息状态怎么更新（pending、streaming、done、error）、用户中途编辑某条消息后怎么截断后续上下文、多个会话之间怎么隔离和切换、以及本地缓存和服务端同步的策略。
我踩过的一个坑是：流式输出时如果直接往消息数组里push新内容，React的渲染频率会非常高，长对话下直接卡死。后来改成用buffer攒一批再更新，或者用requestAnimationFrame节流，才把性能拉回来。这种细节在面试里讲出来，比背一百遍useState原理都有用。
3.3 错误处理与降级：体现工程成熟度的地方
AI接口的不稳定性远高于普通后端接口。模型可能超时、可能返回空、可能返回格式错误的内容、可能触发内容安全策略。前端必须有一套完整的错误处理和降级方案。
我一般会准备这几个层次的回答：首先是请求层，设置合理的超时时间和重试策略，但要注意流式请求的重试不能简单重发，否则会出现重复内容；其次是解析层，对每个chunk做容错解析，遇到不完整的JSON先缓存等下一个chunk拼接；然后是UI层，区分“加载中”“生成中断”“生成失败”三种状态，给用户不同的提示和操作选项；最后是降级层，如果流式失败，自动降级为一次性请求，或者提示用户稍后重试。
面试时如果你能把这几个层次讲清楚，面试官基本能判断你是有实战经验的。
3.4 前端AI能力边界：什么该做，什么不该做
这是一个容易被忽略但很能拉开差距的问题。面试官可能会问“你觉得哪些AI能力适合放在前端做”。这时候你需要有清晰的判断逻辑。
适合放前端的：轻量级的文本预处理（比如敏感词过滤、格式校验）、基于规则的意图识别、简单的本地缓存和去重、以及调用第三方AI服务的编排逻辑。
不适合放前端的：需要大模型推理的（除非用WebGPU跑小模型，但成本和收益要仔细算）、需要保护API密钥的、需要大量上下文管理的、以及对延迟敏感但前端算力不够的。
我一般的回答框架是：先看算力和延迟，再看安全和成本，最后看用户体验。如果前端做能显著降低延迟且不泄露密钥，那就前端做；否则走服务端。这个判断逻辑比具体答案更重要。
4. 项目讲述的“不老实”技巧
4.1 用STAR-R结构讲项目
传统STAR（情境、任务、行动、结果）在AI前端面试里不够用，我建议加一个R（Reflection，反思）。因为AI项目迭代快，面试官更想听你从项目里学到了什么、如果重做会怎么改。
举个例子。不要只说“我做了个AI对话页面，用了SSE流式输出，用户反馈不错”。可以这样说：“当时业务方要求一周内上线一个AI问答入口，我评估后选了SSE方案，因为团队对EventSource比较熟。上线后发现两个问题：一是用户经常在生成过程中刷新页面导致内容丢失，二是长对话下消息列表渲染卡顿。后来我加了本地草稿缓存和虚拟列表，才把体验稳住。如果重做，我会一开始就把消息状态设计成可持久化的结构，而不是等出问题再补。”
这种讲法既展示了你的技术选择，又展示了你的问题发现和解决能力，还展示了你的反思习惯。面试官会觉得你是个能独立扛事的人。
4.2 主动暴露技术决策的权衡
面试里最忌讳的是把项目讲得一帆风顺。真实项目一定有权衡和取舍，主动讲出来反而加分。
比如你可以说：“当时在状态管理上纠结过用Redux还是Zustand。Redux生态成熟但样板代码多，Zustand轻量但团队没人用过。考虑到项目周期紧，我选了Redux Toolkit，因为它能减少一部分样板代码，而且团队成员上手快。但后来发现流式更新场景下Redux的dispatch频率太高，又加了一层中间件做节流。”
这种回答传递的信息是：你不是盲目选型，而是有理由、有判断、有补救。这比“我们用了Redux”这种干巴巴的陈述强太多。
4.3 把“不会”转化成“我会怎么学”
面试里遇到不会的问题很正常，尤其是AI前端这种新方向。关键是怎么回应。老实人说“这个我没接触过”，然后就没下文了。不老实但真诚的做法是：“这个我确实没在生产环境用过，但我了解它的基本原理是XXX。如果让我上手，我会先搭个最小demo验证核心流程，然后重点看XXX方面的文档，因为那通常是坑最多的地方。”
这种回答展示了你的学习路径和问题预判能力，面试官反而会觉得你靠谱。因为AI前端本来就是个快速演进的领域，学习能力比现有知识储备更重要。
5. 高频追问与应对策略
5.1 “流式输出怎么处理半截JSON”
这是经典追问。模型返回的chunk不一定按完整JSON边界切分，可能一个JSON被切成两半。应对策略是维护一个buffer，每次收到chunk先拼接到buffer，然后尝试解析，如果解析失败就等下一个chunk。但要注意设置buffer上限，防止异常情况下无限堆积。
更进一步，可以讲你如何设计解析状态机：用标记位记录当前是否在字符串内、是否在转义字符后，避免在字符串中间错误切分。这个细节能直接体现你的编码功底。
5.2 “用户中途取消生成怎么实现”
这题考的是你对AbortController和流式读取取消的理解。基本回答是用AbortController中断fetch请求，同时清理本地的流读取循环和定时器。但加分点在于：取消后已生成的内容怎么处理？是保留还是清空？保留的话怎么标记“已中断”状态？这些产品层面的考虑能让你脱颖而出。
5.3 “多轮对话上下文超了怎么办”
这题没有标准答案，但有几个方向可以聊：前端做滑动窗口截断（保留最近N轮）、做摘要压缩（调模型总结早期对话）、或者提示用户开启新会话。你需要说明每种方案的优缺点，以及你在项目里怎么选的。比如“我们当时选了滑动窗口，因为实现简单且可控，但缺点是用户如果引用很早之前的内容会丢失上下文。后来加了个手动置顶功能，让用户可以把关键消息固定住。”
5.4 “怎么防止Prompt注入”
前端能做的有限，但可以做一些基础防护：对用户输入做长度限制和特殊字符过滤、在拼接Prompt时用明确的分隔符包裹用户输入、避免把系统Prompt暴露在客户端。更重要的回答是：真正的防护要在服务端做，前端只是第一道防线。这种边界意识面试官很看重。
5.5 “AI生成的内容怎么做安全审核”
这题考的是你对内容安全的理解。前端可以做的是：在渲染前对模型返回的文本做基础过滤（比如屏蔽特定标签）、对Markdown渲染做XSS防护、对链接做安全跳转提示。但同样要说明，完整的内容安全需要服务端和模型层配合。不要试图在前端做所有事，那既不现实也不安全。
6. 面试节奏与沟通策略
6.1 主动引导话题走向你的强项
面试是双向沟通，不是被动答题。当你发现面试官问的方向你不太熟时，可以在回答末尾自然带一句“这块我经验不多，不过我在XXX方面做过类似的尝试”。如果面试官顺着问下去，你就把话题引到了自己的舒适区。
比如面试官问“你们怎么做模型微调的”，你可以说“微调主要是算法同学在做，我这边负责的是前端交互和流式渲染的优化，这块我踩过不少坑”。大部分面试官会顺着问“那你讲讲流式渲染的坑”，你就掌握了主动权。
6.2 用具体数字增强说服力
“优化了性能”不如“把首屏渲染从2.3秒降到了0.8秒”。“处理了长对话”不如“在200轮对话下保持60帧滚动”。数字不需要多精确，但要有。如果记不清具体数字，可以说“大概从X量级降到了Y量级”。面试官不会去核实，但会感受到你有量化意识。
6.3 反问环节要问出水平
面试最后的反问环节，很多人问“团队氛围怎么样”“加班多不多”。这些问题不是不能问，但浪费了展示自己的机会。更好的问法是：“团队现在AI前端这块最大的技术挑战是什么”“你们怎么衡量一个AI交互做得好不好”“这个岗位前三个月最希望我解决什么问题”。这些问题既帮你了解岗位，又让面试官觉得你在认真思考怎么融入。
7. 我踩过的坑与实操心得
7.1 不要过度包装，但要充分展示
“不老实”不等于撒谎。你没做过的技术不要说做过，但你可以说你了解原理、做过demo、研究过方案。面试官反感的不是经验少，而是不懂装懂。我见过候选人把别人的项目说成自己的，追问两个细节就露馅了，直接进黑名单。真诚加上主动展示思考过程，比虚假的完美履历更有说服力。
7.2 准备一个“万能项目”应对各种追问
不管你做过几个AI前端项目，挑一个最完整的，把它吃透到每个技术决策都能讲出所以然。面试官问流式，你从这个项目里讲；问状态管理，还从这个项目里讲；问错误处理，继续从这个项目里讲。一个讲透的项目，比三个泛泛而谈的项目更有价值。
7.3 面试前做一次“自问自答”演练
把你项目里每个技术点都列出来，然后自己问自己“为什么选这个”“遇到什么问题”“怎么解决的”“如果重做会怎么改”。每个问题写三句话的答案，面试前过一遍。这个准备方式比背八股高效得多，因为AI前端面试的问题高度依赖你的项目经历，通用八股反而问得少。
7.4 注意沟通中的“技术自信”
面试时的语气和态度也很重要。同样一句话，“我用了SSE”和“我评估后选了SSE，因为当时场景是单向推送，SSE的自动重连能省不少事”，传递的自信程度完全不同。不要害怕表达自己的判断，哪怕判断不完美，也比没有判断强。AI前端是个新领域，面试官也在摸索，他更想看到的是一个有主见、能独立做技术决策的人。
7.5 十月面试的时间窗口很关键
十月这个时间点，很多团队是急着补人，面试流程会比秋招前期快很多。这意味着你准备的时间可能不多，但也意味着面试官对“完美候选人”的期待会降低。抓住这个窗口，把核心场景准备扎实，比追求面面俱到更有效。我个人的经验是，十月面试里，流式交互、状态管理、错误处理这三块准备到位，基本能覆盖七八成的技术追问。
最后分享一个我常用的准备方法：拿一张白纸，把你最熟悉的AI前端项目画成架构图，标出每个模块的技术选型和数据流向。然后对着这张图，假装给一个不懂的人讲一遍。讲不顺的地方，就是你面试会被问倒的地方。这个方法我每次面试前都会用，比刷题管用。
