企业官网建设流程全解析

1. 这个学习计划到底在解决什么问题

先把话说在前头：市面上打着“AI 前端”旗号的课程和路线图，我翻过的没有一百也有八十，绝大多数犯的是同一个毛病——把“AI 应用前端”和“传统前端”混为一谈，或者干脆把它讲成“调个 API 就完事”。这两种理解都会让你在真正上手项目时卡死。

“AI 应用前端工程师”这个岗位，本质上是站在大模型能力和用户交互界面之间的那个人。你不需要去训练模型，也不需要懂反向传播的数学推导，但你必须清楚：一个流式输出的对话界面怎么做到不卡顿、一个 AI Agent 的执行过程怎么可视化、用户上传的图片在送进模型之前前端要做哪些预处理、多轮对话的上下文怎么在客户端做裁剪和缓存。这些东西，传统前端教程里一个字都不会提，纯 AI 算法教程里也不会讲。

所以这份三个月学习计划的核心目标很明确：让你从“会写页面的前端”变成“能把大模型能力包装成可用产品的工程师”。它适合三类人——有前端基础想转型的、做全栈想补 AI 交互这块短板的、以及产品/测试岗想理解 AI 应用落地细节的。三个月不算长，但如果路线对了，足够你独立做出一个像样的 AI 应用 Demo 并理解背后的每一个决策。

我下面拆解的这套路线，不是拍脑袋想出来的，是我自己带过几轮人、也踩过不少坑之后沉淀下来的。每个阶段该学什么、为什么这么排、哪些地方最容易翻车，我都会讲透。

2. 三个月路线的整体设计与排期逻辑

2.1 为什么是“三个月”而不是六周或半年

先回答一个很多人会问的问题：三个月这个周期是怎么定的。六周太短，你连流式响应和普通请求的区别都还没吃透就结束了；半年又太长，大部分人会在第三个月开始懈怠，而且 AI 领域的技术栈迭代快，拖太久前面学的东西可能已经换了写法。

三个月的合理性在于它刚好能切成三个清晰的阶段，每个阶段四周左右，每阶段都有一个可交付的产物。这很重要——学习计划最怕的就是“学了一堆但什么都没做出来”。我设计的每个阶段结束时，你手里都应该有一个能跑起来、能给别人演示的东西。

具体排期是这样的：

这个表格你先记在心里，后面每一节我都会展开讲每个阶段具体做什么、为什么这么安排。

2.2 阶段划分背后的取舍逻辑

有人可能会问，为什么不先学 AI 理论再学前端实现。我的答案是：对于前端工程师转型，理论必须服务于实现，而不是反过来。你不需要先搞懂 Transformer 的注意力机制才能写一个对话界面，但你需要知道 token 是什么，因为你的输入框字数限制、上下文裁剪策略、甚至计费展示都跟它直接相关。

所以我的排期逻辑是“用到什么学什么，学完立刻用”。第一阶段你会接触到 API 调用和流式传输，那就只学这两块涉及的概念；第二阶段你要处理多轮对话，那就去理解上下文窗口和消息角色；第三阶段做 Agent 可视化，再去了解工具调用和任务编排。这种“按需学习”的方式，比先啃一个月理论再动手要高效得多，也更符合前端工程师的思维习惯。

另一个取舍是工具链的选择。我在计划里会推荐具体的框架和库，但你要明白推荐的理由，而不是照抄。比如流式输出这块，早期大家用 EventSource，后来发现 fetch 配合 ReadableStream 更灵活，现在很多项目直接用各家 SDK 封装好的方案。我会告诉你每个方案的适用场景，你根据自己项目的情况选。

3. 第一阶段：打通前端与大模型的基础链路

3.1 第一周该装什么、配什么

第一周的目标很单纯：让浏览器里的一段文字，变成模型返回的一段文字，并且是逐字蹦出来的那种。听起来简单，但这里面的坑比你想象的多。

环境准备上，我建议直接用Vite + React + TypeScript这套组合。原因很实际：Vite 的冷启动和热更新快，你调界面的时候不用等；TypeScript 在对接 API 时能帮你提前发现字段拼写错误，AI 接口返回的 JSON 结构往往比较深，没有类型提示很容易写错。如果你习惯 Vue 也完全可以，核心逻辑是一样的。

