企业官网建设流程全解析

很多前端同行一听到“AI公司面试”就开始紧张，总觉得要补一堆算法、要懂模型训练，甚至得会写Python。其实我面完MiniMax这轮下来，最大的感受是：AI公司的前端面试，考察的仍然是前端基本功，只是场景变得更“实时”、更“重交互”，而且面试官非常清楚前端在AI产品里能做什么、不能做什么。这篇文章把我的真实面试经历、每轮的考点、以及我复盘后觉得值得准备的细节全部拆开讲，希望能给准备面AI方向前端岗的同学一些参考。

我自己面的是MiniMax的前端岗位，整体流程走完大概三周，包含一轮电话沟通、两轮技术面、一轮HR面。整个过程下来，方向上几乎没有考任何机器学习的内容，但围绕AI应用常见的前端场景问得非常深，尤其是流式输出、Web Worker、性能优化和工程化设计。

1. 面试流程与整体考察思路

1.1 岗位方向与业务背景

MiniMax是做AI大模型应用的公司，旗下产品线覆盖对话、音视频生成等场景。前端在这个体系里的位置很特殊：既要承载Chat类产品的实时对话体验，也要支撑视频生成、语音合成这类重交互、重状态管理的复杂界面。所以面试官在考察候选人时，重点并不是你能不能写页面，而是你面对“非传统前端场景”时，能不能用前端手段给出可靠的方案。

比如对话产品里的流式输出，本质上是一个持续推送的异步数据流，前端要处理的不只是渲染，还有中断、重连、并发消息、滚动性能、虚拟列表等一系列问题。这比普通管理后台的表格页面要复杂得多，也是MiniMax这类公司愿意在面试里花大量时间深挖的方向。

1.2 各轮次面试的考察重点

我整理了一下我经历的三轮面试大致侧重点：

第一轮更像是一次“基本功体检”，面试官会从你简历上的项目入手，层层追问到底层原理。第二轮则是开放式的场景设计，会给你一个AI产品的具体模块，让你现场聊方案。HR面虽然不聊技术，但会非常关注你在跨团队协作里扮演的角色，以及你对AI产品本身有没有热情和理解。

我的建议是：如果你也想面类似的公司，一定不要只刷八股文，而是把每个知识点的“为什么”想清楚。面试官问“事件循环”基本不会只让你背概念，而是给你一段混合了Promise、setTimeout、async/await的代码，让你写出真实输出顺序，再追问背后的任务队列机制。

2. 核心考点拆解：从事件循环到大文件上传

2.1 事件循环与异步并发控制

第一轮面试里，事件循环几乎是必问的。面试官给了一段代码，包含setTimeout、Promise.resolve、async函数和requestAnimationFrame，让我写出执行顺序。说实话，单纯背“微任务先于宏任务”是不够的，因为async函数内部的await会改变代码的微观执行时机。

比如这段代码：

async function test() { console.log(1); await Promise.resolve(); console.log(2); } console.log(3); test(); console.log(4);

输出顺序是3、1、4、2。原因是async函数执行到await时，会立即返回一个Promise，后续代码被放入微任务队列。这个“立即返回”的机制很多人会忽略，导致输出顺序判断错误。

面试官还追问了一个问题：如果用setTimeout实现一个任务队列，怎么控制最大并发数？这其实是前端上传、消息推送、批量请求场景里常遇到的工程问题。思路是维护一个执行中的计数器，每次启动任务时检查是否达到并发上限。

2.2 大文件上传与Web Worker

热词里频繁出现“前端使用worker上传大文件”，这正好也是我面试中遇到的一个题目：如果让你实现一个大文件上传组件，你会考虑哪些问题？

这个问题非常开放，但核心考察点其实是三个：切片、并发控制、断点续传。切片是把一个File对象按指定大小拆成多个Blob，然后用FormData逐个上传；断点续传需要计算每个切片的hash，服务端记录已接收的切片，前端在重新上传时先请求“已上传切片列表”，只补传缺失的部分。

