企业官网建设流程全解析

简介：这份微信小程序AI机器人对话模板面向具备一定编程基础、希望快速搭建智能聊天类小程序的开发者，基于HBuilder编写，提供无接口的纯前端页面与交互模板，接口部分需自行对接调配，适合用作课程设计、功能原型或产品Demo的起点。压缩包共约2000个文件、7.04MB，以JavaScript、TypeScript、JSON、Vue、WXML/WXSS及Markdown文档等为主，分别承担脚本逻辑、数据配置、页面结构、样式表现与使用说明，目录组织清晰，便于按模块查阅和二次改造。已有969人学习下载，说明其作为对话类小程序模板具有一定参考价值。读者可从中获得对话页布局、消息列表、输入交互与基础配置的模板骨架，也能借助说明文档理解工程结构与依赖关系，从而减少从零搭建页面和基础结构的时间，把精力集中在接口联调、业务逻辑与界面定制上。

1. 从输入框到模型再回来：这套 AI 对话小程序模板到底省了哪几步

上周有人丢给我一个压缩包，说是在网上找的 AI 人工智能机器人对话微信小程序模板，问能不能直接挂上自己的模型用。我打开看了一眼：会话列表、消息气泡、输入框、发送按钮、 loading 态都在，缺的只是把请求打到自己的服务端。这类微信小程序模板的价值不在界面多好看，而在于它已经把 wx.request 的封装、滚动到底、键盘顶起输入框、按钮防重复点击这些琐碎活儿串好了。你要做的其实只有三件事：换掉请求地址、接上自己的模型、补上内容安全。它适合手上已经有一个模型服务、想在一两天内做出一个能发给同事试用的对话入口的人；不适合指望开箱就能对外运营的人，那还差用户体系、调用限额和审核流程。下面按我拆包的顺序写，从目录骨架一路写到真机上最容易翻车的那几个点。

2. 拆骨架：四个目录层级与一次对话的完整调用链

拿到一个不认识的模板，我一般不看页面长什么样，先看 app.json 里注册了几个页面、utils 里抽了什么出来。因为界面是可以改的，调用链改起来才费劲。这套 AI 聊天机器人模板的结构属于常见的那一类：一个会话列表页、一个聊天页、一个请求封装、一个消息气泡组件。看懂这四层，后面换模型、换接口、加功能都是在这四层里动刀，不会互相牵连。

2.1 目录结构与四个文件层的职责

先用编辑器把整个包打开，重点看这几个位置。页面层只负责数据和渲染的绑定，请求层只负责把消息数组发出去、把回复拿回来，组件层只管一条消息怎么显示。分清这三件事，你改流式输出的时候就不用去动 wxml。

utils/request.js是整个模板里最值得先读的文件。合格的封装会把 baseURL、超时时间、header 里的鉴权字段、以及非 200 状态的兜底文案都收在一处。如果模板里是直接把 URL 写在页面里的，那基本是个演示级代码，你得先把它抽出来，否则后面加流式、加超时重试会非常难受。

2.2 一次发送的调用链：从 bindconfirm 到 setData

用户在输入框敲完回车，到屏幕上出现回复，中间发生的事比想象中多。我把它拆成六步：读输入框内容、清空输入框、往消息数组里 push 一条用户消息、push 一条内容为空的机器人占位消息、发起请求、拿到结果后按索引更新占位消息。占位消息这一步很关键，没有它，用户在这两三秒里看到的是「点了没反应」。

// pages/chat/chat.js 发送主流程（简化版） const request = require('../../utils/request') Page({ data: { messages: [], // { role: 'user' | 'assistant', content, status } inputValue: '', sending: false, scrollInto: '' // 配合 scroll-into-view 实现自动滚到底 }, onInput(e) { this.setData({ inputValue: e.detail.value }) }, async onSend() { const text = this.data.inputValue.trim() if (!text || this.data.sending) return // 双保险：空内容与重复点击 const messages = this.data.messages.concat([ { role: 'user', content: text, status: 'ok' }, { role: 'assistant', content: '', status: 'loading' } ]) const idx = messages.length - 1 // 记住占位消息的下标 this.setData({ messages, inputValue: '', sending: true, scrollInto: 'msg-' + idx }) try { const reply = await request.chat({ history: messages.slice(0, idx), // 占位消息不参与上下文 question: text }) // 用路径更新，避免整个数组重传 this.setData({ [`messages[${idx}].content`]: reply, [`messages[${idx}].status`]: 'ok' }) } catch (err) { this.setData({ [`messages[${idx}].content`]: '网络开小差了，点我重试', [`messages[${idx}].status`]: 'error' }) } finally { this.setData({ sending: false }) this.saveHistory() } } })

