说实话这轮面试来的有点突然。我本来只是把 MiniMax 挂在海投列表里觉得“AI 大模型公司嘛前端大概就是页面仔做聊天窗口”没想到一面电话打过来之后我花了整整一个晚上重新认识这家公司和整个 AI 产品前端的玩法。面完之后最强烈的感受是AI 公司面试前端问的早就不只是“Vue 响应式原理”和“flex 布局”这种八股了而是“你有没有真的把某个东西从头到尾做出来并且能说清楚它的边界”。这篇文章就按我真实的面试顺序把三面遇到的高频题、我当时的回答思路、以及事后复盘出来的坑全部整理出来。1. 面试前把 MiniMax 和AI 产品前端的特性摸了个透1.1 先搞清楚对方是家什么公司MiniMax 是国内头部的 AI 大模型公司旗下产品包括海螺 AI、星野这类偏 C 端的对话/角色扮演应用。这和传统电商、中后台公司对前端的诉求差异非常大大量流式输出、多模态内容展示、聊天式交互、私有化部署带来的前端配套几乎每个环节都跟“实时渲染”和“状态管理”较劲。我面试前做的最重要一件事是把“MiniMax 前端岗”放到他们实际产品形态里去理解。比如海螺 AI 的网页端它既要处理服务端通过 SSEServer-Sent Events持续推过来的 token又要保证长对话场景下页面不卡顿还要支持文本、图片、语音等多种消息类型的混合展示。这种场景下前端的能力重心不是“做 UI”而是“做数据流”。所以我在准备时把重点从背组件 API 调整到了流式协议设计、渲染性能优化、异常重试这些方向。1.2 从热词里反推岗位画像面试前一晚我把网上近几个月和 MiniMax 相关的技术热词扫了一遍。有意思的是高频出现的不是“前端三件套”而是一串看起来更“后端”的词MiniMax H3 本地部署、H3 整合包、ComfyUI 硬件配置、AnythingLLM、显存不足、VAE 解码。我当时第一反应是“这些东西跟我前端有什么关系”但冷静下来想这恰恰暴露了岗位的真实画像。我用表格整理了一个观察热词方向背后可能的面试考点MiniMax H3 本地部署、整合包对模型部署链路、环境依赖、硬件瓶颈是否有基本认知ComfyUI H3 的硬件配置能否理解不同显存下的策略选择量化、分块、降分辨率AnythingLLM 是 GitHub 前端应用是否研究过 AI 应用的开源前端架构前端 worker 上传大文件、JS 解码 H264对浏览器端计算能力边界是否熟悉字典管理、微前端、组件库中后台前端基本功是否扎实这套组合拳下来基本可以判断面试官不是传统业务团队至少也是和“AI 应用落地”强相关的团队。他们希望招的前端要能配合模型侧做私有化部署也要能快速搭建类对话产品的前端。我后来把简历里的项目描述也做了对应的“翻译”。1.3 给简历里的项目重新做了“翻译”我原本简历上写的是“负责 AI 对话模块的前端开发实现了聊天界面与消息列表”。这写得太“页面”了。面试前我改成了设计了一套基于 SSE 的流式消息协议处理了中断重连、增量渲染与旧消息折叠结合 Web Worker 实现大文件分片上传支持断点续传与分片级重试独立完成 MiniMax H3 本地部署在 12GB 显存环境下通过量化与分块解码将单轮推理显存峰值控制在可运行范围。这轮“翻译”非常关键。面试官后来几乎全程围绕这三条经历追问几乎没有再问我“数组去重有几种写法”这种大路货。所以如果你也想投 AI 公司前端岗建议提前把每一个项目经历都往“性能和协议”上靠而不是停留在“我实现了什么界面”。2. 一面基础题怎么从“八股”变成“现场定位”2.1 组件库、字典管理中后台前端绕不开的考题一面开场是常规自我介绍然后直接进入了技术提问。第一个意外的是这个问题“前端系统管理下的字典管理一般有啥用”这题在业务系统里非常常见但很多人会答得很浅“就是存枚举值嘛用了方便维护。”我当时把层级拆成了三层第一层是“数据字典”本身把业务里可枚举的固定值比如性别、订单状态、角色类型从代码里抽离存到后端配置表或前端常量表里避免硬编码散落各地。第二层是“动态渲染”因为业务枚举会变所以字典项往往需要支持运行时加载前端拿到字典后下拉框、表格列、状态标签才能动态渲染而不是每次改枚举都要发一版前端。第三层是“权限和缓存”字典可能还要区分租户、区分环境这就引出了请求时机、缓存失效、接口粒度的问题。我当时补了一个实际例子如果订单状态有“待支付 / 已支付 / 已取消”三种状态字典管理会把状态值映射到中文文案和 tag 颜色前后端只传 status 的 key界面展示全由前端根据字典解析。这样一来后端枚举变动不会导致前端要跟着发版系统管理的核心价值就是降低耦合。面试官点了点头后续顺着这个点扩展问到了组件库设计思路和微前端拆分说明这题其实是在考察“中后台工程化”的掌握度。2.2 Vue 响应式、微前端与工程化连环问一面大概率会问到框架基础。MiniMax 面试官没上来就让人背“Vue2 和 Vue3 的响应式区别”而是先问“如果有两个系统需要共享一套侧边栏和登录状态你会怎么做”。我从 iframe 嵌入、npm 包共享、微前端三种方案分别说了一遍重点对比了 qiankun 和 module federation。这里有个小坑想提醒大家不要以为微前端只是技术选型问题面试官真正关心的是“拆分的粒度”和“样式/状态隔离的成本”。我当时的回答思路是先判断业务边界比如用户中心、订单中心、支付中心是否独立团队维护再考虑运行时复用与构建时复用的取舍qiankun 适合运行时集成但子应用样式冲突和 JS 沙箱开销都是问题模块联邦更适合做“依赖共享”把 react/vue 这类公共库单独抽出来减少重复加载体积。接着 Vue 响应式被问到了“如果 Vue3 里有一个对象的深层属性被修改整个渲染流程是怎么走的”我顺着reactive的 Proxy 代理、依赖收集、派发更新、组件级更新队列一条线讲下来面试官又抛出了“为什么 Vue3 把 watcher 改成 effect 和调度器”。这就是典型的概念串讲题如果只背结论而不看源码很容易在第二层就被卡住。2.3 手写题Worker 上传大文件与 JS 解码 H264一面有两道比较硬核的手写题都和“浏览器端计算能力边界”有关。第一道是“使用 worker 实现大文件上传写出核心伪代码”。要求是文件切片比如按 5MB 一片每个分片计算 hash作为唯一标识分片并发上传限制并发数支持分片级失败重试。我当时写了一个简版结构// 主线程 const file input.files[0]; const CHUNK_SIZE 5 * 1024 * 1024; const chunks []; let offset 0; while (offset file.size) { chunks.push(file.slice(offset, offset CHUNK_SIZE)); offset CHUNK_SIZE; } const worker new Worker(/upload-worker.js); worker.postMessage({ chunks, fileName: file.name }); worker.onmessage (e) { if (e.data.type progress) { updateProgress(e.data.percent); } if (e.data.type done) { notifyComplete(e.data.fileId); } };Worker 内部维护一个并发池// upload-worker.js let pending []; let activeCount 0; const MAX_CONCURRENT 3; self.onmessage async (e) { const { chunks, fileName } e.data; chunks.forEach((chunk, index) { const task { chunk, index, retries: 0 }; pending.push(task); }); runPool(); }; async function runPool() { while (pending.length activeCount MAX_CONCURRENT) { activeCount; const task pending.shift(); uploadChunk(task) .catch(() { if (task.retries 3) { task.retries; pending.unshift(task); } }) .finally(() { activeCount--; if (pending.length) runPool(); }); } }面试官追问了一句“如果最后一个分片一直失败怎么办”这就是在考察异常处理不能只靠前端无脑重试还要结合后端接口做“分片状态查询”服务端返回哪些分片已上传前端只补传缺失分片。我补了这层才把分。第二道是“前端 JS 怎么解码 H264”。这里的关键是分清“要不要自己写解码器”。正确做法是用浏览器原生能力去解而不是从零实现 H264 算法。目前主流思路是 WebCodecsconst decoder new VideoDecoder({ output: (frame) { // 将 frame 绘制到 canvas 或转为 ImageBitmap }, error: (e) console.error(decode error, e), }); decoder.configure({ codec: avc1.42001f, optimizeForLatency: true }); // 假设拿到的是封装好的视频数据需要先解封装成 AVCC/AnnexB 裸流 decoder.decode(new EncodedVideoChunk({ type: key, timestamp: 0, data: avcChunk }));如果面试官问的是“兼容性不行怎么办”备选方案是 WebAssembly 上跑 ffmpeg 的裁剪版但代价是 wasm 体积大、解码性能不如原生。我当时主动说了一句“如果对延迟要求极高也可以走 WebRTC 拉流把解码压力留给浏览器媒体栈”面试官明显比较认可“方案排序”的表达方式。2.4 一面复盘真正让我卡住的地方回头看一面里让我卡住 20 秒的点反而是个看似简单的问题“你在 Worker 里做分片 hash会不会把主线程内存打爆”我当时只想着并发池和重试没考虑分片 hash 的计算策略。实际上如果每个分片都用 FileReader 读成 ArrayBuffer 再算 md5大文件会让浏览器内存飙升。合理做法是边读边算或者先抽样计算 hash或者用流式哈希库如 hash-wasm 的 streaming 模式降低内存峰值。这个点属于“经验题”没真正上传过几百 MB 文件的人很难第一时间答出来。好在我想起自己之前处理过类似场景补充了“分片上传前先用抽样 hash 做 Quick 校验”的方案算是补救回来了。一面整体感觉是题目不偏但每个基础题都会往下追一层到“性能”和“异常边界”。如果平时只刷题不写真实项目很容易在追问里露馅。3. 二面把 MiniMax H3 本地部署讲成了一段“排障故事”3.1 为什么一个前端要去折腾模型部署二面面试官是技术负责人上来扫了一眼简历直接指着“MiniMax H3 本地部署”这一条问“前端为什么要自己部署模型”我当时给了三个理由也是我真实的动机第一我在做 AI 对话产品的时候发现前端高度依赖后端转发的接口协议如果对模型推理过程没有概念很难理解为什么同一个接口有时速度快、有时速度慢更不可能主动设计出“排队中”“推理中”这类状态反馈。第二本地部署能让我以极低成本反复测试不同输出格式尤其是流式输出。我可以在本地环境直接观察模型返回的增量数据调试 SSE 解析逻辑比联调环境里效率高得多。第三我想搞清楚“一条消息从用户输入到模型推理再回到前端渲染”的全链路。只有部署过模型才知道 token 的生成速率、batch size 对首字延迟的影响、以及不同量化精度对输出质量的影响。这些知识反过来指导我做前端交互设计比如什么时候展示 loading什么时候让用户输入下一条。这个回答之后面试官没有再质疑“前端越界”的问题反而开始认真问部署细节。3.2 H3 的硬件门槛与 ComfyUI 整合包的实际体验MiniMax H3 是开源模型里比较吃显存的那一类。社区里流传很广的“h3 整合包”和“h3 懒人包”本质上就是把运行环境、依赖、预训练权重打包好用户只需要在本地把模型服务拉起来再配合 ComfyUI 这类图形化工作流来做图像/视频生成。我实测下来的硬件结论是显存容量实际体验8GB基本只能跑量化后的小尺寸权重出图分辨率受限容易爆显存12GB如 3060可以跑常规精度的 H3但需要配合分块解码tiled VAE16GB比较舒服能开更高 batch size也能跑中等分辨率视频32GB理论上很充裕但我在测试时仍然碰到了 VAE 解码阶段显存陡增的问题很多教程分享“ComfyUI H3 整合包在 3060 上怎么跑”实际走一遍会发现最卡人的不是模型本身而是环境依赖。PyTorch 版本、CUDA 版本、xformers 是否开启、VAE 的 decode 策略任何一个不对都会报错。3.3 32GB 显存下“VAE 解码内存不足”的完整排障链路这里必须复盘一个我在面试里讲得很详细的真实问题H3 在 32GB 显存下也会报 “ran out of memory when regular VAE decoding”。单看这几词很容易觉得“32G 都跑不动是不是权重有问题”但实际不是。排查过程我分成了四步第一步看日志。崩溃发生在 regular VAE decoding 阶段不是模型主干推理阶段。这说明模型权重加载没问题问题在图像解码环节。第二步查 VAE 的工作方式。H3 这类模型的 VAE 在把 latent 转换为像素时如果直接对整个 latent 做一次解码显存峰值会极高。尤其当输出分辨率大、batch size 大于 1 时解码阶段显存可能瞬间冲高甚至超过 32GB。第三步改用 tiled VAE分块解码。把大的 latent 图切成小块逐块 decode 后再拼回完整图像。这个过程类似前端做“图片瓦片加载”虽然慢一点但显存峰值显著下降。ComfyUI 里可以直接开启tiled VAE相关选项。第四步如果仍然爆显存就降低 batch size、改用 FP16 推理、或者换更小的 VAE 权重变体。我把 ComfyUI 的命令行改成类似这样python main.py \ --highvram \ --force-fp16 \ --use-split-vaeuse-split-vae就是让 VAE 走分块解码。改完再跑同样的工作流显存峰值从接近 32GB 降到 24GB 左右终于稳定跑通了。面试官听完这四步问了一个很有深度的引申题“如果你在浏览器端部署一个轻量模型会遇到类似问题吗”我理解了他是想考察“推理资源约束”这个通用概念就顺着说浏览器端的 WebGPU 推理同样受限需要把模型量化到很小体积并且对输入张量做分块处理本质上和 tiled VAE 的思路一致。这个类比一下把“部署经验”和“前端领域”连接了起来。3.4 技术负责人追问部署经历和前端到底有什么关系二面后半段面试官直接挑明“你做的这些更像算法工程师或运维的活儿前端岗位需要这些吗”我的回答是“需要但目的不同。算法工程师关注的是推理精度运维关注的是服务稳定性前端关注的是‘模型输出如何变成用户可以消费的东西’。”具体展开有三个层面协议对接本地部署能直接把模型返回的原始 JSON 结构打印出来而不是依赖后端二次封装的黑盒这让前端可以更早介入数据格式设计。性能决策知道显存、batch size、量化对速度的影响后前端做交互设计就能理解“为什么这个操作需要等几秒”合理设计 loading、进度条和可取消机制。错误处理部署过程中会遇到大量 OOM、依赖冲突、编译失败的问题这训练了我从日志倒推根因的排查能力。这种能力放在复杂前端项目里就是“看到报错不是直接百度而是先看调用栈和资源占用”。这轮技术负责人面结束后我特意回看了 MiniMax 的产品线他们确实在推进端云协同和私有化部署方向。一个能理解模型部署细节的前端在团队里可以担当“负责将模型能力产品化”的角色而不仅仅是画聊天界面的人。4. 终面系统设计与实时交互的硬核碰撞4.1 SSE 与流式输出AI 对话前端的主干道终面是系统设计题为主。第一个问题是“如果让你设计一个 AI 聊天页面服务端消息是流式到达的你会怎么处理”我把链路拆成了五段第一段连接层。优先用fetch配合ReadableStream而不是原生EventSource。因为原生 EventSource 只支持 GET没法带复杂 headers也很难自定义请求体。用 fetch 流式读取更灵活const response await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages, model: h3 }), }); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { value, done } 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 JSON.parse(line.slice(5)); updateMessageStream(data.delta); } } }第二段增量渲染。每个 message 对象应该有id、role、content、status四个核心字段。流式更新时只改content和status要避免整个列表重新渲染。最好按 message id 做 memo 化只重绘正在接收的那一条。第三段中断恢复。真实场景里 SSE 连接会断前端要记录最后收到的 token 序号或消息序号重连后从断点续拉。如果服务端不支持续传就退化为重新请求并清空旧流。第四段状态机。一条消息至少要经历streaming - completed / failed / aborted几个状态。每个状态对应不同的 UI 表现比如光标闪烁、停止按钮、重试入口。第五段错误兜底。流式接口最容易出现“前一半正常后一半超时”的情况前端必须在 connect 错误、decode 错误、业务错误三种维度分别做提示。4.2 AnythingLLM从开源前端应用反推产品设计面试官提到AnythingLLM 在 GitHub 上是一个比较典型的前端应用让我说说它会怎么设计“模型管理层”。这个问题其实就是考察“前端如何抽象多种模型服务”。AnythingLLM 的形态给了我很大启发它允许用户配置不同的 LLM 服务商把 OpenAI、Anthropic、本地模型等抽象成一个统一的 provider 接口。前端层面核心是三个抽象Provider 封装也就是每个模型服务商都实现同样的chat()、embed()方法返回统一的数据结构模型配置持久化把 API Key、base URL、模型名、温度、上下文长度都存成本地配置对话历史与文档库解耦文档库单独走向量化链路对话时按需检索。我从这个例子展开说如果前端要把 H3 接进一个 AI 应用一定不能把 H3 的请求逻辑写死在页面里而要放在一个可插拔的LLMProvider类里这样后续换模型成本最低。面试官追问“你会怎么设计这个类”我给了大概接口interface LLMProvider { name: string; chat( messages: ChatMessage[], options?: ChatOptions ): PromiseStreamHandler; embed(texts: string[]): Promisenumber[][]; abort(): void; }这个设计思路其实放之四海而皆准不管接 H3 还是其他模型前端都只需要关注“统一的对话协议”和“流式消费”。在 AI 公司面试里“抽象模型服务层”是一个高频考点建议提前准备。4.3 大文件上传与断点续传的完整方案推导终面又提了“大文件上传”问题但这次不是手写 worker而是问“从零设计一个支持断点续传的上传系统”。我把方案拆成前端和后端两个视角前端要做的事切片File 对象按固定大小切成 Blob 数组标识每个分片算 hash如 xxhash主文件也要算一个整体 hash并发控制维护一个发送队列同时最多 3-5 个请求状态持久化把已上传分片记录写到 localStorage 或 IndexedDB页面刷新后能恢复重试与幂等失败分片用uploadId chunkIndex做唯一 key服务端保证同 key 不重复落盘。后端要做的事初始化接口接收文件名、大小、分片数返回 uploadId分片上传接口接收 uploadId、chunkIndex、数据校验后落盘合并接口所有分片到位后触发合并合并前校验文件总大小状态查询接口返回已收到的分片序号前端据此差量重传。面试官会追一个问题“如果用户断网了 10 分钟后回来你已经忘了上传进度怎么办”最稳的做法是前端初始化时先调状态查询接口以服务端已落盘的分片为准而不是以本地记录为准。本地记录只是“提示”服务端才是“权威”。这类系统设计题一定要把“前端只负责表达意图后端负责最终一致性”这个原则讲透。4.4 我差点答崩的开放性问题终面最后一个问题是开放性的“你怎么看 Cursor、Codebuddy 这些前端 AI 工具对岗位的影响”我当时没有按照“AI 会不会取代前端”这种套话回答而是给出了一个实操视角。我说这类工具真正改变的是“编码密度”以前写一个页面需要手动敲几百行现在用自然语言生成一个组件骨架自己再修边界。但前提是你能判断生成代码的质量所以前端的基本功不是被削弱了而是更值钱了。我还补了一个亲身经历我最近做的组件库文档有一半是用 AI 辅助生成的但我和它反复对齐“组件的 props 语义”花了很长时间。AI 能帮你生成 API 文档和用例但它不理解你们团队对组件命名和权限模型的约定。面试官点头等于这个问题的核心是“工具素养”而不是“会不会用某个编辑器”。5. 复盘AI 公司前端岗位真正想看的三个能力5.1 用“端到端理解”替代“页面实现”整场面试下来我最大的体感是面试官对“你会不会写一个弹窗”没有兴趣他关心的是“你能不能理解一条消息如何从模型出发、经过网络、到达浏览器、最终变成流畅的交互”。这意味着准备时要刻意训练“全链路思维”。你做一个聊天界面不能只写v-for渲染消息列表而要主动了解接口协议怎么设计、SSE 怎么解析、断流怎么重连、大量消息怎么虚拟滚动。简历里每一条项目经历都要能向上追溯业务价值、向下延展到协议和性能。5.2 从八股文到“工具链掌握度”传统前端面试看重“原理”AI 公司前端面试更看重“工程效率”。同样是考察框架他们更关心你能不能结合现代工具链把模型接入、工作流编排、私有化部署这些环节串起来。具体来说有这几类工具值得提前积累AI 应用编排类比如 AnythingLLM、Dify 这类开源项目研究它们的前端架构模型部署类至少要跑通过一个开源模型的本地部署哪怕用整合包也算浏览器原生能力类WebCodecs、WebGPU、Web Worker、IndexedDB 这些要能说出它们各自解决的场景前端性能优化类虚拟列表、流式渲染、资源并发控制要能结合 AI 对话这种高频更新场景来谈。5.3 给下一轮面试者的准备清单如果让我把这段经历压缩成一条清单大概是这样至少完整部署过一次开源模型记录下每一步遇到的报错和解决办法把一个 AI 相关的前端项目从“页面实现”重写成“协议 性能 异常”的表述熟练掌握 SSE 和 fetch 流式读取能现场手写解析代码理解 dict/枚举管理、微前端、组件封装这类中后台基础能结合具体业务讲准备一个和 AI 编程工具相关的个人观点不要泛泛而谈留意 ComfyUI、AnythingLLM 这类开源项目的前端设计面试官很可能从里面抽题。这轮面试结束之后我最大的变化是开始把“模型部署”当成前端工具箱里的一项基础能力。以前我觉得 AI 离前端很远顶多是调几个接口现在发现凡是需要实时交互、流式展示、本地推理的 AI 产品几乎每一项技术决策都和前端的工程架构强相关。面试时的那些问题说到底不是想考倒你而是想确认你有没有能力站到模型层和产品层的交界处去思考问题。