AI应用前端三个月学习路线：从流式输出到RAG实战

最近半年，我身边问得最多的问题就是：AI时代前端还有没有活路？要不要转行去做大模型算法？我的答案一直很明确——前端不会消失，但在明显地分化，其中增长最快、最缺人的一个分支，就是“AI应用前端工程师”。这个岗位不是传统意义的“会调接口、会发请求”的前端，而是要直接面对大模型、Agent、RAG这类能力，把它们变成普通人能顺畅使用的产品界面。

这篇三个月学习计划，是我根据带新人、陪跑转岗的实操经验整理的。目标是让有一定前端基础（哪怕只是会React或Vue的基本用法）的开发者，按这个节奏在90天里具备投递AI应用前端岗位的底气。全文按月份拆解，每月都有明确的里程碑、技术选型和避坑点，你可以直接照抄节奏，也可以根据自己每天能投入的时间调整。

1. AI应用前端到底在做什么

1.1 岗位定义：不是“会调接口”的前端

传统前端做的事情，本质上是把后端算好的数据展示出来：用户列表、订单详情、图表统计。数据是确定的，渲染是静态的，交互是有限的。

AI应用前端完全不一样。它面对的不是“算好的结果”，而是“正在生成的Token流”。一个ChatGPT式的聊天窗口、一个对话式知识库、一个会自己调用工具的多Agent系统，它们的界面都有三个共同特点：内容边生成边渲染、状态随推理过程不断变化、用户随时可以中断、追问、纠偏。

所以AI应用前端的核心能力，不是“用Vue还是React”这种框架问题，而是能不能把一次模型推理过程设计成一个让人不焦虑、有掌控感的产品体验。比如模型在思考时你要展示什么，工具调用失败时你要怎么提示，上下文太长了你要怎么提醒用户，这些都是实打实的前端工程问题。

1.2 能力模型变化对比

我用一张表说明传统前端和AI应用前端的差别，这也是很多人转岗时最容易低估的部分：

也就是说，传统前端的旧功夫完全不是白学，它们是地基；但AI应用前端需要在地基上面再加一层新的工程能力，这层能力很少出现在过去的面试题里。

1.3 为什么现在值得学

现在这个时间点去学AI应用前端，有几个明显的现实原因。第一，大模型能力已经通过API开放出来，前端工程师不需要懂怎么训练模型，只需要懂怎么接模型、怎么把模型的能力通过界面放大。第二，AI产品的竞争已经来到体验层，同一个模型API，不同前端做出来的产品，用户感知差距极大，谁的流式渲染更顺、状态反馈更清楚、容错更好，谁就有机会胜出。第三，招聘市场的风向也变了，很多团队在招前端时明确要求“对AI产品有实战经验”“用过Vercel AI SDK或LangChain.js”，这类岗位的简历池远比普通前端岗位小。

2. 三个月路线总览与关键选型

2.1 整体节奏与里程碑

三个月听起来不长，但只要把任务拆成里程碑，其实是足够出一个完整作品的。我建议的节奏是：第一个月专攻“模型交互基础”，第二个月专攻“AI应用前端核心工程能力”，第三个月专攻“项目实战+面试准备”。

每周能投入15小时左右就够，如果只能投入10小时，把第一周和第二周的任务拉长一点也行，但不要跳过。

2.2 为什么我压注React + TypeScript + Vercel AI SDK

技术选型我不打算给太多选项，直接说说我推荐的理由。React和TypeScript是目前AI应用前端生态里支持最成熟的组合，几乎所有AI工具链的官方示例都以React为首选。Vercel AI SDK是做AI应用前端最值得学的库，它把消息管理、流式解析、工具调用、中断恢复全部封装成了useChat这类Hook，能让一个新手在很短时间做出一个手感可靠的聊天界面。

有人问Vue行不行，当然行，Nuxt也已经有对应方案，但你在查资料、看示例、抄作业的时候会发现React生态明显更多。我的建议是这三个月不要纠结框架，选React，把精力省下来去理解模型与UI交互的本质。

2.3 国内可用的模型与部署组合