依赖方面，第一周你只需要装一个 HTTP 请求库。我个人的习惯是用原生的fetch，因为流式响应的处理最终都要落到ReadableStream上，用 axios 反而多一层封装。当然如果你团队统一用 axios，那也没问题，只是处理流的时候要绕一下。

配置上有一个关键点：API 密钥绝对不能写在前端代码里。这是新手最容易犯的致命错误。正确做法是在本地起一个轻量的代理服务，或者用框架提供的服务端路由来转发请求。Vite 的话可以用server.proxy配置，Next.js 直接用 Route Handler。这一步不做，你的密钥等于公开在浏览器里，任何人打开开发者工具都能看到。

提示：第一周就要养成“密钥不进前端”的习惯，后面做任何项目都受益。我见过太多人 Demo 阶段图省事把密钥写死，结果上线前忘了改。

3.2 流式输出：从“等半天”到“逐字蹦”

流式输出是 AI 应用前端的第一个技术门槛，也是体验差异最大的地方。传统请求是“发出去、等、一次性拿到全部结果”，而大模型生成一段话可能要十几秒，如果等全部生成完再显示，用户会以为页面卡死了。流式输出就是让文字像打字机一样一个个冒出来。

实现原理其实不复杂。服务端返回的不再是一个完整的 JSON，而是一串按行分隔的数据块，每个块里包含一小段新生成的文本。前端拿到这些块之后，解析出文本内容，追加到界面上。关键在于解析逻辑要健壮——数据块可能被截断、可能包含空行、可能有特殊的前缀标记。

我用一个简化的例子说明解析思路：

const response = await fetch('/api/chat', { method: 'POST', body: JSON.stringify({ message }) }); const reader = response.body.getReader(); const decoder = new TextDecoder(); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n'); buffer = lines.pop() || ''; for (const line of lines) { if (!line.trim()) continue; // 解析每一行的数据，提取文本内容 const text = parseChunk(line); appendToUI(text); } }

这段代码里有个细节值得说：buffer的作用是处理“半个数据块”的情况。网络传输不会保证每次read()返回的都是完整的一行，可能一行数据被切成两次返回。所以你要把最后不完整的那部分留在 buffer 里，等下一块数据来了再拼起来。这个坑我当初踩过，表现就是偶尔出现乱码或者丢字，排查了半天才发现是没处理截断。

3.3 第一阶段的验收标准与常见翻车点

第一阶段结束时，你应该能做出一个页面：有一个输入框，输入问题后点击发送，页面上逐字显示模型的回答。听起来简单，但验收的时候我会看这几个细节：

• 流式输出过程中，页面是否保持可交互，输入框能不能继续输入
• 如果用户连续发送多条消息，前一条的流是否被正确中断
• 网络异常时，界面是否有合理的错误提示，而不是白屏
• 滚动条是否自动跟随最新内容，但用户手动上滑后不再强制拉回

最后一条特别容易被忽略。自动滚动做不好，用户体验会很差——你正在往上翻看历史内容，结果新内容一来页面又被拽到底部。正确做法是判断用户当前是否在底部附近，只有在底部时才自动滚动。

第一阶段的常见翻车点我列一下：密钥泄露、流式解析丢字、并发请求没做中断处理、错误状态没处理导致白屏。这几个问题你提前注意，能省下大量调试时间。

4. 第二阶段：掌握 AI 应用的核心交互模式

4.1 多轮对话的上下文管理

进入第二个月，你要处理的核心问题是“记忆”。单轮对话很简单，问一句答一句。但真实应用里，用户会追问、会指代、会切换话题，模型需要知道之前聊了什么才能给出合理回答。

上下文管理的本质是：每次请求都要把历史消息一起发给模型。但这里有个硬约束——模型的上下文窗口是有限的，你不能无限往里面塞历史记录。所以前端需要做裁剪策略。

常见的裁剪方式有三种。第一种是滑动窗口，只保留最近 N 条消息，简单粗暴但可能丢掉重要信息。第二种是摘要压缩，把较早的对话让模型总结成一段话，用摘要代替原文。第三种是关键信息提取，把用户提到的关键实体（名字、数字、偏好）单独存起来，每次请求时作为系统提示注入。

我实际项目里最常用的是滑动窗口加关键信息提取的组合。滑动窗口保证近期对话的完整性，关键信息提取保证长期记忆不丢失。具体保留多少条，要看你的场景——客服类应用可能需要保留更多轮次，而工具类应用三五轮就够了。

