1. 这个学习计划到底在解决什么问题先把话说在前头市面上打着“AI 前端”旗号的课程和路线图我翻过的没有一百也有八十绝大多数犯的是同一个毛病——把“AI 应用前端”和“调个大模型 API 画个聊天框”划等号。真到了面试或者接私活的时候人家问你流式渲染怎么做的、多轮对话状态怎么管的、Agent 的工具调用结果怎么在前端可视化立马露馅。这份“三个月学习计划”要解决的核心矛盾就一个前端工程师如何从“会写页面”升级成“能把 AI 能力稳稳当当落到产品界面里”的人。注意我的措辞是“落到产品界面”不是“会调接口”。这两者之间的差距大概相当于会切菜和能掌勺一桌席的差距。它适合三类人一是有一到三年经验、HTML/CSS/JS 已经写顺了但没碰过 AI 相关业务的初中级前端二是做传统后台管理系统做腻了、想往 AI 产品方向转的开发者三是全栈但前端偏弱、想补齐 AI 应用交互这一环的工程师。如果你连fetch和Promise都还写不利索那我建议先花两周把基础夯实再回来不然这个计划里的流式处理、并发控制会让你非常痛苦。三个月十二周听起来不长但如果你每天能保证两到三小时的有效投入周末再压上半天做项目这个周期是够把一个合格 AI 应用前端该有的能力框架搭起来的。关键在于节奏——不是把知识点铺一遍就完事而是每一周都要有能跑起来、能拿出手的东西。我见过太多人学完一堆概念简历上写“熟悉大模型应用开发”结果连一个带流式输出的对话界面都拿不出来这就很尴尬。下面我把这十二周拆成四个阶段每个阶段讲清楚学什么、为什么这么排、怎么落地、容易踩什么坑。这不是那种“第 1 周学 HTML”的流水账而是按真实项目里会用到的能力倒推出来的路线。2. 第一阶段把地基打到能承重第 1-3 周2.1 为什么第一阶段不碰 AI先啃交互底层很多人一上来就想接大模型我劝你先忍住。AI 应用前端和普通前端最大的区别不在“AI”而在“交互的实时性和不确定性”。普通表单提交用户点一下转个圈返回结果完事。AI 应用呢用户发一句话字符是一个一个往外蹦的中间可能断流可能报错可能用户等不及又发了一条。这套东西的底层是流式数据处理和异步状态管理你基础不牢后面全是空中楼阁。所以前三周我的安排是这样的第一周把 JavaScript 的异步模型彻底吃透重点是Promise、async/await、AbortController和ReadableStream。别觉得这些老生常谈我面试过的人里能说清楚AbortController怎么中断一个正在进行的流式请求的十个里不到三个。第二周啃 TypeScript 的类型系统尤其是泛型、联合类型和类型收窄因为 AI 接口返回的数据结构又深又杂没有类型约束你会在undefined上浪费大量时间。第三周上手一个现代框架的响应式系统React 的useState/useEffect或者 Vue 的ref/reactive都行重点理解“状态变化如何驱动视图更新”这是后面做流式渲染的根基。提示这三周不要贪多每天一个核心概念配一个能跑的小 demo。比如学ReadableStream就写一个把一段长文本逐字打印到页面的例子不涉及任何 AI纯练手。2.2 流式处理AI 应用前端的命门我把流式单独拎出来讲因为它太重要了。大模型的输出天然是流式的后端通常用 SSEServer-Sent Events或者分块的 HTTP 响应把 token 一个个推给前端。前端要做的事情是接收、拼接、渲染、处理中断、处理错误。先讲接收。SSE 的标准用法是EventSource但它有个硬伤——只支持 GET 请求没法带复杂的请求体。所以实际项目里更常见的是用fetch配合ReadableStream手动解析。核心代码大概长这样const response await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ message }), signal: controller.signal }); const reader response.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value, { stream: true }); // 解析 chunk通常是 data: xxx\n\n 格式 handleChunk(chunk); }这段代码看着简单坑却不少。第一decoder.decode的{ stream: true }参数必须加否则一个多字节字符被切在两个 chunk 里就会乱码中文场景下这个问题特别明显。第二chunk 的边界不保证落在完整的一行上你得自己维护一个缓冲区把不完整的行攒着等下一个 chunk 拼上再解析。第三AbortController要提前准备好用户点“停止生成”的时候能立刻中断不然请求还在跑白白烧 token。渲染这块别傻乎乎地每来一个字符就setState一次。React 里高频setState会导致大量重渲染页面直接卡死。正确做法是用requestAnimationFrame做节流或者把累积的文本先存在ref里按固定间隔比如 50ms批量更新一次状态。我实测下来50ms 的间隔肉眼看起来已经是“逐字蹦出”的效果了但渲染压力小了一个数量级。2.3 状态管理多轮对话不是数组 push 那么简单新手做对话界面最容易写成一个大数组用户发一条 push 一条AI 回一条 push 一条。跑起来没问题但一旦涉及“重新生成”“编辑历史消息”“分支对话”这些需求整个数据结构就崩了。我的建议是从第一天就用消息树而不是消息数组来建模。每条消息有唯一的id和指向父消息的parentId这样“重新生成”就是在同一个父节点下挂一个新的子节点用户可以自由切换不同分支。这个设计一开始会多写几十行代码但后期扩展性完全不是一个量级。状态管理库的选择上小项目用框架自带的就够了别上来就 Redux。但如果对话状态复杂到需要跨组件共享、需要时间旅行调试那 Zustand 或者 Pinia 这类轻量方案比 Redux 舒服得多。我个人的偏好是 Zustand它的immer中间件处理嵌套的消息树更新非常顺手。3. 第二阶段把 AI 能力接进来第 4-6 周3.1 大模型接口调用从“能通”到“稳”第四周开始正式接触大模型接口。这里我不绑定任何具体厂商因为接口形态大同小异你要掌握的是通用模式认证怎么传、消息格式怎么组织、参数怎么调、错误怎么处理。消息格式基本是{ role, content }的数组role分system、user、assistant三种。system消息用来设定 AI 的人设和约束这个位置很关键很多效果差异就出在这里。参数方面temperature控制随机性做客服类应用调到 0.2 左右保证稳定做创意类可以到 0.8max_tokens限制输出长度别设太大不然用户等半天还费钱。错误处理是重灾区。网络超时、限流、内容被拦截、模型过载每种错误前端都要有对应的提示和重试策略。我一般会封装一个统一的请求层把错误码映射成用户能看懂的话同时保留原始错误信息方便排查。重试策略上限流类的错误适合指数退避重试内容拦截类的错误重试也没用直接提示用户改输入。注意API Key 绝对不能写在前端代码里。哪怕你做了混淆抓包一样能拿到。正确做法是前端请求自己的后端后端再去调大模型接口Key 存在服务端的环境变量里。这是红线别抱侥幸心理。3.2 提示词工程前端也得懂的那部分你可能觉得提示词是后端或者算法的事但实际项目里前端往往要负责提示词的模板管理和动态拼装。比如用户选了一个“代码助手”的角色前端要把对应的 system prompt 拼进去用户上传了一个文件前端要把文件内容作为上下文注入。这里有个实用技巧把提示词做成可配置的模板用占位符标记变量运行时替换。这样产品和运营改提示词不用动代码前端也不用每次改文案就发版。模板引擎用最简单的字符串替换就行别上 Handlebars 那种重家伙。另外前端要做上下文长度控制。大模型的上下文窗口是有限的历史消息太多会超限。你得实现一个裁剪策略比如保留最近 N 轮对话或者按 token 数估算动态裁剪。token 估算不用太精确中文大概一个字一个 token英文四个字符一个 token粗略算够用了。3.3 多模态输入图片、文件怎么处理现在的 AI 应用基本都支持传图片和文件了。前端这块要做的事情包括文件选择、预览、压缩、格式校验、上传进度、以及把文件内容转成接口需要的格式。图片处理有个坑手机拍的照片动辄好几兆直接传上去又慢又费额度。前端应该先压缩用canvas把图片缩到合理尺寸比如长边 1024px再转成 base64 或者上传到对象存储拿 URL。压缩质量设 0.8 左右肉眼几乎看不出差别体积能小一大半。文件解析这块纯前端能做的有限。PDF、Word 这类格式的文本提取要么用现成的库比如 pdf.js要么交给后端处理。我的建议是前端只做格式校验和预览真正的解析放后端前端拿解析后的纯文本就行。这样职责清晰也不容易出兼容性问题。4. 第三阶段做出能拿得出手的项目第 7-9 周4.1 项目选型别做烂大街的聊天框到了这个阶段你得有一个完整的项目撑简历。我强烈建议不要再做那种“输入问题返回答案”的通用聊天框面试官看吐了。选一个有明确场景、有差异化功能的方向。几个我比较看好的方向一是带工具调用的 Agent 界面用户提问后前端要展示 AI 调用了哪些工具、每个工具的输入输出是什么、最终答案怎么来的这种可视化能力很加分二是文档问答系统用户上传文档前端做分块展示、引用溯源、高亮定位考验的是信息组织和交互设计三是多模型对比界面同一个问题发给多个模型并排流式输出考验并发控制和布局能力。选哪个取决于你的目标岗位。投 AI 产品公司选 Agent 界面投企业服务方向选文档问答投偏研究的团队选多模型对比。别贪多三个月能把一个做深做透就很好了。4.2 工程化让项目看起来像“正经项目”很多人的项目跑起来没问题但代码一团糟面试官一看仓库就 pass 了。工程化这块至少要做到TypeScript 严格模式打开、ESLint Prettier 配置好、组件按功能分目录、API 请求统一封装、环境变量区分开发和生产。构建工具用 Vite别用 Webpack 折腾自己。Vite 的冷启动和热更新速度对开发体验的提升是实打实的。部署可以用 Vercel 或者 Netlify推代码自动构建省心。如果涉及后端用 Serverless 函数就够了没必要自己搭服务器。测试这块不用追求覆盖率但核心的流式解析逻辑、状态管理逻辑要有单元测试。用 Vitest写起来快。我见过太多人项目里一个测试都没有面试官问“你怎么保证流式解析不出错”只能干瞪眼。4.3 性能优化AI 应用特有的那些点AI 应用的性能瓶颈和普通应用不一样。普通应用优化的是首屏加载和交互响应AI 应用还要考虑长列表渲染和高频更新。对话历史长了之后几百条消息全渲染出来会卡。解决方案是虚拟滚动只渲染可视区域内的消息。react-window或者vue-virtual-scroller都是成熟方案接入成本不高。但要注意流式输出中的那条消息高度是变化的虚拟滚动库要能处理动态高度这个得挑支持dynamic size的。另一个点是内存管理。流式请求的reader用完要释放AbortController要及时清理事件监听要记得解绑。这些在单次对话里看不出问题但用户开着页面聊一下午内存泄漏就显现出来了。养成好习惯useEffect的清理函数里把该断的都断掉。5. 第四阶段冲刺与查漏补缺第 10-12 周5.1 模拟面试那些高频被问到的点最后三周除了完善项目要开始针对性地准备面试。AI 应用前端这个方向高频问题集中在几个方面流式渲染的实现原理、多轮对话的状态设计、大模型接口的错误处理、提示词的前端管理、以及性能优化。我整理了一个自查清单你可以对着过一遍考察点能说清楚吗项目里有体现吗SSE 和 fetch stream 的区别与选型流式 chunk 的边界处理消息树 vs 消息数组的取舍AbortController 的中断时机高频 setState 的优化手段上下文超限的裁剪策略API Key 的安全存放多模态输入的压缩与校验每一项都要能结合自己的项目讲出具体做法和踩过的坑光背概念没用。5.2 简历与作品集怎么把三个月说清楚简历上别写“学习了 AI 应用前端开发”要写“独立完成了一个带工具调用可视化的 Agent 对话应用实现了流式渲染、多轮对话分支管理、并发请求控制”。用动词用具体功能用数字。作品集方面GitHub 仓库的 README 要写好放截图、放架构图、放核心代码片段、放你遇到的问题和解决方案。面试官没时间跑你的代码README 就是你的门面。如果项目部署上线了把链接放最显眼的位置能点开直接用的项目比什么都强。提示如果你在学 AI 应用前端的过程中顺手把一些通用能力比如流式解析、消息树管理抽成了独立的 npm 包发出去哪怕没什么下载量面试时也是一个很好的话题说明你有抽象和复用的意识。5.3 持续学习三个月之后往哪走三个月能让你入门但离“资深”还差得远。后续可以往几个方向深入一是AI Agent 的交互范式现在这块还在快速演进工具调用、多步推理、人机协作的界面设计有很多可探索的空间二是端侧 AI随着浏览器能力增强一些轻量模型可以直接跑在前端这块的工程实践还比较空白三是AI 应用的可观测性怎么监控流式请求的成功率、延迟、token 消耗怎么在前端做埋点和告警这是企业级应用的刚需。我个人的体会是AI 应用前端这个方向技术更新快但底层的东西——异步、状态、渲染、性能——是不变的。把底层打牢上面换什么框架、接什么模型都是几天就能上手的事。反过来如果只追新概念不练基本功风一吹就倒了。最后分享一个我踩过的坑刚开始做流式渲染的时候我图省事直接在onmessage里setState本地测试没问题一上真机、网络稍微慢一点页面就卡成幻灯片。后来改成缓冲区 requestAnimationFrame批量更新才彻底解决。这个教训让我明白AI 应用前端的很多问题本质还是前端的老问题只是被 AI 的实时性放大了。把每一次卡顿都当成线索去挖比看十篇教程都有用。