Web Worker在这种场景下的价值体现在两个地方：一是计算文件hash时，如果文件很大，在主线程算MD5会让页面卡死，应该放到Worker里做；二是当用户同时上传多个文件、每个文件又有很多切片时，上传状态的管理逻辑放在Worker里可以让主线程只负责渲染结果。

面试官追问了一个实际工程问题：如果用户停掉上传，重新打开页面，已经上传的切片还在吗？答案是前端需要把上传进度保存到localStorage或IndexedDB，重新初始化时读取进度，再向后端确认哪些切片已存在。这里能看出来，一个看似简单的问题背后，牵扯到浏览器存储、网络请求、状态持久化等多个知识点。

2.3 虚拟列表与长列表渲染

对话类应用、日志展示、AI生成的代码或文本流式输出，都会遇到长列表问题。MiniMax这类AI产品的界面里，消息列表可能很长，如果直接把几千条消息节点全部渲染到DOM里，性能会非常差。虚拟列表是必聊的话题。

面试官让我聊“如果让你实现一个虚拟列表，你会怎么做”，核心思路是：外层容器固定高度，内层用一个高度等于总列表高度的占位元素撑开滚动条，然后根据scrollTop计算出当前可视区起始索引，只渲染可视区域附近的一小部分节点。

这个题目不难，但面试官会追问细节：如果列表项高度不固定怎么办？我当时的回答是先渲染一次未截断的内容，拿到每个项目实际高度后缓存起来，后续滚动时直接用缓存高度计算位置。这个方法在大多数场景下够用，也有优化空间，但至少说明你理解虚拟列表的根本问题是什么。

3. 框架原理与工程化深度追问

3.1 Vue还是React：框架本质是什么

我简历上写的主要是Vue，但面试官并不介意你用的是哪个框架，而是会问“你对Vue的响应式原理理解到什么程度”。这个问题如果只回答“用Object.defineProperty或Proxy拦截数据变化”，肯定是不够的。

我现场从三个层面答了：数据拦截、依赖收集、派发更新。Vue 2用Object.defineProperty，Vue 3用Proxy，核心都是要在数据变化时通知到依赖它的组件；依赖收集发生在render函数执行时，组件渲染访问了哪个数据，就把当前组件的渲染effect收集到这个数据的依赖列表里；数据变化时依次触发这些effect，组件重新渲染。

面试官接着问了一个很有深度的问题：为什么Vue 3改成Proxy之后，框架层面就不需要$set了？这个问题的关键在于，Object.defineProperty只能拦截已有属性的读取和写入，所以Vue 2需要特殊API来检测“新增属性”；而Proxy是整个对象的代理，无论属性是否存在，访问都会被代理捕获，自然不需要$set。

这类问题在AI公司出现，是因为它们的前端项目往往需要处理大量动态数据——比如一个实时消息对象会不断追加字段、一个流式响应会逐步增加内容，如果你的框架不适合动态数据模型，代码写起来会非常别扭。

3.2 微前端的价值与风险

第二轮面试聊到工程化时，面试官提到“假设我们要把多个AI产品整合到一个工作台里，你会怎么考虑架构”。我自然提到了微前端，但面试官其实更希望你聊清楚“什么时候不该用微前端”。

微前端的思路是让多个独立团队用不同技术栈开发不同子应用，然后在主应用里统一加载。它的价值在于解耦团队、独立发布、渐进迁移。但代价也很明显：运行时性能损耗、样式隔离困难、公共依赖重复加载、通信机制复杂。如果团队只有一个产品线、人数也不多，强行上微前端只会增加维护成本。

面试时可以提出更务实的方案：先统一技术栈，用Monorepo管理多个包，通过组件库和工具库实现代码复用；当业务真的需要独立部署、独立发布时，再考虑用qiankun或module federation。这种思路说明你不仅懂方案，还懂“取舍”，在真实项目里比堆技术名词有说服力得多。

3.3 构建优化与前端架构

