企业官网建设流程全解析

1. 三个月学习计划到底在学什么

先把话说清楚：这个计划不是教你“调个API就自称AI工程师”，而是把你从一个会写页面的前端，推到能独立扛起一个AI应用前端项目的水平。三个月，十二周，每天能投入三到四小时的话，刚好够走完一轮“基础补齐—核心能力—项目实战—面试冲刺”的完整闭环。

我见过太多前端同学卡在同一个地方：React写得溜，TypeScript也熟，但一碰到LLM相关的需求就懵了。流式输出怎么接？对话历史怎么管？RAG的引用溯源在前端怎么渲染？Agent的执行步骤怎么可视化？这些问题在传统前端教程里根本找不到答案，因为它们是AI应用特有的交互范式。这个计划要解决的，就是这道鸿沟。

适合谁来学？有三类人最合适。第一类是有1-3年前端经验，想往AI方向转型的开发者；第二类是在公司里被动接了AI项目，边做边补课的工程师；第三类是已经会用大模型API做demo，但缺乏系统性工程能力、做出来的东西只能自己玩玩的独立开发者。如果你连JavaScript的异步编程都不太熟，建议先补完基础再来，不然第三周就会卡住。

整个计划的核心逻辑是：前一个月打地基，中间一个月攻核心场景，最后一个月做完整项目并准备面试。地基包括LLM基础概念、Prompt工程、流式通信协议；核心场景包括对话界面、RAG知识库前端、Agent执行可视化；项目实战要求你从零搭一个可部署的AI应用，面试冲刺则针对AI应用前端岗位的高频考点做专项突破。

注意：这个计划假设你已经有前端基础（HTML/CSS/JS、至少一个框架、Git基本操作）。如果这些还不熟，先把基础补到能独立做一个TodoList应用的程度，再开始下面的内容。

2. 第一个月：地基怎么打才不虚

2.1 第一周：把LLM的基本概念嚼碎

很多人一上来就急着写代码调API，结果连Token是什么、上下文窗口怎么算、Temperature和Top_p的区别都说不清楚。面试官一问就露馅。第一周的任务不是写代码，是把概念吃透。

你需要搞清楚这几个核心概念：Token化（文本怎么变成模型能处理的数字）、上下文窗口（模型一次能“记住”多少内容）、Temperature/Top_p/Top_k（控制输出随机性的三个参数，各自适用场景不同）、System Prompt/User Prompt/Assistant Prompt（三种角色的分工）、幻觉问题（模型为什么会编造事实）。这些概念不需要你深入到数学层面，但必须能用大白话解释给一个产品经理听。

推荐的学习方式是：找一份主流大模型的官方文档，把“核心概念”章节通读一遍，然后用自己的话写一份笔记。笔记里要包含每个概念的定义、实际影响、以及一个你亲手验证过的例子。比如Temperature设为0和设为1，同一个Prompt的输出差异有多大，自己跑一遍就记住了。

这一周还要完成一个最小可运行demo：用Node.js或浏览器端调用一个LLM API，实现“输入问题—输出回答”的基本流程。不用做界面，控制台能跑通就行。目的是让你熟悉API的请求格式、鉴权方式、响应结构。

实操心得：调API时先把max_tokens设小一点（比如256），不然调试阶段很容易一不小心烧掉大量额度。另外，把每次请求的Prompt和响应都打印到控制台，方便对比不同参数的效果。

2.2 第二周：流式输出与SSE协议

传统HTTP请求是“发出去—等—收完整响应”，但LLM的输出是一点一点生成的。如果等全部生成完再显示，用户盯着空白屏幕十几秒，体验极差。所以AI应用前端必须掌握流式输出，而流式输出的技术基础是SSE（Server-Sent Events）。

SSE是一种服务器推送技术，允许服务器在建立连接后持续向客户端发送数据。它的协议格式很简单：每条消息以data:开头，以两个换行符结束。前端用EventSource接口或者fetch配合ReadableStream来接收。