代码里有两个容易被忽略的参数。messages.slice(0, idx)是为了把占位消息排除在上下文之外，否则发给模型的对话里会多出一条空白的 assistant 记录，有些模型会因此返回很奇怪的结果。scrollInto绑到 wxml 里的scroll-into-view，值必须是元素的 id，所以列表项要写id="msg-{{index}}"，拼错一个字符就是「不回滚」这个玄学现象。sending这个开关放在 data 里而不是页面实例上，是为了顺手把发送按钮置灰，用户能看见状态。

2.3 十分钟跑起来的最小配置

想先看到东西跑起来，改三个地方就够：页面注册、项目配置、请求地址。第一步确认app.json里 chat 页面已经注册，没有就加上，路径必须和实际目录一模一样。

{ "pages": [ "pages/index/index", "pages/chat/chat" ], "window": { "navigationBarTitleText": "AI 助手", "navigationBarBackgroundColor": "#ffffff", "navigationBarTextStyle": "black", "backgroundTextStyle": "light" }, "style": "v2", "sitemapLocation": "sitemap.json" }

第二步打开project.config.json，把appid换成自己的。模板里常见的是测试号或者留空，留空的情况下开发者工具能跑，但真机上登录、内容安全、云开发全都用不了，所以第一件事就是换掉。

{ "appid": "你自己的小程序 appid", "compileType": "miniprogram", "libVersion": "2.30.0", "setting": { "urlCheck": true, "es6": true, "enhance": true, "postcss": true, "minified": true } }

第三步是域名。小程序后台的开发设置里配 request 合法域名，必须是 HTTPS、必须备案、证书链完整，端口只能是 443。很多人图省事在开发者工具里勾了「不校验合法域名」，本地跑得飞起，一上真机全部超时，这就是后面第 5 章第一个坑的来源。配完域名先在工具里点「真机调试」发一条消息，能收到回复再往下做，不然后面排查流式问题时你会分不清是域名问题还是代码问题。

提示：域名配置修改后要重新编译并清一次缓存才生效，工具侧有时会保留旧的校验结果。

3. 接模型：三种请求方式的取舍与上下文预算表

模板默认给的通常是一次性返回：发过去，等三秒，整段回复蹦出来。体验上比流式差一截，但实现最简单、失败最好兜底。我一般建议先用一次性返回把链路打通，确认域名、鉴权、错误码都对了，再改成流式。顺序反了，一旦真机没反应，你根本判断不了是网络问题、服务端没 flush，还是解码写错了。

3.1 wx.request、轮询与 WebSocket 的取舍

三条路都能把回复送到小程序里，差别在成本和可控性。

一次性返回的坑在于超时。模型生成一段八百字的回答经常超过 10 秒，而wx.request默认超时 60 秒，本身够用，但中间如果挂了一层网关，网关的读超时往往只有 15 秒或 30 秒，表现就是「短问题正常，长问题必失败」。我通常会在请求封装里显式写timeout: 60000，同时把网关的读超时调到 65 秒以上，两边留出余量。轮询我不推荐用在对话上，一秒一次请求，二十轮对话就是二十次计费调用，成本会很难看。

3.2 流式输出落地：enableChunked 与服务端 flush

流式这条路上，小程序侧只要加两个参数：enableChunked: true打开分块接收，然后监听onChunkReceived。真正的麻烦在服务端和编码上。服务端必须用text/event-stream或application/octet-stream输出，并且每写完一小段就 flush，不能等整个响应结束。如果前面有 Nginx，要关掉proxy_buffering，否则 Nginx 会把你的分块攒成一整块再转发，小程序侧看到的效果和一次性返回一模一样，你会怀疑是自己代码写错了。