MiniMax这类公司很在乎首屏性能和包体大小，因为AI应用往往要加载SDK、模型状态、协议解析等额外资源。面试官问了我简历上一个项目是怎么做构建优化的，我的回答用到了三个方向：代码分割、依赖优化、按需加载。

代码分割用动态import把路由组件拆成独立chunk，访问对应路由时才加载资源；依赖优化则是把变化频率低的第三方库externals出来，通过CDN引用，减少打包体积；按需加载对应的是业务层面的组件或模块，比如一个视频编辑器的功能面板，用户打开才加载。

还有一个容易被忽略的点：sourcemap策略。很多人上线时会把它关闭，但一旦线上报错需要定位问题，没有sourcemap会非常痛苦。我的做法是生产环境生成sourcemap但不公开URL，上传到内部错误监控平台，这样既能定位问题，也不暴露源码。这种细节面试官听的时候明显眼前一亮。

4. AI场景下的前端技术要点

4.1 SSE与流式交互设计

AI对话类产品的核心体验就是“字一个一个蹦出来”，这个效果的底层技术是SSE（Server-Sent Events），而不是WebSocket。这是面试里反复出现的问题，我也单独拿出来讲。

SSE基于HTTP协议，服务器可以向客户端持续推送事件流。相比WebSocket，SSE的优势是协议简单、自带重连机制、不需要额外的心跳封装。对话产品只需要服务端单向推送，SSE是最合适的选择。

前端接入SSE的代码大致是这样的：