这里有个实操细节：消息的角色标记要正确。对话历史里每条消息都有角色，通常是 system、user、assistant 三种。system 用来设定模型的行为准则，user 是用户输入，assistant 是模型回复。如果你把角色搞混了，模型的行为会变得很奇怪。我见过有人把历史消息全部标成 user，结果模型开始模仿用户的语气跟自己对话。

4.2 文件上传与多模态输入的前端处理

现在的 AI 应用早就不只是文字对话了，图片、PDF、音频都是常见输入。前端在这块要做的事情比想象中多。

以图片为例，用户选了一张 5MB 的照片，你不能直接原图上传。原因有两个：一是传输慢，二是很多模型对图片尺寸和大小有硬限制。所以前端需要做压缩和格式转换。用 Canvas 把图片绘制到指定尺寸，再导出为合适的格式，这个过程可以在浏览器里完成，不需要服务端参与。

function compressImage(file, maxWidth = 1024, quality = 0.8) { return new Promise((resolve) => { const img = new Image(); img.onload = () => { const canvas = document.createElement('canvas'); const scale = Math.min(1, maxWidth / img.width); canvas.width = img.width * scale; canvas.height = img.height * scale; const ctx = canvas.getContext('2d'); ctx.drawImage(img, 0, 0, canvas.width, canvas.height); canvas.toBlob(resolve, 'image/jpeg', quality); }; img.src = URL.createObjectURL(file); }); }

PDF 的处理稍微复杂一些，通常需要服务端配合做文本提取，前端负责上传和进度展示。这里要注意的是上传进度反馈，大文件上传如果没有进度条，用户会以为卡住了。用XMLHttpRequest的upload.onprogress或者 fetch 配合流式读取都能实现。

还有一个容易被忽略的点：文件预览。用户选了文件之后，界面上要能看到自己选了什么，图片显示缩略图，PDF 显示文件名和页数。这个体验细节做好了，整个应用的专业感会提升一个档次。

4.3 第二阶段必须搞定的状态管理

到了这个阶段，你的应用状态开始变复杂了：对话列表、当前会话、上传的文件、加载状态、错误信息、用户配置……如果还用第一阶段的useState到处传，代码会乱成一团。

我的建议是在第二阶段引入一个轻量的状态管理方案。不一定要上 Redux 这种重型的，Zustand 或者 Jotai 对中小型 AI 应用来说足够了。核心是把会话状态和UI 状态分开管理。会话状态包括消息列表、上下文、模型参数；UI 状态包括侧边栏开合、当前选中的会话、输入框内容。

分开的好处是，当你做“切换会话”这个操作时，只需要替换会话状态，UI 状态保持不变。如果混在一起，切换会话时可能会把侧边栏的开合状态也重置了，体验很割裂。

另外，消息的本地持久化也建议在这个阶段加上。用 IndexedDB 或者 localStorage 把对话存下来，刷新页面不丢失。这个功能实现起来不难，但对用户体验的提升非常明显。注意存储时要考虑容量限制，历史消息太多的话要做清理策略。

5. 第三阶段：Agent 可视化与工程化收尾

5.1 Agent 执行过程的可视化怎么做

第三个月进入进阶内容。AI Agent 和普通对话的区别在于，Agent 会调用工具、分步骤执行任务。比如你让它“帮我查一下明天北京的天气然后推荐穿什么”，它可能会先调用天气查询工具，拿到结果后再调用推荐逻辑，最后汇总输出。

前端在这块的价值是把执行过程透明化。用户需要知道 Agent 现在在干什么、调用了什么工具、拿到了什么结果。如果只是转圈等待，用户会焦虑；如果能看到“正在查询天气……已获取结果……正在生成建议”，信任感会强很多。

实现上，通常用步骤列表或者时间线来展示。每个步骤有状态（等待中、执行中、已完成、失败），有输入输出摘要。数据来源是服务端推送的事件流，前端根据事件类型更新对应步骤的状态。

这里有个设计上的取舍：展示粒度。太粗了用户看不懂，太细了信息过载。我的经验是，每个工具调用展示为一步，步骤内可以折叠查看详细参数和返回结果。默认折叠，用户想看细节时再展开。

5.2 性能优化：AI 应用前端的专属课题

AI 应用有一些独特的性能问题，传统前端优化手段不一定管用。我挑几个典型的讲。