// utils/request.js 流式请求封装 function chatStream({ history, question, onDelta, onDone, onError }) { const task = wx.request({ url: 'https://your-domain.com/api/chat/stream', method: 'POST', timeout: 60000, enableChunked: true, // 关键：开启分块接收 header: { 'content-type': 'application/json', 'authorization': 'Bearer ' + getToken() }, data: { history, question }, success: () => onDone && onDone(), fail: (e) => onError && onError(e) }) let buffer = new Uint8Array(0) const decoder = new TextDecoder('utf-8') task.onChunkReceived((res) => { // res.data 是 ArrayBuffer，可能从汉字中间切断，必须拼接后再解码 const chunk = new Uint8Array(res.data) const merged = new Uint8Array(buffer.length + chunk.length) merged.set(buffer, 0) merged.set(chunk, buffer.length) buffer = merged // 找出最后一个换行，之前的都是完整行，剩下的留到下次 let text = decoder.decode(buffer, { stream: true }) const lastBreak = text.lastIndexOf('\n') if (lastBreak === -1) return const complete = text.slice(0, lastBreak) buffer = new TextEncoder().encode(text.slice(lastBreak + 1)) complete.split('\n').forEach((line) => { const trimmed = line.trim() if (!trimmed.startsWith('data:')) return const payload = trimmed.slice(5).trim() if (payload === '[DONE]') return try { const json = JSON.parse(payload) onDelta && onDelta(json.delta || '') } catch (e) { // 半截 JSON 直接丢弃，等下个分块补齐 } }) }) return task }

这段代码里最值钱的是那个buffer。分块是按字节切的，一个 UTF-8 汉字占三字节，切成 1+2 两半是常态，直接decode会得到乱码或问号。所以要先拼接、再按行切、只处理完整的行，剩下的塞回 buffer。{ stream: true }参数的作用就是告诉解码器「后面还有」，它会把不完整的字节序列暂存起来。另外success回调在流式模式下只表示连接关闭，不代表内容成功，真正的结束标志是服务端发的[DONE]或者最后一个分块。这一点如果不注意，很容易出现「回复显示完了但按钮一直是 loading」的情况。

服务端那边我一般用最朴素的方式写，Node 里就是设置好响应头，然后边读模型的流边 write。

// server/chat.js（Node + Express 片段） app.post('/api/chat/stream', async (req, res) => { res.setHeader('Content-Type', 'text/event-stream; charset=utf-8') res.setHeader('Cache-Control', 'no-cache') res.setHeader('Connection', 'keep-alive') res.setHeader('X-Accel-Buffering', 'no') // 让 Nginx 不要缓冲 res.flushHeaders() const stream = await model.stream(req.body) // 你的模型 SDK for await (const part of stream) { const delta = part.text || '' if (!delta) continue res.write('data: ' + JSON.stringify({ delta }) + '\n\n') } res.write('data: [DONE]\n\n') res.end() })

X-Accel-Buffering: no这一行是给 Nginx 看的，比改配置文件方便，但如果前面有 CDN 或者负载均衡，仍然需要在那一层单独关缓冲，这一点不同环境差异很大，我没有通用答案，只能一层一层试。res.flushHeaders()的作用是先把响应头推出去，避免客户端一直卡在等待首字节。写完[DONE]一定要end()，否则连接会挂在那里直到超时，用户侧表现为「最后一个字出来了，但发送按钮过很久才恢复」。

注意：enableChunked需要基础库 2.20.2 及以上，模板里libVersion写得太低会静默失效，不报错，只是变成一次性返回。

3.3 上下文预算：滑窗、摘要与 token 估算表

模板默认往往是把整个messages数组原样发过去，聊到三十轮之后就会开始出问题：请求体越来越大、首字延迟上升、费用直线上升、模型开始答非所问。这不是模型变笨了，是上下文里塞了太多无关内容。我的做法是三条线同时控：条数上限、字符上限、单条截断。

摘要压缩的做法是：当消息数超过阈值，把最前面的若干轮丢给模型做一次「用三句话概括这段对话里的用户需求与已确认信息」，把结果作为一条system消息插到最前面，然后删掉那些轮次。这一步要单独计费，所以别每轮都做，我一般在会话空闲时或者轮次到 12 的倍数时才触发。字符上限的估算不用太精确，中文大致按 1 字 1 token 上下浮动，英文按 4 字符 1 token，留 20% 余量就够工程用了。

4. 会话体验：滚动、打字机与 Markdown 渲染的三个实现细节

功能通了之后，决定这套 AI 聊天机器人好不好用的就不是模型了，是手感。滚动会不会跳、字是不是一个个出来、代码块有没有高亮、键盘弹起来会不会挡住输入框，这些细节在演示时特别明显，而这套微信小程序模板的价值恰恰在于它替你处理了其中一部分。

4.1 消息数据结构与 setData 的增量更新