const eventSource = new EventSource('/api/chat/stream'); eventSource.onmessage = (event) => { const data = JSON.parse(event.data); updateMessageContent(data.text); }; eventSource.onerror = (error) => { // 处理断线重连 };

但面试官真正关注的是：如果一条消息没推完就断开了怎么办？这里的方案是给每条消息一个唯一ID，前端记录最后接收到的ID，重连后从服务端补齐缺失的部分。另外，生成型AI的输出可能包含特殊字符、换行、Markdown代码块，前端在做增量渲染时需要小心处理，不能直接把半截Markdown扔给渲染器，否则会出现闪烁。

4.2 本地化部署与前端边界

最近热词里频繁出现“MiniMax H3本地部署”“Anything-LLM”“ComfyUI”这些内容，如果你面试前了解过这些概念，会在谈业务场景时更有底气。

Anything-LLM是一个将大模型包装成知识库应用的框架，它本身是一个前端应用，通过浏览器调用后端API，支持多文档检索和对话。这里前端的核心挑战是：如何管理一个持续增长的会话上下文？上下文太长会导致Token超限，前端需要在界面上提供“清空上下文”“切换知识库”等控制能力，同时把上下文状态同步到URL或本地存储，让用户刷新页面后还能恢复会话。

ComfyUI则是节点式AI工作流工具，前端需要处理大量节点的拖拽、连线、实时状态展示。它本质上是一个非常复杂的前端图形化编辑器，需要用到画布渲染、自定义节点、图数据结构、序列化等能力。如果你能在面试中谈到“我很清楚AI工具类前端不只是套壳，而是要把复杂状态管理做扎实”，面试官会认为你真的理解这个岗位。

4.3 前端如何参与AI产品迭代

面试官在第二轮问了一个我没想到的问题：你觉得前端在AI产品里能做什么，不只是实现UI？这个问题很开放，但也是体现你对岗位理解深度的好机会。

我的回答分了几层：第一层是做沉浸式的交互体验，比如流式渲染、骨架屏、优雅的加载状态；第二层是做用户可控的反馈机制，比如让用户看到“模型在思考中”的进度、支持打断生成、支持编辑历史消息；第三层是数据采集与效果观感优化，前端能记录用户对生成结果的点赞/点踩、停留时⻓、复制行为等，这些数据对模型效果评估和产品迭代都有价值。

我还提到了一个具体的例子：AI生成的长文本如果直接渲染，阅读体验很差。我们可以在前端做“结构化后处理”，把模型输出的纯文本分段落、抽标题、生成目录，甚至高亮关键实体。这个并不需要后端参与，纯前端就能做，但对产品体验的提升非常明显。这个回答说完以后，面试官明显聊得更投入了。

5. 手写题与算法题实录

5.1 手写题：可控并发的任务调度器

面试现场手写题是：“实现一个函数，接收任务数组和并发数，要求保证同时执行的任务数不超过给定值，并返回所有任务结果。”

这道题可以直接用Promise.resolve + while循环实现，关键思路是维护一组“正在执行”的Promise，每完成一个就从任务队列里拿下一个。我当时写的是：

async function runWithConcurrency(tasks, limit) { const results = new Array(tasks.length); let index = 0; const workers = Array.from({ length: Math.min(limit, tasks.length) }, async () => { while (true) { const current = index++; if (current >= tasks.length) return; results[current] = await tasks[current](); } }); await Promise.all(workers); return results; }

核心在于用index++作为初始化任务的下标，每个worker不断取下一个任务。这样不会重复执行，也让并发控制的逻辑清晰。面试官追问了异常处理：如果其中一个任务reject了怎么办？可以用Promise.allSettled替代Promise.all，或者在每个任务外面包一层Promise.resolve().then(task).catch(e => e)，确保一个失败不影响其他任务。

这道手写题其实是从大文件上传并发切片的场景抽象出来的。如果你平时写过上传组件的并发控制，答这道题非常顺手。

5.2 算法题：井字棋与minimax算法的启发

面试里没有直接考minimax算法，但聊到AI产品时，面试官问了一个策略游戏场景：如果一个前端游戏产品要做简单AI对手，你会怎么设计？我顺口提到了minimax算法。

minimax是博弈树搜索的经典算法，它的思想是：双方都做出最优选择，轮到我时选对自己最有利的分支，轮到对手时选对对手最有利（也就是对我最不利）的分支。井字棋因为状态空间很小，可以用minimax完整搜索。

如果要用JavaScript实现一个井字棋AI，核心并不复杂：

function minimax(board, depth, isMaximizing) { const winner = checkWinner(board); if (winner === 'AI') return 10 - depth; if (winner === 'HUMAN') return depth - 10; if (isBoardFull(board)) return 0; if (isMaximizing) { let best = -Infinity; for (const move of getEmptyCells(board)) { board[move] = 'AI'; best = Math.max(best, minimax(board, depth + 1, false)); board[move] = null; } return best; } else { let best = Infinity; for (const move of getEmptyCells(board)) { board[move] = 'HUMAN'; best = Math.min(best, minimax(board, depth + 1, true)); board[move] = null; } return best; } }

面试聊到这道题，重点不是真的让你实现它，而是看你能不能把复杂问题拆解成递归、状态评估、回溯这三件事。前端做类似功能时，AI决策往往不需要很高的强度，反而要关注“响应速度”和“可解释性”，这些概念跟模型后端一起协作时非常重要。

5.3 开放设计题：对话工作台

第二轮技术面试的开放题是：如果要你做一个AI对话工作台，支持多会话、多模型切换、流式输出、历史记录管理，你会怎么设计前端架构？

我当时从三个层面回答：状态管理上，会话列表、当前会话消息、流式状态、模型配置分开管理，流式输出时的消息内容单独用一个reducer处理，避免大量useEffect同步数据；数据持久化上，历史记录存IndexedDB，降低请求频率；组件划分上，会话列表、消息列表、编辑器、模型设置各自独立，消息列表用虚拟滚动。

面试官肯定了整体思路，追加了一个细节：如果用户在一个会话中连续发送多条消息，每条消息都在流式输出，而服务端返回的顺序可能不一样，你怎么保证界面显示顺序正确？我的方案是每条消息在创建时就分配一个本地消息ID，并把消息ID与服务端流式响应对应起来，前端维护Map，渲染时按本地消息ID排序。问题本身不难，但说明面试官非常关注真实业务里的边角场景，而不是纸上谈兵。

6. 常见问题与避坑指南

6.1 技术面试容易翻车的四个点

第一，只背结论不解释原理。比如问“为什么虚拟DOM快”，你一定要说清楚它到底在什么场景下快、什么场景下不比直接操作DOM更快，以及它的核心价值其实是“可预测的更新”和“跨平台能力”。面试官问任何问题，都会期待你将“是什么、为什么、什么时候用”串起来。

第二，简历上写的项目被追问就答不上来。这个是最致命的。写在上面的每一个点，你都要能说出来“为什么这么做”“有没有对比过其他方案”“性能提升了多少”。面试官对AI公司前端项目的预期，是你真的做过、真的思考过，而不是挂在README里的demo。

第三，不会表达“我不会”。AI领域很宽，遇到不懂的很正常。我当时有个问题确实没准备到，直接说“这块我没实际做过”，然后补了一句“但基于我理解，我大概会从这几个角度去查资料”。面试官对这种坦诚是认可的，反而会跟你继续聊思路。

第四，忽略跨端和工程化问题。AI产品常常需要同时支持PC端和移动端，也会用到Electron壳子，前端在面试时如果对桌面端、响应式、PWA、离线缓存这些完全没概念，会显得视野太窄。

6.2 如何准备AI公司的前端面试

如果你准备面MiniMax或其他AI公司的前端岗，我给一个具体的准备清单：

• 事件循环、Promise、async/await必须能写出代码执行顺序，并能解释宿主环境的任务队列机制。
• 手写防抖节流、并发控制、虚拟列表、简易响应式系统，每道题都要能讲清楚适用场景和边界问题。
• 会聊SSE和WebSocket的选型，AI对话为什么用SSE更合适，断线重连怎么做。
• 了解大文件上传的完整链路，包括切片、hash、断点续传、并发控制、进度恢复。
• 有一个拿得出手的复杂项目，能讲清楚技术选型、状态管理、性能优化和数据流设计。
• 对AI产品本身有好奇心，能说出几个你常用的AI应用，并分析它们前端体验上的得失。

6.3 关于项目经历描述的核心建议

关于项目经历，我强烈建议不要只写“实现了某某模块”，而是按“背景—方案—难点—结果”的结构来描述。比如不要写“实现了管理系统”，要写“在xx项目中负责xx模块，因为数据量大需要高效渲染，采用了虚拟滚动+按需加载方案，首屏时间降低xx%，滚动帧率稳定在50帧以上”。

面试官听项目时最在意的，不是你用了多牛的技术，而是你有没有解决问题的能力。这个能力在AI公司同样重要，因为AI产品的前端需求变化很快，今天还在做对话界面的流式渲染，明天可能就要做视频生成的进度管理，没有迁移能力很难适应。

7. 面试后的总结与思考

整轮面试走下来，我最大的体会有三点：一是AI公司的前端面试没有想象中那么“黑科技”，核心仍然是前端基本功，只是问题场景更贴近真实AI产品；二是一个非常关键的加分项是“理解AI应用的产品逻辑”，说话之间如果自然流露出对AI应用的熟悉度，会有明显帮助；三是面试官对工程化深入、有性能敏感度的候选人明显更感兴趣，这不是因为公司要做传统后台，而是因为AI应用的交互复杂度决定了前端必须考虑这些问题。

最后分享一个小技巧：在面试结束的提问环节，可以问面试官“你们现在前端遇到最大的技术挑战是什么”。这个提问既能体现你对岗位的关注，也能让你对团队的技术方向有个判断。我当时就问了一嘴，面试官聊了很多关于大模型输出在前端渲染上的一些优化实践，非常坦诚。回来之后我又查了不少资料，把这里面涉及的SSE重连策略、Markdown增量渲染、虚拟列表自适应高度都过了一遍。虽然这场面试最后因为薪资预期和岗位级别的匹配问题没有走完，但整个面试过程带给我的学习收获，远超刷十篇面经。如果你也在准备AI方向的前端岗位，希望这篇内容对你有点帮助。