原理想通了，落地还是要选一个能稳定调用的模型API。国内可用的大模型API，比如DeepSeek、通义千问、智谱GLM、Kimi，都提供了兼容OpenAI格式的流式接口，这意味着你用OpenAI的SDK或Vercel AI SDK时，只需要改baseURL和模型名称，代码几乎不用动。我会建议你第一周就用DeepSeek这类价格低、响应快的模型来练手，跑通之后再切换成其他模型验证兼容性。

部署端我推荐两条路：如果你只是做Demo和面试展示，直接部署到Vercel或Cloudflare Pages都行，它们对流式响应支持比较友好；如果你要部署到自己的服务器，记得在Nginx里关掉对SSE响应的缓冲，很多本地调试没问题、上服务器就卡住的现象都是这个原因，后面我会专门讲。

3. 第一个月：先摸透模型的“脾气”

3.1 Token、上下文窗口、Temperature，这三个词必须滚瓜烂熟

做AI应用前端不需要会训练模型，但必须清楚模型的输入输出边界。Token你可以理解成模型处理文本的最小原子单位，英文一般一个单词是一个或多个Token，中文通常一个字可能就对应一个到两个Token。它决定了你的请求成本和速度。

上下文窗口就是你一次请求里能塞进去的全部内容之和，包括系统提示词、历史消息、用户当前输入和你附加给模型的文档片段。一旦超出窗口，模型要么报错，要么会“忘记”前面的内容。Temperature则控制模型回答的随机程度，越高越发散，越低越稳定。做问答客服类产品时通常调低，做文案创意类产品时可以调高。

前端工程师最容易踩的坑，是在界面上让用户无限制地聊很久，却不清理历史消息，最后Token溢出，用户看到报错还不知道怎么回事。你作为前端，必须在上层做好“记忆管理”。

3.2 流式输出：AI应用前端的命根子

很多新手第一次调模型接口，会用await fetch(url)然后response.json()，一下就拿到完整回答。这样功能上没错，但产品体验是灾难——用户要干等好几秒甚至十几秒，没有任何中间反馈。真正合格的AI应用前端，必须用流式接收。

实现流式接收的核心不是WebSocket，而是SSE（Server-Sent Events），一种服务器单向推送的HTTP协议。模型的每个Token生成后，服务端就会通过text/event-stream格式推送过来。前端用fetch拿到响应体之后，不能直接解析JSON，要用response.body.getReader()逐块读取字节流，再用TextDecoder不断解码。

我贴一段最核心的解析代码，这段逻辑值得你手打三遍：

