企业官网建设流程全解析

1. 三个月从传统前端转向AI应用前端，我到底在学什么

先把话说在前头：AI应用前端工程师，不是让你去训练大模型，也不是让你去调参炼丹。这个岗位的核心价值，是把大模型的能力包装成用户能直接用的产品界面。你每天打交道的，是流式输出、对话状态管理、提示词模板、多轮上下文、工具调用结果渲染这些东西。说白了，前端还是那个前端，只是你面对的后端从“返回一个JSON”变成了“返回一个会思考、会流式吐字、偶尔还会胡说八道的黑盒”。

我之所以给自己定这个三个月计划，是因为去年下半年开始，团队里几乎所有新需求都绕不开AI。老板不会问你“会不会Transformer”，他只会问“这个对话窗口能不能像ChatGPT那样一个字一个字往外蹦”“用户上传的图片能不能直接让模型分析”“多轮对话的历史怎么存怎么取”。这些问题，传统前端技能树里根本没有。我试过直接上手做，结果第一周就卡在流式响应上——用axios拿不到分块数据，换成fetch又不知道怎么处理SSE，折腾了两天才跑通一个最简陋的demo。那次之后我就明白，零散地学没用，必须有一个结构化的路线。

这个计划适合什么人？如果你已经会Vue或React，能独立写页面、调接口、处理状态管理，那这个计划就是为你准备的。如果你连组件生命周期都还没搞明白，建议先把基础打牢，否则后面学AI部分会非常痛苦。三个月的时间，我把它拆成三个阶段：第一个月补AI应用层的核心概念和流式交互基础，第二个月深入对话系统、多模态和工具调用，第三个月做完整项目并补齐工程化能力。每个阶段都有明确的产出物，不是看完视频就算完，而是要能跑起来、能演示、能讲清楚为什么这么做。

下面我把每个阶段拆开讲，包括我实际踩过的坑、用到的工具、以及那些文档里不会写的细节。

2. 第一个月：搞懂AI应用前端的底层交互逻辑

2.1 为什么流式输出是第一个必须啃下来的硬骨头

传统前端调接口，习惯的是“发请求→等响应→拿完整数据→渲染”。但AI应用的默认交互是流式的，模型生成一个字就吐一个字，用户看到的是文字逐渐浮现的效果。这个体验差异背后，是技术实现的根本不同。如果你还用axios去接，会发现response永远在pending状态，因为axios默认等整个响应体接收完才resolve。我一开始就栽在这里，后来换成fetch加ReadableStream才解决。

具体来说，流式输出主要依赖SSE（Server-Sent Events）或者WebSocket。SSE更常见，因为它是基于HTTP的单向推送，实现简单，浏览器原生支持EventSource。但EventSource有个限制：它只能发GET请求，没法带复杂的请求体。所以实际项目中，大家更常用fetch加ReadableStream来手动解析SSE格式的数据流。下面是我实际用的解析代码，你可以直接抄：

async function fetchStream(url, body, onChunk) { const response = await fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(body) }); 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]') return; try { const json = JSON.parse(data); onChunk(json); } catch (e) { // 忽略解析失败的行 } } } } }

这段代码的关键点在于buffer的处理。网络传输不会按照你想象的“一行一个数据包”来，可能一次收到半行，也可能一次收到三行。所以必须用buffer暂存不完整的行，等下一个数据块到了再拼接。我一开始没做这个处理，结果偶尔会出现JSON.parse报错，调试了半天才发现是数据被截断了。

注意：不同模型服务商返回的SSE格式略有差异。有的用data:前缀，有的直接返回JSON行。接入前一定要先看文档，或者用curl手动请求一次，把原始返回打出来看。

2.2 对话状态管理：别再用useState硬撑了

流式输出跑通之后，下一个坑就是对话状态管理。一个对话界面涉及的状态比普通页面复杂得多：消息列表、当前正在生成的消息、生成状态（idle/loading/streaming）、错误状态、上下文窗口管理、滚动位置控制。我一开始用useState堆，写到第三个状态就开始乱了，组件重渲染频繁，流式输出的时候整个页面都在抖。