小程序里setData是跨线程通信，传的数据量越大越慢。一个常见的错误写法是每收到一个字就this.setData({ messages: this.data.messages })，把整个数组重新传一遍。二十轮对话之后，数组里可能有几万字，每一帧传几万字，页面就开始卡，滑动掉帧，输入框有延迟。

正确做法是用路径更新，只传变化的那一条，而且只传变化的那部分。

// 只更新最后一条消息的内容，不重传整个数组 updateLastMessage(text) { const idx = this.data.messages.length - 1 this.setData({ [`messages[${idx}].content`]: text }) }

如果消息数量可能超过 100 条，还要额外做一件事：列表只渲染最近 50 条，往上翻的时候用「查看更早的消息」按钮加载。wx:for里放几百个节点，滚动性能会明显下降，这不是 setData 的问题，是渲染层节点太多。模板里如果没做这个分页，建议你自己加一个visibleStart变量，wxml 里循环messages.slice(visibleStart)，这样最省事。

4.2 打字机效果的节流与中断

流式返回本身就是逐段到达的，不需要再模拟打字机。但有些服务端不支持流式，只能在客户端做假打字机。这时候有两个参数要想清楚：每次追加几个字、间隔多少毫秒。追加快、间隔短，看起来流畅但setData频率高；追加慢、间隔长，看起来一顿一顿。

我的经验值是每次 2～4 个字、间隔 30～50 毫秒，并且用一个定时器统一驱动，不要每收到一次数据就新起一个定时器。更关键的是中断：用户点了「停止生成」，或者退出页面，定时器必须清掉，否则setData会在页面销毁后继续执行，控制台报一堆警告。

// 假打字机：先缓存完整文本，再用定时器逐段吐出 startTypewriter(fullText) { this.stopTypewriter() let cursor = 0 this._timer = setInterval(() => { if (cursor >= fullText.length) return this.stopTypewriter() cursor += 3 this.updateLastMessage(fullText.slice(0, cursor)) // 内容变长后需要重新滚到底 this.setData({ scrollInto: 'msg-' + (this.data.messages.length - 1) }) }, 40) }, stopTypewriter() { if (this._timer) { clearInterval(this._timer) this._timer = null } }, onUnload() { this.stopTypewriter() // 页面销毁必须清，否则定时器泄漏 }

onUnload里那一行是血泪经验。开发时页面切换看不出来，真机上反复进出聊天页几次，就会发现有多个定时器同时在跑，文字越打越快，像开了倍速。

4.3 Markdown 与代码块：轻量解析比整包引库更划算

模型返回的内容里经常带**加粗**、列表、代码块。直接塞进<text>里会原样显示星号，体验很差。常见的做法是引一个 Markdown 渲染库，但整包引进来往往几百 KB，主包体积一下子上去了，而小程序主包有 2MB 限制。

我的取舍是：正文只处理加粗、行内代码、有序无序列表这四种，用正则替换成 nodes 数组交给rich-text；代码块单独拎出来，用等宽字体和深色背景的<text>渲染，不做语法高亮。这样加起来不到 100 行代码，体积几乎为零。真有代码高亮需求，就用分包把渲染库放到subpackages里，聊天页做一次懒加载，别塞主包。

// utils/md.js 轻量解析：只处理四种常见标记 function toNodes(md) { let html = md .replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;') .replace(/\*\*(.+?)\*\*/g, '<strong>$1</strong>') .replace(/`([^`\n]+)`/g, '<code>$1</code>') .replace(/^\s*[-*]\s+(.+)$/gm, '<div class="li">· $1</div>') .replace(/\n/g, '<br/>') return [{ type: 'nodes', name: 'div', attrs: { class: 'md' }, children: parse(html) }] }

注意第一步的转义必须先做，否则模型返回的<会被当成标签解析，轻则排版错乱，重则整段内容消失。rich-text只支持有限的标签和属性,class在部分基础库版本上不生效，样式最好写成内联或者用rich-text内部的style，这一点不同版本表现不一致，测的时候以真机为准。

5. 避坑排查：真机跑不通的五个高频翻车点

下面这五条基本都是我在不同项目里真实遇到过的，顺序按出现频率排。每一条我都写成「现象、原因、解决」，方便你对着症状直接找。

5.1 开发者工具正常，真机请求全部失败

现象：工具里发消息秒回，扫码到手机上一直转圈，最后弹「网络异常」。