const controller = new AbortController(); const res = await fetch('/api/chat', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages }), signal: controller.signal }); const reader = res.body.getReader(); const decoder = new TextDecoder(); let content = ''; while (true) { const { done, value } = await reader.read(); if (done) break; content += decoder.decode(value, { stream: true }); // 这里按SSE格式按行解析，处理以 data: 开头的内容 // 每次拿到新的增量后，更新到当前正在渲染的消息里 updateCurrentMessage(content); }

注意，必须把decoder.decode的第二个参数{ stream: true }写上，否则中文字符如果恰好被拆在两个二进制块里，就会解出乱码。这个坑我踩过很久才反应过来。

3.3 第一个里程碑：300行内做出一个能用的AI聊天页

第一个里程碑不要贪多，做一个最基础的聊天页面就好：输入框、消息列表、流式打字机效果、Markdown渲染、中断生成按钮。

Markdown渲染直接用react-markdown加remark-gfm即可，别自己写正则去处理标题和代码块，会非常痛苦。中断生成按钮本质上就是触发AbortController.abort()，同时要在UI里把加载态切掉。如果你能把“停止生成”这个交互做得顺滑，这个月就算过关了。

很多教程会在这里跳过对“为什么用户需要中断功能”的讲解，我想多说一句：语言模型非常擅长一本正经地“跑偏”，用户一旦发现它理解错了意图，第一反应就是停止生成，而不是等它把错的内容全说完。你的界面必须给用户这个逃生舱。

3.4 第一月避坑清单

这个月最容易踩的坑，我按踩到的频率排个序：

• 不用response.json()拿完整数据，一定要流式读取。
• TextDecoder忘记传{ stream: true }导致中文乱码。
• 把整个历史消息无限期往请求里塞，Token白白烧掉。
• 没有做“模型正在生成中”的状态锁，用户连续点击发送导致并发请求互相覆盖。
• 直接把模型输出用dangerouslySetInnerHTML渲染——这会引爆XSS漏洞，正确做法永远是先用react-markdown转成安全React节点再做渲染。

第5点必须记住，因为模型输出里很可能出现一段攻击性脚本，它会利用你前端的信任边界。安全底线不能妥协。

4. 第二个月：从“会聊天”到“能干活”

4.1 为什么我建议直接学Vercel AI SDK，而不是裸写fetch

第一个月让你手写fetch，是为了理解底层原理，知道流式到底是怎么工作的。到了第二个月，就该站上巨人的肩膀用Vercel AI SDK了。

这个库解决了我前几年做AI聊天时最头疼的一堆问题：消息数组的自动维护、流式增量更新的状态管理、请求中断和错误重试的封装、工具调用参数的解析与执行。你不需要再手动维护那个while(true)的读取循环，只需要这样写：

import { useChat } from 'ai/react'; export default function Chat() { const { messages, input, handleInputChange, handleSubmit, isLoading, stop } = useChat({ api: '/api/chat', }); return ( <div> {messages.map(m => ( <div key={m.id}> <strong>{m.role}:</strong> <span>{m.content}</span> </div> ))} <form onSubmit={handleSubmit}> <input value={input} onChange={handleInputChange} /> <button type="submit">发送</button> {isLoading && <button onClick={stop}>停止</button>} </form> </div> ); }

不要觉得这样偷懒就学不到东西。真正的进阶在于理解这个Hook背后的Promise链式更新与React并发渲染策略，而这些理解会直接影响你未来能不能处理复杂AI项目。

4.2 Function Calling，才是AI应用前端真正的分水岭

只会做聊天框，那是第一个月的水平。第二个月的核心必须放在工具调用上，也就是Function Calling。什么叫工具调用？简单说，模型在回答你的问题时，可以决定“我需要先查一下数据库”“我需要先搜一下知识库”“我需要先算一下这个数学题”，然后它会把参数发给你定义的函数，你执行完之后把结果回传给它，它再基于结果组织最终回答。

这个时候前端的职责就不再只是渲染文字了，而是要把模型“使用工具”的过程可视化：它正在调用什么工具、传了什么参数、工具返回了什么、出错了它是否要换一种方式重试。我给你一个最小示例：

const { messages } = useChat({ api: '/api/chat', async onToolCall({ toolCall }) { if (toolCall.toolName === 'searchKnowledge') { return await searchKnowledge(toolCall.args.query); } if (toolCall.toolName === 'getWeather') { return await getWeather(toolCall.args.city); } } });

前端渲染时，不要只显示纯文本，最好把每一步都渲染成一张卡片。比如“正在调用 天气查询 工具，参数：北京”，执行完显示“查询结果：晴，25℃”。用户看到这样的UI，会觉得这个AI非常“聪明”，而不是觉得它卡住了。

这里有一个产品层面的经验：工具调用一定不能像黑盒一样执行，你必须给用户看到中间过程。否则用户只会看到AI在那里转圈圈，然后突然蹦出一个回答，这种信任感是建立不起来的。

4.3 多轮对话与上下文管理

第二个月的另一个重点是“上下文管理”。你做一个客服机器人，不可能用户每问一句，就把三个月前的聊天记录全部塞给模型，既烧钱又容易超出上下文窗口。

前端侧要做的，是设计一套“记忆裁剪”策略。我的常用做法是：永远保留系统提示词和最近N轮对话，如果早期某条消息关联着重要信息（比如用户说“我买的订单号是ABC123”），就把它抽出来放进一个长期记忆字段，每次请求都带上。还有一种思路是根据Token数来裁减，超过一个阈值就把最早的消息折叠成摘要。语言模型本身可以帮你做摘要，你只需要在界面里展示“系统已自动压缩早期对话”，给用户一个透明的提示。

这类需求听起来是后端的活，但在AI应用前端这个岗位里，前后端的边界非常模糊。很多团队的前端工程师需要直接对接模型调用层，所以你最好主动把消息组装逻辑、Token计数、裁剪规则这些都写在懂。

4.4 RAG文档型产品的展示层怎么做

RAG检索增强生成，是现在知识库类产品最主流的架构。前端要做的，不只是把文档上传到后端，还要把“引用来源”这个信息结构设计好。

一个完整的RAG前端界面通常包含：文档上传入口、对话窗口、引用来源列表。当用户提问后，模型回答的每句话如果有引用，要能在文本里标出[1][2]这样的锚点，侧边栏对应展示“这些说法来自哪份文档、原文哪一段”。这个体验一旦做出来，产品专业度会立刻提升一个档次。如果涉及上传大文档，别忘了用Worker做前端分片上传，避免主线程卡死。

展示引用是纯粹的UI工程能力，也是面试官最容易从中看出“你到底做没做过AI应用”的细节。很多人只会聊天框，一问到“如果模型引用了一段不存在的文档你怎么处理”就答不上来，其实就是这个维度没做过。

5. 第三个月：做一个能说服面试官的项目

5.1 三个选题，对应三个热门方向

到了第三个月，不要再做TodoList套壳AI了。我推荐三个选题，都是面试官听得懂、也愿意聊的项目方向：

第一个是“企业知识库问答机器人”。它覆盖了RAG、文档上传、引用展示、会话管理，技术点非常全面，最接近真实生产需求。

第二个是“AI写作助手”。重点处理Markdown渲染、内容流式输出、文章续写、语气调整这些偏体验层的功能，适合展示你对前端细节的打磨能力。

第三个是“多Agent协作应用”。比如你做一个“需求拆解Agent + 代码生成Agent + 测试Agent”，让几个Agent扮演不同角色协同处理一个任务。这个方向恰好是热搜里“AI Agent”相关关键词对应的大热门。做这个项目时，你要在前端展示每个Agent的独立消息线程、任务分配关系、最终融合结果，你的差异化优势就体现出来了。

选一个，认真做，不要三个都开，贪多必死。

5.2 工程化补齐：部署、限流、鉴权、错误恢复

面试官一定会问你“这个项目能不能上线跑”，所以第三个月前两周要完成工程化补齐。

部署上，用Vercel或Cloudflare的Edge Runtime部署一个流式接口是很顺的，成本低、响应快。但如果你用自建服务器，记得把反向代理缓冲关掉，否则SSE会一段一段地卡住输出。鉴权和限流也很重要，很多人的项目在本地能跑，上公网被人刷一下就垮了，你至少要加一个简单的用户级速率限制和Token用量统计。还有错误恢复：模型调用偶尔会超时或返回502，前端要设计好“重试”“退避”“提示用户稍后再试”的完整链路，这些在面试里是被高频追问的细节。

5.3 直接对着2026年面试风向刷题

这个月也到了刷题时间。我整理了五个这两年面试中被点名概率极高的AI应用前端题，每道题都附上回答思路：

1. 模型流式输出时，用户突然断网或组件卸载，你怎么处理？
   答：通过AbortController取消请求，监听visibilitychange恢复连接，用lastEventID做断点续传。

2. SSE和WebSocket分别适合什么场景？
   答：SSE更轻、自动重连、适合模型单向下发；WebSocket适合多Agent协作、白板协同这类需要双向持续通信的场景。

3. 模型偶尔返回不合法JSON，前端怎么兜底？
   答：不用裸的JSON.parse，先做正则提取或找Markdown代码块边界，再用结构化schema校验，最后用一个小算法做括号配对修补。

4. 一个无限增长的消息列表，怎么保证滚动性能？
   答：虚拟列表 + 固定区间估算高度 + 新消息自动滚动策略 + 图片引用懒加载。

5. 工具调用过程中，用户感觉AI“卡住”了，你怎么优化感受？
   答：给工具调用设五个状态——等待、调用中、展示工具名、展示参数摘要、返回结果，任何一步超过阈值就提示可取消。

这些题没有标准答案，但回答里如果能带上你真实踩过的坑，哪怕语言组织笨拙一点，面试官反而更信任你。

5.4 用AI编程工具加速学习，但不被反噬

现在每个人都在用AI编程工具，你完全可以借助它们生成脚手架、补齐CSS样式、翻译复杂类型定义。但有一个原则：第一遍学新知识点时，核心逻辑必须手写，尤其是流式解析、状态管理、工具调用渲染这三块。

我见过太多人让AI把Vercel AI SDK示例抄过来，跑通了，但问一句“如果message流里有多个增量update，React为什么没有重复渲染”就卡住。这种“假会”在面试里三句话就会被戳穿。正确用法是：让AI生成项目骨架，你亲手重写数据流与渲染层，最后再回到代码里对比AI的写法和自己的写法，想清楚差异的原因。

6. 这些坑我踩过，希望你别再踩

6.1 流式与并发：上服务器就卡住、组件卸载后疯狂报错

先讲一个最典型的“本地没问题，线上就卡住”的案例。本地调试时，SSE流输出很流畅，部署到Nginx服务器后，要等模型把所有内容生成完，界面才一次性蹦出来。原因是Nginx默认对上游响应做了缓冲，SSE的每个数据块被攒着不往下发。解决办法是在Nginx配置里加一句proxy_buffering off;，或者用X-Accel-Buffering: no这个响应头。Vercel这类平台没这个问题，但自建服务器的人早晚会遇到。

还有一个高频报错是“组件卸载后状态更新”。当用户快速切换页面或点击停止后，旧请求的回调还在执行，它会试图setState到一个已经卸载的组件，React会报警告甚至内存泄漏。记住要在useEffect的清理函数里执行controller.abort()，并且用一个布尔标志位跳过卸载后的状态更新。

6.2 渲染与安全：模型输出的Markdown里藏了攻击脚本

做AI聊天界面的新手，最容易图省事用dangerouslySetInnerHTML把模型返回的内容当HTML直接渲染。这在以前渲染后端返回的富文本时可能还凑合，但渲染模型输出是绝对禁区，因为模型输出可能包含<img onerror="...">、<iframe>这类恶意标签，一旦被解析执行，用户的Cookie、本地存储、登录态都可能被偷走。正确做法永远是经过react-markdown这类库做安全转换，并且把自定义HTML标签的allowDangerousHtml关掉。

还有一类渲染性能问题：边流式接收边setState时，如果每次小块数据都触发整棵树的重渲染，页面会明显卡顿。我的经验是把流式增量合并到一个小的时间片里更新，比如每50毫秒批量刷新一次，既保证打字机效果，又不会让React频繁协调大组件树。

6.3 产品与成本：上下文无限膨胀，费用悄悄失控

这一点不算技术坑，但比技术坑更要命。如果产品允许用户无限聊下去，历史消息就会无限膨胀，每次请求都在烧Token。前端要做的不仅是裁剪消息，还要把“当前上下文占用比例”用UI展示给用户，比如“本次会话已使用上下文窗口的60%”，并提供一键清空会话的入口。相信我，用户看得懂这个提示，也会感谢你给了他控制的权力。

另外在工具调用场景，如果模型陷入死循环，不停调用同一个工具且每次都失败，前端必须设置最大重试次数。否则你的后端日志会异常好看，账单也会异常吓人。

6.4 最后几句真心话

三个月计划写到这，我发现真正决定一个人能不能转成功的，往往不是技术，而是节奏感。第一个月大家都很兴奋，天天看文档到深夜；第二个月开始迷茫，感觉做了聊天框之后不知道自己还能做什么；第三个月有人在项目里越挖越深，有人开始刷各种面试题然后焦虑发呆。你在第二个月低迷时，一定要记住：只要把第一个月做的聊天Demo，往RAG和Function Calling这两个方向各推进一步，你的项目就会立刻拉开和普通“AI套皮应用”的差距。

带过的人里，按这个路线坚持下来、每周都产出点东西的，基本都拿到了目标岗位的面试机会。中途断掉的，几乎都是想“等我准备得再充分一点再动手”的人。这个领域没有准备充分的那一天，只有你今天写的那个fetch请求、那条流式渲染管线、那个工具调用卡片——它们才是三个月后你手里真正能用来谈判的作品集。你从今天开始动手，就已经赢了那些还在收藏夹里吃灰的人。