简介：这份资源是一套微信小程序AI聊天页面的完整前端源码，面向希望快速上手小程序对接大语言模型的开发者与学习者，尤其适合想体验AI对话能力、又不想从零搭建界面的初中级前端人员。压缩包共6个文件，约386KB，包含wxml页面结构、wxss样式、js逻辑、json配置以及bot与user两张png头像图片，覆盖了聊天界面从布局到交互的核心文件，结构精简，便于直接导入微信开发者工具运行调试。资源的核心价值在于演示了小程序端如何接入LLM语言大模型并完成对话流程，同时支持自定义AI人设，例如儿童教育领域专家、商城客服或法律顾问，并可设定回复语气与具体要求，方便读者在此基础上扩展成客服、教育、咨询等实际场景。目前已有978人学习下载，适合作为小程序AI对话功能的入门参考与二次开发起点。
1. 微信小程序聊天页面接大模型：为什么“能跑通”和“能上线”是两回事
很多人第一次做 AI 聊天小程序，卡住的地方不是模型调用，而是聊天页面本身。微信小程序的scroll-view、输入框键盘顶起、消息气泡高度自适应、流式输出时的滚动跟随，这几件事凑在一起，能把一个看起来简单的对话界面拖成一周的活。更别说还要对接 LLM 语言大模型，处理流式返回、上下文裁剪、超时重试。
这个标题讲的就是这条链路：微信小程序聊天页面 + AI 大语言模型，把 LLM 语言大模型源码接进小程序里。它解决的是“用户在小程序里发一句话，模型流式吐字，页面像微信一样滚起来”这件事。适合谁？适合已经会写小程序基础页面、想加 AI 对话能力的开发者，也适合后端同学想搞清楚小程序侧到底要什么接口。
我先把结论放前面：小程序端不要直连模型厂商接口，密钥会裸奔；聊天页面不要用scroll-view硬撑，流式输出会抖；上下文不要全量回传，token 账单会教你做人。下面按“页面怎么做 → 接口怎么接 → 坑在哪 → 怎么验证”推一遍。
2. 聊天页面先立住：消息列表、输入区与流式滚动的三个关键实现
2.1 消息数据结构与渲染层设计
聊天页面的核心不是 UI，是数据结构。一条消息至少要有id、role、content、status、createTime。role区分user和assistant，status区分sending、streaming、done、failed。没有status，你就没法在流式输出时显示光标，也没法在失败时给重试按钮。
我一般用data.messages存全量列表，用data.scrollTop控制滚动。渲染时用wx:for遍历，气泡宽度用max-width: 70%，高度自适应。注意：小程序里scroll-view必须给固定高度，否则scroll-into-view不生效。常见做法是用flex布局，把scroll-view的height设成calc(100vh - 输入区高度)，输入区高度用rpx写死。
// pages/chat/chat.js Page({ data: { messages: [], // 全量消息列表 scrollIntoView: '', // 锚点 id，用于滚动到底部 inputValue: '', // 输入框内容 isStreaming: false // 是否正在流式输出 }, // 追加一条用户消息 appendUserMessage(content) { const msg = { id: `u_${Date.now()}`, role: 'user', content, status: 'done', createTime: Date.now() }; this.setData({ messages: [...this.data.messages, msg], inputValue: '' }); this.scrollToBottom(); }, // 追加一条助手占位消息，后续流式填充 appendAssistantPlaceholder() { const msg = { id: `a_${Date.now()}`, role: 'assistant', content: '', status: 'streaming', createTime: Date.now() }; this.setData({ messages: [...this.data.messages, msg] }); return msg.id; }, // 滚动到底部：用最后一条消息 id 做锚点 scrollToBottom() { const list = this.data.messages; if (!list.length) return; this.setData({ scrollIntoView: `msg_${list[list.length - 1].id}` }); } });逻辑说明：appendUserMessage负责把用户输入落成一条完整消息，同时清空输入框；appendAssistantPlaceholder先塞一条空内容、状态为streaming的助手消息，等流式数据回来再逐段setData更新content。scrollToBottom用最后一条消息的 id 做锚点，配合scroll-into-view实现滚动。
参数说明：id用时间戳加前缀，避免同一毫秒内冲突；status是后续做“重新生成”和“停止输出”的依据；scrollIntoView的值必须和wxml里id="msg_{{item.id}}"对应，少一个前缀就滚不动。
2.2 流式输出的 setData 策略与性能边界
流式输出最容易翻车的地方是setData频率。模型每吐一个字就setData一次，小程序逻辑层和渲染层通信会堵，页面直接卡成 PPT。血泪经验：按时间片合并，比如每 80 到 120 毫秒更新一次，或者按字符数累积到 8 到 12 个字符再更新。
// 流式更新缓冲区：按时间片合并 setData let streamBuffer = ''; let streamTimer = null; const FLUSH_INTERVAL = 100; // 毫秒 function flushStream(page, msgId) { if (!streamBuffer) return; const list = page.data.messages; const idx = list.findIndex(m => m.id === msgId); if (idx === -1) return; // 只更新目标消息的 content，避免全量 diff page.setData({ [`messages[${idx}].content`]: list[idx].content + streamBuffer }); streamBuffer = ''; } function onStreamChunk(page, msgId, chunk) { streamBuffer += chunk; if (!streamTimer) { streamTimer = setTimeout(() => { flushStream(page, msgId); streamTimer = null; }, FLUSH_INTERVAL); } }逻辑说明：onStreamChunk收到分片后先塞进streamBuffer，不立即setData；flushStream按固定间隔把缓冲区内容合并进目标消息。用messages[${idx}].content这种路径更新，只改一条消息的字段，比整个messages数组重新赋值轻得多。
参数说明：FLUSH_INTERVAL设 100 毫秒是折中值，设太小等于没合并，设太大用户会觉得字是一段一段蹦。如果模型吐字特别快，可以改成按字符数阈值触发，比如缓冲区超过 10 个字符就 flush。注意streamTimer要在流结束时清掉，否则最后一段可能丢。
2.3 输入区键盘顶起与滚动跟随的配合
小程序输入框在真机上键盘弹起时，页面会被顶上去，scroll-view高度如果写死100vh，底部消息会被键盘挡住。常见做法是用adjust-position配合bindfocus和bindblur，在聚焦时把scroll-view高度改小，失焦时恢复。
<!-- pages/chat/chat.wxml 片段 --> <scroll-view scroll-y scroll-into-view="{{scrollIntoView}}" scroll-with-animation style="height: {{scrollHeight}}px;" > <view wx:for="{{messages}}" wx:key="id" id="msg_{{item.id}}"> <view class="bubble {{item.role}}">{{item.content}}</view> </view> </scroll-view> <view class="input-bar"> <input value="{{inputValue}}" bindinput="onInput" bindfocus="onFocus" bindblur="onBlur" adjust-position="{{false}}" confirm-type="send" bindconfirm="onSend" /> </view>逻辑说明：adjust-position="{{false}}"关掉系统自动顶起，改由我们自己控制scrollHeight。onFocus里把scrollHeight减去键盘高度，onBlur恢复。scroll-with-animation让滚动平滑，但流式输出时如果频繁触发滚动，动画会排队，建议只在用户发送消息和流结束时开动画，流式过程中用scroll-top直接跳。
参数说明：scrollHeight初始值用wx.getSystemInfoSync().windowHeight减去输入区高度；键盘高度从bindfocus的e.detail.height拿。注意不同机型键盘高度不一样，别写死。
3. 对接 LLM 语言大模型：从请求封装到流式解析的完整链路
3.1 为什么必须走自建后端中转
小程序端直连模型厂商接口有三个硬伤：第一，API Key 写在小程序里，反编译就能拿到；第二，小程序wx.request不支持流式读取，只能等完整响应；第三，模型厂商接口域名不在小程序合法域名列表里，真机直接请求失败。所以标准链路是：小程序 → 自建后端 → 模型厂商。
后端要做四件事：鉴权（识别是哪个用户）、限流（防止刷）、上下文管理（裁剪历史）、流式转发（把模型的 SSE 转成小程序能收的格式）。小程序侧只跟自己的后端打交道，接口设计成POST /chat/stream，请求体带sessionId和message，响应用分块传输。
// utils/request.js：小程序侧流式请求封装 // 注意：小程序原生 wx.request 不支持流式，这里用 enableChunked function streamChat({ sessionId, message, onChunk, onDone, onError }) { const task = wx.request({ url: 'https://your-backend.example.com/chat/stream', method: 'POST', enableChunked: true, // 关键：开启分块接收 header: { 'content-type': 'application/json', 'authorization': `Bearer ${wx.getStorageSync('token')}` }, data: { sessionId, message }, success(res) { // 非流式兜底：如果后端没走 chunked，这里拿到完整结果 if (res.statusCode !== 200) { onError(new Error(`HTTP ${res.statusCode}`)); } }, fail(err) { onError(err); } }); // 监听分块数据 task.onChunkReceived((res) => { // res.data 是 ArrayBuffer，需要转成字符串 const text = arrayBufferToString(res.data); // 按 SSE 格式解析，取 data: 后面的内容 const lines = text.split('\n'); lines.forEach(line => { if (line.startsWith('data:')) { const payload = line.slice(5).trim(); if (payload === '[DONE]') { onDone(); } else { try { const json = JSON.parse(payload); onChunk(json.delta || ''); } catch (e) { // 分块可能截断 JSON，忽略本次，等下一块 } } } }); }); return task; } // ArrayBuffer 转字符串，处理 UTF-8 中文 function arrayBufferToString(buffer) { const bytes = new Uint8Array(buffer); let result = ''; let i = 0; while (i < bytes.length) { const byte = bytes[i]; if (byte < 0x80) { result += String.fromCharCode(byte); i += 1; } else if (byte < 0xE0) { result += String.fromCharCode(((byte & 0x1F) << 6) | (bytes[i + 1] & 0x3F)); i += 2; } else { result += String.fromCharCode( ((byte & 0x0F) << 12) | ((bytes[i + 1] & 0x3F) << 6) | (bytes[i + 2] & 0x3F) ); i += 3; } } return result; }逻辑说明：enableChunked: true是小程序侧接收流式数据的关键开关，不开就只能等完整响应。onChunkReceived每次拿到一段ArrayBuffer，先转字符串，再按 SSE 的data:行解析。[DONE]是结束标记，收到就调onDone。JSON 解析失败不要慌，分块可能把一条 JSON 截成两半，等下一块拼上再解析。
参数说明：sessionId用于后端关联上下文，同一个会话复用；authorization用登录态换的 token，别把模型厂商的 Key 放这里。arrayBufferToString只处理了 UTF-8 三字节以内的情况，中文基本够用，遇到 emoji 四字节字符会乱码，需要补四字节分支。
3.2 后端流式转发的接口约定与上下文裁剪
后端接口建议统一成 SSE 格式，每条消息data: {"delta":"..."}，结束发data: [DONE]。这样小程序侧解析逻辑简单，换模型厂商也不用改前端。上下文裁剪放在后端做，按 token 数截断，保留最近 N 轮对话加系统提示词。
# 后端伪代码：流式转发 + 上下文裁剪 # 假设用某模型 SDK，具体调用按厂商文档来 import json MAX_CONTEXT_TOKENS = 3000 # 上下文 token 上限 SYSTEM_PROMPT = "你是一个简洁的助手，回答控制在三句话以内。" def build_messages(session_id, user_message): history = load_history(session_id) # 从存储读历史 messages = [{"role": "system", "content": SYSTEM_PROMPT}] # 从最近往远取，直到接近 token 上限 total = count_tokens(SYSTEM_PROMPT) picked = [] for msg in reversed(history): t = count_tokens(msg["content"]) if total + t > MAX_CONTEXT_TOKENS: break picked.append(msg) total += t messages.extend(reversed(picked)) messages.append({"role": "user", "content": user_message}) return messages def stream_chat(session_id, user_message): messages = build_messages(session_id, user_message) # 调用模型流式接口，逐块 yield for chunk in model_client.chat_stream(messages): delta = chunk.choices[0].delta.content or "" if delta: yield f"data: {json.dumps({'delta': delta}, ensure_ascii=False)}\n\n" yield "data: [DONE]\n\n" save_history(session_id, user_message)逻辑说明：build_messages从最近的历史往前取，累加 token 直到接近上限就停，保证不超模型上下文窗口。stream_chat把模型返回的 delta 包成 SSE 格式，ensure_ascii=False保证中文不被转义。最后存历史，注意存的是用户消息和助手完整回复，不是分片。
参数说明：MAX_CONTEXT_TOKENS要留出模型最大输出 token 的空间，比如模型窗口 4096，输出留 1024，上下文就设 3000。count_tokens可以用厂商提供的 tokenizer，粗略估算按字符数除以 1.5 也行，但中文场景误差大，建议用准确工具。
3.3 超时、重试与“停止输出”的实现
流式请求可能中途断掉，用户也可能点“停止输出”。超时用wx.request的timeout字段，设 30 秒到 60 秒。重试不要自动重试流式请求，容易重复扣费，改成在消息气泡上给“重新生成”按钮。停止输出用task.abort()，同时通知后端中断模型调用。
// 停止输出：中断请求并标记消息状态 function stopStreaming(page, task, msgId) { if (task) { task.abort(); // 中断小程序侧请求 } const list = page.data.messages; const idx = list.findIndex(m => m.id === msgId); if (idx !== -1) { page.setData({ [`messages[${idx}].status`]: 'done' }); } // 通知后端中断，避免继续消耗 token wx.request({ url: 'https://your-backend.example.com/chat/abort', method: 'POST', data: { sessionId: page.data.sessionId } }); }逻辑说明：task.abort()只中断小程序侧接收，后端可能还在跑，所以补一个/chat/abort通知后端停。消息状态改成done，让光标消失。注意abort后onChunkReceived不会再触发，但已经缓冲的内容要 flush 一次，否则最后几个字丢。
参数说明：timeout建议 60000，模型首字延迟高的时候 30 秒不够。重试按钮触发时，先把上一条助手消息状态改成failed，再重新走一遍appendAssistantPlaceholder，不要在原消息上追加，否则内容会混。
4. 避坑与排查：聊天小程序接大模型最常见的五个翻车点
4.1 真机流式不生效，开发者工具正常
现象：开发者工具里流式吐字正常，真机上一等就是完整回复，没有逐字效果。原因：enableChunked在部分基础库版本或部分机型上行为不一致，且开发者工具模拟了分块，真机走的是另一套网络栈。解决：先确认基础库版本，enableChunked需要较新版本；再检查后端响应头有没有Transfer-Encoding: chunked，如果后端框架默认开了 gzip 压缩，分块会被缓冲。关掉该接口的压缩，或者显式设置X-Accel-Buffering: no。
4.2 中文乱码，英文正常
现象：流式返回的英文没问题，中文变成问号或乱码。原因：ArrayBuffer转字符串时按单字节处理，UTF-8 中文占三字节，被拆开就乱。解决：用TextDecoder替代手写转换，小程序环境支持new TextDecoder('utf-8')。如果分块把多字节字符截断，需要维护一个字节缓冲区，等下一个分块拼上再解码。
4.3 消息列表越长越卡，滚动掉帧
现象：对话超过 50 条后，滚动明显卡顿，流式输出时更严重。原因：setData全量更新messages数组，每次 diff 整个列表。解决：用路径更新只改目标字段；列表超过 100 条做分页或虚拟列表，只渲染可视区域；历史消息折叠，默认只显示最近 20 条，上拉加载更多。
4.4 上下文超限，模型返回报错或截断
现象：聊了十几轮后，模型开始报错或回复不完整。原因：历史消息全量回传，超过模型上下文窗口。解决：后端按 token 裁剪，保留最近 N 轮；系统提示词固定占一部分；用户消息过长时先截断或提示用户。注意裁剪要成对裁，别把用户消息和助手回复拆散。
4.5 密钥泄露与接口被刷
现象：后端接口被陌生 IP 高频调用，token 消耗异常。原因：接口没鉴权或鉴权太弱，小程序端 token 被复用。解决：接口必须带登录态校验；按用户维度限流，比如每分钟 10 次；后端记录每次调用的 token 消耗，异常时告警；模型厂商的 Key 只存在后端环境变量里，绝不下发到小程序。
5. 上线前怎么验证：三个可复现的检查动作与一个压测技巧
先说验证方法，再说一个我常用的压测技巧。上线前别只看“能回复”，要看“断网、超时、并发”三种情况下的表现。
第一个检查动作：断网重连。把手机切飞行模式，发一条消息，看页面是否显示失败状态和重试按钮；恢复网络后点重试，看是否能正常走完流式。这个动作能暴露status字段没处理、错误没捕获的问题。
第二个检查动作：超时中断。在后端把模型调用延迟调到 40 秒，看小程序 60 秒超时前是否正常显示“正在输入”，超时后是否给出提示。注意超时后要abort请求，否则后端还在跑。
第三个检查动作：上下文边界。连续发 30 轮短消息，看第 30 轮是否还能正常回复；再发一条超长消息（比如 2000 字），看后端是否正确截断或提示。这个动作能验证 token 裁剪逻辑。
压测技巧：用脚本模拟 20 个并发会话，每个会话发 10 轮，观察后端 token 消耗速率和响应延迟。重点看首字延迟（TTFB）和流式结束时间。如果首字延迟超过 3 秒，用户会觉得卡；如果并发下延迟飙升，说明后端模型调用没做连接池或限流。
# 用 curl 模拟流式请求，观察分块到达时间 curl -N -X POST https://your-backend.example.com/chat/stream \ -H "content-type: application/json" \ -H "authorization: Bearer test-token" \ -d '{"sessionId":"test-001","message":"你好"}' \ --no-buffer逻辑说明：-N关闭 curl 的缓冲，--no-buffer确保逐块输出，这样你能看到每个data:行到达的时间。如果所有行几乎同时出现，说明后端没真正流式，可能被压缩或缓冲了。
参数说明：sessionId用固定值方便复现；authorization用测试 token，别用真实用户。观察重点：第一条data:和最后一条[DONE]的时间差，以及中间是否有超过 2 秒的空档。
最后说个我自己的习惯：每次改完流式相关代码，先在开发者工具里用“弱网模拟”跑一遍，再去真机跑一遍。开发者工具的弱网和真机弱网不是一回事，真机上 4G 切 Wi-Fi 的瞬间最容易暴露分块解析的边界问题。这个方案值不值得做？如果你要做的是对话类小程序，聊天页面加 LLM 对接是绕不过去的基础设施，把上面这几个点踩实，后面加语音、加图片、加多轮工具调用都是在这个骨架上长。希望帮到你。
本文还有配套的精品资源，点击获取
