企业官网建设流程全解析

如果现在给你三个月时间，让你从普通前端转成AI应用方向的前端工程师，你会怎么安排？我经常被问到这个问题。这两年AI应用的前端开发和传统前端开发的差距越来越大，不少朋友以为AI应用前端就是“调个接口，把返回的文本渲染出来”，但真正做过ChatGPT类产品、Agent工作台或者AI创作工具的人都知道，这个方向对前端的理解要求和普通业务前端完全不同。这篇东西就是我带团队、做面试官、自己也亲自写过多个AI应用前端之后，总结出来的一份三个月学习计划。它不绕弯子，不灌鸡汤，每个阶段都有明确的目标、验收标准和建议动手做的项目，适合已经有一到两年前端基础、现在想往AI应用方向靠的朋友。

这个计划的核心逻辑是：第一，把前端基本功重新打磨到能支撑复杂交互的水准；第二，用一个月时间吃透AI应用的交互模式与底层数据流；第三，用一个月时间做出一个有区分度的作品集项目，同时把自己放到面试市场中去检验。三个月听起来不长，但如果安排合理，足够让你的简历从“做过管理系统”变成“做过AI应用”。

1. 先搞清楚：AI应用前端工程师和普通前端差在哪

1.1 一个聊天框背后的完整前端命题

很多人觉得AI应用前端就是“把用户的话发给大模型，然后再把回答显示出来”。如果你只停留在这一步，那这个岗位的工作内容确实和普通前端没什么区别。但真实情况完全不是这样。

以现在最常见的对话型AI产品为例，前端要处理的不仅仅是“发消息、收消息”。一个最小的完整闭环拆开来看，至少包括：

• 流式接收与增量渲染：模型输出不是一次性返回完整结果，而是一个字一个字或者一个块一个块地流式回来。前端要通过SSE或者WebSocket接收这些增量内容，并在页面上稳定、平滑地渲染出来。这里涉及打字机效果、中文断句、Markdown解析、代码高亮、数学公式渲染等一堆问题。
• 多轮上下文的维护：会话历史、系统提示词、用户修改过的消息、重新生成、流式过程中的中断与继续，都需要前端有清晰的数据模型来承载。
• 工具调用的可视化：当AI Agent调用外部工具时，前端要把“正在调用什么工具”“输入了什么参数”“返回了什么结果”这些中间过程展示给用户，而不是只给一个笼统的“思考中”的状态。这比普通业务前端常见的进度条复杂得多。
• 状态与异常恢复：网络中断、模型超时、内容被过滤、余额不足、并发会话管理，这些都需要在前端做兜底和恢复逻辑。

这些工作叠加起来，难度一点不比后端架构设计低。传统前端可能大部分时间在和表单、列表、权限、图表打交道，而AI应用前端需要和“持续到达的不稳定数据流”打交道，这是思维模式上的本质变化。

1.2 为什么AI应用前端是当前值得投入的方向

从职业发展角度讲，这个方向有两个明显优势。第一，AI应用的产品形态还在快速演化，岗位需求远没有饱和。现在不仅专门的AI创业公司在招，电商、办公、教育、金融各个行业都在尝试做AI助手、智能客服、智能写作等产品。这些产品的共同点就是需要前端来实现AI交互体验，而市场上熟悉这套技术栈的人还不多。第二，AI应用前端有强技术壁垒，不容易被替代。普通CRUD页面的前端经验很难直接迁移到流式渲染、Agent交互、并发状态管理这些场景，这意味着你一旦掌握，就具备了稀缺性。

简单来说，这是一个投入三个月时间、可以明显拉开与同龄前端差距的方向。接下来我按三个阶段拆解具体的学习内容。

2. 三个月学习计划的总体架构与阶段性验收标准

2.1 三个月的整体安排

我把整个计划分成三个阶段，对应三个能力层次：打底、进阶、实战。

这个顺序不是随便排的。你有前端基础的话，第1个月偏重“把知识补到能打硬仗的水平”，同时要用最快的速度把大模型API调用链路走通。如果不先走通一个最小Demo，你对后面SSE、WebSocket这些概念的感受就是空的。第2个月才是真正的核心，我后面会详细说为什么这部分最能拉开差距。第3个月本质上不是学习月，而是“输出月”，前两个月学到的任何东西，最后都得落到一个能讲清楚的项目上。