这一周的任务是：手写一个流式对话demo。后端用一个简单的Node.js服务转发LLM的流式响应，前端用fetch的ReadableStream逐块读取并渲染。关键难点在于：如何处理不完整的数据块。LLM返回的流是字节流，一个JSON对象可能被切分成多个chunk，你需要维护一个缓冲区，按换行符或特定分隔符拼接后再解析。

// 前端流式读取的核心逻辑示意 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.startsWith('data: ')) { const data = line.slice(6); if (data === '[DONE]') continue; const parsed = JSON.parse(data); // 渲染 parsed.choices[0].delta.content } } }

这段代码看起来简单，但实际写的时候坑很多。比如TextDecoder的stream: true参数不加，中文会乱码；比如缓冲区不处理，最后一个chunk会丢失；比如[DONE]标记不判断，JSON.parse会报错。这些坑我都踩过，你照着上面的逻辑写，能省不少时间。

2.3 第三周：Prompt工程的前端视角

Prompt工程通常被认为是后端或算法的事，但AI应用前端必须懂，因为很多交互逻辑直接依赖Prompt的设计。比如：多轮对话时怎么拼接历史消息？用户上传文档后怎么构造RAG的查询Prompt？Agent执行时怎么让模型输出结构化的步骤？

这一周要掌握的核心技能是：结构化输出。让LLM返回JSON而不是自由文本，前端才能可靠地解析和渲染。常用的方法是：在System Prompt里明确要求输出格式，给出示例，并设置较低的Temperature。更可靠的方式是使用Function Calling或Tool Use能力，让模型按照预定义的Schema输出。

你需要动手实现一个“结构化输出解析器”：给定一个JSON Schema，构造Prompt让模型输出符合Schema的JSON，然后在前端做校验和容错。容错包括：模型多输出了markdown代码块标记怎么处理、JSON不完整怎么补全、字段类型不对怎么转换。

常见问题：模型经常在JSON外面包一层json，解析前要先strip掉。另外，模型可能会在JSON后面加解释性文字，需要用正则提取第一个完整的JSON对象。

2.4 第四周：对话历史管理与状态设计

多轮对话是AI应用最基础也最容易做砸的功能。新手常见的错误是：把所有历史消息一股脑塞进上下文，导致Token超限；或者只保留最近几条，导致模型“失忆”；或者没有区分System/User/Assistant角色，导致模型行为混乱。

这一周要设计一套对话历史管理方案。核心考虑三点：Token预算（上下文窗口有限，历史消息不能无限增长）、信息密度（哪些历史消息值得保留，哪些可以压缩）、角色正确性（每条消息的角色标记不能错）。

一个实用的方案是：维护一个消息数组，每条消息包含role、content、timestamp、tokenCount。当总Token数接近上下文窗口的80%时，触发压缩策略。压缩策略可以是：保留System Prompt和最近N轮对话，把更早的对话用LLM总结成一段摘要，作为一条System消息插入。

前端还需要处理对话分支的场景：用户编辑了某条历史消息，后续对话要基于修改后的内容重新生成。这要求你的状态管理支持树形结构，而不是简单的线性数组。React可以用useReducer配合不可变更新来实现，Vue可以用Pinia的嵌套状态。

这一周还要完成一个完整的对话界面：消息列表、输入框、发送按钮、加载状态、错误提示、重新生成按钮、复制回答按钮。看起来简单，但每个细节都有讲究。比如加载状态不能只转圈，要显示“正在思考...”并逐字渲染；比如错误提示要区分网络错误、额度不足、内容过滤等不同情况。

3. 第二个月：核心场景攻坚

3.1 第五周：RAG知识库的前端交互

RAG是当前AI应用最落地的场景之一。前端在RAG里的角色不是做向量检索，而是把检索和生成的过程可视化，让用户信任答案。具体来说，要做三件事：引用溯源（每条回答标注来源文档和段落）、检索预览（展示召回了哪些片段，相似度多少）、反馈闭环（用户可以对引用打分，帮助优化检索）。

