过去大半年我陆续帮不少前端朋友看过简历、聊过转型方向大家最焦虑的问题出奇一致AI 浪潮来了前端工程师会不会被拍在沙滩上我的观点一直比较明确前端不会消失但“前端工程师”这个岗位的职能边界一定会被重写。当 AI 能力从页面里的一个辅助功能变成整个产品的核心交互入口时一种叫AI 应用前端工程师的角色正在浮出水面——它不是“会调接口的前端”而是能用工程化手段把大模型能力包装成真正可用、可商用产品体验的人。这篇文章把我总结的三个月学习计划完整写出来适合两类人一是已经在写前端、想往 AI 应用方向靠的开发者二是有点编程基础、想直接切入 AI 应用开发的新人。计划按周拆解有阶段目标、有实战路径、也有我踩过的坑你可以直接照着排。1. AI 应用前端的岗位画像和传统前端到底差在哪很多人以为 AI 应用前端 普通前端 调一下大模型 API把这个想简单了。传统前端处理的核心是“确定状态下的数据展示与用户操作”表单、列表、详情页、弹窗交互路径基本可控而 AI 应用前端处理的是“不确定状态下的流式输出、生成过程可视化、多轮上下文管理、甚至多个模型协同”。这带来的是整个技术栈、思维方式、交付标准的差异。1.1 交互模式的变化从表单到对话与生成传统 Web 产品里用户点按钮前端发请求后端返回 JSON前端渲染。整个过程是“请求-响应”的闭环。但 AI 应用的核心交互变成了这样用户输入一段自然语言模型不是一次性返回结果而是流式吐出 token字符前端要实时渲染同一个输入模型可能给出多个版本的答案还可能需要调用工具、检索资料再汇总回答多轮对话里前端不仅要展示消息还要维护上下文状态、处理上下文超长、做会话持久化Agent智能体类产品还需要前端展示“正在调用工具”“检索中”“任务执行进度”等过程性信息。这些交互在传统前端里基本没有对应的最佳实践。你很难用一套 antd Table 把“模型生成长达两千字回答并逐字刷新”的过程优雅地呈现出来。1.2 典型产品形态与技能需求从行业里已经跑出的产品形态看AI 应用前端常见的落地方向包括AI 对话助手、知识库问答系统RAG、代码生成工具Copilot 类、Agent 工作台、AI 视频/短剧生成工具的前端编排界面、本地部署模型的 Web 控制台等。上手这些项目需要的技能清单和传统前端对比一下技能维度传统前端AI 应用前端框架选型React/Vue 均可深度使用 React/Next.js 生态者优先Vue 也有空间数据交互普通 fetch/axiosfetch ReadableStream流式读取、SSE、WebSocket状态管理通用业务状态消息状态机生成中/中断/失败、上下文仓库、任务状态渲染重点确定性数据展示流式文本、增量渲染、Markdown/代码高亮、过程卡片后端能力通常不关心至少要懂 API Key 保护、请求转发、鉴权核心业务认知业务逻辑LLM 运行机制、上下文窗口、Prompt 行为、工具调用所以如果你只按传统前端的知识体系去学做到薪资提升和岗位转型天花板非常明显。AI 应用前端要啃的是“模型和能力接入”这一层。1.3 对前端工程师是机会还是威胁我的判断是机会大于威胁。模型本身给的是“毛坯能力”用户需要的是“成品体验”。把流式输出、上下文管理、工具调用过程、多模型切换做得让用户无感、稳定、好用这是非常典型的前端工程问题不是模型能替代的。相反如果你只会写固定模板页面那 AI 写代码工具确实会替代你。方向其实是清楚的往前端的技术深水区走往 AI 应用的工程化走。2. 三个月总规划阶段划分、学习节奏与验收标准先说结论三个月时间按全职学习每天 6~8 小时算比较从容如果是上班族业余学每天 3~4 小时可以把战线拉长到四个月但路径不变。整体分为三个阶段第一个月重构基础栈第二个月打通 AI 能力接入第三个月做三个实战项目并部署上线。2.1 阶段任务和每周目标我习惯按“周”为单位定计划因为按天排太容易崩按“月”又太模糊。三阶段大致这样分布第 1~4 周基础栈重构死磕 React Next.js TypeScript目标是能独立搭出符合 AI 应用形态的前端骨架第 5~8 周AI 能力接入掌握流式输出、上下文管理、Function Calling、Agent 界面设计把 API 能力完整接进前端第 9~12 周三个实战项目覆盖对话类、RAG 知识库类、Agent 工作台类部署上线写技术总结。每周留出半天做复盘和补漏这个非常关键。AI 应用前端要学的点很碎流式渲染、请求取消、类型收窄、Markdown 渲染、高亮主题任何一个点卡住都可能消耗半天不留复盘时间很容易被挫败感带崩。2.2 学习策略先窄后宽先通再深三个月听起来不短但 AI 应用前端涉及的知识面确实宽。最容易翻车的就是“什么都要学什么都只学皮毛”。我的策略是先窄后宽。第一个月只深度打通一条技术栈我推荐 React Next.js原因后面细说不要同时学 Vue、Angular也别去碰微前端、后端微服务这些暂时用不上的东西。把一个栈打穿提炼出通用的工程方法论第二个月接入 AI 能力时你才有余力处理真正的难点。技术栈确定以后资料选择也要收敛。不要收藏几百篇文章那只会制造“我学了很多”的幻觉。我的做法是每阶段只盯 1~2 本系统书或官方文档 2~3 个高质量开源项目源码。比如 React 阶段啃官方文档和几个 Next.js 官方示例AI 接入阶段重点读 Anthropic、OpenAI 的官方文档和开源 Agent 框架的源码。2.3 每个阶段的验收标准没有验收标准的学习计划等于白写。我给自己定的标准是可以量化的基础栈阶段不看教程的情况下用 Next.js 从零搭一个带路由、状态管理、API 转发、流式展示的聊天页骨架跑通并部署到线上AI 能力接入阶段能解释清楚 fetch 流式读取的每个 chunk 如何处理能处理中断、错误、token 超限能独立接入至少两个不同厂商的大模型 API实战阶段三个项目全都上线每个项目有完整的 README、架构图用文字表述也没关系和录屏 Demo。验收标准不是为了交作业而是让你每两周左右就能感受到“我真的能做出来东西”的正反馈。这一点在长周期自学里比任何激励都管用。3. 第一个月把基础栈重构成 AI 应用需要的形态如果你是纯新手第一个月会是最痛苦也最值得的一个月。如果你本来就有前端基础这个月不要跳过——重点是查漏补缺并且把思维从“做管理后台”切换到“做生成式交互”。3.1 为什么首选 React Next.jsAI 生态里前端框架的事实标准就是 React Next.js这基本没什么悬念。原因有三一是目前主流 AI 应用的参考代码、开源项目、组件库大多基于 React二是 Next.js 的 API Routes / Server Actions 天然适合做 API Key 保护层前端代码里不用暴露密钥三是流式渲染场景下React 的构建模型和生态里的 react-markdown、react-syntax-highlighter 等库支持度最好。如果你之前主要写 Vue我的建议不是让你一定放弃 Vue而是先认真评估一下目标岗位的 JD——目前看 AI 应用前端岗对 Next.js/React 的偏好明显更强相比之下 Vue 的机会少一些。保守打法是把 React 学起来Vue 作为第二技能别再花太多时间。3.2 必须打牢的四个硬点第一个月里最值得花时间的四个点TypeScript 类型收窄。AI 应用的接口数据结构非常不稳定一个字段可能是 string也可能为 null还可能干脆不存在。正确使用类型守卫、联合类型、泛型能让你在接大模型返回时少写几十个 if。请求层面的状态设计。不要再用简单的 loading boolean 来处理AI 应用里请求状态至少要有idle、pending、streaming、success、error、aborted。你需要在状态机层面想清楚这些状态怎么流转、UI 怎么反馈。Next.js 的 API Routes 和 Server Components。理解哪些代码跑在服务端哪些跑在客户端这直接决定你的 API Key 和敏感逻辑放哪里。基础渲染性能。流式刷新对 DOM 更新压力很大必须了解 React 的渲染调度、flushing 策略、列表 key 的精确使用。这个月先知道“这里有问题”第二个月接流式的时候再深挖。3.3 练手项目聊天界面骨架这个月不急着接大模型 API先搭一个“假聊天页面骨架”。数据用本地 mock 流式返回自己写一个异步生成器模拟 token 逐字输出。要实现的交互包括消息列表自动滚动、生成中的光标动画、Markdown 渲染、代码块复制按钮、停止生成按钮、会话历史切换。这个骨架做完你已经比很多只会写静态页面的前端强了因为你在为“真实生成式体验”做工程准备。我当时练手的骨架大概长这样左侧会话列表中间消息流底部输入框顶部模型选择下拉框。这些组件看着简单但每个都有细节消息列表滚动时要不要“锁定底部”用户上翻历史时是否暂停自动滚动生成过程中输入框是否锁定这些交互细节决定了产品的专业度而专业度恰恰是 AI 应用前端被低估的价值点。4. 第二个月AI 能力接入这是和通用前端真正拉开差距的地方这个月内容最硬核也是你在市场里区别于普通前端的关键。核心要做五件事接入 API、处理流式输出、管理上下文、理解 Function Calling/Agent、守住安全边界。4.1 先把大模型 API 的统一协议理解透市面上的大模型服务商很多但大多兼容 OpenAI 的 API 风格即 POST 一个 chat/completions 结构然后以 SSEServer-Sent Events方式回推数据流。我的建议是先拿最快能上手的平台跑通再横向对比其他平台。本地可以用 Ollama 之类的工具跑一个小模型接口也做成了兼容格式好处是免费、无审查限制调试方面更灵活。你需要熟悉的核心参数包括但不限于model模型名、messages消息数组、temperature采样温度、max_tokens生成上限、stream是否流式。对前端工程师来说messages和stream是两个心智负担最重的点消息数组就是你要维护的上下文而 stream 则决定你如何把网络数据流一点点渲染到页面上。4.2 流式输出是体验底线很多第一次做 AI 应用的人都会忽略流式等模型 10 秒后一次性吐出一整段回答——用户早就跑了。流式输出的技术方案主流是 SSE 或fetch ReadableStream前端要拿到的是“流里的增量文本”每收到一个 chunk 就更新一次页面。我强烈建议直接用fetch配合ReadableStream手动解析而不是找封装好的 SDK。原因有两个一是你能精确控制取消请求AbortController可以一次性把“停止生成”“超时中断”“组件卸载时清理”都处理掉二是很多真实场景需要同时对流式文本做额外处理比如累积 buffer、识别结束标记、提取增量内容。如果你用了 SDK这层控制力基本就丢了。流式渲染的性能问题会在这个月集中暴露。模型一秒钟可能吐出几十个 token如果每个 token 都触发 React 重新渲染整个消息列表必卡。务必要学的技术是只在最后一个消息节点做增量更新对历史消息做 memo 缓存同时可以引入一个小的 buffer 策略——几十毫秒内合并 DOM 更新而不是每次 token 都改。提示流式中断是必须自己处理的场景。用户点了“停止生成”后端连接要断开前端要保留已生成的部分并且把状态从 streaming 切到 aborted。这个状态不处理好用户就会遇到“还在转圈但永远没有结束”的假死体验。4.3 上下文管理AI 应用前端的隐形核心传统前端不管上下文因为后端早就查好数据了。但 AI 应用里你的聊天界面实际上就是“模型记忆的外化”。你需要设计一个消息管理器职责包括维护 messages 数组保证每一条消息结构完整role、content、时间戳、附加元数据计算 token 用量当接近模型上下文上限时自动触发截断或摘要压缩策略支持“重新生成”“编辑消息”后的消息分支逻辑建立会话持久化刷新页面后恢复历史上下文。我见过太多人把 messages 直接塞 useState 里结果上下文一长接口直接报错“超长”。这里其实有一个挺关键的“人机交互”设计问题到底要不要把系统提示词、检索结果、工具调用过程都给模型看前端如何定义这些内容的存储位置、展示位置和发送逻辑我建议第二个月专门花几天把“消息管理器”这个模块做好它是 AI 应用前端区别于传统前端的核心技术资产。4.4 Function Calling 与 Agent 界面的前端呈现当你开始做 Agent 类产品模型不再只是“聊天”它会请求调用工具。比如用户问“现在几点”模型回复一个工具调用请求前端需要执行获取时间的函数并把结果回传给模型。这个过程在前端界面里怎么呈现最简单的做法是“等待期间显示一张工具卡片”告诉用户模型正在处理什么。往上走一步你可以做任务卡片组模型连续调用多个工具前端按时间线展示每个调用的输入输出、耗时、状态。再往复杂做就是 Agent 工作台左侧任务列表右侧过程流顶部资源占用底部调试控制台。做这类界面时你的终极目标是让“黑盒推理过程”变得透明可理解这在产品体验上是一个极强的加分项。Function Calling 的接口结构不同厂商略有差异但处理思路一致前端维护一个工具定义清单把模型返回的工具调用解析成可执行指令执行完后把结果推回 messages。第二个月至少完整跑通一个工具调用链路包括一个前后端配合的计算工具和一个检索工具。4.5 安全边界密钥绝不能放前端这是接 API 时最严肃的红线。大模型 API 通常按 token 计费一旦密钥暴露轻则成本飙升重则完整对话内容对外泄露。正确的做法是前端只请求自家后端由 Next.js 的 API Routes 这类服务端接口保存密钥并转发大模型请求。前端环境变量里只放后端地址密钥放在服务端环境变量里。还要算好“内容安全”这笔账用户输入和模型输出都可能有恶意 prompt、注入攻击或不合规内容发布到公网之前建议加一层内容审核或接入合规过滤服务。这不是鼓励过度审查而是做线上产品的基本责任。5. 第三个月三个实战项目把技能串成产品能力理论基础再好没有拿得出手的项目面试官和用户都不认。第三个月做实操不贪多踏踏实实做完三个项目每个项目都能上线访问。5.1 项目一带流式输出的 AI 对话助手第一个项目把前两个月所有基础能力串起来多轮对话、流式渲染、Markdown、代码高亮、会话历史、停止生成、上下文超限处理。技术栈直接用 Next.js Tailwind CSS数据库可以先用 SQLite/本地 JSON 文件部署到 Vercel 这类平台就跑通了完整的开发闭环。验收标准连续对话 50 轮以上不卡死刷新页面能恢复历史流式输出过程中页面不掉帧手机端访问布局正常。这个项目虽然“简单”但它是一切 AI 应用的地基值得投入一周认真打磨。5.2 项目二知识库问答RAG前端第二个项目做 RAG 应用。本质是用户上传文档系统把文档切片、向量化存入向量库用户提问时检索相关片段拼进 Prompt再交给模型生成。前端的职责包括上传文件的进度反馈大文件分片、解析状态、索引状态文档管理列表删除、重新索引、查看切片对话过程中展示“引用了哪些文档片段”可点击跳转原文引用来源的悬停卡片、置信度标识。RAG 前端的核心难点是“检索过程和生成过程的可视化”。用户问一个问题系统是不是真的查到了相关材料前端要把“命中哪些片段”“模型基于哪些内容生成了回答”展示清楚用户才会信任产品。这个信任感不是模型给的是前端交互设计给的。5.3 项目三Agent 工作台第三个项目直接挑战最复杂的形态Agent 工作台。界面至少包含主对话区、工具调用卡片列表、任务执行轨迹时间线、上下文管理面板、模型配置区。功能上支持“自定义工具开关”“多智能体任务编排”“人工确认节点”。这个项目的学习价值在于让你理解当模型能力变得可组合、可编排时前端界面本身就是产品逻辑的载体。你不再只是展示模型输出而是在设计人类与多个模型/工具之间的协作界面。做完这个项目你对 AI 应用前端的理解基本能覆盖市面上绝大多数相关岗位的要求。每个项目做完后记得输出一篇简短的技术文档讲讲架构选择、踩过的坑、性能数据。这不仅是学习复盘更是将来求职时有分量的作品展示。6. 一些踩过才懂的经验性能、成本、体验细节最后一个月我其实只做了三件事把三个项目打磨干净、把技术文档补齐、把面试中常见问题系统梳理一遍。这个阶段踩的坑最多也最有价值分享几个代表性的。6.1 渲染性能别让流式输出拖垮页面前面提过每个 token 都 setState 是会卡的。实际测量时你会发现一个 2000 字的回答如果一次性渲染和逐字渲染并频繁更新 DOM帧率差异会非常大。解决方案在工程上无非三条路一是 React 的useDeferredValue和memo组合减少渲染频率二是自己做一个批量刷新 buffer比如 50ms 内的 token 合并为一次 DOM 更新三是只在消息末尾节点做 render历史消息全部组件化缓存。但要注意过度优化也是坑先测再优化比什么都重要。6.2 成本控制上下文膨胀是隐形杀手模型按 token 计费而多轮对话的上下文会不断膨胀。80% 的新手都会忽略这个问题的严重性。前端能做的成本控制包括会话长度可视化告诉用户当前已消耗多少 token、自动触发“压缩上下文”把历史对话交给模型生成摘要、无操作自动清理临时会话、限制单条消息最大长度。别小看这个很多团队的第一笔大模型账单就是这么爆掉的。6.3 竞态问题迟到的请求会覆盖新结果用户连续提问时网络波动可能导致“旧请求的响应比新请求晚到”页面内容被旧结果覆盖这是非常典型的竞态问题。解决方案就是所有请求都带上AbortController并且用请求序号或请求 ID 做校验——只有最新的请求才被允许写入页面状态。这个点很多做了多年的前端也会忽略但在 AI 应用里因为请求时长长、网络不可控几乎必然会遇到。6.4 给不同基础的人调整计划如果你是纯新人且之前没接触过前端三个月的计划请自动放宽到五个月甚至半年。前两周一定会有“连环境都配不明白”的挫败期这很正常。你可以在第 0 周先补 HTML/CSS/JavaScript 基础再按阶段走。如果你本身是后端或者算法工程师React/Next.js 部分可以压缩到三周把精力重点压在流式处理、上下文管理和 Function Calling 的链路理解上你的工程能力和数据结构基础在 AI 应用前端方向是很大的优势。三个月走完之后我自己最大的体会是这个方向不是让你把前端抛弃掉而是让你把人机交互的边界往前推了一大步——从“展示数据”变成“呈现智能”。模型负责生成内容你负责生成信任。把流式渲染调到行云流水、把上下文管得省心省力、把 Agent 的思考过程画得清清楚楚这些能力一旦长在身上不管 AI 工具怎么迭代你都有不可替代的位置。如果你正卡在某个具体环节——比如流式渲染调不通、上下文超限处理不好、部署时 API 的环境变量配置报错——建议直接回到对应的官方文档把那一章啃透再继续。AI 应用前端的学习没有捷径但走三个月系统路径你会比漫无目的刷教程的人快上好几倍。