2.2 每阶段验收与自测方式

学习计划最怕没有验收。我建议每个周末留半天时间，不看教程，关闭所有工具，自己从零开始写一个功能模块。具体说：

• 第一周结束：不借助框架，用原生fetch请求一个文本模型接口，把返回值完整地显示在页面上。不需要流式，只要能把非流式响应渲染出来就行。
• 第二周结束：用React实现一个带消息列表、输入框、发送按钮的完整聊天界面，支持加载态、错误态和简单的历史消息展示。
• 第三周结束：实现真正的流式输出，页面上的文字像打字机一样逐渐出现，并且支持中途停止。
• 第四周结束：完成一个包含会话创建、切换、删除，消息持久化到localStorage的小产品。

每周的验收都很具体。如果你在某个周末发现自己完不成，说明这一周的学习方式有问题，要马上调整，而不是拖着往下走。

3. 第1个月：前端地基与大模型入门

3.1 为什么我建议你选React而不是其他框架

如果你现在对React和Vue都只是“用过”而不是“熟练”，那这个月我建议你把React作为主攻方向。不是说Vue不好，而是AI应用生态里React的成熟度最高。你看Vercel AI SDK、LangChain.js的官方示例，绝大多数都是React版；主流AI开源项目如ChatGPT-Next-Web、Lobe Chat这类成熟产品也都是React技术栈。遇到问题查资料、抄代码、找开源参考，React方向会顺利很多。

另外要特别提醒一点：不要在这个阶段被“要不要学Next.js”这个问题拖住。如果你会Next.js当然更好，不会的话，先用Vite搭一个React单页应用也完全够用。AI应用前端的核心在交互和状态管理，不在服务端渲染。等后面作品集需要部署上线时，再补Next.js不迟。

3.2 必须吃透的JavaScript与TypeScript核心

这一个月的前端地基重心不是CSS，也不是组件库，而是JavaScript异步编程和TypeScript类型设计。

异步编程是第一位。你后面接触到的所有AI交互都是异步的：发送消息、接收流式数据、处理中断、并发请求。如果你对Promise、async/await、事件循环、微任务宏任务的理解只是停留在“能跑”的阶段，那后面调试流式渲染会非常痛苦。我建议你花一周时间专门做三件事：手写一个Promise.all并发限制工具；手写一个带重试机制的请求封装；给一个模拟的流式数据源写一个消费器，用ReadableStream按块读取数据。

TypeScript类型设计是第二位。AI应用前端最麻烦的就是消息类型的设计。一条消息可能是用户文本，可能是模型回复，可能是工具调用结果，也可能是系统错误。如果你不用联合类型、可辨识联合、泛型约束把这些情况建模清楚，代码很快就会变得不可维护。这个月可以练一个练习：用TypeScript给一个聊天应用定义完整的消息模型，包括普通文本消息、流式片段消息、工具调用消息、错误消息，并为每一条消息设计渲染器的映射关系。

3.3 用最快速度跑通一个大模型API Demo

第一周的Demo不需要用任何SDK，直接用浏览器fetch调用OpenAI兼容接口就好。现在国内外的模型服务商大多数都提供OpenAI兼容格式，你只需要一个API Key和一个聊天补全接口就能开始。

这个Demo要刻意做成非流式加载的样子。先发送一个普通请求，拿到完整JSON响应，再把content字段显示到页面上。这一步的价值是让你明白一个最基本的事实：大模型API本质上就是一个HTTP接口，输入消息数组，输出文本结果。不要被“大模型”三个字吓住。

第二周再把接口切换成流式模式，用fetch加上ReadableStream逐步读取数据块。很多前端第一次接触流式时会在这里卡住，因为不清楚getReader()和read()的用法，也不知道怎么把一个个data块解析出来。我给你一个最简单的流式解析思路：

const response = await fetch(url, { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ messages }) }); 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:开头的行 // 然后JSON.parse解析出增量文本 }