原因：urlCheck被关掉了，或者请求域名没在小程序后台配置。开发者工具里的「不校验合法域名」只作用于工具本身，真机走的是真实校验，域名未备案、证书链不全、用了非 443 端口，都会直接失败。另一个隐蔽原因是请求地址写成了http://，工具能通，真机不行。

解决：后台配好 request 合法域名，确认是 HTTPS 且证书链完整（用openssl s_client -connect 域名:443看是否能拿到完整链），端口固定 443。改完重新编译、清缓存、重新扫码。

5.2 流式输出在真机上「一次性蹦出来」

现象：本地开发时一个字一个字往外冒，真机上一等三秒，然后整段出现。

原因：三层缓冲叠加。Nginx 的proxy_buffering默认开着；服务端没调用flush；或者客户端解码时把不完整的行一直攒着没吐。还有一种情况是基础库版本低，enableChunked静默失效，不报错。

解决：服务端加X-Accel-Buffering: no，Nginx 该关的关；检查libVersion；在onChunkReceived里加一行日志打印每次收到的字节数，如果第一次就收到几 KB，说明是上游缓冲，不是客户端问题。

5.3 聊到二三十轮后页面明显卡顿

现象：刚开始很顺，聊久了滑动掉帧，输入框打字有延迟，切页面要等一两秒。

原因：setData每次都在传整个messages数组；同时列表里渲染了几百个节点。两者叠加，通信量和渲染量同时爆炸。

解决：改成路径更新只传最后一条；列表只渲染最近 50 条，更早的折叠；messages里不要存图片 base64 这类大字段，图片走 URL。

5.4 提交内容被判违规，接口返回 87014

现象：某条消息发出去直接报错，或者内容安全接口返回87014，提示内容含违规信息。

原因：模板里压根没做内容安全检测，或者只在前端做了关键词过滤。前端过滤靠不住，用户可以直接调接口。

解决：服务端在转发给模型之前、以及拿到回复之后，各调一次security.msgSecCheck（v2 需要传openid、scene、version: 2），命中就返回统一的提示文案，不要回显原文。检测本身有频率限制，别对每个字都调，按整条消息调。

5.5 输入框被键盘顶起，或者发送后不收键盘

现象：安卓机上输入框被键盘挡住；或者发完消息键盘不收起，挡住刚出来的回复。

原因：input组件的adjust-position默认是 true，会整体上推页面，但在scroll-view布局里推的位置经常不对；confirm-type没设成send，回车键是换行不是发送。

解决：给input加confirm-type="send"、bindconfirm绑发送、cursor-spacing="20"留出光标与键盘的距离；发送成功后调wx.hideKeyboard()。如果用了自定义输入框，adjust-position可以设成 false，自己监听bindkeyboardheightchange手动调scroll-top。

提示：.error状态的消息一定要给用户一个可点的重试入口，否则一条失败就整段对话卡死，用户只能退出重进。

6. 进阶：把模板改成能长期维护的形态

模板跑通到能演示，大概半天；改到能长期维护，主要差三件事：记忆分层、参数可调、上线前有一份自检清单。我一般会先做记忆分层。最前面放一条固定的 system 提示，写清人设、输出格式、不能做什么，控制在 200～400 字。中间放一条摘要，由早期对话压缩而来，只在轮次到阈值时更新。最后放最近 8～12 轮的原文。这三段拼起来再发，比把历史全塞进去省一半以上的 token，回答质量反而更稳，因为无关内容少了。

参数可调这件事，我建议不要写死在代码里。首字延迟高的时候能临时调小 max_tokens，出问题时能一键切回一次性返回，这些都应该通过一个远程配置来控制，而不是发版。小程序侧拿到配置后存在globalData里，聊天页 onLoad 时取一次，取不到就用默认值兜底。灰度的时候可以按 openid 尾号分组，先放 10% 的用户走新链路，观察两天错误率和平均响应时间再全量。

这张表我每次上线前都会走一遍，十分钟能省掉后面几小时的排查。最后说个习惯：不管模板多完整，我都会先把utils/request.js重写一遍，把超时、重试、错误码、日志埋点集中到一处，再去动页面。因为出问题的时候，九成的原因都在这一层，而模板自带的封装往往只考虑了「成功」这一条路径。从那以后我每次接这类对话模板，都强制先跑一遍真机的最短链路，再谈功能和样式。希望帮到你。

本文还有配套的精品资源，点击获取