1. 这个学习计划到底在解决什么问题先把话说在前头市面上打着“AI 前端”旗号的课程和路线图我翻过的没有一百也有八十绝大多数犯的是同一个毛病——把“AI 应用前端”和“传统前端”混为一谈或者干脆把它讲成“调个 API 就完事”。这两种理解都会让你在真正上手项目时卡死。“AI 应用前端工程师”这个岗位本质上是站在大模型能力和用户交互界面之间的那个人。你不需要去训练模型也不需要懂反向传播的数学推导但你必须清楚一个流式输出的对话界面怎么做到不卡顿、一个 AI Agent 的执行过程怎么可视化、用户上传的图片在送进模型之前前端要做哪些预处理、多轮对话的上下文怎么在客户端做裁剪和缓存。这些东西传统前端教程里一个字都不会提纯 AI 算法教程里也不会讲。所以这份三个月学习计划的核心目标很明确让你从“会写页面的前端”变成“能把大模型能力包装成可用产品的工程师”。它适合三类人——有前端基础想转型的、做全栈想补 AI 交互这块短板的、以及产品/测试岗想理解 AI 应用落地细节的。三个月不算长但如果路线对了足够你独立做出一个像样的 AI 应用 Demo 并理解背后的每一个决策。我下面拆解的这套路线不是拍脑袋想出来的是我自己带过几轮人、也踩过不少坑之后沉淀下来的。每个阶段该学什么、为什么这么排、哪些地方最容易翻车我都会讲透。2. 三个月路线的整体设计与排期逻辑2.1 为什么是“三个月”而不是六周或半年先回答一个很多人会问的问题三个月这个周期是怎么定的。六周太短你连流式响应和普通请求的区别都还没吃透就结束了半年又太长大部分人会在第三个月开始懈怠而且 AI 领域的技术栈迭代快拖太久前面学的东西可能已经换了写法。三个月的合理性在于它刚好能切成三个清晰的阶段每个阶段四周左右每阶段都有一个可交付的产物。这很重要——学习计划最怕的就是“学了一堆但什么都没做出来”。我设计的每个阶段结束时你手里都应该有一个能跑起来、能给别人演示的东西。具体排期是这样的阶段时间核心目标交付产物第一阶段第 1-4 周打通前端与大模型的基础链路一个支持流式输出的对话页面第二阶段第 5-8 周掌握 AI 应用的核心交互模式一个带上下文管理和文件上传的对话应用第三阶段第 9-12 周完成 Agent 可视化与工程化一个可演示的 Agent 工作流前端这个表格你先记在心里后面每一节我都会展开讲每个阶段具体做什么、为什么这么安排。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 模式偶尔丢字数据块边界处理错误检查 buffer 拼接逻辑流中断无提示未处理连接异常添加错误捕获和重试机制页面卡顿每次更新都触发全量重渲染优化状态更新粒度使用 memo其中“偶尔丢字”这个我重点说一下。它的表现是大部分时候正常但偶尔少一两个字很难复现。根因通常是多字节字符比如中文被切分在了两个数据块之间。TextDecoder的{ stream: true }参数就是解决这个问题的它会把不完整的多字节序列缓存起来等后续字节到了再一起解码。如果你手动用String.fromCharCode之类的处理就很容易出这个问题。6.2 上下文管理的踩坑记录上下文这块我踩过最深的坑是消息顺序错乱。有一次用户反馈模型答非所问排查发现是并发请求导致历史消息的顺序乱了。用户快速发了两条消息两个请求几乎同时发出第二个请求带的历史里没有第一条消息的回复模型就懵了。解决办法是串行化请求或者在前端维护一个请求队列。用户发送消息后如果上一条还在处理中要么禁用发送按钮要么把新消息排队。我倾向于禁用发送按钮加一个明确的提示让用户知道需要等待。另一个坑是上下文超长导致的截断。不同模型的上下文窗口大小不一样你不能假设它无限大。前端最好能估算 token 数量接近上限时主动裁剪并提示用户。粗略估算的话中文大约一个字一个 token英文大约四个字符一个 token实际会有偏差但够用了。6.3 我个人的几条实操心得最后分享几条我自己的经验都是文档里不会写的。第一先跑通再优化。我见过太多人在第一阶段就纠结“用哪个状态管理库”“要不要上 SSR”结果两周过去了还没跑通一个完整的请求。先用最笨的办法跑通有了体感之后再重构效率高得多。第二多准备几个测试用的提示词。开发过程中你需要反复测试准备一组覆盖不同场景的提示词——短的、长的、带格式要求的、需要多轮追问的。这样每次改完代码能快速验证有没有回归问题。第三关注模型的返回格式稳定性。有些模型在流式输出时开头会带一些特殊标记或者结尾的格式和中间不一样。你的解析逻辑要能容错不能假设格式永远一致。我一般会在解析层加一层清洗把明显的标记去掉。第四界面上的等待反馈要分级。请求发出后 300 毫秒内没响应显示一个轻量的加载指示超过 3 秒显示更明确的“正在思考”提示超过 10 秒给用户一个取消的选项。这种分级的反馈设计能显著降低用户的焦虑感。这套计划我自己跑过一遍也看着别人跑过几遍。三个月能不能达到“能独立做 AI 应用前端”的水平取决于你每周实际投入的时间。如果每周能保证 15 小时以上的有效学习按这个路线走下来做出一个能演示、能讲清楚技术决策的项目是没问题的。如果时间更少那就把周期拉长但阶段划分和每阶段的交付物不要变——有交付物才有正反馈有正反馈才撑得下去。 
长河君 · 2026/11/2 8:30:47 · 阅读 1.2k AI应用前端工程师三个月进阶路线：从流式输出到Agent可视化
1. 这个学习计划到底在解决什么问题先把话说在前头市面上打着“AI 前端”旗号的课程和路线图我翻过的没有一百也有八十绝大多数犯的是同一个毛病——把“AI 应用前端”和“传统前端”混为一谈或者干脆把它讲成“调个 API 就完事”。这两种理解都会让你在真正上手项目时卡死。“AI 应用前端工程师”这个岗位本质上是站在大模型能力和用户交互界面之间的那个人。你不需要去训练模型也不需要懂反向传播的数学推导但你必须清楚一个流式输出的对话界面怎么做到不卡顿、一个 AI Agent 的执行过程怎么可视化、用户上传的图片在送进模型之前前端要做哪些预处理、多轮对话的上下文怎么在客户端做裁剪和缓存。这些东西传统前端教程里一个字都不会提纯 AI 算法教程里也不会讲。所以这份三个月学习计划的核心目标很明确让你从“会写页面的前端”变成“能把大模型能力包装成可用产品的工程师”。它适合三类人——有前端基础想转型的、做全栈想补 AI 交互这块短板的、以及产品/测试岗想理解 AI 应用落地细节的。三个月不算长但如果路线对了足够你独立做出一个像样的 AI 应用 Demo 并理解背后的每一个决策。我下面拆解的这套路线不是拍脑袋想出来的是我自己带过几轮人、也踩过不少坑之后沉淀下来的。每个阶段该学什么、为什么这么排、哪些地方最容易翻车我都会讲透。2. 三个月路线的整体设计与排期逻辑2.1 为什么是“三个月”而不是六周或半年先回答一个很多人会问的问题三个月这个周期是怎么定的。六周太短你连流式响应和普通请求的区别都还没吃透就结束了半年又太长大部分人会在第三个月开始懈怠而且 AI 领域的技术栈迭代快拖太久前面学的东西可能已经换了写法。三个月的合理性在于它刚好能切成三个清晰的阶段每个阶段四周左右每阶段都有一个可交付的产物。这很重要——学习计划最怕的就是“学了一堆但什么都没做出来”。我设计的每个阶段结束时你手里都应该有一个能跑起来、能给别人演示的东西。具体排期是这样的阶段时间核心目标交付产物第一阶段第 1-4 周打通前端与大模型的基础链路一个支持流式输出的对话页面第二阶段第 5-8 周掌握 AI 应用的核心交互模式一个带上下文管理和文件上传的对话应用第三阶段第 9-12 周完成 Agent 可视化与工程化一个可演示的 Agent 工作流前端这个表格你先记在心里后面每一节我都会展开讲每个阶段具体做什么、为什么这么安排。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 模式偶尔丢字数据块边界处理错误检查 buffer 拼接逻辑流中断无提示未处理连接异常添加错误捕获和重试机制页面卡顿每次更新都触发全量重渲染优化状态更新粒度使用 memo其中“偶尔丢字”这个我重点说一下。它的表现是大部分时候正常但偶尔少一两个字很难复现。根因通常是多字节字符比如中文被切分在了两个数据块之间。TextDecoder的{ stream: true }参数就是解决这个问题的它会把不完整的多字节序列缓存起来等后续字节到了再一起解码。如果你手动用String.fromCharCode之类的处理就很容易出这个问题。6.2 上下文管理的踩坑记录上下文这块我踩过最深的坑是消息顺序错乱。有一次用户反馈模型答非所问排查发现是并发请求导致历史消息的顺序乱了。用户快速发了两条消息两个请求几乎同时发出第二个请求带的历史里没有第一条消息的回复模型就懵了。解决办法是串行化请求或者在前端维护一个请求队列。用户发送消息后如果上一条还在处理中要么禁用发送按钮要么把新消息排队。我倾向于禁用发送按钮加一个明确的提示让用户知道需要等待。另一个坑是上下文超长导致的截断。不同模型的上下文窗口大小不一样你不能假设它无限大。前端最好能估算 token 数量接近上限时主动裁剪并提示用户。粗略估算的话中文大约一个字一个 token英文大约四个字符一个 token实际会有偏差但够用了。6.3 我个人的几条实操心得最后分享几条我自己的经验都是文档里不会写的。第一先跑通再优化。我见过太多人在第一阶段就纠结“用哪个状态管理库”“要不要上 SSR”结果两周过去了还没跑通一个完整的请求。先用最笨的办法跑通有了体感之后再重构效率高得多。第二多准备几个测试用的提示词。开发过程中你需要反复测试准备一组覆盖不同场景的提示词——短的、长的、带格式要求的、需要多轮追问的。这样每次改完代码能快速验证有没有回归问题。第三关注模型的返回格式稳定性。有些模型在流式输出时开头会带一些特殊标记或者结尾的格式和中间不一样。你的解析逻辑要能容错不能假设格式永远一致。我一般会在解析层加一层清洗把明显的标记去掉。第四界面上的等待反馈要分级。请求发出后 300 毫秒内没响应显示一个轻量的加载指示超过 3 秒显示更明确的“正在思考”提示超过 10 秒给用户一个取消的选项。这种分级的反馈设计能显著降低用户的焦虑感。这套计划我自己跑过一遍也看着别人跑过几遍。三个月能不能达到“能独立做 AI 应用前端”的水平取决于你每周实际投入的时间。如果每周能保证 15 小时以上的有效学习按这个路线走下来做出一个能演示、能讲清楚技术决策的项目是没问题的。如果时间更少那就把周期拉长但阶段划分和每阶段的交付物不要变——有交付物才有正反馈有正反馈才撑得下去。