这一周的任务是搭一个RAG问答界面的前端。后端假设已经提供了检索和生成接口，前端需要处理的数据结构包括：query、retrieved_chunks（每个chunk包含content、source、score）、answer、citations（回答中哪些句子引用了哪个chunk）。

渲染引用溯源的常见做法是：在回答文本中用上标数字标记引用位置，鼠标悬停或点击时弹出对应的原文片段。实现上可以用markdown-it的自定义插件，把[1]这样的标记转换成可交互的组件。难点在于流式输出时引用的动态更新：回答还在逐字生成，引用标记可能后出现，需要维护一个映射关系，确保标记出现时能立即关联到正确的chunk。

实操心得：检索片段的展示不要只显示文本，要显示来源文件名、页码或段落号、相似度分数。用户看到“来自《产品需求文档v2.3》第4.2节，相似度0.87”会比只看到一段文字信任得多。

3.2 第六周：Agent执行过程的可视化

Agent是比RAG更复杂的场景。一个Agent可能包含多个步骤：思考、选择工具、执行工具、观察结果、继续思考或给出最终答案。前端需要把这个过程实时、清晰地展示给用户，否则用户不知道Agent在干什么，会觉得“卡住了”。

这一周要掌握的核心技术是：流式事件解析与状态机渲染。Agent的执行过程通常以事件流的形式返回，每个事件有类型（thought、tool_call、tool_result、final_answer）和内容。前端需要维护一个步骤列表，根据事件类型渲染不同的UI组件。

设计要点：思考过程用折叠面板展示，默认收起，用户想看细节可以展开；工具调用显示工具名称、输入参数、执行状态（进行中/成功/失败）；工具结果显示摘要，过长时截断并提供“查看完整结果”按钮；最终答案用醒目的样式突出。整个步骤列表要支持自动滚动到最新步骤，但用户手动滚动查看历史时不要强制跳回。

// Agent事件流的状态管理示意 const [steps, setSteps] = useState([]); function handleEvent(event) { switch (event.type) { case 'thought': setSteps(prev => [...prev, { type: 'thought', content: event.content }]); break; case 'tool_call': setSteps(prev => [...prev, { type: 'tool_call', tool: event.tool, input: event.input, status: 'running', id: event.id }]); break; case 'tool_result': setSteps(prev => prev.map(s => s.id === event.id ? { ...s, status: 'done', result: event.result } : s )); break; case 'final_answer': setSteps(prev => [...prev, { type: 'answer', content: event.content }]); break; } }

这段代码的关键在于tool_call和tool_result通过id关联，确保结果能更新到对应的步骤上。实际开发中还要处理事件乱序、重复、丢失的情况，需要加去重和超时机制。

3.3 第七周：多模态与文件上传

现在的AI应用早就不只是文本对话了。用户会上传图片让模型分析、上传PDF让模型总结、上传Excel让模型处理数据。前端需要处理文件上传、格式校验、预览、分片上传、进度显示这一整套流程。

这一周的重点是PDF和图片的处理。PDF在前端可以用pdf.js渲染预览，但文本提取通常在后端做。前端要做的是：显示上传进度、显示文件缩略图或首页预览、上传成功后把文件ID传给对话接口、在对话中引用文件内容。

图片处理相对简单，但要注意：压缩后再上传。用户手机拍的照片可能好几MB，直接上传既慢又浪费额度。用canvas做等比压缩，把长边限制在1024或2048像素，质量设为0.8左右，通常能压到几百KB，对模型理解影响不大。

常见问题：上传大文件时不要用fetch一把梭，要用XMLHttpRequest或axios的onUploadProgress来显示进度。另外，文件类型校验不能只看扩展名，要检查MIME类型，防止用户改后缀绕过限制。

3.4 第八周：性能优化与体验打磨

前七周做出来的东西能跑，但可能很卡。这一周专门解决性能和体验问题。AI应用前端的性能瓶颈通常不在渲染，而在流式更新的频率和长列表的渲染。

