简介面向小程序开发者这份资料系统讲解如何将大模型聊天机器人快速集成到微信、支付宝等小程序平台覆盖技术选型、数据收集与预处理、模型架构选型、训练评估、云端部署以及前端交互设计与隐私安全等完整链路适合具备基础小程序开发知识并希望接入人工智能能力的读者。资源共2003个文件压缩包大小约2.45MB以JavaScript/TypeScript逻辑代码、JSON配置、WXSS样式、WXML页面结构、WXS脚本等小程序工程文件为主辅以Markdown文档、License协议说明等目录按功能组织便于快速定位。目前已有四百零五位学习者下载。内容中既包含对话消息加解密、Markdown/HTML解析、emoji处理等实用工具代码也涉及RNN、LSTM、Transformer等模型选型思路以及延迟优化、数据同步、隐私加密等落地问题从项目初始化到部署上线可作为从零到上线的小程序人工智能助手完整参考。 小程序接大模型聊天机器人这活儿最近找我咨询的人特别多。很多人第一反应是“直接在小程序里调大模型API不就行了”真上手才发现坑不少域名白名单过不去、API Key没法藏、流式输出不流畅、上下文越聊越乱。我前后给几个项目做过类似接入从踩坑到稳定跑通大概捋出了一套比较顺的流程这篇就把架构设计、核心代码、上线前的那些破事一次讲清楚。适合刚准备做AI聊天类小程序、或者已经在开发但卡在联调阶段的同学参考。1. 整体设计与方案选型先把路走对1.1 为什么小程序不能直连大模型先说最核心的问题小程序平台对网络请求的管控非常严格。你在大模型服务商那拿到的API地址基本不可能直接填进小程序的request合法域名里审核大概率会卡在“域名未配置”或者“内容类目不符”上。就算你把域名配好了还有一个更致命的问题——API Key。小程序端的代码是可以通过抓包或者反编译看到的只要请求里带了Key就等于把钱包密码贴在大门上。我在一个早期项目里就吃过这个亏有人直接把我的Key拿去刷额度一天烧掉几十块。所以小程序接大模型铁律就是小程序端绝不直接持有密钥也绝不直接请求大模型服务商。正确做法是在中间加一层自己的后端服务由后端统一保管Key、转发请求、做流式转发和鉴权。1.2 架构选型小程序 中转服务 大模型推荐的整体架构长这样小程序端负责聊天页面的展示、用户输入、流式渲染。只和后端通信不关心大模型是哪家。中转后端接收小程序请求携带用户消息调用大模型API并把结果流式返回给小程序。同时承担鉴权、限流、日志等职责。大模型侧可以是云端API国内国外都有也可以是自建的本地模型服务比如用Ollama部署的开源模型。这个结构的优点很明显API Key安全换模型服务商不用改小程序代码还能在后端统一做缓存和敏感词过滤。下面我用一张表把直连和中转的区别列出来。对比维度小程序直连大模型小程序 后端中转API Key安全极差可被反编译提取安全密钥只存后端域名审核大概率不通过主动权在你自己手里鉴权与限流难以实现可在后端灵活控制换模型服务商需重新发版只改后端配置流式输出支持受平台限制多后端可按需拼接、转发1.3 模型选型怎么定模型选型这事没有标准答案完全看你的使用场景和预算。如果做的是通用闲聊、客服问答国内云厂商的对话模型API响应速度和中文效果都不错按量计费还挺便宜。如果做的是垂直领域比如法律、医疗、教育微调过的开源模型可能比通用大模型更合适。如果只是自己体验、内部工具、或者预算紧张用Ollama在服务器上部署一个7B/13B的开源模型也能跑省掉了按次计费但需要一台有显卡或大内存的机器响应速度也取决于硬件。我自己常用的方案是正式环境用主流云端API测试和demo阶段用Ollama本地模型这样开发期不烧钱上线前切过去就行。接口抽象层建议一开始就做好避免以后迁移时改前端改到哭。2. 核心技术点拆解先搞清楚这几个环节2.1 流式输出打字机效果的关键聊天机器人最影响体验的就是“打字机效果”——大模型一边生成一边把文字推送出来用户看到的是逐字蹦出来的回答而不是转圈等十几秒。云端大模型API基本都支持流式返回SSE格式也就是数据以data: {...}的格式一段一段推过来。后端要做的事就是把这种流式数据原样转发给小程序。小程序端用wx.request配合enableChunked: true就能在onChunkReceived回调里逐段拿到数据然后追加到页面上。很多人在这一步用WebSocket其实不是必需的。大模型对话是单向的请求-响应链路后端也在边生成边返回用普通的HTTPS请求加chunked传输就够了。WebSocket反而增加了心跳、重连这些复杂度收益不大。2.2 鉴权与防刷别让你的接口裸奔中转服务一旦上线就会暴露在小程序的流量里。如果不做任何鉴权别人完全可以绕过你的小程序直接拿你的接口地址去刷模型账单会非常惊人。常见做法是小程序先调用wx.login拿到code传给后端后端再去微信的code2Session接口换openid然后后端发一个自定义token比如JWT给小程序。后续的聊天请求都带上这个token后端先校验token再转发请求。限流也要做。比较实用的是按openid做频控比如每用户每分钟最多N次请求后端用内存或Redis记一下即可。防的是有人写脚本暴力刷。2.3 上下文管理别让模型“失忆”大模型本身不记事儿每次调用都是无状态的。聊天体验要好就要在后端把历史对话拼进messages数组再发给模型。但对话越长token消耗越大成本越高响应也越慢。我的做法是维护一个滑动窗口一个会话最多保留最近6~10轮对话用户消息 助手回复超出部分丢弃。如果消息特别长就按字符数截断保证总长度在模型上下文窗口的合理范围内。前端只需要传message给后端后端自己拼历史小程序端只管显示这样状态管理最省心。3. 实操落地一套可直接跑通的方案3.1 后端用Node.js实现中转接口这里用Node.js Express做示例因为小程序开发者普遍对JS更熟。核心逻辑就是一个POST /api/chat接口接收用户输入带上历史消息请求大模型API然后把结果流式转发。我用的是Node 18自带的fetch不用额外引库。// server.js const express require(express); const app express(); app.use(express.json()); // 这里以某云厂商对话API为例实际地址和鉴权头按你的服务商替换 const LLM_API_URL https://your-llm-provider.example.com/v1/chat/completions; const LLM_API_KEY process.env.LLM_API_KEY; // 简单内存会话实际项目建议用Redis const sessions {}; function getSession(userId) { if (!sessions[userId]) { sessions[userId] { messages: [] }; } return sessions[userId]; } function appendMessage(session, role, content) { session.messages.push({ role, content }); // 滑动窗口最多保留最近10条消息 if (session.messages.length 10) { session.messages session.messages.slice(-10); } } app.post(/api/chat, async (req, res) { const userId req.headers[x-user-id] || anonymous; const userMessage (req.body.message || ).trim(); if (!userMessage) { return res.status(400).json({ error: empty message }); } const session getSession(userId); appendMessage(session, user, userMessage); // 设置响应头SSE流式输出 res.setHeader(Content-Type, text/event-stream; charsetutf-8); res.setHeader(Cache-Control, no-cache); res.setHeader(Connection, keep-alive); try { const llmResponse await fetch(LLM_API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${LLM_API_KEY} }, body: JSON.stringify({ model: your-model-name, messages: session.messages, stream: true, temperature: 0.7, max_tokens: 1024 }) }); if (!llmResponse.ok) { const errText await llmResponse.text(); console.error(LLM API error:, errText); res.write(data: {error: llm_error}\n\n); return res.end(); } const reader llmResponse.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; let fullReply ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); // 按换行拆分SSE数据块 const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { if (!line.startsWith(data:)) continue; const data line.replace(/^data:\s*/, ).trim(); if (data [DONE]) continue; try { const json JSON.parse(data); const delta json.choices?.[0]?.delta?.content || ; if (delta) { fullReply delta; res.write(data: ${JSON.stringify({ delta })}\n\n); } } catch (e) { // 忽略无法解析的块 } } } // 保存完整回复到会话 if (fullReply) { appendMessage(session, assistant, fullReply.trim()); } res.write(data: [DONE]\n\n); res.end(); } catch (err) { console.error(proxy error:, err); res.write(data: {error: proxy_error}\n\n); res.end(); } }); app.listen(3000, () console.log(chat proxy listening on 3000));如果后端用Python FastAPI核心逻辑完全一致读取请求调用大模型流式接口用StreamingResponse转发SSE块。选哪种语言取决于你团队的熟悉程度不构成方案差异。3.2 小程序端聊天页面的完整实现小程序端的核心是三个部分消息列表渲染、输入框交互、流式数据接收。wxml结构很简单外层用scroll-view做消息列表下面放输入框和发送按钮。!-- chat.wxml -- view classchat-page scroll-view classmessage-list scroll-y scroll-into-view{{scrollToId}} view wx:for{{messages}} wx:keyid classmessage-row {{item.role user ? user : assistant}} view classmessage-bubble{{item.content}}/view /view /scroll-view view classinput-bar input bindinputonInput value{{draft}} placeholder说点什么... confirm-typesend bindconfirmsendMessage / button bindtapsendMessage sizemini typeprimary发送/button /view /viewjs层最关键的是用enableChunked: true来接收流式数据。这里有几个细节要注意enableChunked需要在基础库2.20.1以上才支持onChunkReceived里收到的数据是ArrayBuffer需要手动转成字符串流式接收结束后会用complete事件通知这时再把临时内容保存到历史消息中。// chat.js Page({ data: { messages: [], draft: , scrollToId: }, tempContent: , // 当前流式回复的临时内容 onInput(e) { this.setData({ draft: e.detail.value }); }, sendMessage() { const text this.data.draft.trim(); if (!text) return; const userMsg { id: u_ Date.now(), role: user, content: text }; this.setData({ messages: [...this.data.messages, userMsg], draft: }); // 添加一个空的助手消息占位后面流式写入 const assistantMsg { id: a_ Date.now(), role: assistant, content: }; this.setData({ messages: [...this.data.messages, assistantMsg] }); this.tempContent ; this.requestChat(text); }, requestChat(text) { const task wx.request({ url: https://api.yourdomain.com/api/chat, method: POST, enableChunked: true, header: { Content-Type: application/json, x-user-id: wx.getStorageSync(userId) || anonymous }, data: { message: text }, // 分块数据接收 // 注意低版本基础库会自动忽略 enableChunked这里可以做个兼容 }); task.onChunkReceived((response) { const arrayBuffer response.data; const chunk this.arrayBufferToString(arrayBuffer); const lines chunk.split(\n); for (const line of lines) { if (!line.startsWith(data:)) continue; const payload line.replace(/^data:\s*/, ).trim(); if (payload [DONE]) continue; try { const json JSON.parse(payload); if (json.delta) { this.tempContent json.delta; this.updateLastMessage(this.tempContent); } } catch (e) { // 解析失败跳过 } } }); task.onComplete(() { // 流式结束后把最终内容同步到消息列表 this.updateLastMessage(this.tempContent); }); }, updateLastMessage(content) { const messages [...this.data.messages]; const last messages[messages.length - 1]; if (last last.role assistant) { last.content content; this.setData({ messages, scrollToId: last.id }); } }, arrayBufferToString(buffer) { const bytes new Uint8Array(buffer); let str ; const chunkSize 8192; for (let i 0; i bytes.length; i chunkSize) { str String.fromCharCode.apply(null, bytes.subarray(i, i chunkSize)); } return decodeURIComponent(escape(str)); } });这里几个重点再强调一下。第一String.fromCharCode.apply(null, bytes)一次性处理大ArrayBuffer会爆栈所以必须分段转。第二decodeURIComponent(escape(str))是处理中文乱码的土办法实测稳定。第三onChunkReceived的触发频率不固定网络慢的时候可能一次来一大块所以解析时要按行切割并且保留buffer中未完成的行。3.3 参数选择经验温度、max_tokens、模型大模型API里最常见的几个参数这里给出我实测下来的经验值。temperature控制随机性。闲聊、创意写作可以设到0.8~0.9客服、医疗、法律这类严肃场景建议0.2~0.3太低容易答得机械太高容易胡说。max_tokens控制单次回复的最大长度一般1024足够如果回复可能很长调到2048。注意这个限制是包含输入上下文token的所以上下文窗口小的模型历史消息不能拼太多。还有一个容易被忽视的字段是system prompt也就是系统人设。我建议在小程序场景里一定要设置哪怕只是一句“你是一个友好的AI助手”都能显著减少模型答非所问的概率。4. 上线前必须处理的几个坑4.1 域名白名单和本地联调微信小程序的环境分为开发版、体验版和正式版域名校验规则还不太一样。开发版可以在项目设置里勾选“不校验合法域名”这样你本地乱写的接口地址也能通。但体验版和正式版就不行了必须在微信公众平台后台配置request合法域名而且要满足域名必须备案必须是HTTPS线上环境不能带端口号我见过很多人在这一步卡住开发版好好的一上传体验版就全部请求失败报错提示“url not in domain list”。解决办法就是提前在后台把域名配上而且改域名配置不是即时生效的有时要等几分钟建议提前操作。4.2 超时、重试与流式中断小程序默认request超时时间是60秒大模型流式回复如果特别长可能超过这个时间。建议设置timeout: 60000或者提醒用户一次别问太长的问题。流式中断也是个常见问题用户锁屏、切后台、网络波动都会导致连接中断。后端那边模型还在生成但前端已经收不到了。我这边做了一层兜底前端在页面onShow时如果发现上一条消息只有占位没有完整内容就重新拉取会话历史后端保留最近一次完整回复。实测下来这个兜底逻辑能挽回不少体验分。另外服务端要考虑并发问题。如果多人同时使用后端是异步的但要防止同一个用户的多个请求交叉导致上下文乱序。我在会话锁这块吃过亏最简单的处理是同一用户同一时刻只允许一个请求其他请求排队或直接拒绝。4.3 常见报错排查速查表报错现象大概率原因解决办法请求失败提示不在合法域名列表域名未配置或未生效后台配置后等几分钟再试errno 600001: request:fail本地联调没关域名校验开发版勾选不校验合法域名启用enableChunked后无回调基础库版本过低升级到2.20.1以上做版本兼容onChunkReceived收到中文乱码ArrayBuffer转字符串编码问题用分段转换 escape/unescape处理回复内容戛然而止服务端流被截断或超时检查后端错误日志加长超时时间费用异常飙升接口被外部刷量加鉴权和按用户频控注意小程序账号如果因为内容违规或主体资质问题被限制线上请求也会跟着受影响。开发和测试阶段尽量用独立的体验版账号避免影响正式环境。4.4 关于本地部署大模型的补充热词里反复出现“Ollama部署大模型”这里多说一句。如果你只想做内部工具或者demo完全可以用Ollama在服务器上起一个开源模型比如qwen2.5:7b然后把后端接口地址从云端API换成你本地的http://localhost:11434/v1/chat/completions即可因为Ollama是兼容OpenAI格式的。但有两个前提要注意。一是本地服务必须能被小程序访问到也就是你的服务器要有公网IP或者用内网穿透工具临时暴露否则小程序连不上。二是模型推理需要硬件支持7B模型量化版大概需要8GB以上内存能跑但速度一般13B或更大参数模型建议上独显。我自己测试时用一台16GB内存的小服务器跑7B量化版单轮回复速度大概5~10秒做开发预览够用正式商用还是云端API更省心。如果你有GPU机器本地部署的性价比会明显提升。最后聊点我自己的体会小程序做AI聊天技术本身并不复杂真正的难点都在边界上合规、鉴权、成本控制、流式体验优化。我刚开始做的时候一味追求功能结果在一个小群里被刷了几百次接口月底账单吓一跳。后来老老实实把鉴权、限流、日志这套补上心里才踏实。再说一个优化小技巧同样的用户问题如果大模型回答结果比较固定比如常见FAQ可以在后端做一层简单缓存。命中缓存就直接返回省掉一次大模型调用成本和响应速度都改善明显。当然这要求你的后端对消息做归一化处理关键词匹配也是一种折中。这套方案跑通之后你还可以往两个方向扩展一是接入语音输入把用户语音转文字再喂给大模型交互更自然二是给回复内容做富文本渲染让模型用Markdown输出在小程序端用解析库渲染成带格式的卡片。核心思路都一样能跑通一个基础聊天功能后面加什么花样都顺理成章。本文还有配套的精品资源点击获取
小程序接入大模型聊天机器人：架构设计与流式输出实战指南
简介面向小程序开发者这份资料系统讲解如何将大模型聊天机器人快速集成到微信、支付宝等小程序平台覆盖技术选型、数据收集与预处理、模型架构选型、训练评估、云端部署以及前端交互设计与隐私安全等完整链路适合具备基础小程序开发知识并希望接入人工智能能力的读者。资源共2003个文件压缩包大小约2.45MB以JavaScript/TypeScript逻辑代码、JSON配置、WXSS样式、WXML页面结构、WXS脚本等小程序工程文件为主辅以Markdown文档、License协议说明等目录按功能组织便于快速定位。目前已有四百零五位学习者下载。内容中既包含对话消息加解密、Markdown/HTML解析、emoji处理等实用工具代码也涉及RNN、LSTM、Transformer等模型选型思路以及延迟优化、数据同步、隐私加密等落地问题从项目初始化到部署上线可作为从零到上线的小程序人工智能助手完整参考。 小程序接大模型聊天机器人这活儿最近找我咨询的人特别多。很多人第一反应是“直接在小程序里调大模型API不就行了”真上手才发现坑不少域名白名单过不去、API Key没法藏、流式输出不流畅、上下文越聊越乱。我前后给几个项目做过类似接入从踩坑到稳定跑通大概捋出了一套比较顺的流程这篇就把架构设计、核心代码、上线前的那些破事一次讲清楚。适合刚准备做AI聊天类小程序、或者已经在开发但卡在联调阶段的同学参考。1. 整体设计与方案选型先把路走对1.1 为什么小程序不能直连大模型先说最核心的问题小程序平台对网络请求的管控非常严格。你在大模型服务商那拿到的API地址基本不可能直接填进小程序的request合法域名里审核大概率会卡在“域名未配置”或者“内容类目不符”上。就算你把域名配好了还有一个更致命的问题——API Key。小程序端的代码是可以通过抓包或者反编译看到的只要请求里带了Key就等于把钱包密码贴在大门上。我在一个早期项目里就吃过这个亏有人直接把我的Key拿去刷额度一天烧掉几十块。所以小程序接大模型铁律就是小程序端绝不直接持有密钥也绝不直接请求大模型服务商。正确做法是在中间加一层自己的后端服务由后端统一保管Key、转发请求、做流式转发和鉴权。1.2 架构选型小程序 中转服务 大模型推荐的整体架构长这样小程序端负责聊天页面的展示、用户输入、流式渲染。只和后端通信不关心大模型是哪家。中转后端接收小程序请求携带用户消息调用大模型API并把结果流式返回给小程序。同时承担鉴权、限流、日志等职责。大模型侧可以是云端API国内国外都有也可以是自建的本地模型服务比如用Ollama部署的开源模型。这个结构的优点很明显API Key安全换模型服务商不用改小程序代码还能在后端统一做缓存和敏感词过滤。下面我用一张表把直连和中转的区别列出来。对比维度小程序直连大模型小程序 后端中转API Key安全极差可被反编译提取安全密钥只存后端域名审核大概率不通过主动权在你自己手里鉴权与限流难以实现可在后端灵活控制换模型服务商需重新发版只改后端配置流式输出支持受平台限制多后端可按需拼接、转发1.3 模型选型怎么定模型选型这事没有标准答案完全看你的使用场景和预算。如果做的是通用闲聊、客服问答国内云厂商的对话模型API响应速度和中文效果都不错按量计费还挺便宜。如果做的是垂直领域比如法律、医疗、教育微调过的开源模型可能比通用大模型更合适。如果只是自己体验、内部工具、或者预算紧张用Ollama在服务器上部署一个7B/13B的开源模型也能跑省掉了按次计费但需要一台有显卡或大内存的机器响应速度也取决于硬件。我自己常用的方案是正式环境用主流云端API测试和demo阶段用Ollama本地模型这样开发期不烧钱上线前切过去就行。接口抽象层建议一开始就做好避免以后迁移时改前端改到哭。2. 核心技术点拆解先搞清楚这几个环节2.1 流式输出打字机效果的关键聊天机器人最影响体验的就是“打字机效果”——大模型一边生成一边把文字推送出来用户看到的是逐字蹦出来的回答而不是转圈等十几秒。云端大模型API基本都支持流式返回SSE格式也就是数据以data: {...}的格式一段一段推过来。后端要做的事就是把这种流式数据原样转发给小程序。小程序端用wx.request配合enableChunked: true就能在onChunkReceived回调里逐段拿到数据然后追加到页面上。很多人在这一步用WebSocket其实不是必需的。大模型对话是单向的请求-响应链路后端也在边生成边返回用普通的HTTPS请求加chunked传输就够了。WebSocket反而增加了心跳、重连这些复杂度收益不大。2.2 鉴权与防刷别让你的接口裸奔中转服务一旦上线就会暴露在小程序的流量里。如果不做任何鉴权别人完全可以绕过你的小程序直接拿你的接口地址去刷模型账单会非常惊人。常见做法是小程序先调用wx.login拿到code传给后端后端再去微信的code2Session接口换openid然后后端发一个自定义token比如JWT给小程序。后续的聊天请求都带上这个token后端先校验token再转发请求。限流也要做。比较实用的是按openid做频控比如每用户每分钟最多N次请求后端用内存或Redis记一下即可。防的是有人写脚本暴力刷。2.3 上下文管理别让模型“失忆”大模型本身不记事儿每次调用都是无状态的。聊天体验要好就要在后端把历史对话拼进messages数组再发给模型。但对话越长token消耗越大成本越高响应也越慢。我的做法是维护一个滑动窗口一个会话最多保留最近6~10轮对话用户消息 助手回复超出部分丢弃。如果消息特别长就按字符数截断保证总长度在模型上下文窗口的合理范围内。前端只需要传message给后端后端自己拼历史小程序端只管显示这样状态管理最省心。3. 实操落地一套可直接跑通的方案3.1 后端用Node.js实现中转接口这里用Node.js Express做示例因为小程序开发者普遍对JS更熟。核心逻辑就是一个POST /api/chat接口接收用户输入带上历史消息请求大模型API然后把结果流式转发。我用的是Node 18自带的fetch不用额外引库。// server.js const express require(express); const app express(); app.use(express.json()); // 这里以某云厂商对话API为例实际地址和鉴权头按你的服务商替换 const LLM_API_URL https://your-llm-provider.example.com/v1/chat/completions; const LLM_API_KEY process.env.LLM_API_KEY; // 简单内存会话实际项目建议用Redis const sessions {}; function getSession(userId) { if (!sessions[userId]) { sessions[userId] { messages: [] }; } return sessions[userId]; } function appendMessage(session, role, content) { session.messages.push({ role, content }); // 滑动窗口最多保留最近10条消息 if (session.messages.length 10) { session.messages session.messages.slice(-10); } } app.post(/api/chat, async (req, res) { const userId req.headers[x-user-id] || anonymous; const userMessage (req.body.message || ).trim(); if (!userMessage) { return res.status(400).json({ error: empty message }); } const session getSession(userId); appendMessage(session, user, userMessage); // 设置响应头SSE流式输出 res.setHeader(Content-Type, text/event-stream; charsetutf-8); res.setHeader(Cache-Control, no-cache); res.setHeader(Connection, keep-alive); try { const llmResponse await fetch(LLM_API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${LLM_API_KEY} }, body: JSON.stringify({ model: your-model-name, messages: session.messages, stream: true, temperature: 0.7, max_tokens: 1024 }) }); if (!llmResponse.ok) { const errText await llmResponse.text(); console.error(LLM API error:, errText); res.write(data: {error: llm_error}\n\n); return res.end(); } const reader llmResponse.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; let fullReply ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); // 按换行拆分SSE数据块 const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { if (!line.startsWith(data:)) continue; const data line.replace(/^data:\s*/, ).trim(); if (data [DONE]) continue; try { const json JSON.parse(data); const delta json.choices?.[0]?.delta?.content || ; if (delta) { fullReply delta; res.write(data: ${JSON.stringify({ delta })}\n\n); } } catch (e) { // 忽略无法解析的块 } } } // 保存完整回复到会话 if (fullReply) { appendMessage(session, assistant, fullReply.trim()); } res.write(data: [DONE]\n\n); res.end(); } catch (err) { console.error(proxy error:, err); res.write(data: {error: proxy_error}\n\n); res.end(); } }); app.listen(3000, () console.log(chat proxy listening on 3000));如果后端用Python FastAPI核心逻辑完全一致读取请求调用大模型流式接口用StreamingResponse转发SSE块。选哪种语言取决于你团队的熟悉程度不构成方案差异。3.2 小程序端聊天页面的完整实现小程序端的核心是三个部分消息列表渲染、输入框交互、流式数据接收。wxml结构很简单外层用scroll-view做消息列表下面放输入框和发送按钮。!-- chat.wxml -- view classchat-page scroll-view classmessage-list scroll-y scroll-into-view{{scrollToId}} view wx:for{{messages}} wx:keyid classmessage-row {{item.role user ? user : assistant}} view classmessage-bubble{{item.content}}/view /view /scroll-view view classinput-bar input bindinputonInput value{{draft}} placeholder说点什么... confirm-typesend bindconfirmsendMessage / button bindtapsendMessage sizemini typeprimary发送/button /view /viewjs层最关键的是用enableChunked: true来接收流式数据。这里有几个细节要注意enableChunked需要在基础库2.20.1以上才支持onChunkReceived里收到的数据是ArrayBuffer需要手动转成字符串流式接收结束后会用complete事件通知这时再把临时内容保存到历史消息中。// chat.js Page({ data: { messages: [], draft: , scrollToId: }, tempContent: , // 当前流式回复的临时内容 onInput(e) { this.setData({ draft: e.detail.value }); }, sendMessage() { const text this.data.draft.trim(); if (!text) return; const userMsg { id: u_ Date.now(), role: user, content: text }; this.setData({ messages: [...this.data.messages, userMsg], draft: }); // 添加一个空的助手消息占位后面流式写入 const assistantMsg { id: a_ Date.now(), role: assistant, content: }; this.setData({ messages: [...this.data.messages, assistantMsg] }); this.tempContent ; this.requestChat(text); }, requestChat(text) { const task wx.request({ url: https://api.yourdomain.com/api/chat, method: POST, enableChunked: true, header: { Content-Type: application/json, x-user-id: wx.getStorageSync(userId) || anonymous }, data: { message: text }, // 分块数据接收 // 注意低版本基础库会自动忽略 enableChunked这里可以做个兼容 }); task.onChunkReceived((response) { const arrayBuffer response.data; const chunk this.arrayBufferToString(arrayBuffer); const lines chunk.split(\n); for (const line of lines) { if (!line.startsWith(data:)) continue; const payload line.replace(/^data:\s*/, ).trim(); if (payload [DONE]) continue; try { const json JSON.parse(payload); if (json.delta) { this.tempContent json.delta; this.updateLastMessage(this.tempContent); } } catch (e) { // 解析失败跳过 } } }); task.onComplete(() { // 流式结束后把最终内容同步到消息列表 this.updateLastMessage(this.tempContent); }); }, updateLastMessage(content) { const messages [...this.data.messages]; const last messages[messages.length - 1]; if (last last.role assistant) { last.content content; this.setData({ messages, scrollToId: last.id }); } }, arrayBufferToString(buffer) { const bytes new Uint8Array(buffer); let str ; const chunkSize 8192; for (let i 0; i bytes.length; i chunkSize) { str String.fromCharCode.apply(null, bytes.subarray(i, i chunkSize)); } return decodeURIComponent(escape(str)); } });这里几个重点再强调一下。第一String.fromCharCode.apply(null, bytes)一次性处理大ArrayBuffer会爆栈所以必须分段转。第二decodeURIComponent(escape(str))是处理中文乱码的土办法实测稳定。第三onChunkReceived的触发频率不固定网络慢的时候可能一次来一大块所以解析时要按行切割并且保留buffer中未完成的行。3.3 参数选择经验温度、max_tokens、模型大模型API里最常见的几个参数这里给出我实测下来的经验值。temperature控制随机性。闲聊、创意写作可以设到0.8~0.9客服、医疗、法律这类严肃场景建议0.2~0.3太低容易答得机械太高容易胡说。max_tokens控制单次回复的最大长度一般1024足够如果回复可能很长调到2048。注意这个限制是包含输入上下文token的所以上下文窗口小的模型历史消息不能拼太多。还有一个容易被忽视的字段是system prompt也就是系统人设。我建议在小程序场景里一定要设置哪怕只是一句“你是一个友好的AI助手”都能显著减少模型答非所问的概率。4. 上线前必须处理的几个坑4.1 域名白名单和本地联调微信小程序的环境分为开发版、体验版和正式版域名校验规则还不太一样。开发版可以在项目设置里勾选“不校验合法域名”这样你本地乱写的接口地址也能通。但体验版和正式版就不行了必须在微信公众平台后台配置request合法域名而且要满足域名必须备案必须是HTTPS线上环境不能带端口号我见过很多人在这一步卡住开发版好好的一上传体验版就全部请求失败报错提示“url not in domain list”。解决办法就是提前在后台把域名配上而且改域名配置不是即时生效的有时要等几分钟建议提前操作。4.2 超时、重试与流式中断小程序默认request超时时间是60秒大模型流式回复如果特别长可能超过这个时间。建议设置timeout: 60000或者提醒用户一次别问太长的问题。流式中断也是个常见问题用户锁屏、切后台、网络波动都会导致连接中断。后端那边模型还在生成但前端已经收不到了。我这边做了一层兜底前端在页面onShow时如果发现上一条消息只有占位没有完整内容就重新拉取会话历史后端保留最近一次完整回复。实测下来这个兜底逻辑能挽回不少体验分。另外服务端要考虑并发问题。如果多人同时使用后端是异步的但要防止同一个用户的多个请求交叉导致上下文乱序。我在会话锁这块吃过亏最简单的处理是同一用户同一时刻只允许一个请求其他请求排队或直接拒绝。4.3 常见报错排查速查表报错现象大概率原因解决办法请求失败提示不在合法域名列表域名未配置或未生效后台配置后等几分钟再试errno 600001: request:fail本地联调没关域名校验开发版勾选不校验合法域名启用enableChunked后无回调基础库版本过低升级到2.20.1以上做版本兼容onChunkReceived收到中文乱码ArrayBuffer转字符串编码问题用分段转换 escape/unescape处理回复内容戛然而止服务端流被截断或超时检查后端错误日志加长超时时间费用异常飙升接口被外部刷量加鉴权和按用户频控注意小程序账号如果因为内容违规或主体资质问题被限制线上请求也会跟着受影响。开发和测试阶段尽量用独立的体验版账号避免影响正式环境。4.4 关于本地部署大模型的补充热词里反复出现“Ollama部署大模型”这里多说一句。如果你只想做内部工具或者demo完全可以用Ollama在服务器上起一个开源模型比如qwen2.5:7b然后把后端接口地址从云端API换成你本地的http://localhost:11434/v1/chat/completions即可因为Ollama是兼容OpenAI格式的。但有两个前提要注意。一是本地服务必须能被小程序访问到也就是你的服务器要有公网IP或者用内网穿透工具临时暴露否则小程序连不上。二是模型推理需要硬件支持7B模型量化版大概需要8GB以上内存能跑但速度一般13B或更大参数模型建议上独显。我自己测试时用一台16GB内存的小服务器跑7B量化版单轮回复速度大概5~10秒做开发预览够用正式商用还是云端API更省心。如果你有GPU机器本地部署的性价比会明显提升。最后聊点我自己的体会小程序做AI聊天技术本身并不复杂真正的难点都在边界上合规、鉴权、成本控制、流式体验优化。我刚开始做的时候一味追求功能结果在一个小群里被刷了几百次接口月底账单吓一跳。后来老老实实把鉴权、限流、日志这套补上心里才踏实。再说一个优化小技巧同样的用户问题如果大模型回答结果比较固定比如常见FAQ可以在后端做一层简单缓存。命中缓存就直接返回省掉一次大模型调用成本和响应速度都改善明显。当然这要求你的后端对消息做归一化处理关键词匹配也是一种折中。这套方案跑通之后你还可以往两个方向扩展一是接入语音输入把用户语音转文字再喂给大模型交互更自然二是给回复内容做富文本渲染让模型用Markdown输出在小程序端用解析库渲染成带格式的卡片。核心思路都一样能跑通一个基础聊天功能后面加什么花样都顺理成章。本文还有配套的精品资源点击获取