这个循环就是所有流式聊天前端的底层骨架。第1个月不需要处理得太复杂，核心是把“持续读取-更新界面”的链路打通。

4. 第2个月：流式体验与Agent交互的前端实现

4.1 流式输出的几个真实难点与解法

第二个月是拉开差距的关键，我按实际项目中高频出现的难题来讲。

第一个难题是“Markdown与代码渲染的时序问题”。流式输出时，模型可能分多次返回一个完整Markdown代码块的各个部分。比如返回序列是```js ``，然后是`console.log`，最后是``` ``。如果你在每一个增量块到达时都重新对全文做一次Markdown解析，页面会闪，而且光标位置会乱；如果只解析新增部分，又可能因为代码块没有闭合而解析失败。

实际项目里比较稳的做法是：用react-markdown配合remark-gfm，在渲染时保留一个“待解析的完整消息文本”，每次收到新块就追加到这条消息后面，然后整体重新解析并渲染到DOM。 性能上看起来不划算，但对大多数文本量级来说完全足够，而且能避免时序问题。真正需要性能优化的场景，可以用react-virtuoso做长列表虚拟滚动。

第二个难题是“中文流式渲染的停顿感”。英文按空格分词，中文没有明显空格，模型经常一次返回一个完整的词或者几个字。如果前端每个小块都立刻更新DOM，视觉上就是一顿一顿的。更好的体验是做“微节流”：比如每60到100毫秒将累积的增量批量推送到界面上一次，让文字输出更平滑。你可以用一个简单的定时器实现，也可以在React 18里用useTransition延迟更新。

第三个难题是“用户中断与错误恢复”。流式过程中用户点击停止，前端需要调用reader.cancel()来终止读取，同时保留已经收到的那部分内容；如果网络出错，要提示用户并提供“重新生成”的入口。这里面最容易被忽略的是“状态同步”：停止按钮、加载中、正在生成、已完成这四个状态要放在一个状态的有限集合里管理，否则很容易出现“按钮已经显示重新生成了，但底层流还在跑”这种bug。

4.2 WebSocket前端在AI应用中的实际定位

很多人以为AI应用前端只要会SSE就够了，但实际项目中WebSocket出现的频率也在上升。典型场景是语音对话类AI和实时协作类Agent：用户语音上传后，服务端可能通过WebSocket持续回传识别文本、模型思考过程、最终回复等多个信息流；或者在一个Agent工作台里，多个关联会话的状态需要实时同步。

前端处理WebSocket和SSE的差异点在于：SSE是单向的、断线自动重连的机制要靠自己实现；WebSocket是双向的、需要自己处理心跳、重连和消息序号去重。如果你之前没有写过WebSocket，这个月要手动实现一个带自动重连、心跳检测、消息队列的封装。我给你一个基础结构：