流式输出时，如果每收到一个字符就setState，React会疯狂重渲染，页面直接卡死。解决方案是批量更新：用一个缓冲区收集字符，每50ms或每积累20个字符才触发一次状态更新。React 18的useTransition也可以用来把流式更新标记为低优先级，避免阻塞用户输入。

长对话列表要用虚拟滚动。react-window或@tanstack/react-virtual都是成熟方案。但要注意：流式输出中的最后一条消息高度是动态变化的，虚拟滚动库需要支持动态高度。如果搞不定，可以只对历史消息做虚拟滚动，最后一条消息单独渲染。

这一周还要做错误边界和降级方案。LLM接口可能超时、可能返回格式错误、可能被内容过滤拦截。每种情况都要有对应的UI提示和重试机制。比如超时后显示“响应超时，点击重试”，格式错误显示“解析失败，请重新生成”，内容过滤显示“该内容不符合使用规范”。

4. 第三个月：项目实战与面试冲刺

4.1 第九周至第十周：从零搭一个完整项目

前八周都是分模块练习，这两周要把所有东西串起来，做一个可部署、可演示、有完整交互的AI应用。选题建议从以下三个方向选一个：个人知识库问答（RAG+对话）、AI写作助手（多轮对话+结构化输出）、数据分析Agent（Agent+文件上传+图表渲染）。

以个人知识库问答为例，完整的功能清单包括：用户上传文档（PDF/TXT/Markdown）、文档列表管理、基于文档的问答、引用溯源展示、对话历史保存、多轮对话、重新生成、复制回答、反馈打分。技术栈建议：React/Next.js + TypeScript + Tailwind CSS + Zustand（状态管理）+ Vercel AI SDK（流式处理）。

项目开发要遵循先跑通再优化的原则。第一周先把主流程跑通：上传文档→后端处理→前端问答→流式渲染。第二周再补细节：引用溯源、错误处理、加载状态、响应式布局、部署上线。部署可以用Vercel或Netlify，前端项目部署很简单，后端如果用了Node.js服务，可以部署到Railway或Fly.io。

实操心得：项目一定要部署上线，有一个可访问的URL。面试时直接打开给面试官看，比说一百句“我做过”都管用。部署过程中遇到的问题（环境变量、跨域、构建优化）本身就是很好的面试素材。

4.2 第十一周：面试高频考点专项突破

AI应用前端岗位的面试题和普通前端有重叠，但多了几个专属考点。我整理了一个高频问题清单，你对照着准备：

除了技术问题，面试官还会考察你对AI应用产品形态的理解。比如：你觉得AI对话界面未来会怎么演变？RAG和Fine-tuning各自适合什么场景？Agent的落地难点在哪里？这些问题没有标准答案，但你要能说出自己的观察和思考。

4.3 第十二周：简历包装与项目复盘

最后一周不是学新东西，而是把前十一周的积累转化成面试官能看懂的语言。简历上的项目描述不要写“使用了React和TypeScript”，要写“实现了流式对话的增量渲染，首字延迟降低到800ms以内”或者“设计了引用溯源交互，用户对回答的信任度评分提升30%”。

项目复盘要准备三个版本：30秒版本（电梯演讲，说清楚做了什么、解决了什么问题、技术亮点是什么）、3分钟版本（展开技术细节，讲清楚架构设计和关键决策）、10分钟版本（完整演示，包括踩坑经历和优化过程）。面试时根据面试官的兴趣灵活切换。

还要准备一个技术难点故事。比如：“流式输出时引用标记后出现，我一开始用索引关联，结果发现索引会错位。后来改成用chunk ID做映射，并在前端维护一个待解析队列，确保标记出现时能立即关联到正确的引用。”这种故事比干巴巴地说“我做过RAG”有说服力得多。

最后再分享一个小技巧：面试前把项目里最复杂的那个模块的代码重新读一遍，确保能解释每一行的意图。面试官经常会指着某段代码问“为什么这么写”，答不上来就很尴尬。

