说实话前端圈这两年最热门的话题之一就是“前端到底能不能搞AI应用开发”。我作为一个写了多年页面的老前端一开始也觉得这东西是算法工程师的专利直到真的被丢了个“聊天机器人”需求硬着头皮从零啃了一遍大模型API、流式输出、上下文管理这些玩意之后才反应过来——大部分AI应用开发本质上还是工程接入问题前端不但能做而且能做得很顺。这篇是“前端手摸手跑路之AI应用开发”系列的第一篇目标很朴素不讲训练模型、不谈数学原理就按我们前端最熟悉的套路把大模型API调用、SSE流式输出、跨域与密钥安全、上下文管理这些基础打牢带你在3小时内跑通一个能用的AI对话小助手。1. 为什么前端做AI应用开发反而不是件难事1.1 技术栈没有变变的是数据来源很多前端同学一听“AI应用开发”第一反应是“这不得先学Python、学PyTorch、学机器学”其实完全不是这么回事。你去看看市面上大量号称AI产品的应用拆开来看最核心的逻辑还是收集用户输入组装参数请求一个HTTP接口然后把返回的内容渲染到页面上。这跟我们以前调后端接口做列表页、详情页没有本质区别只不过这次返回的不再是固定结构的JSON而是一段动态生成的文本流。我用一个生活化的类比来解释以前我们做前端是从数据库里取数据数据库里有什么我们就展示什么现在做AI应用开发是从大模型里“取生成结果”模型会根据我们给的对话历史现场编一段内容出来。前者是“查字典”后者是“让一个很聪明但有时候不太靠谱的同事帮你写方案”。所以你之前会的Vue、React、状态管理、构建部署、HTTP请求在这里全部用得上一项都不会白学。1.2 你不需要自己训练模型只需要学会和模型对话这是新手最容易绕进去的误区。有人总觉得AI应用开发自己造一个大模型于是先去研究几万张显卡的集群部署结果还没开始就放弃了。真实的行业分工早就清晰了——模型训练和推理优化是专门的团队在搞应用开发者只需要做一件事把用户的输入整理成模型能理解的格式调用现成的API再把模型返回的结果包装成产品。这就像你要做一款外卖App完全不需要自己开一家餐厅。你只需要把“用户想吃什么”翻译成订单交给后厨去炒菜再把菜端到用户面前。如今各大云厂商、AI平台都提供了标准化的模型服务接口你拿到一个API Key就能接入几十种模型。所以别被“AI应用开发”这四个字唬住它真正的门槛不在AI理论而在工程能力怎么把流式响应处理好、怎么管理对话记忆、怎么处理并发和错误这些恰恰是前端的主场。1.3 前端开发者在AI应用里的三个独特优势我踩过一圈坑之后愈发觉得前端在这个领域不是“过来打杂的”而是有实打实的优势第一交互敏感度。AI应用最典型的体验特征是什么是“打字机”式的流式输出是用户点“停止生成”能随时中断是对话列表的动态插入和滚动定位。这些交互对后端同学来说可能需要重新理解但对前端来说就是老本行属于基本功范畴。第二工程化思维。现在AI应用越来越复杂动不动就是Agent工作流、多轮工具调用、消息状态机。你能不能把一条消息的状态发送中、流式接收中、完成、失败管理清楚能不能把各种回调事件拆成清晰的组件这很考验组件化能力和状态管理能力前端在这方面有天然优势。第三离用户近。AI应用的迭代速度极快今天上线一个功能明天就可能根据用户反馈调整Prompt或交互。前端本来就处在用户和产品之间改了效果立刻能看见这种快速试错的能力在AI应用开发中极其重要。另外现在前端面试的考察范围也明显在往AI方向靠什么“AI应用开发怎么入门”“你做过哪些AI相关项目”都快成常见题了早一步动手面试就多一份底气。2. 告别黑盒先把大模型API的几个核心概念整明白2.1 一次最简单的模型调用请求不管你是接哪家的大模型服务只要它是OpenAI兼容接口那请求格式基本上大同小异。我强烈建议第一次接触的人先用curl把最原始的请求打一遍亲眼看看返回长什么样比看十篇教程都管用。这里我给一个简化版的调用示例curl https://你的API服务地址/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的_API_Key \ -d { model: gpt-4o-mini, messages: [ {role: system, content: 你是一个友好的助手}, {role: user, content: 你好请用一句话介绍你自己} ], stream: false }注意看这里的请求体关键点全在messages数组里。它是由一条条消息组成的每条消息必须有role和content两个字段。role有三种system表示系统设定告诉模型“你是个什么样的角色”user表示用户说的话assistant表示模型之前回复过的内容。前端同学可以把这个数组理解成聊天记录数组。每次请求新问题时不是只把新问题发给模型而是要把历史上所有的对话消息都带上。这是AI应用和普通接口开发最大的一个不同点普通接口是无状态的你传什么就是什么大模型API是有“记忆”的但这个记忆全靠你每次请求时手动把历史消息塞给它。你不带历史它就完全失忆你带太多历史又会撞上上下文窗口限制。就这一个细节能引出一堆工程问题后面专门讲。2.2 SSE流式输出聊天不是等出来的是“读”出来的如果你把上面请求里的stream改成true返回方式会完全不同。这就是AI聊天应用最核心的机制SSEServer-Sent Events。理解SSE不需要什么高深知识你只需要知道两件事。第一它和WebSocket不一样。WebSocket是双向通信适合实时游戏、多人协作这类场景SSE是单向的服务器主动往客户端推数据而且底层就是普通的HTTP所以天然能复用浏览器原生的请求机制不需要额外维护一个长连接协议。在AI对话场景里模型只需要从服务端一路往客户端推内容SSE是再合适不过的。第二它的数据格式很“朴素”是普通的文本流。每行数据长这样data: {choices:[{delta:{content:你}}]} data: {choices:[{delta:{content:好}}]}每段以data:开头后面跟一段JSON字符串消息之间用空行分隔。等模型输出完最后会有一个特殊标记[DONE]。这种格式对前端来说非常好解析但有一个隐藏的坑因为它是流式的你拿到的一个数据块里可能含有多行也可能一行被劈成两半。你必须在代码里做“按行切分 缓存半截”的处理这也是后面实操部分的核心代码逻辑。那为什么AI聊天必须用流式而不是等模型全生成完再一次性返回呢因为大模型推理再快生成几百个字也得要几秒到几十秒。如果用户点击发送后看着空页面干等十几秒体验直接崩了。流式输出让用户看到第一个字等后续内容陆续“打”出来符合人脑对实时反馈的期待。你在ChatGPT、各种AI助手产品里看到的打字机效果底层都是SSE。2.3 上下文窗口一个前端最容易忽略的预算问题“上下文窗口”是每个做AI应用的人都绕不开的一个概念。简单说模型每次能接收的文本总量是有限的这个上限就叫上下文窗口。你可以把它想象成一次会议最多能同时容纳多少个发言记录满了之后只能把最早的发言“请出会议室”。对大模型来说衡量“发言长度”的单位不是字数而是token。token可以粗略理解成“单词/词组/字的碎片”一般来说一个英文字符约等于0.25个token一个汉字大概占1到2个token。不同模型的上下文窗口差距很大小的可能只有4000个token粗略算下来也就几千字的对话历史大的有128K、200K甚至更多能塞下一整本长篇小说。这对前端意味着什么呢意味着你不能无限地把聊天记录全往请求里塞。用户聊了一百轮之后如果还是把全部历史都传上去第一个撞墙的就是上下文窗口API会直接报错。而且还有成本问题——大模型API基本都是按token计费的你每次请求带的历史越多花的钱就越多。很多新手做出来的Demo上线之后用户聊多了发现账单爆了就是这个原因。所以应用开发阶段必须设计一套上下文管理策略比如只保留最近N条消息、把过长的历史做摘要压缩、或者让用户手动清空会话。这些策略我们后面实操部分会给出一个简单可用的版本。2.4 温度与随机性别忽略那几个“小参数”除了model和messages之外请求体里通常还有几个可选参数很多前端第一次接触会直接忽略但它们对产品形态影响很大。最典型的是temperature它控制模型输出的随机性取值范围一般是0到2。数值越低输出越保守、越稳定适合做客服、写代码、提取摘要数值越高输出越发散、越有“创意”适合写文案、头脑风暴。另外一个常见参数是max_tokens它限制单次生成内容的最大长度假设你把模型接口并到前端但不做任何限制一旦模型“话痨”起来输出可能异常长不仅拖慢渲染费用也受不了。我个人的习惯是MVP阶段先把它设成500到800跑通之后再根据场景调。3. 三小时跑通第一个AI对话小助手3.1 工程初始化与总体结构约定了原理我们就开始实操。这一小节我会用 Vite Vue3 来搭建项目React 的思路完全一样核心逻辑不变。为什么用 Vite因为它是目前前端构建工具里开箱即用做得最好的几个之一启动快、Proxy配置简单特别适合快速原型验证。我先说下这次Demo的整体结构前端负责用户输入、展示消息列表、解析和渲染SSE流、维护对话上下文。前端开发服务器的Proxy负责把请求转发到大模型服务并在转发时注入 Authorization 头避免密钥暴露在浏览器。生产环境可选一个极薄的Node服务做同样的事或者用Nginx配置转发。初始化项目这一步不用多讲直接跑一遍初始化命令就行。跑完之后创建src/api/chat.js放请求逻辑创建src/components/ChatMessage.vue放单条消息展示根组件里维护消息列表和输入框。目录别太复杂先把流程跑通最重要。3.2 前端代理层解决跨域和密钥安全前端同学第一次写AI应用最容易遇到的两个问题一是浏览器跨域二是API Key不小心写在前端代码里。这两个问题有一个共同的解决方案不直接请求大模型的API而是请求我们自己前端的同源地址再由服务端去转发。在Vite开发环境下配置Proxy只需要几行代码。我在vite.config.js里会这样写import { defineConfig } from vite; import vue from vitejs/plugin-vue; export default defineConfig({ plugins: [vue()], server: { proxy: { /api: { target: https://你的大模型API域名, changeOrigin: true, rewrite: path path.replace(/^\/api/, ), configure(proxy) { proxy.on(proxyReq, (proxyReq) { proxyReq.setHeader(Authorization, Bearer ${process.env.LLM_API_KEY}); }); }, }, }, }, });这段配置干了三件事第一浏览器客户端请求的是/api/chat/completions属于同源请求不存在跨域问题第二Vite开发服务器收到请求后会在内部转发到真实的大模型API地址第三转发的时候由Node侧注入Authorization头API Key只存在于开发服务器的环境变量里浏览器永远接触不到。可能有人会问跨域问题不能通过后端开CORS解决吗能解决一部分但密钥问题不行。API Key放在前端代码里等于把银行卡密码写在便利贴上贴门口任何一个打开DevTools的用户都能看到。所以不管多麻烦密钥必须留在服务端。这条原则我建议你从第一行代码开始就严格遵守。3.3 核心代码用fetch ReadableStream解析流式响应接下来是整个Demo最核心的部分解析SSE流。EventSource虽然原生支持SSE但它有几个硬伤——只能发GET请求、不能自定义请求头、断线重连逻辑不可控制。到大模型API这一趴基本都要求POST所以实际开发中大家更常用fetchReadableStream自己手动解析。代码看起来有点绕其实逻辑很清晰// src/api/chat.js export async function sendMessageStream({ messages, onData }) { const response await fetch(/api/chat/completions, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model: gpt-4o-mini, messages, stream: true, temperature: 0.7, max_tokens: 800, }), }); if (!response.ok) { const err await response.json().catch(() ({})); throw new Error(err.error?.message || HTTP ${response.status}); } const reader response.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; // 把二进制流解码成字符串并拼接到buffer里 buffer decoder.decode(value, { stream: true }); // 按换行符拆分注意最后一段可能是半截要留在buffer里等下次拼接 const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { const trimmed line.trim(); if (!trimmed.startsWith(data:)) continue; const data trimmed.slice(5).trim(); if (data [DONE]) continue; try { const json JSON.parse(data); const content json.choices?.[0]?.delta?.content; if (content) onData(content); } catch (e) { // 如果解析失败通常是半截JSON交给下一轮处理 } } } }这段代码里有几个细节值得单独强调第一buffer变量的作用。网络传输是分包进行的V8的解析粒度、网卡的MTU、服务器的发送策略都会导致一个数据块里可能只有半行JSON。如果你不对buffer做缓存处理很容易出现“解析JSON失败”的偶发报错。解决方案就是上面的思路遇到换行符才认为是完整一行没遇到的半截字符串留在buffer里继续拼接。第二decoder.decode(value, { stream: true })。大模型的流式返回是UTF-8编码的但如果一个汉字被拆成两个二进制块直接按单块解码会出现乱码。TextDecoder加上stream: true就是为了处理这种情况它会缓存不完整的多字节字符等下一块数据来了再拼接。第三data:后面不一定都有空格有的是data:{...}所以解析时用slice(5)之后还要再trim()一下避免混入空格污染JSON字符串。这段代码写完之后前端就已经“能收到”模型的流式输出片段了。下一步是把这些片段渲染到页面上。3.4 维护对话上下文与状态管理很多新手做完上面那步就以为万事大吉结果发现模型“完全没有记忆”——你问它“我叫张三”下一轮问“我叫什么”它一脸茫然。原因前面说过了每次请求都是独立的你得手动把历史消息传给它。所以我会在组件里维护一个messages数组结构如下const messages ref([ { id: 1, role: assistant, content: 你好我是AI助手有什么可以帮你, status: done }, ]);用户每次发送消息就先往数组里push一条role: user的消息紧接着再push一条role: assistant的空消息它的content会在流式回调里不断追加同时给它打一个status: streaming标记用来控制“停止生成”按钮和打字机光标。真正发请求时要把UI里的消息数组转换成API需要的格式。注意两点一是UI消息比API消息多了一些跟渲染相关的字段要过滤掉二是要控制历史消息条数防止上下文爆炸。我习惯做一个简单的截断函数function buildRequestBody(messages) { // 保留最近的20条消息防止上下文无限膨胀 const recent messages.slice(-20); return { model: gpt-4o-mini, messages: recent.map(m ({ role: m.role, content: m.content, })), stream: true, }; }这里slice(-20)是一个简单粗暴但有效的方案。如果产品形态是“需要长时间记忆的智能体”那就要上更复杂的策略比如把更早的对话交给模型生成摘要再把摘要作为system消息塞进去。这一步是目前实现“类人记忆”的常见做法等系列后几篇再展开。3.5 生产环境怎么加一层后端Vite的Proxy只适用于开发环境。打包上线之后你不可能还跑着一个Vite开发服务器。生产环境的主流做法是前端静态文件放在Nginx/CDN上API请求打到自己的一台轻量后端服务上由后端转发到大模型API。如果你已经会Node其实只要一小段代码就能搞定一个转发服务import express from express; import fetch from node-fetch; // Node 18直接用内置fetch也行 const app express(); app.use(express.json()); app.post(/api/chat/completions, async (req, res) { const upstreamRes await fetch(https://你的大模型API域名/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${process.env.LLM_API_KEY}, }, body: JSON.stringify(req.body), }); res.status(upstreamRes.status); // 上游是流式响应时直接把流pipe回给前端 upstreamRes.body.pipe(res); }); app.listen(3000, () console.log(proxy server run at 3000));这段代码的核心逻辑就是“透传”前端请求打到我们自己后端后端加上密钥再请求大模型API然后把响应流原样管道回给前端。这样做的好处一是密钥安全二是可以在中间层做缓存、限流、日志、审计后续要扩展Agent能力也方便。有些团队也用Serverless函数做这个转发层成本更低思路一样。这一块你可以根据自己的技术栈选原理都是相同的。4. 流式输出的进阶打磨让体验从“能跑”到“好用”4.1 文本增量渲染与Markdown处理流式响应接进来之后最“原始”的渲染方式是把content当纯文本直接塞进DOM。这样很快就能跑通但如果模型返回的是带Markdown语法的内容页面上全是#、**、反引号用户看着很难受。所以稍微正式一点的AI对话应用都会引入Markdown渲染。方案也很直接组件里装一个markdown-it之类的库把content实时渲染成HTML。不过流式场景有一个性能坑如果你在每次onData回调触发时都重新渲染整个消息内容页面很可能会越用越卡。原因在于Markdown解析和DOM更新都是CPU密集型操作几十个字感觉不到几百上千字时输入框可能开始掉帧。我的经验是用“分帧渲染”的思路不是每一小块内容到了马上去解析而是把最新内容丢进一个待渲染队列用requestAnimationFrame把渲染频率和浏览器刷新率对齐。这样用户看到的效果依然是“连续的流式输出”实际渲染次数大幅减少长文本下明显更流畅。需要注意的是Markdown渲染方案也影响流式展示的稳定性比如代码块在没闭合之前是会整体乱掉的这个只能等整体出来再修复或者给消息一个“渲染完成”的标记后再做一次最终渲染。4.2 中断、取消与重试用户点击“停止生成”是一个高频操作。想想你自己用聊天产品时如果模型开始“胡说八道”第一反应就是点停止。前端实现这个交互的底层能力是AbortController。我给的sendMessageStream函数一开始其实应该接收一个signal信号。调用时创建AbortController然后把signal传进fetch的配置项里。用户点击停止时执行controller.abort()fetch 就会抛出一个AbortError。代码里要单独捕获这个错误不能把它当成普通网络错误处理否则界面上会错误地弹“网络异常”。const controller new AbortController(); try { await sendMessageStream({ messages, signal: controller.signal, onData }); } catch (err) { if (err.name AbortError) { // 用户主动停止不提示错误 } else { // 网络错误/接口异常提示重试 } }重试策略在AI应用里同样重要。大模型API的稳定性不像普通后端接口高峰期经常会出现5xx、429限流。我建议在MVP阶段至少做一层“指数退避”重试第一次失败等1秒重试第二次等2秒第三次等4秒最多试3次。退避时间要递增避免大家同时重试把服务打得更死。4.3 请求并发与限流策略聊天页面的并发问题容易被忽视。我见过一个真实案例聊天应用上线后有用户连点发送按钮同一时间发出十几个请求把模型API的配额瞬间打爆。前端要做的事情很简单——当有一条消息正在流式生成时禁止再次发送。UI上表现为“发送按钮禁用”或“输入框锁死”一股脑发出去的结果大概率是上下文错乱加账单失控。还有一个浏览器层的并发限制浏览器对同一域名下的HTTP/1.1连接数有限制通常是6个左右。SSE流式请求本身非常占用连接如果同一个页面同时跑多个流式请求其他资源请求会被阻塞表现为页面图片、接口全部变慢。所以同一个对话框里一次只允许一个流式请求在跑是最稳妥的规则。真有多线程生成需求的产品也要通过后端统一调度而不是让浏览器同时开多条长连接。5. 前端AI应用踩坑实录常见问题与排查思路5.1 常见问题速查表写到这里我把实际开发里最常踩的坑整理成了一张速查表按“症状→可能原因→解决方案”来组织建议直接收藏备用。症状可能原因解决方案控制台跨域报错前端直接请求了大模型API域名走Vite/后端/Nginx代理不要直连上游流式内容一截一截乱码UTF-8字符被拆成多块解码用TextDecoder(..., { stream: true })偶发 JSON.parse 失败SSE数据行被网络分包截断用buffer缓存半截行按换行符拆分界面一直空白内容不出请求没到后台或后台没关缓冲检查Network请求状态Nginx关proxy_buffering off后端加X-Accel-Buffering: no第一次请求成功后续报错token超限历史消息无限堆积超出上下文窗口截断历史、摘要压缩、定期清空会话收到401/403API Key无效或没有在转发时注入确认环境变量、确认服务端转发逻辑收到429触发限流或被并发打爆加指数退避重试前端限制并发请求内容过低级或出格被拒模型内容安全策略拦截检查返回里的content_filter字段按规范提示用户点击停止后仍不断弹出错误没有单独捕获AbortErrorerr.name AbortError时静默处理5.2 用Network面板像“老司机”一样排查排查AI应用问题我第一件事永远是打开浏览器DevTools的Network面板而不是去看业务代码。因为AI应用大量涉及流式传输、鉴权、代理转发这些环节的状态码和响应数据比业务代码里的console更能说明问题。看什么呢第一看请求是不是发到了你以为的地址尤其是代理配置最容易在这里露馅——你以为请求到了/api/...实际上可能被rewrite成了别的路径第二看HTTP状态码如果是401/403就去查密钥和代理头如果是429就去查限流策略如果是5xx就去查上游服务状态第三看Timing一栏如果Content Download时间特别短但页面又没显示流式内容十有八九是后端把流给缓冲了等到全部生成完才一次性返回。遇到这种情况浏览器侧看Response是获取不到实时状态的只能通过服务端日志或直接curl上游接口来判断。5.3 关于部署时Nginx/Docker的stream缓冲坑这是我在生产环境踩过最深的一个坑必须单独拿出来说。前端项目打包之后我用Docker起了一个Nginx容器同时反代后端API。结果上线测试时发现用户问一个问题后页面等了足足十几秒然后模型答案“哗”一下整体出现根本没有流式效果。当时第一反应是前端解析代码写错了排查了半小时最后发现根因在Nginx的缓冲上。Nginx默认会把上游响应缓冲到一定大小再发给客户端大型响应甚至会等上游完全结束才发送。这对静态资源、普通API没有影响但直接毁掉了SSE流式体验。解决方案是在Nginx配置里手动关掉缓冲location /api/ { proxy_pass http://你的后端服务:3000; proxy_buffering off; proxy_cache off; proxy_set_header X-Accel-Buffering no; }如果你用的不是Nginx而是其他网关也要记得处理同样的缓冲逻辑。判断自己是不是踩了这个坑很简单用curl -N直接请求后端API如果curl能收到流而浏览器收不到那基本就是中间层缓冲在作怪。另外如果你用了CDN刷新也注意有些CDN会缓冲SSE响应生产环境尽量只用CDN缓存静态资源API请求绕开CDN直连源站。5.4 最后的调试小技巧curl是你的好朋友趁结尾再分享一个我个人的调试习惯。每次对接大模型API我基本不用前端直接测而是先用curl模拟请求把上游返回的原始格式看清楚。这样能明确责任边界——是上游返回格式不对还是我前端解析出了问题。curl -N https://你的大模型API域名/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的_API_Key \ -d {model:gpt-4o-mini,messages:[{role:user,content:你好}],stream:true}-N参数的意思是禁用curl自身的缓冲让它把流式内容实时打印出来。如果这行命令能正常输出一段段带data:前缀的文本说明上游没问题接下来再从前端、代理、网关逐层排查。反过来如果curl这里就已经是空响应或报错那就不用再在前端代码里反复折腾了。坦白讲前端做AI应用开发和传统前端最大的区别不是技术栈换了而是思维模式换了以前我们处理的是静态数据渲染完就结束了现在我们要处理的是“持续生成的、有上下文、有随机性的数据”需要时刻想着流式状态、历史约束和异常恢复。很多坑只有自己踩一遍才能真正理解。这篇算是把地基打完了下一篇我们再来聊聊怎么给AI助手加上工具调用Function Calling让它不止会聊天还能帮你查天气、查数据库、操作外部系统。对前端来说那才是真正打开AI应用开发大门的时刻。