后来我换成了useReducer加Context的方案，把对话相关的状态收敛到一个reducer里。这样每个action的意图很清晰，也方便做时间旅行调试。再后来发现Zustand更轻量，没有Provider嵌套的烦恼，就切过去了。如果你用React，我建议直接上Zustand；Vue的话Pinia就够用。

状态结构大概长这样：

{ messages: [ { id, role: 'user' | 'assistant' | 'system', content, status: 'done' | 'streaming' | 'error' } ], currentStreamingId: null, isGenerating: false, error: null, contextWindow: 10 // 保留最近多少轮对话 }

这里有个细节：流式输出的时候，不要每收到一个字符就更新整个messages数组。那样会导致所有消息组件都重渲染。正确做法是把正在生成的那条消息单独拎出来，用一个独立的state或者ref来存它的内容，等生成结束了再合并回messages。我实测下来，这样能把流式输出的渲染性能提升好几倍，尤其是消息多的时候。

2.3 提示词模板：前端也要懂“怎么跟模型说话”

很多人觉得提示词是后端的事，前端只管展示。但实际项目中，很多提示词模板是前端拼装的，因为需要根据用户输入动态插入变量。比如一个翻译功能，提示词可能是“把下面的文本翻译成{targetLang}：{text}”。前端需要做的是模板替换、变量校验、以及防止用户输入破坏提示词结构。

我踩过的坑是：用户输入里如果包含特殊字符或者换行，直接拼进提示词会导致模型理解偏差。后来我加了一层转义处理，把用户输入用分隔符包起来，比如用三个反引号或者XML标签。这样模型能清楚区分“指令”和“用户内容”。另外，提示词模板最好集中管理，不要散落在各个组件里。我建了一个prompts目录，每个模板一个文件，导出成函数，接收参数返回最终字符串。这样改提示词的时候不用翻组件，也方便做A/B测试。

3. 第二个月：深入对话系统、多模态与工具调用

3.1 多轮对话的上下文管理，比你想象的复杂

第一个月跑通单轮对话后，我以为多轮就是加个数组的事。结果真正做起来才发现，上下文管理是个深坑。首先是token限制，模型的上下文窗口是有限的，你不能把历史消息无限往里塞。我一开始没做截断，聊了十几轮之后接口直接报错。后来加了滑动窗口，只保留最近N轮，但这样又会丢失早期的重要信息。

更优雅的方案是做摘要压缩：当历史消息超过阈值时，调用模型把早期对话总结成一段简短摘要，然后把摘要作为system消息放在最前面。这样既保留了关键信息，又控制了token消耗。我实测下来，摘要压缩能把上下文长度控制在原来的三分之一左右，效果还不错。

另一个坑是消息顺序。有些模型对消息顺序敏感，system消息必须在最前面，user和assistant必须交替出现。如果你中间插入了一个工具调用的结果，格式又不一样。我建议在发送请求前，用一个函数统一做消息格式化，确保符合目标模型的规范。这个函数里要处理：角色映射、空消息过滤、连续同角色消息合并、工具调用结果格式化。

3.2 多模态输入：图片、文件、语音怎么接

现在的AI应用早就不只是文字对话了。用户要传图片让模型分析，要上传PDF让模型总结，要语音输入直接转文字。前端要处理的东西一下子多了起来。图片相对简单，转成base64或者上传到对象存储拿URL，然后按模型要求的格式塞进消息里。但要注意图片大小限制，大部分模型对base64图片有尺寸要求，超过会报错。我一般在前端先做压缩，用canvas把图片压到合理尺寸再传。

文件处理更麻烦。PDF、Word这些格式，前端没法直接解析内容，通常要传到后端做文本提取。但有些场景下，前端需要做初步校验：文件类型、大小、页数。我遇到过用户传了一个200页的PDF，后端处理超时，前端一直转圈。后来加了前端页数预估（通过文件大小粗略判断），超过阈值就提示用户拆分。

语音输入依赖浏览器的MediaRecorder API，录完音频后要么直接传给后端做语音识别，要么用前端的Web Speech API。Web Speech API的好处是免费、无需后端，但兼容性一般，而且识别准确率看网络环境。我一般把它作为降级方案，优先走服务端识别。

3.3 工具调用与函数调用：让AI真正“动手做事”

工具调用是AI应用从“聊天玩具”变成“生产力工具”的关键。用户说“帮我查一下明天北京的天气”，模型不会自己查，而是返回一个工具调用的请求，前端或者后端执行这个工具，把结果再喂给模型，模型再生成最终回答。前端在这个过程中要做的事情包括：解析工具调用请求、展示工具执行状态、渲染工具返回结果。

我做过一个日程管理的AI助手，用户说“帮我约张三明天下午三点开会”，模型返回一个createEvent的工具调用，前端拿到后调用日历API创建事件，然后把创建结果返回给模型，模型再回复用户“已为您创建”。这个流程里，前端需要处理工具调用的中间状态：正在调用、调用成功、调用失败。用户体验上，最好能展示一个“正在为您创建日程...”的提示，而不是干等。

工具调用的结果渲染也是个问题。不同工具返回的数据结构完全不同，天气返回的是JSON，日历返回的是事件对象。我建议为每种工具定义一个结果渲染组件，根据工具名称动态加载。这样新增工具的时候只需要加一个组件，不用改主流程。

4. 第三个月：完整项目实战与工程化收尾

4.1 选一个能讲清楚的项目，别贪大

第三个月的核心是做一个完整的、能拿得出手的项目。我见过很多人一上来就想做“全能AI助手”，结果三个月过去连登录都没做完。我的建议是选一个垂直场景，做深做透。比如“AI简历优化助手”、“AI会议纪要生成器”、“AI代码审查助手”。场景越具体，你越容易把细节做好，面试的时候也越容易讲清楚。

我选的是“AI会议纪要生成器”。用户上传会议录音或者粘贴会议文字记录，系统调用模型生成结构化纪要，包括议题、结论、待办事项。这个项目覆盖了文件上传、语音转文字、流式输出、结构化数据渲染、历史记录管理这些核心技能点，而且业务价值清晰，演示效果好。

项目结构上，我用Next.js做全栈，前端React加Tailwind，后端API Routes处理模型调用和文件存储。数据库用SQLite起步，后面换Postgres。模型调用层做了一个统一的适配器，支持切换不同的模型服务商。这样做的原因是，AI应用经常需要根据成本、速度、效果在不同模型之间切换，如果代码里到处硬编码模型名称，改起来会疯掉。

4.2 工程化细节：错误处理、重试、降级

AI应用的错误处理比普通应用复杂得多。模型可能超时、可能返回格式错误、可能触发内容过滤、可能限流。每一种错误都需要不同的处理策略。我整理了一个错误处理表，你可以参考：

重试策略我用的指数退避，第一次等1秒，第二次等2秒，第三次等4秒。但要注意，不是所有错误都值得重试。内容过滤这种重试多少次都一样，直接提示用户就行。流中断的话，如果已经生成了一部分内容，不要丢弃，让用户可以选择继续。

降级方案也很重要。如果模型服务完全不可用，前端应该展示一个友好的提示，而不是白屏。我一般会准备一个静态的fallback内容，或者引导用户使用其他功能。这个细节很多个人项目会忽略，但实际产品中非常关键。

4.3 性能优化：流式渲染、虚拟列表、缓存

AI应用的性能瓶颈主要在渲染上。流式输出的时候，如果消息列表很长，每次字符更新都触发全量重渲染，页面会卡到没法用。我的优化方案是：正在生成的消息用独立的组件渲染，用ref直接操作DOM更新文本内容，绕过React的渲染机制。等生成结束后，再把最终内容提交到状态里。这样流式过程中只有那一个组件在更新，其他消息完全不受影响。

虚拟列表是另一个必备技能。当对话历史有几百条的时候，全部渲染会导致内存暴涨。我用的是react-window，只渲染可视区域内的消息。但虚拟列表和流式输出结合的时候有个坑：正在生成的消息高度是动态变化的，虚拟列表需要不断重新计算。我的做法是，流式生成期间暂时关闭虚拟列表，等生成结束再开启。虽然有点粗暴，但实测下来体验最稳定。

缓存方面，模型的响应结果可以缓存。相同的输入加相同的参数，如果短时间内重复请求，直接返回缓存结果。我用的是IndexedDB做本地缓存，设置一个合理的过期时间。这样用户刷新页面或者切换对话再切回来，不用重新请求模型，体验流畅很多。

5. 那些文档不会告诉你的避坑经验

5.1 模型不是每次都会按你想要的格式返回

这是我最深刻的教训。你精心设计了提示词，要求模型返回JSON格式，测试的时候十次有九次是对的，但上线后总有那么一两次返回了带markdown代码块的JSON，或者多了一句“好的，以下是JSON”。前端如果直接JSON.parse，直接崩。我的解决方案是写一个健壮的解析函数，先尝试直接解析，失败后提取代码块内容再解析，再失败就降级为纯文本展示。永远不要相信模型会100%遵守格式指令。

5.2 流式输出的滚动跟随是个玄学问题

用户希望看到最新生成的内容，所以流式输出的时候页面要自动滚动到底部。但用户如果手动往上滚了，你再强制滚到底部，用户会很烦。我的做法是监听滚动事件，判断用户是否在底部附近（比如距离底部50像素以内），如果在就自动跟随，如果不在就停止跟随，并显示一个“回到底部”的按钮。这个逻辑听起来简单，但边界情况很多，比如内容高度变化、滚动惯性、移动端触摸滚动，我调了整整两天才调稳。

5.3 Token计数和成本控制要提前做

很多个人开发者一开始不在意token消耗，直到收到账单才傻眼。前端虽然不直接计算token，但可以做预估和限制。比如限制单次输入的最大字符数，限制对话历史的最大轮数，在界面上展示本次对话消耗的token估算值。我用的是tiktoken的JS版本做前端预估，虽然不完全准确，但足够用来做限制和提示。另外，流式输出的时候如果发现已经生成了很长的内容，可以提供一个“停止生成”的按钮，让用户主动中断，避免浪费。

5.4 测试AI应用不能只靠手动点

AI应用的输出是不确定的，同样的输入可能得到不同的输出。传统的断言测试根本没法用。我的做法是分两层：第一层是单元测试，测那些确定性的逻辑，比如消息格式化、错误处理、状态流转；第二层是集成测试，用固定的mock数据模拟模型返回，测整个流程能不能跑通。至于模型输出的质量，只能靠人工评估，我建了一个测试用例集，每次改提示词或者换模型，都跑一遍看看效果有没有退化。

6. 三个月之后，我实际达到了什么水平

说实话，三个月不可能让你成为AI应用前端专家，但足够让你从“完全不懂”变成“能独立做项目”。我现在能独立完成一个中等复杂度的AI对话应用，从界面到流式交互到工具调用到部署上线，整个链路都跑通过一遍。遇到问题知道去哪里查、怎么排查、用什么方案解决。面试的时候，我能把流式输出的实现细节、上下文管理的取舍、工具调用的完整流程讲清楚，这些是背八股文背不出来的。

如果你也在走这条路，我的建议是：不要等“学完了”再动手做项目，第一个月学完流式输出就可以开始搭界面了，边做边学效率最高。遇到卡住的地方，先去翻官方文档和GitHub上的开源项目，大部分问题别人都遇到过。最后，保持耐心，AI应用前端这个方向变化很快，但底层的那套交互逻辑和工程思维是相对稳定的，把基础打牢，后面学新东西会快很多。