简介这份智能聊天机器人微信小程序源码面向小程序开发者、AI初学者及产品经理提供了一套在微信平台实现人机对话的完整工程。压缩包内含19个文件涵盖js逻辑脚本、wxml页面结构、wxss样式、json配置以及png、jpg图片素材覆盖入口逻辑、页面渲染、样式布局与数据配置等核心开发环节包体仅15KB结构轻量便于整体阅读和二次开发。已有556人学习下载。通过阅读源码可以快速理解聊天机器人的项目组织方式入口脚本负责全局生命周期全局配置声明页面路径页面目录存放对话界面及交互逻辑公共工具模块封装通用函数模型或API调用部分预留智能应答能力。这份资源既适合新手对照练习小程序开发与NLP的简单结合也可作为基础模板供有经验的开发者接入云小微等第三方平台优化对话策略与用户体验。1. 一个智能聊天机器人小程序项目解压后先别急着编译很多人在拿到智能聊天机器人微信小程序源码之后做的第一件事是把 rar 解压、拖进微信开发者工具然后点编译。多数情况下页面能起来但发消息时会有两种情况要么控制台报 url not in domain list要么接口一直转圈。这两个现象和对话模型本身没关系问题都出在小程序平台的域名校验和 appid 配置上。这个源码包适合三类人想快速搭一个聊天机器人 demo 的学生需要给公司做内部客服原型的开发者以及想完整读一遍小程序页面路由、全局状态和请求封装的新手。它能跑通从启动页、聊天页到机器人接口的完整闭环但真正让它可用前置条件是把 appid 换成自己的、把接口地址换成允许访问的 https 域名。2. 从 app.json 读目录聊天小程序的项目骨架与启动顺序很多人拿到这类源码习惯先找 index.js 里有没有“智能”字样其实更应该先看 app.json。app.json 在微信小程序里不是普通配置文件它决定页面路由、窗口表现和网络超时。对聊天机器人项目来说页面路由决定用户启动后进的是聊天页还是引导页网络配置决定机器人的请求能不能通过合法域名校验。先读配置文件能避免后面改页面时找不到报错原因。2.1 文件结构先分清哪些是页面哪些是配置解压后我一般会按文件类型而不是目录名字去看。下面这份是聊天小程序最常见的骨架不同源码可能多一个 components 目录但核心就这几类文件/目录在项目里的职责改之前先确认app.js全局生命周期、登录态初始化是否在 onLaunch 里调了 wx.loginapp.json页面路由、窗口样式、网络超时pages 第一项决定启动页project.config.json开发者工具工程配置appid 是不是你自己的pages/index聊天页或首页页面四件套是否齐全pages/chat会话页或历史记录页路由有没有在 app.json 注册utils请求封装、通用函数机器人接口地址、key 是否写在这里images图标、头像、背景rar 解压后是否丢失文件这个表格想说明的是pages 下面每个页面都有四个同名前缀文件wxml 管结构、wxss 管样式、js 管逻辑、json 管页面级配置。聊天机器人页面里最重要的两个文件是 index.wxml 和 index.js前者是气泡列表和输入框后者是消息数组和请求逻辑。压缩包里的 utils 目录通常不大但决定了机器人接的是哪家服务所以下一步必须拆开看。2.2 app.json 里的路由规则大多数老源码的入口是 pages/index/index直接把聊天页放在首页。下面的配置是这一类项目的典型形态{ pages: [ pages/index/index, pages/chat/chat ], window: { navigationBarBackgroundColor: #ffffff, navigationBarTitleText: 智能聊天机器人, navigationBarTextStyle: black }, networkTimeout: { request: 15000 }, sitemapLocation: sitemap.json }这里 pages 数组的顺序有实际意义数组第一个元素是启动页用户打开小程序先看到它。聊天项目通常把聊天页放在第一位因为用户打开就是要对话。如果想加一个广告页或引导页只需要把它写在 pages 的第一位同时保证对应目录下有 wxml、js、json、wxss 四个文件。networkTimeout 里的 request 控制 wx.request 的超时时间我习惯设 15000 毫秒机器人接口响应超过 15 秒基本就可以认为不可用设置更短还能避免用户一直等。需要注意两点。第一页面路径不要带 .wxml 后缀第二新增的 page 目录如果没有注册进 pages 数组编译时会报某个页面找不到的错。我在帮人排查这类项目时一半以上的报错出在这个地方。2.3 app.js全局生命周期和登录态初始化聊天机器人往往需要知道用户身份最常见的是在 app.js 的 onLaunch 里执行登录流程。解压包里这段代码一般是这样的App({ onLaunch() { const token wx.getStorageSync(token) if (!token) { wx.login({ success: (res) { console.log(wx.login code:, res.code) // 把 code 发给自己的后端后端用 code 换 openid 和 session_key wx.request({ url: https://api.example.com/login, method: POST, data: { code: res.code }, success: (loginRes) { wx.setStorageSync(token, loginRes.data.token) } }) } }) } }, globalData: { userInfo: null, botName: mini-bot } })这段代码的逻辑是先从本地缓存读 token没有就调 wx.login 拿到临时 code再把 code 发给后端换取业务 token。这里有两个容易踩的坑。第一wx.login 只返回 code不能直接拿到 openid也不能拿 code 到前端去当身份凭证使用必须走后端接口换。第二globalData 适合存全局配置不适合存聊天记录小程序切后台再回来时 globalData 可能被重置消息列表最好持久化到 wx.setStorageSync。读完这三个文件基本就能判断这套源码的机器人服务是接在哪里的。如果 utils 里有 api.js 或 request.js那对话请求大概率封装在“里面”如果 app.js 里有第三方平台关键字说明可能用了现成服务。下一步就是把请求封装拆开看。3. 机器人对话链路从 wx.request 到返回消息的协议设计聊天机器人要能说话前端必须有一个“发送消息 - 拿回复 - 渲染气泡”的闭环。小程序源码里最容易被忽略的是协议设计很多人在 index.js 里直接写了 wx.request后面要换机器人服务商时就得把所有页面翻一遍。所以封装一个 request 不只是代码整洁而是给后续换模型、换服务商留接口。3.1 为什么压缩包里通常没有模型文件很多人下载智能聊天机器人源码后会找 model 目录但真正的小程序包里几乎看不到模型文件。原因有两个层面小程序包体积限制在 2MB 左右放不下动辄几百 MB 的深度学习模型另外微信小程序的运行环境是 JavaScript就算把模型量化到几 MB端的推理速度也远不如服务端。常见做法是把词嵌入、seq2seq、Transformer 这类模型放在后端服务器小程序只负责把用户输入 POST 过去再把返回的文本渲染出来。当然也有例外。纯本地规则的项目会在 utils 里维护一个关键词-回复表用 if else 或正则匹配这种方式不依赖网络但对话能力基本等于没有只能当演示。这里以 HTTP 接口为主因为绝大多数可以二次开发的源码都是这种形态。3.2 三种接入方式怎么选接入方式网络依赖开发量典型场景本地规则匹配无最小离线 demo、固定问答HTTP API 对接需要 https 域名中大多数源码默认方案云开发云函数需要云环境中高不想自己买服务器的个人项目选择时主要看两件事。第一是接口地址能不能改很多源码里写死了第三方平台的 URL拿到后先测试这个域名是否还有效第二是返回字段是不是 { code, msg, data } 这种标准结构如果不是前端解析逻辑就得跟着改。我一般会把请求封装单独放一个文件这样切换接入方式时只改一个文件页面代码不动。3.3 写一个能替换的请求封装下面是一份非常通用的 utils/api.js适合大多数 HTTP 型聊天机器人const BASE_URL https://api.example.com // 替换成实际接口地址 const TOKEN_KEY token function chat(message, sessionId) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}/v1/chat, method: POST, timeout: 15000, header: { Content-Type: application/json, Authorization: Bearer ${wx.getStorageSync(TOKEN_KEY)} }, data: { msg: message, sessionId: sessionId || wx.getStorageSync(sessionId) || }, success: (res) { if (res.statusCode 200 res.data res.data.code 0) { resolve(res.data.data) } else { reject(new Error(API error ${res.statusCode})) } }, fail: (err) reject(err) }) }) } module.exports { chat }这段代码做了几件事把 base URL 收敛到常量从 storage 里带 token把用户消息和会话 id 一起提交只有业务码为 0 时才 resolve其他情况全部 reject。参数里 sessionId 是保持多轮对话上下文的关键。如果你的后端是无状态接口每次请求都要把历史消息拼在 msg 里如果后端维护会话sessionId 要保持不变不能每次生成新的否则机器人会忘记前文。这里还要强调 timeout。wx.request 的 timeout 既影响用户等待时长也影响 loading 状态的恢复。我见过不少项目把 timeout 写成 60000结果是接口已经挂了用户还要白等一分钟。15 秒比较合理失败后立刻在 UI 上给提示比一直转圈体验好。3.4 在页面里同步对话状态封装完请求后页面里只需要维护消息数组和输入状态。调用方式如下const { chat } require(../../utils/api) Page({ data: { messages: [], inputVal: , sending: false }, onSend() { const content this.data.inputVal.trim() if (!content || this.data.sending) return const userMsg { id: Date.now(), role: user, content } this.setData({ messages: [...this.data.messages, userMsg], inputVal: }) chat(content, wx.getStorageSync(sessionId)) .then((reply) { this.setData({ messages: [...this.data.messages, { id: Date.now() 1, role: bot, content: reply }] }) }) .catch(() { wx.showToast({ title: 机器人打盹了稍后再试, icon: none }) }) } })这里的关键是 messages 数组永远只做追加不做原地修改。小程序里 setData 修改数组的某一项会触发整个数组 diff消息多的时候会有明显卡顿。用展开运算符重新生成数组虽然多占一点内存但在几十条消息的聊天场景里根本没压力。sending 标志在下一章展开说明。4. 聊天页实战滚动定位、输入态与消息会话聊天页是所有交互最集中的地方消息列表要自动滚到底部输入框要有防连点机器人回复期间不能让用户乱发。这个源码的 pages/index 里如果只做了一件事那一定是把这三件事处理干净。下面按数据设计、模板结构、逻辑处理、样式适配四个层次拆开说。4.1 先把消息数据结构定下来我建议不管原项目怎么写的都统一成下面三种字段字段类型作用idnumber/string作为 wx:key 和 scroll-into-view 锚点roleuser / bot决定气泡靠左还是靠右contentstring展示的文本内容id 必须唯一且在整个会话中保持不变不要在渲染时用数组下标当 id因为删除或插入消息时下标变化会导致滚动定位错乱。聊天记录如果要存本地直接在 onHide 或 onUnload 里 wx.setStorageSync 存整条 messages 数组下次打开时从 storage 恢复。4.2 WXML 骨架scroll-view 承担滚动定位消息列表不用 view 加 overflow-y而应该用 scroll-view因为 scroll-view 提供了 scroll-into-view 锚点定位这是聊天页自动滚动的标准做法。view classchat-page scroll-view classmessage-list scroll-y scroll-into-view{{toView}} scroll-with-animation view wx:for{{messages}} wx:keyid idmsg-{{item.id}} classmessage {{item.role user ? message--user : message--bot}} view classbubble{{item.content}}/view /view /scroll-view view classinput-bar input value{{inputVal}} bindinputonInput bindconfirmonSend confirm-typesend placeholder说点什么... cursor-spacing100 / button bindtaponSend sizemini typeprimary发送/button /view /viewscroll-into-view 的值必须与子元素的 id 完全匹配而且不需要加 # 前缀。当 toView 变化时scroll-view 会滚动到指定 id 的元素位置。滚动动画用 scroll-with-animation 开启否则会瞬间跳到底部视觉上很生硬。还有一个隐蔽问题如果连续两条消息都设置同一个 toView第二次 setData 时值没有变化scroll-view 不会重新滚动。解决方法是每条消息都用新的 id我直接用 Date.now() 生成避免重复。4.3 发送逻辑和防连点发送按钮的 bindtap 和 input 的 bindconfirm 绑定同一个 onSend这要求函数里必须同时处理输入框内容和重复点击。下面是带完整异常处理的版本Page({ data: { messages: [], inputVal: , toView: , sending: false }, onInput(e) { this.setData({ inputVal: e.detail.value }) }, onSend() { const content this.data.inputVal.trim() if (!content || this.data.sending) return const userMsg { id: Date.now(), role: user, content } this.setData({ messages: [...this.data.messages, userMsg], inputVal: , toView: msg-${userMsg.id}, sending: true }) chat(content, wx.getStorageSync(sessionId)) .then((reply) { const botMsg { id: Date.now() 1, role: bot, content: reply } this.setData({ messages: [...this.data.messages, botMsg], toView: msg-${botMsg.id} }) }) .catch(() { wx.showToast({ title: 请求失败请重试, icon: none }) }) .finally(() { this.setData({ sending: false }) }) } })sending 是防连点开关。在异步请求没有返回前sending 一直是 trueonSend 第一步就把这种情况拦截掉避免用户疯狂点发送导致消息顺序错乱。finally 里无论成功失败都复位 sending防止一次失败后整个输入框永久锁死。注意 onInput 里不要做 trim因为用户在输入空格时 trim 会清掉内容等到 onSend 再 trim 是最稳妥的。4.4 键盘遮挡和顶部导航栏高度输入框被键盘顶起来是小程序里的经典问题。input 组件默认就有 adjust-position 属性拉起键盘时会自动上推页面但有两个细节经常被忽略。第一cursor-spacing 要设置它表示输入光标与键盘顶部的距离我一般设 100否则光标正好被键盘盖住。第二iPhone 底部的 home indicator 区域会挡住发送按钮需要在 input-bar 上加底部安全区 padding.input-bar { display: flex; align-items: center; padding: 16rpx 24rpx; padding-bottom: calc(16rpx env(safe-area-inset-bottom)); background: #f7f7f7; border-top: 1rpx solid #e5e5e5; } .message-list { flex: 1; padding: 24rpx; box-sizing: border-box; }注意 env(safe-area-inset-bottom) 只在 iPhone X 及以后机型上有值安卓和普通机型是 0所以必须用 calc 叠加而不是直接替换 padding-bottom。如果页面开了自定义导航栏顶部导航栏高度在 iOS 和安卓上不一样还要叠加状态栏高度。不要写死数值用 wx.getWindowInfo() 读取 statusBarHeight 再动态设置 paddingTop否则刘海屏上消息会顶到状态栏。5. 修改刚进入的加载页面启动页与首屏逻辑的改动点“修改刚进入的加载页面”是很多人在拿到聊天机器人源码后要做的第一件事默认启动页可能是开发者自己的品牌页也可能是带着加载动画的引导页。修改它其实只需要搞清楚微信小程序的启动机制核心就是 app.json 的 pages 数组顺序以及页面 onLoad 里那几行状态代码。5.1 先确认当前启动页是哪一个微信小程序没有独立的“首页”配置入口启动页就是 pages 数组的第一个元素。如果源码当前是 pages/index/index 在最前面那用户打开后看到的就是聊天页。要改成加载页把加载页放到第一位要删掉加载页把它的路径从数组里移除同时删掉对应目录。改完之后在微信开发者工具里点编译如果看到 Page not found 或白屏多半是数组里写了不存在的路径。这里有一个容易误判的点loading 页面不一定要单独建页面。有些源码是在 index 页面的 onLoad 里显示 wx.showLoading等机器人接口返回后再 hideLoading这种情况下用户看到的“加载页”其实是聊天页本身。改的时候不要去找 splash 目录直接搜 showLoading 关键字就能定位到加载逻辑。5.2 加一个独立的 splash 页面如果想让用户先看到 logo 和加载动画再加一个 splash 页面是最干净的方式。在 pages 目录下新建 splash 目录四个文件都建好然后把 app.json 的 pages 数组调整成{ pages: [ pages/splash/splash, pages/index/index ] }splash.js 里写Page({ onLoad() { setTimeout(() { wx.redirectTo({ url: /pages/index/index }) }, 1500) } })这里的 1500 是加载页停留时间单位毫秒。用来做品牌展示 1500 就够如果还要等机器人接口预加载可以改成 2000 到 3000但不要超过 5 秒用户等太久会直接关掉小程序。跳转用 wx.redirectTo 而不是 wx.navigateTo理由是 redirectTo 会关闭当前页面用户按返回键时不会回到加载页用 navigateTo 的话页面栈里会残留 splash返回时又看到一遍加载动画体验很差。5.3 只改文案和图片素材的快捷方式如果项目里已经有 splash 页面只是想换 logo、标题、背景不需要动 JS。打开 splash.wxml找到 image 标签把 src 替换成 images 目录下的新图片文字内容直接在 wxml 里改。改完图片发现真机上还是旧图的情况很常见这是微信的图片缓存导致的。我一般把图片文件名加上版本号比如 logo_202406.png而不是覆盖 logo.png这样能绕过缓存。小程序包体积有限图片尽量控制在 100KB 以内一张 1MB 的背景图会让首次加载明显变慢。5.4 loading 与页面跳转的配对使用 wx.showLoading 做加载状态时有一个必须遵守的规则showLoading 和 hideLoading 必须成对出现而且最好在同一个函数作用域里保证 finally 执行。下面的写法是反例因为接口失败时 hideLoading 不会执行loading 层会一直盖住页面wx.showLoading({ title: 加载中 }) chat(你好) .then((reply) { wx.hideLoading() this.setData({ messages: [reply] }) }) // 如果请求失败hideLoading 永远不会被调用正确写法是把 hideLoading 放进 finally或者在 catch 里也调用 hideLoading。另外 setTimeout 与 showLoading 配合时要注意跳转后隐藏先 redirectTo 再 hideLoading 会有短暂闪烁正确顺序是先 hideLoading 再跳转。如果机器人接口本身要 3 秒才返回加载页停 1 秒后跳过去还要转圈倒不如把加载页停留时间设短一点让聊天页自己去 loading。6. 真机联调、域名校验与发布前的最后检查聊天机器人小程序在开发者工具里跑得通不代表真机可以跑通。最典型的差异是开发者工具默认勾选了“不校验合法域名”但这个选项只管工具不管真机。真机上 wx.request 遇到不在白名单里的域名会直接报 url not in domain list而且这个错误在 vConsole 里看起来很像网络超时。6.1 三条最容易被忽略的规则第一request 合法域名必须在微信公众平台后台配置常见路径是“开发管理 - 开发设置 - 服务器域名”。修改域名每月有次数限制所以不要把测试环境和生产环境分开反复改我一般先配一个固定的 https 域名接口路径通过子路径区分环境。第二域名必须是 HTTPS且证书链完整小程序对自签名证书不认。第三本地调试时可以把“不校验合法域名”打开但提交体验版之前一定要关掉用真机走一遍完整流程。如果后端还没上线又想先调通页面可以用微信开发者工具的真机调试功能配合局域网地址但真机上同样受域名限制。更顺滑的方案是用云开发在云函数里调用外部接口小程序端只请求云函数路径云函数发起 HTTP 请求时不受小程序合法域名限制。6.2 提审前走一遍的核对表把聊天机器人小程序提交审核前至少要过一遍下表的检查项检查项做法appidproject.config.json 里换成自己小程序的 appid服务器域名后台配置 request 合法域名隐私保护指引在后台声明收集文本信息否则审核可能驳回启动页app.json pages 第一项是否是预期页面错误提示请求失败时页面要给出可见的 toast不能白屏关于 AI 对话类目如果你的机器人是通用闲聊提审时平台可能会要求补充材料。这是这类源码二次开发最容易翻车的地方建议把对话范围收窄成具体业务比如商品客服、校园助手并在页面里写明使用目的别做无边界问答。工具类目下纯演示用途的智能聊天机器人资料齐全通常是能通过的。最后分享一个很实用的小技巧在聊天页的 onError 或者 request 的 fail 回调里把 errMsg 和接口返回码通过 wx.showToast 弹出来。这样真机联调时不用每次打开 vConsole 翻日志用户反馈“发不了消息”时让他截个图就能定位是域名问题还是接口问题。我在改别人的机器人源码时第一件事就是在请求封装里加这行提示排查效率能提高一大截。本文还有配套的精品资源点击获取