长列表渲染。对话轮次多了之后，消息列表可能上百条。如果全部渲染，滚动会卡。解决方案是虚拟滚动，只渲染可视区域内的消息。但 AI 应用有个特殊之处：流式输出时最后一条消息在不断变化，虚拟滚动要处理好这个动态项。

Markdown 渲染开销。模型的回复通常包含 Markdown 格式，代码块、表格、列表都有。每次流式更新都重新解析整个 Markdown 会很耗性能。优化思路是只解析新增的部分，或者用增量渲染的方式。有些库支持流式 Markdown 解析，可以关注一下。

请求取消与竞态处理。用户快速切换会话或者连续发送消息时，旧请求可能还在进行中。如果不取消，旧请求的返回可能会覆盖新请求的结果。用AbortController来管理请求的生命周期，切换时主动取消。

5.3 从 Demo 到可交付：工程化清单

三个月结束时，你的项目应该具备一定的工程化水准。我列一个清单，你可以对照检查：

• 环境变量管理：密钥、接口地址通过环境变量注入，不同环境用不同配置
• 错误边界：组件崩溃不会导致整个页面白屏
• 加载状态：所有异步操作都有 loading 反馈
• 空状态：没有数据时显示引导文案，而不是空白
• 响应式布局：至少在常见屏幕尺寸下可用
• 基础的可访问性：键盘可操作、对比度达标

这些不是锦上添花，而是区分“练手项目”和“能拿出手的项目”的分界线。面试或者演示的时候，这些细节往往比功能本身更能体现你的工程素养。

6. 常见问题与排查技巧实录

6.1 流式输出相关的典型故障

流式输出这块的问题最集中，我整理了一个速查表：

其中“偶尔丢字”这个我重点说一下。它的表现是大部分时候正常，但偶尔少一两个字，很难复现。根因通常是多字节字符（比如中文）被切分在了两个数据块之间。TextDecoder的{ stream: true }参数就是解决这个问题的，它会把不完整的多字节序列缓存起来，等后续字节到了再一起解码。如果你手动用String.fromCharCode之类的处理，就很容易出这个问题。

6.2 上下文管理的踩坑记录

上下文这块我踩过最深的坑是消息顺序错乱。有一次用户反馈模型答非所问，排查发现是并发请求导致历史消息的顺序乱了。用户快速发了两条消息，两个请求几乎同时发出，第二个请求带的历史里没有第一条消息的回复，模型就懵了。

解决办法是串行化请求，或者在前端维护一个请求队列。用户发送消息后，如果上一条还在处理中，要么禁用发送按钮，要么把新消息排队。我倾向于禁用发送按钮加一个明确的提示，让用户知道需要等待。

另一个坑是上下文超长导致的截断。不同模型的上下文窗口大小不一样，你不能假设它无限大。前端最好能估算 token 数量，接近上限时主动裁剪并提示用户。粗略估算的话，中文大约一个字一个 token，英文大约四个字符一个 token，实际会有偏差但够用了。

6.3 我个人的几条实操心得

最后分享几条我自己的经验，都是文档里不会写的。

第一，先跑通再优化。我见过太多人在第一阶段就纠结“用哪个状态管理库”“要不要上 SSR”，结果两周过去了还没跑通一个完整的请求。先用最笨的办法跑通，有了体感之后再重构，效率高得多。

第二，多准备几个测试用的提示词。开发过程中你需要反复测试，准备一组覆盖不同场景的提示词——短的、长的、带格式要求的、需要多轮追问的。这样每次改完代码能快速验证有没有回归问题。

第三，关注模型的返回格式稳定性。有些模型在流式输出时，开头会带一些特殊标记，或者结尾的格式和中间不一样。你的解析逻辑要能容错，不能假设格式永远一致。我一般会在解析层加一层清洗，把明显的标记去掉。

第四，界面上的等待反馈要分级。请求发出后 300 毫秒内没响应，显示一个轻量的加载指示；超过 3 秒，显示更明确的“正在思考”提示；超过 10 秒，给用户一个取消的选项。这种分级的反馈设计，能显著降低用户的焦虑感。

这套计划我自己跑过一遍，也看着别人跑过几遍。三个月能不能达到“能独立做 AI 应用前端”的水平，取决于你每周实际投入的时间。如果每周能保证 15 小时以上的有效学习，按这个路线走下来，做出一个能演示、能讲清楚技术决策的项目是没问题的。如果时间更少，那就把周期拉长，但阶段划分和每阶段的交付物不要变——有交付物才有正反馈，有正反馈才撑得下去。