5. 几个容易踩的坑和应对策略

5.1 不要陷入“调API”的舒适区

很多前端同学学AI应用，学着学着就变成了“调API工程师”——只会把请求发给后端，拿到响应渲染出来。这样在面试时毫无竞争力。你必须理解数据从模型到屏幕的完整链路：Token怎么变成流、流怎么变成事件、事件怎么变成状态、状态怎么变成UI。每一层都要能说清楚。

5.2 不要忽视传统前端基本功

AI应用前端首先是前端。CSS布局、响应式设计、无障碍访问、性能优化这些基本功不能丢。我见过候选人能把Agent可视化讲得头头是道，但写出来的界面在移动端直接错位，这种照样过不了面试。每天花半小时练练CSS和组件设计，不亏。

5.3 不要只做一个项目

一个项目只能覆盖部分场景。如果你只做了RAG问答，面试官问Agent可视化你就答不上来。建议至少做两个不同类型的项目：一个对话类（RAG或多轮对话），一个Agent类（工具调用或数据分析）。两个项目互补，覆盖面更广。

5.4 不要闭门造车

AI应用前端是一个快速演进的领域，新的交互范式、新的工具链层出不穷。定期看看主流AI产品的更新，读读优秀开源项目的源码，参与一些技术社区的讨论。我个人的习惯是每周花一小时浏览GitHub Trending上的AI应用项目，看看别人在怎么做交互。

5.5 不要忽略软技能

AI应用前端工程师经常需要和产品经理、算法工程师、后端工程师协作。你需要能听懂算法同学说的“召回率”“相似度阈值”，也需要能用产品经理听得懂的话解释“为什么流式输出不能做全文搜索”。沟通能力在这个岗位上的权重比普通前端更高。

6. 学习资源与工具链推荐

6.1 必读文档与教程

• Vercel AI SDK文档：目前最成熟的AI应用前端工具库，流式处理、对话管理、工具调用都有封装，源码也值得读。
• OpenAI API文档的“核心概念”章节：虽然你不一定用OpenAI，但概念是通用的。
• MDN的SSE和Streams API文档：底层原理必须掌握，不能只会用封装库。
• React官方文档的“状态管理”和“性能优化”章节：AI应用的状态复杂度比普通应用高一个量级。

6.2 工具链建议

6.3 值得研究的开源项目

• Chatbot UI：经典的对话界面实现，适合入门参考。
• LangChain Chat：展示了RAG和Agent的完整前端交互。
• Open WebUI：功能极其丰富，代码量大，适合进阶研究。
• assistant-ui：专注于对话交互的组件库，设计思路值得学习。

研究开源项目不要只看界面，要读源码里的状态管理逻辑和流式处理逻辑。这两个地方最能体现AI应用前端的特殊性。

7. 三个月之后的路怎么走

三个月能让你入门，但离“资深”还有距离。接下来的路有两条：纵向深入和横向扩展。纵向深入是指把某一个场景做到极致，比如专门做RAG的前端交互，研究引用溯源、多跳推理可视化、知识图谱渲染；横向扩展是指补齐后端和算法能力，能独立完成从数据处理到前端展示的全链路。

我个人的建议是先把纵向做深，再考虑横向。因为AI应用前端岗位的核心竞争力在于对AI交互范式的深刻理解，而不是全栈但每样都浅。你在面试时能讲清楚“为什么Agent的执行步骤要用折叠面板而不是平铺”“为什么流式输出时引用标记要延迟渲染”，比你会写Python后端更有价值。

这个领域变化很快，三个月前流行的交互方式可能三个月后就过时了。但底层能力不会过时：对流式数据的处理、对复杂状态的管理、对用户体验的敏感度。把这三样练好，不管工具怎么变，你都能快速适应。

我在实际带人的过程中发现，能坚持走完这三个月的人，通常不是最聪明的，而是最能“坐得住”的。每天三小时，雷打不动，十二周后回头看，你会发现自己已经和三个月前完全不一样了。