class AIWebSocket { constructor(url) { this.url = url; this.ws = null; this.heartbeatTimer = null; this.reconnectTimer = null; this.messageQueue = []; } connect() { this.ws = new WebSocket(this.url); this.ws.onopen = () => { this.startHeartbeat(); this.flushQueue(); }; this.ws.onmessage = (event) => { // 解析消息并分发到对应的会话状态管理 }; this.ws.onclose = () => { this.stopHeartbeat(); this.scheduleReconnect(); }; } }

不用把所有逻辑写到最完美，但至少要把“断网重连后，之前发送但未确认的消息怎么办”这个问题想清楚。很多AI应用里用户发送一条消息后，如果网络闪断，会出现“服务端收到了，但前端不知道”的情况，处理不好就是重复发送或者消息丢失。

4.3 Function Calling与Agent工具调用的可视化

这是我认为AI应用前端和传统前端最不一样的地方，也是面试时最能展现深度的地方。

当模型决定调用某个工具时，API返回的not一条纯文本，而是一个结构化对象，里面包含工具名称和参数。前端要做的是把这段过程变成用户能看懂的界面。举个实际例子：一个“AI数据分析助手”中，模型判断需要查天气，返回了{"name": "get_weather", "arguments": {"city": "北京"}}。前端可以：

• 在消息流中插入一个“工具卡片”，显示“正在查询北京的天气”；
• 工具返回结果后，把结果折叠起来，让用户看到最终结论；
• 如果有多个工具连续调用，就显示一条工具调用链路，类似“查询城市 -> 调用天气API -> 查询交通信息 -> 汇总生成出行建议”。

这个可视化逻辑可以用一个专门的组件来承载，消息模型里单独定义tool_call类型。我在实际项目里常用的方案是：把工具调用和工具执行结果分别作为独立的消息类型，通过消息序号关联起来，渲染时按时间线排列。这样即使一个会话里穿插了五六次工具调用，页面的时间线依然清晰。

做这个组件的过程，本质上就是在理解“AI Agent的交互范式”。你在简历上如果能写清楚“使用可辨识联合类型建模流式消息与工具调用，自研工具调用时间线组件”，面试官一定会让你展开聊，这就是你的差异化。

4.4 搭一个有真实感的Agent前端交互框架

第2个月的输出物应该是一个可以跑起来的中型项目。我给你一个具体选题建议：做一个“AI工作台”，左边是会话列表，中间是聊天区，右边是工具调用时间线。聊天区支持流式渲染、Markdown解析、重新生成和中断；工具调用时间线展示每一步调用的输入输出；数据存在localStorage或IndexedDB中。

做的时候要有意加入下面几个细节：

• 消息发送后立刻追加一条用户消息，并显示一个临时的“等待模型响应”占位符；
• 流式接收时，增量内容只更新最后一条assistant消息；
• 工具调用过程中，在时间线区域插入一个带状态（执行中/成功/失败）的卡片；
• 支持一键清空当前会话并新建会话，切换会话时保留各自的消息状态。

完成这个项目后，你应该能熟练回答这几个问题：如何实现一个可中断的流式请求？如何避免重复渲染导致的消息内容错乱？如何设计消息类型让前端能区分文本、工具调用和错误？这些问题几乎就是我面试AI应用前端时必问的。

5. 第3个月：作品集、简历与面试突围

5.1 如何选题做一个高区分度的AI应用

到了第3个月，你已经有能力做项目了，这时候最大的坑反而是“不知道做什么”。我建议选题遵循一个原则：做你自己会高频使用的工具，而不是追热点。热点项目（AI聊天壳、AI画图站）已经泛滥了，面试官看到同质化的作品很难提起兴趣。

我给三个方向供参考：

• AI文档助手：上传一份文档，通过对话完成总结、翻译、提取要点。这里会涉及文件读取、长文本分块、流式输出、历史会话，技术覆盖面很广。
• 数据分析对话：让用户上传CSV，AI生成表格解读和图表建议。前端要处理文件解析、图表渲染、消息与图表的混排展示，视觉效果好。
• 个人知识库问答：用户录入多篇笔记，AI基于这些笔记内容做问答。前端核心是知识库管理、引用来源展示（模型返回中带引用编号，前端要渲染成可点击的脚注），这个交互非常像真实产品。

做完后不要只追求功能，要有两到三个“体验亮点”。比如：流式过程中代码块可以高亮；引用来源可以悬浮预览；长会话中消息列表虚拟滚动保持流畅。这些亮点在简历里比“调用了大模型接口”有价值得多。

5.2 简历上项目经历怎么描述

写简历的时候，很多前端容易写成“负责聊天界面的开发”这种流水账。我建议按照“业务背景-个人职责-技术方案-难点解决-量化结果”的结构来写，举一个示范：

AI数据分析助手（独立开发） 技术栈：React + TypeScript + Vite + Vercel AI SDK 核心工作：设计统一消息类型模型，以可辨识联合类型区分用户消息、模型回复、工具调用与错误消息；实现基于ReadableStream的流式增量渲染，通过微节流策略优化中文逐字输出的视觉体验；实现工具调用时间线组件，将模型内部的Function Calling过程可视化，支持执行中、成功、失败三态展示；使用IndexedDB持久化多会话消息，支持会话切换与历史恢复。 难点解决：针对流式Markdown解析时序导致代码块闪烁的问题，采用整段累积重解析方案，配合虚拟滚动保证长会话流畅度。

这样写，面试官很容易从里面抓出两三个点来深挖，而这些点你在第2个月都已经亲手做过，完全经得起追问。

5.3 AI应用前端面试题背后的本质

这个方向的面试题，表面上看有很多种问法，核心逃不开三类。

第一类是异步与流式。比如“让你实现一个打字机效果，你会考虑哪些问题”“SSE和WebSocket的区别”“如何取消一个流式请求”。本质考察你对数据流的掌控力。

第二类是状态与架构。比如“如果一个页面同时有三个AI会话在运行，状态怎么组织”“工具的中间结果放哪一层”“消息类型越来越复杂时，如何保持渲染器的可扩展性”。本质考察你的类型设计和状态管理能力。

第三类是场景设计。比如“设计一个AI编程助手的对话界面，用户每发一条消息，模型都可能修改文件列表，前端如何展示这种变化”。本质考察你能不能把一个AI产品的交互模型落地。建议你遇到场景题时，先画消息模型，再画组件结构，再谈状态流转，这个答题结构本身就比零散讲要好。

6. 这三个月里最容易踩的坑

6.1 技术选型上的坑

我见过很多人在第1个月就钻进“学LangChain还是学Vercel AI SDK”这个问题里出不来。实际上对于前端工程师来说，你现在只需要搞清楚两件事：一是Vercel AI SDK这类工具帮我们封装好了流式请求和消息状态，可以大幅提高效率；二是它的封装也屏蔽了底层细节，如果你只会用SDK而不理解底层ReadableStream，面试时一深挖就露馅。

我的建议是：第1个月、第2个月自己做底层实现，不要用SDK；第3个月为了赶作品集进度，可以尝试用一次Vercel AI SDK。这样你既理解了黑盒内部原理，又能在实际项目中体会到封装带来的效率提升，简历里也能诚实地说自己两种方式都实践过。

6.2 流式渲染的细节坑

流式渲染的坑特别多，我只挑影响最大的三个说。

第一个是“消息内容被覆盖”。很多新手在一个组件里直接用一个state保存“当前正在生成的文本”，当用户发出新消息后，还没来得及重置state，结果新消息和旧回复串在一起。解决方法是每条assistant消息在创建时就有独立的id和独立的消息对象，流式增量只更新对象里的content字段，而不是用一个全局变量。

第二个是“多次请求乱序”。用户连续发送多条消息，或者点了重新生成，前端同时发出多个请求，慢的请求后到却把快的请求内容覆盖了。解决方法是每次请求都绑定一个唯一的消息id和会话版本号，回调里先校验版本号再更新UI。

第三个是“大模型输出被截断时的体验”。API会返回finish_reason，可能是正常结束，也可能是长度限制导致的截断。前端要在finish_reason非normal时显示“内容被截断，请继续或重新生成”的提示，这是很多产品都会漏掉但用户又很在意的地方。

6.3 学习节奏和心理预期

最后说一点不是技术但很重要的事。三个月计划最怕的不是学不会，而是前两周热情高涨，到第3周因为某个知识点卡住就放弃。我建议你给自己定一个“最低完成量”：每天至少集中精力写45分钟到1小时代码，周末完成本周验收任务。不要一天学12小时，第二天完全休息，这种节奏学前端是大忌。

另外，遇到卡住的问题不要太死磕。现在网上资料比你想象的多，直接去GitHub找开源AI应用项目，读别人的实现，甚至用AI问答工具帮你解释代码，都是完全可以的。我的经验是，一个流式渲染的问题如果卡了一个下午还没解决，就停下来，换个时间再想，或者把问题拆得更小。情绪稳定地推进，比任何技巧都重要。

这个方向的学习曲线确实不平稳，但当你亲手把一个带流式输出、工具调用可视化、多会话管理的AI应用前端做完之后，你对整个AI应用的产品形态会有一个质的理解。后面再去看任何AI产品的界面，你会下意识地去想它的消息模型怎么设计、流式状态怎么管理、工具调用怎么呈现——能有这种感觉，说明你已经在用AI应用前端的思维思考了。