最近总有人问我前端都这么卷了还要不要冲AI应用方向我的回答是与其焦虑不如用三个月时间给自己一次系统升级。这套计划不是让你去卷大模型底层算法而是把AI能力接到网页端成为真正能交付AI应用的前端工程师。现在前端行业最明显的变化是招聘需求从“会写页面”变成了“会接AI”。无论是给内部工具加一个AI问答面板还是做一个像Manus那样的AI Agent网页端又或是给传统业务系统嵌入大模型能力本质上都在等一批能把大模型API、实时流、多轮对话做好的前端开发。这个计划就是围绕这些真实需求设计的适合有半年以上前端经验、想在AI应用方向建立竞争力的同学也适合刚入门但愿意挑战自己的新人。1. 三个月计划的整体设计不是堆技术栈而是做项目闭环1.1 为什么要锁定期限为三个月三个月不是拍脑袋定的数字我见过太多人学AI前端最后被Prompt、Agent、Function Calling这些名词劝退。其实真正要掌握的没有想象中那么玄70%的工作还是你熟悉的UI、状态、异步、性能另外30%才是大模型接入和AI交互设计。三个月刚好够把这30%学透再用项目磨到能写进简历的程度。如果把战线拉到半年反而容易陷入“这也要学那也要学”的焦虑最后啥都浅尝辄止。从投入产出比看三个月也很合理。按每周投入15到20小时计算三个月大约是180到240小时这个体量足够你完成所有核心知识点的刻意练习也足够做出两到三个有说服力的项目。而且AI应用前端这个方向更新太快学习计划必须短平快快速跑通一个完整闭环之后再迭代比一开始就想搞一个万能方案靠谱得多。1.2 学习路线的三个阶段拆解我把整个计划拆成三个阶段每四周一个节点每个阶段都有明确产出。第一个月叫“思维升级”核心是掌握AI会话类应用的前端形态会写流式交互、会封装会话组件第二个月叫“能力集成”核心是把大模型API、Agent机制、多AI协作接进前端做出真正能解决问题的功能第三个月叫“实战交付”核心是完成几个拿得出手的项目同时把面试常考的点系统梳理一遍。阶段周期核心任务产出物第一阶段第1-4周理解AI应用前端形态掌握SSE/WebSocket流式交互封装AI会话UI组件一个可运行的多轮对话前端支持Markdown渲染和停止生成第二阶段第5-8周对接大模型API实现Function Calling和Agent事件流处理性能与异常一个AI Agent工作台能调用工具并展示运行过程第三阶段第9-12周完成两到三个项目整理AI前端面试题和排查手册两个完整项目Demo一份面试复习清单别把阶段理解成技术的简单罗列它们之间是咬合关系。第一阶段打交互基础第二阶段做能力接入第三阶段把这些能力沉淀成作品。很多人一上来就冲Agent和Function Calling结果连SSE的数据流都没搞清楚写出来的界面既不丝滑也不可靠这才是最要命的。1.3 工具链选择的底层逻辑工具链不需要多但每个都要能扛住实战。前端框架我建议优先React TypeScript原因很简单AI应用相关的开源项目、UI组件、示例代码大多是React生态的遇到问题能参考的资料最多。构建工具选Vite开发体验比Webpack好太多HMR快到不用等。样式方案用Tailwind CSSAI应用界面里临时性的状态样式特别多用Tailwind写起来比写一堆CSS类名快得多而且深色模式切换非常方便。UI组件可以从 shadcn/ui 或者 Ant Design 5.0 里选我更倾向前者它不锁定组件结构方便你按AI应用场景二次封装。状态管理不需要太重Zustand或Jotai足够如果你愿意也可以直接用React Query管理服务端状态把AI请求和流式状态交给它缓存和重试。后端不是你两个月能学完的但你至少要会通过Node.js或现有网关转发大模型请求一定不要把API Key直接放在前端代码里这是安全和合规的底线。2. 第一个月从传统前端到AI应用前端的思维升级2.1 理解AI应用的前端形态不再是表单列表传统后台业务页面的核心是表单、表格、详情、增删改查用户把数据填进去提交看到结果。AI应用前端完全不是这个逻辑它的核心变成了“对话”——用户用自然语言发起请求模型返回文本、图片或者工具调用结果前端要实时展示生成过程允许用户中断、重试、继续追问。这意味着你必须把“等待结果”这种交互变成一个动态的流程。举个我做过的小程序企业知识库问答页面用户提出一个问题后模型不是一次性返回答案而是先显示“正在读取文档”再一段一段输出回答同时旁边有一个token计数器跳动。用户如果发现回答方向不对可以点“停止生成”按钮立刻打断流式请求再补充限定条件重新提问。这种体验和传统请求别人后端接口完全不一样你不能再用一个loading转圈打发了前端需要处理流式的数据分片、分段渲染、可取消的操作以及长时间连接下的异常恢复。2.2 技术栈选型与项目初始化第一个月第一天不要急着写业务代码先把项目骨架搭好。我用Vite初始化一个React TypeScript项目然后接入Tailwind CSS这套组合已经成为AI前端项目的默认起点。你可以通过下面命令快速开始npm create vitelatest ai-frontend -- --template react-ts cd ai-frontend npm install npm install tailwindcss tailwindcss/vite按Tailwind CSS v4的用法在vite.config.ts里加上tailwindcss/vite插件然后新建一个index.css里面写import tailwindcss;就完成了。接下来建议直接安装ai这个开源SDK以及ai-sdk/react它能帮我们管理流式请求、消息状态还有错误重试省去大量手写hooks的重复工作。如果你不想引入SDK也可以自己写一个useChatStream的hook核心就是封装fetch和ReadableStream。我在做这个阶段时遇到过一个问题直接使用npm create vite默认模板后React 19的并发渲染对字符串流式解析会有一些额外的渲染开销。所以建议在所有需要频繁更新的消息组件上尽量用不可变的数据结构避免大数组的重复渲染。这个习惯越早养成后面做Agent工作台时越轻松。2.3 流式输出与实时交互SSE和WebSocket的正确打开方式AI应用前端最核心的技术点就是流式渲染。大语言模型生成token需要时间如果等全部生成完再显示用户会以为页面卡死了。业界普遍用SSEServer-Sent Events来推送生成内容它本质上是一条HTTP长连接服务端可以持续往客户端发送文本片段。前端用fetch拿到ReadableStream再逐段解析就能实现一个字一个字蹦出来的打字机效果。const res await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages }) }); const reader res.body!.getReader(); const decoder new TextDecoder(utf-8); while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value, { stream: true }); // 这个 chunk 里可能包含多个 SSE 事件需要按行拆分 const lines chunk.split(\n); for (const line of lines) { if (line.startsWith(data: )) { const payload JSON.parse(line.slice(6)); if (payload.done) return; appendMessage(payload.choices?.[0]?.delta?.content ?? ); } } }这段代码是我第一版流式渲染的核心看起来简单踩坑不少。首先是中文乱码如果你直接对每个chunk调用TextDecoder就会出现中文字符被截成两半导致乱码。解决方法是必须使用{ stream: true }参数让解码器跨chunk缓存残余字节。其次是事件边界问题服务端发来的一个chunk可能包含多行data:也可能一行没有结束所以不能假设每次reader.read()都拿到一条完整事件要先按换行符切分再逐行处理。那WebSocket什么时候用SSE适合服务端单向推送但如果你要做一个AI Agent或者多AI协作系统就可能需要前端向后端发送事件、后端主动推送中间状态。WebSocket是双向的适合指令和事件来回交换的复杂场景。比如你在做一个后台实时数据看板Python Django后端收集到新的任务进度通过channels推送到前端前端不需要轮询连接建立后会持续收到事件。AI应用里推荐做法是模型生成的文本流用SSEAgent的状态流转用WebSocket两者各司其职。2.4 组件库的二次封装让AI会话界面开发提速第一个月后半段我开始封装AI会话界面里的通用组件。聊天界面看起来简单但真要写好涉及消息列表、气泡、Markdown渲染、代码高亮、引用内容、附件缩略图等一堆东西。如果每个页面都从零写效率太低。我建议先从简单的ChatMessage组件开始它的props应该能表达一条消息最基础的属性interface ChatMessage { id: string; role: user | assistant | system | tool; content: string; status?: streaming | completed | error | interrupted; toolCalls?: Array{ name: string; args: Recordstring, unknown; status: string }; }有了这个类型基础渲染层就可以根据status控制打字机动画、错误提示、停止按钮根据content决定是用普通文本还是Markdown渲染。如果是Markdown一定不要直接把dangerouslySetInnerHTML塞给用户内容用react-markdown配合remark-gfm再为代码块单独封装高亮组件。这样既安全又能出效果。组件封装的核心思路是“数据驱动UI”你的界面不应该关心某次回答是哪个模型生成的只需要关心消息对象的字段和状态。3. 第二个月AI能力集成与工程化实践3.1 对接大模型API从Prompt工程到Function Calling到了第二个月你要开始真正接大模型了。不管用的是DeepSeek、阿里通义还是OpenAI兼容接口前端侧的流程基本一致把用户消息数组发给后端后端带着密钥去请求大模型然后把流式响应转发给前端。你要重点掌握的是messages数组的结构它不只是简单的user/assistant还包括system系统提示词和不同角色的历史消息。前端要做的是在本地维护一个消息列表每次发送请求前把完整上下文一起提交。比普通对话更进一步的是Function Calling这是让AI应用从“聊天机器人”进化成“智能体”的关键。举个例子你的页面里有一个“查询订单物流”按钮用户问“我的订单到哪了”模型并不直接知道物流数据它可以返回一个工具调用请求前端解析到tool_calls字段后就去调后端物流查询接口拿到结果再以tool角色的消息发回给模型模型把最终答案整理给用户。这个机制的难点在于前端要处理好工具调用的生命周期发起中、执行中、成功、失败每一步都要有相应UI反馈不能让用户干瞪眼。配置Function Calling时要特别注意大模型返回的JSON可能不标准。我在项目里遇到过一次模型返回的arguments字段是一个JSON字符串但里面混了换行和转义符直接用JSON.parse会报错。后来我做了两层兜底先用正则提取最外层花括号再包裹一层try/catch解析失败就把原始字符串返回给用户并提示“工具调用失败请重试”。这类防御性代码AI前端工程师一定要多写。3.2 AI Agent前端集成状态机、多轮会话与工具调用AI Agent和普通聊天前端的区别在于它不再是一轮问答就结束而是像一个“干活的人”一样拆解任务、调用工具、检查结果。前端虽然不负责Agent的决策逻辑但要负责把Agent运行的过程可视化。推荐用事件流协议来解决后端把Agent执行过程中的关键节点推送到前端前端根据事件类型渲染不同的界面。比如一个“自动做一个行业信息简报”的Agent你会在页面上看到这些事件事件类型前端展示说明agent_start显示“开始分析任务”Agent开始干活tool_call显示工具名称、参数预览模型决定调用搜索或查询工具tool_result显示工具返回的数据摘要前端把结果反馈给用户agent_message实时输出模型回答用于阶段性总结agent_complete展示最终产出物提供下载按钮任务完成这个状态下前端最忌讳的是把所有事件塞进一条消息气泡里。我在做Agent工作台时单独设计了一个“运行轨迹”面板放在聊天记录的右侧所有状态事件按顺序排列用图标区分工具调用和消息输出。这样做的好处是用户可以感知到Agent“在思考”而不是怀疑页面卡死。为了让后端事件格式统一我还定义了一个前端可解析的AgentEvent联合类型事件字段里必须有id和createdAt方便前端做时间线渲染和增量更新。3.3 多AI协作场景下的前端架构设计多AI协作是最近很热的话题前端也不是没有难点。比如你同时让多个AI模型完成同一个任务每个模型的输出速度不一样前端的消息列表就会交错更新。如果不做统一协议页面很快就会乱成两套气泡、两种滚动逻辑。我当时采用的方案是“统一消息协议 独立渲染通道”。消息协议里固定加上agentId和modelName字段每个AI参与者都是独立的消费者前端根据agentId把消息路由到对应的会话面板或者分组。视觉上的设计也要注意。用户同时看多个AI回答时要能很容易分辨谁是谁。我给每个参与者的气泡背景色、头像、名字做了配置化还做了一键折叠任意一个AI输出的功能。这个体验很像看实时弹幕信息密度大但用户可以按需选择。如果你做的是多个模型同屏对比还要考虑横向布局的响应式问题——移动端上两个模型答案的对比高度可能完全不一致这需要前端灵活调整卡片高度而不是强行等高。3.4 性能优化与异常兜底流式中断、超时、上下文管理AI应用前端最怕的事就是流式请求挂到一半页面既不报错也不结束。第一个要做的就是可取消。使用AbortController当用户点击“停止生成”时调用abort()同时把消息状态标记为interrupted这样用户能明确知道这条消息是被主动打断的。第二个是超时兜底有些模型服务响应会特别慢你不能让用户无限等待。我用过两种策略整体超时用setTimeoutAbortController超过60秒没有收到任何分片就自动断开重试空闲超时用定时器检查每个chunk的间隔如果超过15秒没有新数据就提示“模型思考时间过长”。上下文管理同样重要。很多前端直接把用户所有聊天记录发给后端结果上下文越来越长最后超出了模型窗口。我写了一个简单的token估算函数Math.ceil(content.length / 4)如果当前上下文估算值超过模型窗口的70%就触发提醒或者把最早的消息摘要成一段系统提示优雅压缩上下文。再有就是重试机制流式请求可能因为网络抖动而失败前端应该提供“重新生成”按钮重试时带上之前的信息摘要而不是把失败上下文原样扔过去。4. 第三个月实战项目与面试准备4.1 自己选题做2-3个拿得出手的项目第三个月的核心任务是把前面学的东西变成作品。我不建议跟着视频或文档抄一遍而是做三个方向不同的项目形成组合拳。第一个是AI聊天助手包含流式渲染、Markdown渲染、停止生成、会话历史持久化这个项目用来展示你的交互基本功。第二个是AI Agent工作台包含Function Calling、工具调用过程可视化、任务运行轨迹用来展示你对Agent架构的理解。第三个可以做企业知识库问答前端体验RAG检索结果和AI回答的融合展示同时处理引用来源、文档分片的跳转。每个项目都要达到可以现场演示的程度。简历上写“熟练使用AI SDK”没用面试官更愿意看到你打开一个页面输入一个问题然后笑着看他看着token一点点蹦出来。项目代码要放到GitHubREADME里写清楚功能清单和技术架构最好配一个GIF演示。我当时还在项目里加了一个“暗黑模式”切换后来面试时经常作为交互细节被问到这是加分项。4.2 前端面试中AI方向的高频考点第三个月后半段我开始整理AI前端面试可能高频遇到的问题。这里分享一张我整理的表格按“问题、考察点、参考回答思路”来列你可以直接用面试问题考察点参考回答思路大语言模型接口怎么接入前端API调用与安全先由后端转发请求前端通过fetch或SDK获取消息重点说明流式接入和密钥安全SSE和WebSocket有什么区别实时通信理解SSE是单向HTTP长连接适合模型生成WebSocket是双向长连接适合Agent状态流转如何实现打字机流式渲染流式数据处理fetch ReadableStream TextDecoder注意中文按流解码前端为什么要托管上下文数组状态设计消息不能只存字符串要有role、状态、工具调用字段才能支持重新生成和分支Function Calling是什么大模型工具调用模型返回结构化工具调用请求前端执行后回传结果形成多轮工具循环怎么防止AI应用中的XSS前端安全不用dangerouslySetInnerHTML用markdown渲染库转义对链接加安全校验复习这些题目不用死记硬背核心是理解AI应用的数据流。把所有题当成一个完整的设计来答用户发消息前端更新消息数组请求后端后端调用模型返回流前端逐段渲染期间可能穿插工具调用和状态更新最后落库。把这条链路想顺了很多问题都能顺着答出来。4.3 常见问题与排查技巧实录最后分享一些我在这三个月里实际踩过的坑和排查方法。常见问题可能原因解决方案流式输出内容乱码TextDecoder没有开启stream: true使用decoder.decode(value, { stream: true })刷新页面后聊天记录全丢只存在内存里接IndexedDB把消息数组持久化恢复后重新渲染停止生成后重新提问上下文错乱中断消息没有标记interrupted消息列表维护status字段重发时过滤未完成消息Function Calling返回JSON解析失败模型输出不标准先做正则提取再做try/catch兜底最后重试一次WebSocket一直掉线没有心跳机制每隔30秒发一个ping收到pong后继续否则重连印象最深的是有一次SSE正常返回完所有内容但页面上最后一段却丢失了。排查了很久发现是done事件和内容数据在同一个TCP包里我的解析逻辑只处理了data:开头的行[DONE]被当成普通JS语句跳过了。后来我专门写了一个parseSSEStream的工具函数把数据解析和UI更新彻底分离这个工具后来被我所有AI项目复用。建议你也把自己的坑沉淀成这种可复用的小函数而不是每次都在组件里CtrlC。这三个月的路走下来最大的变化不是技术列表变长了而是你对“AI应用”这件事从抽象概念变成了具体的工程实现。刚开始可能会被Function Calling和Agent事件流吓到但只要你把一个完整消息流打通后面再遇到新的AI交互模式你都会觉得它不过是在这套消息协议上加了一些字段。我个人最后的建议是不要追求把所有AI概念学完再动手先用最笨的方式写好一个流式对话页面然后不断往里面加能力。能跑起来比什么都强。
最近总有人问我前端都这么卷了还要不要冲AI应用方向我的回答是与其焦虑不如用三个月时间给自己一次系统升级。这套计划不是让你去卷大模型底层算法而是把AI能力接到网页端成为真正能交付AI应用的前端工程师。现在前端行业最明显的变化是招聘需求从“会写页面”变成了“会接AI”。无论是给内部工具加一个AI问答面板还是做一个像Manus那样的AI Agent网页端又或是给传统业务系统嵌入大模型能力本质上都在等一批能把大模型API、实时流、多轮对话做好的前端开发。这个计划就是围绕这些真实需求设计的适合有半年以上前端经验、想在AI应用方向建立竞争力的同学也适合刚入门但愿意挑战自己的新人。1. 三个月计划的整体设计不是堆技术栈而是做项目闭环1.1 为什么要锁定期限为三个月三个月不是拍脑袋定的数字我见过太多人学AI前端最后被Prompt、Agent、Function Calling这些名词劝退。其实真正要掌握的没有想象中那么玄70%的工作还是你熟悉的UI、状态、异步、性能另外30%才是大模型接入和AI交互设计。三个月刚好够把这30%学透再用项目磨到能写进简历的程度。如果把战线拉到半年反而容易陷入“这也要学那也要学”的焦虑最后啥都浅尝辄止。从投入产出比看三个月也很合理。按每周投入15到20小时计算三个月大约是180到240小时这个体量足够你完成所有核心知识点的刻意练习也足够做出两到三个有说服力的项目。而且AI应用前端这个方向更新太快学习计划必须短平快快速跑通一个完整闭环之后再迭代比一开始就想搞一个万能方案靠谱得多。1.2 学习路线的三个阶段拆解我把整个计划拆成三个阶段每四周一个节点每个阶段都有明确产出。第一个月叫“思维升级”核心是掌握AI会话类应用的前端形态会写流式交互、会封装会话组件第二个月叫“能力集成”核心是把大模型API、Agent机制、多AI协作接进前端做出真正能解决问题的功能第三个月叫“实战交付”核心是完成几个拿得出手的项目同时把面试常考的点系统梳理一遍。阶段周期核心任务产出物第一阶段第1-4周理解AI应用前端形态掌握SSE/WebSocket流式交互封装AI会话UI组件一个可运行的多轮对话前端支持Markdown渲染和停止生成第二阶段第5-8周对接大模型API实现Function Calling和Agent事件流处理性能与异常一个AI Agent工作台能调用工具并展示运行过程第三阶段第9-12周完成两到三个项目整理AI前端面试题和排查手册两个完整项目Demo一份面试复习清单别把阶段理解成技术的简单罗列它们之间是咬合关系。第一阶段打交互基础第二阶段做能力接入第三阶段把这些能力沉淀成作品。很多人一上来就冲Agent和Function Calling结果连SSE的数据流都没搞清楚写出来的界面既不丝滑也不可靠这才是最要命的。1.3 工具链选择的底层逻辑工具链不需要多但每个都要能扛住实战。前端框架我建议优先React TypeScript原因很简单AI应用相关的开源项目、UI组件、示例代码大多是React生态的遇到问题能参考的资料最多。构建工具选Vite开发体验比Webpack好太多HMR快到不用等。样式方案用Tailwind CSSAI应用界面里临时性的状态样式特别多用Tailwind写起来比写一堆CSS类名快得多而且深色模式切换非常方便。UI组件可以从 shadcn/ui 或者 Ant Design 5.0 里选我更倾向前者它不锁定组件结构方便你按AI应用场景二次封装。状态管理不需要太重Zustand或Jotai足够如果你愿意也可以直接用React Query管理服务端状态把AI请求和流式状态交给它缓存和重试。后端不是你两个月能学完的但你至少要会通过Node.js或现有网关转发大模型请求一定不要把API Key直接放在前端代码里这是安全和合规的底线。2. 第一个月从传统前端到AI应用前端的思维升级2.1 理解AI应用的前端形态不再是表单列表传统后台业务页面的核心是表单、表格、详情、增删改查用户把数据填进去提交看到结果。AI应用前端完全不是这个逻辑它的核心变成了“对话”——用户用自然语言发起请求模型返回文本、图片或者工具调用结果前端要实时展示生成过程允许用户中断、重试、继续追问。这意味着你必须把“等待结果”这种交互变成一个动态的流程。举个我做过的小程序企业知识库问答页面用户提出一个问题后模型不是一次性返回答案而是先显示“正在读取文档”再一段一段输出回答同时旁边有一个token计数器跳动。用户如果发现回答方向不对可以点“停止生成”按钮立刻打断流式请求再补充限定条件重新提问。这种体验和传统请求别人后端接口完全不一样你不能再用一个loading转圈打发了前端需要处理流式的数据分片、分段渲染、可取消的操作以及长时间连接下的异常恢复。2.2 技术栈选型与项目初始化第一个月第一天不要急着写业务代码先把项目骨架搭好。我用Vite初始化一个React TypeScript项目然后接入Tailwind CSS这套组合已经成为AI前端项目的默认起点。你可以通过下面命令快速开始npm create vitelatest ai-frontend -- --template react-ts cd ai-frontend npm install npm install tailwindcss tailwindcss/vite按Tailwind CSS v4的用法在vite.config.ts里加上tailwindcss/vite插件然后新建一个index.css里面写import tailwindcss;就完成了。接下来建议直接安装ai这个开源SDK以及ai-sdk/react它能帮我们管理流式请求、消息状态还有错误重试省去大量手写hooks的重复工作。如果你不想引入SDK也可以自己写一个useChatStream的hook核心就是封装fetch和ReadableStream。我在做这个阶段时遇到过一个问题直接使用npm create vite默认模板后React 19的并发渲染对字符串流式解析会有一些额外的渲染开销。所以建议在所有需要频繁更新的消息组件上尽量用不可变的数据结构避免大数组的重复渲染。这个习惯越早养成后面做Agent工作台时越轻松。2.3 流式输出与实时交互SSE和WebSocket的正确打开方式AI应用前端最核心的技术点就是流式渲染。大语言模型生成token需要时间如果等全部生成完再显示用户会以为页面卡死了。业界普遍用SSEServer-Sent Events来推送生成内容它本质上是一条HTTP长连接服务端可以持续往客户端发送文本片段。前端用fetch拿到ReadableStream再逐段解析就能实现一个字一个字蹦出来的打字机效果。const res await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages }) }); const reader res.body!.getReader(); const decoder new TextDecoder(utf-8); while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value, { stream: true }); // 这个 chunk 里可能包含多个 SSE 事件需要按行拆分 const lines chunk.split(\n); for (const line of lines) { if (line.startsWith(data: )) { const payload JSON.parse(line.slice(6)); if (payload.done) return; appendMessage(payload.choices?.[0]?.delta?.content ?? ); } } }这段代码是我第一版流式渲染的核心看起来简单踩坑不少。首先是中文乱码如果你直接对每个chunk调用TextDecoder就会出现中文字符被截成两半导致乱码。解决方法是必须使用{ stream: true }参数让解码器跨chunk缓存残余字节。其次是事件边界问题服务端发来的一个chunk可能包含多行data:也可能一行没有结束所以不能假设每次reader.read()都拿到一条完整事件要先按换行符切分再逐行处理。那WebSocket什么时候用SSE适合服务端单向推送但如果你要做一个AI Agent或者多AI协作系统就可能需要前端向后端发送事件、后端主动推送中间状态。WebSocket是双向的适合指令和事件来回交换的复杂场景。比如你在做一个后台实时数据看板Python Django后端收集到新的任务进度通过channels推送到前端前端不需要轮询连接建立后会持续收到事件。AI应用里推荐做法是模型生成的文本流用SSEAgent的状态流转用WebSocket两者各司其职。2.4 组件库的二次封装让AI会话界面开发提速第一个月后半段我开始封装AI会话界面里的通用组件。聊天界面看起来简单但真要写好涉及消息列表、气泡、Markdown渲染、代码高亮、引用内容、附件缩略图等一堆东西。如果每个页面都从零写效率太低。我建议先从简单的ChatMessage组件开始它的props应该能表达一条消息最基础的属性interface ChatMessage { id: string; role: user | assistant | system | tool; content: string; status?: streaming | completed | error | interrupted; toolCalls?: Array{ name: string; args: Recordstring, unknown; status: string }; }有了这个类型基础渲染层就可以根据status控制打字机动画、错误提示、停止按钮根据content决定是用普通文本还是Markdown渲染。如果是Markdown一定不要直接把dangerouslySetInnerHTML塞给用户内容用react-markdown配合remark-gfm再为代码块单独封装高亮组件。这样既安全又能出效果。组件封装的核心思路是“数据驱动UI”你的界面不应该关心某次回答是哪个模型生成的只需要关心消息对象的字段和状态。3. 第二个月AI能力集成与工程化实践3.1 对接大模型API从Prompt工程到Function Calling到了第二个月你要开始真正接大模型了。不管用的是DeepSeek、阿里通义还是OpenAI兼容接口前端侧的流程基本一致把用户消息数组发给后端后端带着密钥去请求大模型然后把流式响应转发给前端。你要重点掌握的是messages数组的结构它不只是简单的user/assistant还包括system系统提示词和不同角色的历史消息。前端要做的是在本地维护一个消息列表每次发送请求前把完整上下文一起提交。比普通对话更进一步的是Function Calling这是让AI应用从“聊天机器人”进化成“智能体”的关键。举个例子你的页面里有一个“查询订单物流”按钮用户问“我的订单到哪了”模型并不直接知道物流数据它可以返回一个工具调用请求前端解析到tool_calls字段后就去调后端物流查询接口拿到结果再以tool角色的消息发回给模型模型把最终答案整理给用户。这个机制的难点在于前端要处理好工具调用的生命周期发起中、执行中、成功、失败每一步都要有相应UI反馈不能让用户干瞪眼。配置Function Calling时要特别注意大模型返回的JSON可能不标准。我在项目里遇到过一次模型返回的arguments字段是一个JSON字符串但里面混了换行和转义符直接用JSON.parse会报错。后来我做了两层兜底先用正则提取最外层花括号再包裹一层try/catch解析失败就把原始字符串返回给用户并提示“工具调用失败请重试”。这类防御性代码AI前端工程师一定要多写。3.2 AI Agent前端集成状态机、多轮会话与工具调用AI Agent和普通聊天前端的区别在于它不再是一轮问答就结束而是像一个“干活的人”一样拆解任务、调用工具、检查结果。前端虽然不负责Agent的决策逻辑但要负责把Agent运行的过程可视化。推荐用事件流协议来解决后端把Agent执行过程中的关键节点推送到前端前端根据事件类型渲染不同的界面。比如一个“自动做一个行业信息简报”的Agent你会在页面上看到这些事件事件类型前端展示说明agent_start显示“开始分析任务”Agent开始干活tool_call显示工具名称、参数预览模型决定调用搜索或查询工具tool_result显示工具返回的数据摘要前端把结果反馈给用户agent_message实时输出模型回答用于阶段性总结agent_complete展示最终产出物提供下载按钮任务完成这个状态下前端最忌讳的是把所有事件塞进一条消息气泡里。我在做Agent工作台时单独设计了一个“运行轨迹”面板放在聊天记录的右侧所有状态事件按顺序排列用图标区分工具调用和消息输出。这样做的好处是用户可以感知到Agent“在思考”而不是怀疑页面卡死。为了让后端事件格式统一我还定义了一个前端可解析的AgentEvent联合类型事件字段里必须有id和createdAt方便前端做时间线渲染和增量更新。3.3 多AI协作场景下的前端架构设计多AI协作是最近很热的话题前端也不是没有难点。比如你同时让多个AI模型完成同一个任务每个模型的输出速度不一样前端的消息列表就会交错更新。如果不做统一协议页面很快就会乱成两套气泡、两种滚动逻辑。我当时采用的方案是“统一消息协议 独立渲染通道”。消息协议里固定加上agentId和modelName字段每个AI参与者都是独立的消费者前端根据agentId把消息路由到对应的会话面板或者分组。视觉上的设计也要注意。用户同时看多个AI回答时要能很容易分辨谁是谁。我给每个参与者的气泡背景色、头像、名字做了配置化还做了一键折叠任意一个AI输出的功能。这个体验很像看实时弹幕信息密度大但用户可以按需选择。如果你做的是多个模型同屏对比还要考虑横向布局的响应式问题——移动端上两个模型答案的对比高度可能完全不一致这需要前端灵活调整卡片高度而不是强行等高。3.4 性能优化与异常兜底流式中断、超时、上下文管理AI应用前端最怕的事就是流式请求挂到一半页面既不报错也不结束。第一个要做的就是可取消。使用AbortController当用户点击“停止生成”时调用abort()同时把消息状态标记为interrupted这样用户能明确知道这条消息是被主动打断的。第二个是超时兜底有些模型服务响应会特别慢你不能让用户无限等待。我用过两种策略整体超时用setTimeoutAbortController超过60秒没有收到任何分片就自动断开重试空闲超时用定时器检查每个chunk的间隔如果超过15秒没有新数据就提示“模型思考时间过长”。上下文管理同样重要。很多前端直接把用户所有聊天记录发给后端结果上下文越来越长最后超出了模型窗口。我写了一个简单的token估算函数Math.ceil(content.length / 4)如果当前上下文估算值超过模型窗口的70%就触发提醒或者把最早的消息摘要成一段系统提示优雅压缩上下文。再有就是重试机制流式请求可能因为网络抖动而失败前端应该提供“重新生成”按钮重试时带上之前的信息摘要而不是把失败上下文原样扔过去。4. 第三个月实战项目与面试准备4.1 自己选题做2-3个拿得出手的项目第三个月的核心任务是把前面学的东西变成作品。我不建议跟着视频或文档抄一遍而是做三个方向不同的项目形成组合拳。第一个是AI聊天助手包含流式渲染、Markdown渲染、停止生成、会话历史持久化这个项目用来展示你的交互基本功。第二个是AI Agent工作台包含Function Calling、工具调用过程可视化、任务运行轨迹用来展示你对Agent架构的理解。第三个可以做企业知识库问答前端体验RAG检索结果和AI回答的融合展示同时处理引用来源、文档分片的跳转。每个项目都要达到可以现场演示的程度。简历上写“熟练使用AI SDK”没用面试官更愿意看到你打开一个页面输入一个问题然后笑着看他看着token一点点蹦出来。项目代码要放到GitHubREADME里写清楚功能清单和技术架构最好配一个GIF演示。我当时还在项目里加了一个“暗黑模式”切换后来面试时经常作为交互细节被问到这是加分项。4.2 前端面试中AI方向的高频考点第三个月后半段我开始整理AI前端面试可能高频遇到的问题。这里分享一张我整理的表格按“问题、考察点、参考回答思路”来列你可以直接用面试问题考察点参考回答思路大语言模型接口怎么接入前端API调用与安全先由后端转发请求前端通过fetch或SDK获取消息重点说明流式接入和密钥安全SSE和WebSocket有什么区别实时通信理解SSE是单向HTTP长连接适合模型生成WebSocket是双向长连接适合Agent状态流转如何实现打字机流式渲染流式数据处理fetch ReadableStream TextDecoder注意中文按流解码前端为什么要托管上下文数组状态设计消息不能只存字符串要有role、状态、工具调用字段才能支持重新生成和分支Function Calling是什么大模型工具调用模型返回结构化工具调用请求前端执行后回传结果形成多轮工具循环怎么防止AI应用中的XSS前端安全不用dangerouslySetInnerHTML用markdown渲染库转义对链接加安全校验复习这些题目不用死记硬背核心是理解AI应用的数据流。把所有题当成一个完整的设计来答用户发消息前端更新消息数组请求后端后端调用模型返回流前端逐段渲染期间可能穿插工具调用和状态更新最后落库。把这条链路想顺了很多问题都能顺着答出来。4.3 常见问题与排查技巧实录最后分享一些我在这三个月里实际踩过的坑和排查方法。常见问题可能原因解决方案流式输出内容乱码TextDecoder没有开启stream: true使用decoder.decode(value, { stream: true })刷新页面后聊天记录全丢只存在内存里接IndexedDB把消息数组持久化恢复后重新渲染停止生成后重新提问上下文错乱中断消息没有标记interrupted消息列表维护status字段重发时过滤未完成消息Function Calling返回JSON解析失败模型输出不标准先做正则提取再做try/catch兜底最后重试一次WebSocket一直掉线没有心跳机制每隔30秒发一个ping收到pong后继续否则重连印象最深的是有一次SSE正常返回完所有内容但页面上最后一段却丢失了。排查了很久发现是done事件和内容数据在同一个TCP包里我的解析逻辑只处理了data:开头的行[DONE]被当成普通JS语句跳过了。后来我专门写了一个parseSSEStream的工具函数把数据解析和UI更新彻底分离这个工具后来被我所有AI项目复用。建议你也把自己的坑沉淀成这种可复用的小函数而不是每次都在组件里CtrlC。这三个月的路走下来最大的变化不是技术列表变长了而是你对“AI应用”这件事从抽象概念变成了具体的工程实现。刚开始可能会被Function Calling和Agent事件流吓到但只要你把一个完整消息流打通后面再遇到新的AI交互模式你都会觉得它不过是在这套消息协议上加了一些字段。我个人最后的建议是不要追求把所有AI概念学完再动手先用最笨的方式写好一个流式对话页面然后不断往里面加能力。能跑起来比什么都强。
