企业官网建设流程全解析

简介：压缩包是一套面向小程序开发者的AI功能实践案例，围绕智能语音、图像识别等场景，展示了在微信小程序中集成人工智能能力的完整实现思路。资源共包含59个文件，体积仅1.36MB，其中12个js脚本负责核心逻辑，7个wxss与5个wxml构建界面结构，另有20余张图片和4个gif动图辅助演示，说明文档帮助快速上手。已有242人浏览学习，适合刚开始接触AI与小程序融合开发、希望参考工程化代码的初学者。包内按功能模块组织目录，覆盖多个页面模块，包含录音控制、工具函数封装以及运行效果展示；下载后可直接导入开发者工具运行，对照源码理解语音交互、记录管理等功能的实现细节。压缩包虽小，但代码组织规范，适合作为课程设计或毕业设计的参考基础。

1. 这个 zip 装的是什么：一个能跑、能改、能交作业的 AI 小程序骨架

收到一份名字带 “demo.zip” 的压缩包时，先别急着解压。这类包在微信小程序里特别常见，通常是一个“能跑的最小闭环”：前端页面齐全，中间层封装好了网络请求，后端或云函数里塞了一个真实可调用的 AI 模型接口。你要做的不是把它当成品用，而是当脚手架拆。我见过很多次，学生拿到手就在app.js里改两行颜色交作业，结果答辩时被问 “模型在哪训练的” 就卡住。这个标题下的 zip 一般价值在于：它给了你一条从页面到模型的完整链路，适合拿来做成人工智能课程大作业、毕设演示或者产品原型验证。最适合的人有两类：一是想快速跑通 AI 小程序的开发者，二是需要“有界面、有效果、能讲解”的初学者。接下来我会按解压、跑通、改造、避坑的顺序，把它拆成一套可复现的流程。

2. 把 demo.zip 解压到跑通：先从微信开发者工具里看见画面

拿到压缩包，第一步不是看代码，而是先确认目录结构。绝大多数微信小程序 AI demo 的目录在解压后会呈现一个标准形态，和原生小程序项目一致：.js、.json、.wxml、.wxss四件套铺在pages下，根目录有app.js、app.json和project.config.json。这一章的目标是让你在 10 分钟内把它跑起来，并搞清楚哪些文件是灵魂、哪些文件可以随便动。

2.1 解压前先看目录：哪些文件能删、哪些文件绝对别动

用任意解压工具打开 zip，先看一级目录。正常情况会看到pages/、utils/、components/（未必有）、app.js、app.json、project.config.json、sitemap.json这类文件。有一个细节：很多 demo 会把 AI 模型的调用封装在utils/或services/目录里，文件名可能是api.js、request.js、model.js。这个文件是整个项目的“命根子”，因为里面定义了请求地址、密钥拼接方式、鉴权参数和回调函数。

我的建议是先做一次文件分类。能随便删的是：README.md、docs/、图片资源里的演示图。绝对不能动的是：project.config.json里的appid字段、utils/下的请求封装、app.json里的页面注册列表。打开project.config.json看一眼，里面有个"appid"字段，如果你的 demo 作者留下了自己的 AppID，你要么换成自己的、要么在开发者工具里改成测试号，不然真机预览会提示权限错误。这一步虽然简单，但踩坑概率极高。

2.2 打开项目的最小操作序列与三个入口参数

跑一个微信小程序不需要命令行，但注册流程绕不开。先到微信公众平台注册一个小程序账号，拿到自己的 AppID。然后在微信开发者工具里选择“导入项目”，目录选到解压后包含app.js的那一层，而不是外层文件夹。这是一个典型的低级错误：小程序项目要求目录里直接有app.js与app.json，如果你选到了外层，工具会直接提示“文件不存在”或“不是小程序项目”。

导入后有 3 个入口参数值得看一眼，都在工具栏或project.config.json里。第一个是 AppID，换成本人的再点“确定”。第二个是 “JS 调试”和“不校验合法域名”开关，开发阶段建议打开“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。原因很简单：很多 demo 的 AI 接口使用的是临时域名或 IP 地址，没备案、没证书，不开这个开关连请求都发不出去。第三个是 ECMAScript 版本，如果看到代码里用了async/await或可选链?.，把编译环境选到 ES6+，否则会报一堆语法错误。

注意：跑通 demo 不等于理解 demo。看到页面能加载、按钮能点击、控制台不报错，这只是第一步。你还要点开 “Network” 面板，看每个按钮触发的是哪个接口，请求参数长什么样，模型返回了什么结构。这一步决定了你后面改代码的速度。

2.3 真机预览前的产品设置：AppID 与合法域名

模拟器上跑通之后，很多人直接点“预览”生成二维码，结果手机上一片白屏或按钮无响应。这里有个微信平台层面的限制：模拟器上开着“不校验合法域名”能跑，但真机上这个开关失效。你在“详情 - 本地设置”里勾选的选项只对开发工具生效，手机上跑的是线上体验版逻辑。

正确顺序是：在微信公众平台后台的“开发 - 开发管理 - 开发设置 - 服务器域名”里，把 AI 接口的域名加进request合法域名列表。通常是一个https://开头的地址，如果你只是本地写 demo，也可以用内网穿透工具转成临时域名，但要注意微信要求这个域名必须完成 ICP 备案。国内云厂商的主机会默认帮你备案，个人服务器则要自己查。真机预览时如果看到request:fail，第一反应不是查代码，而是查域名列表和手机网络代理，这两个问题占了真机失败原因的六成以上。

3. AI 能力放哪边：云端接口、端侧模型与小程序的中间层

跑通只是起点。理解了程序结构之后，就要面对 AI demo 最核心的架构问题：模型到底在哪里跑。有一类 zip 里塞的是 Python 后端代码，小程序只是壳；另一类则在小程序端用 TensorFlow.js 跑模型。这两条路各有取舍，用错场景，体验和成本都会让你难受。

3.1 为什么 demo 通常把 AI 能力放在云端而不是小程序里

从搜到的热词里能看出一个倾向：大量用户搜“人工智能大作业”“微信小程序项目实例”“ai开发微信小程序”，说明多数人是把 AI 能力当作一个黑匣子接进来。黑匣子不可怕，可怕的是你把训练好的几百 MB 模型塞进小程序包里。微信小程序主包大小限制是 2MB（通过分包后总包可到 20MB 以上），一个 ResNet50 的量化模型不在设备上跑，那在云端跑几乎是唯一选择。

另一个现实原因是：绝大多数 demo 的 AI 能力来自公有云 API，比如图像识别、语音转文字、文本分类和大模型对话。这些接口已经封装成 HTTP 服务，小程序端只需要wx.request发一个POST请求，带上图片 base64 或文本参数，就能拿到结果。云端方案的好处是小程序端代码量小、不需要处理模型文件、算力成本和维护都由服务方承担；坏处是网络延迟不可控、有调用计费、接口在审核时容易被盯上。

这里的“中间层”是我想强调的。优质的小程序 AI demo 不会让页面直接wx.request到模型服务，而是会在utils/request.js里做一个统一封装。页面调modelApi.detect(imagePath)，封装层负责拼接 token、设置超时、统一错误码、把返回数据裁剪成页面需要的结构。这样做的直接收益是：你在改造自己的大作业时不用动页面，只需要换一个 API 地址。

3.2 小程序端封装一层请求：URL 配置、超时与回调

很多 demo 会把这层封装命名为api.js，里面用Promise包裹wx.request。下面这段代码是一个典型的封装模板，我把关键参数都标注出来了：

const BASE_URL = 'https://your-api.example.com'; function request(path, data, method = 'POST') { return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${path}`, method: method, data: data, timeout: 15000, // 15 秒超时，AI 接口通常比普通接口慢 header: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${wx.getStorageSync('token')}`, }, success: (res) => { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data); // 解包出实际业务数据 } else { reject({ message: res.data.message || '接口异常' }); } }, fail: (err) => { reject({ message: '网络请求失败，请检查网络或域名配置' }); }, }); }); } // 页面里调用时，统一走这个门面 function recognizeImage(filePath) { return request('/ai/recognize', { image: wx.getFileSystemManager().readFileSync(filePath, 'base64') }); }

写这个封装时有三个参数值得上心。一是timeout，AI 模型推理时间往往在 2 到 8 秒之间，20 秒以上的大模型流式接口另说。如果你把超时设成默认的 60 秒，用户会感觉“卡死了”；设成 5 秒又容易误杀慢模型。我一般用 15 秒作为通用值，并保证接口失败时页面有明确的 toast 提示。二是header里的鉴权，很多小程序的接口会校验Authorization头，格式是Bearer加一个空格再加 token，少一个空格会直接 401。三是返回数据的解包层级，不同的 AI 服务商返回结构不同，有的包在data.result，有的包在data.data.output，最好在resolve之前统一成实际业务对象，不然页面里到处写.data.data.result会非常难受。

3.3 端侧也有能用的场景：极简图像分类的一次完整调用

云端方案是主流，但如果你搜“微信小程序中的视频下载”“小程序逆向”这类热词，你会发现有些 demo 对端的依赖非常高——涉及本地文件处理的场景，比如身份证识别、扫码、视频帧提取，用户自己就能感觉到上传等待的痛。这时可以考虑端侧推理。小程序支持加载 TensorFlow.js 转换后的模型，模式是tfjs或tfjs-lite，但要求模型经过量化压缩，不能直接在浏览器里训练。

下面是一段端侧图像分类的最小代码，模型放在项目models/目录下，通过wx.getFileSystemManager()读取后喂给 TensorFlow.js：

const tf = require('@tensorflow/tfjs'); async function classify(imagePath, modelPath, labels) { const model = await tf.loadLayersModel('file://' + modelPath); const fileData = wx.getFileSystemManager().readFileSync(imagePath); // 把二进制图片解码成像素张量，并调整到模型要求的尺寸 224x224 const tensor = tf.browser.fromPixels({ data: fileData, width: 224, height: 224 }, 3); const expanded = tensor.expandDims(0).toFloat(); const input = expanded.div(255.0); // 归一化到 0-1 区间 const prediction = await model.predict(input).dataSync(); tensor.dispose(); // 释放显存，微信小程序的 WebGL 上下文很稀缺 let maxIndex = 0; for (let i = 1; i < prediction.length; i++) { if (prediction[i] > prediction[maxIndex]) maxIndex = i; } return { label: labels[maxIndex], confidence: prediction[maxIndex] }; }

这段代码能跑通的关键点在于：模型路径必须是包内路径，微信不允许访问本地文件系统的绝对路径，只能用wx.env.USER_DATA_PATH或项目内相对路径，然后用file://协议拼接。tf.browser.fromPixels在微信里需要一个带data、width、height的对象，直接把readFileSync的 ArrayBuffer 给它是不行的，必须包一层。最后那个dispose()很多人不做，做多了图像识别就会翻车——小程序 WebGL 上下文数量有限，来往几次就黑屏。端侧方案适合识别速度要求高、数据隐私敏感、图片规格固定的场景。

4. 把 demo 改成自己的人工智能大作业：替换模型与替换 UI

你在搜索引擎里输入“微信小程序源码”“人工智能大作业”这些热词时，大部分诉求其实是“怎么把它变成我的东西”。这一步要做的不是小改样式，而是三件硬核的事：把写死的数据替换成真实接口、把页面布局改成自己的、处理跨端迁移的差异。每一件都有不少坑。

4.1 从写死数据改成真实接口调用

demo 里最常见的一种偷懒做法是“伪装接口”：页面拿到的是一个固定 JSON 数组，然后假装它是从 AI 返回的。这种项目能跑，但答辩时经不住追问。替换成真实接口的操作分三步走。

第一步，找接口定义。打开utils/api.js，定位到项目声明请求的方法，看它调用的服务器地址是什么、需要哪些参数。如果你手头没有后端，可以选择现成的公有云 AI API，比如文字识别、通用物体检测和文本生成类接口。这些服务商一般都提供 API key，开通后在自己的控制台创建一个应用，拿到API Key和Secret Key。第二步，改封装。把原来写死的result数组替换成Promise请求，页面里用wx.showLoading包住请求过程，拿回数据后setData更新。第三步，处理 token 有效期。AI 服务的鉴权 token 通常几小时到几天就过期，你的小程序需要在每次启动时检查本地缓存，过期就重新申请。

这里有个容易忽略的坑：图片上传给 AI 接口时要压缩。原图 3MB 以上，上传和识别都会变慢；常见的做法是先用wx.compressImage把图片压到 80% 质量、最长边不超过 1024px，再转成 base64。这个动作能把你接口的响应时间从 6 秒降到 2 秒，体验完全是两个级别。

4.2 界面改造：自定义导航栏时高度怎么算

换掉 demo 默认的导航栏样式，是让项目看起来“不像模板”最直接的手段。微信原生导航栏样式固定，只能调背景色和文字颜色，想放一个居中的 logo 或者自定义返回按钮，就得在app.json或单个页面的.json配置里加"navigationStyle": "custom"。但一关掉原生导航栏，你就得自己算顶部安全距离，这一步做不对，按钮会顶到状态栏里。

我总结过一个靠谱的计算公式，也是热词“微信小程序顶部导航栏高度”背后的大量需求。顶部总高度由两部分组成：状态栏高度 + 导航栏高度。状态栏高度可以用wx.getSystemInfoSync().statusBarHeight获取，安卓的通常 24 到 48px，iOS 刘海屏在 44 到 47px 之间。导航栏本身没有官方固定值，业界通用做法是取44px，也就是 iOS 导航栏的标准高度。总高度 =statusBarHeight + 44，在你的custom-nav组件里用padding-top撑开内容区。验证方式很简单：真机上用 Xcode 模拟器和安卓模拟器各看一遍，顶部不遮挡才算过。如果你算出来的高度感觉不对，还有一个笨办法——先打开一个页面用原生导航栏，用开发者工具的“胶囊按钮”做参照物，自定义导航栏时把按钮顶部和胶囊底部对齐，宽度对齐即可。

// 在页面的 onLoad 中读取，并注入到数据中，wxml 里用内联样式或用 CSS 变量 const systemInfo = wx.getSystemInfoSync(); this.setData({ navBarHeight: systemInfo.statusBarHeight + 44, statusBarHeight: systemInfo.statusBarHeight, });

这个高度在不同机型上是真实的“玄学”区。代码跑出来的结果有时比预想的多了 1px 或少 1px，建议在自定义导航栏的容器上设置position: fixed; top: 0; left: 0; right: 0，再配合padding-top动态绑定statusBarHeight。胶囊按钮的位置不能用代码读取，但可以放到wx.getMenuButtonBoundingClientRect().top做精确对齐，这个 API 在开发者工具和老版本微信上偶尔返回 0，真机上更可靠。

4.3 用 uni-app 迁移一次，以及它与原生开发的三处不同

如果你看到热词里有“uniapp 开发 微信小程序 vs android / ios / 鸿蒙”，说明你已经在考虑跨端了。demo 大概率是原生小程序写的，想迁移到 uni-app 也可以，只是要清楚三个差异点，否则迁移后会遇到一堆兼容问题。

第一，生命周期不同。原生小程序的onLoad对应 uni-app 的onLoad，onShow对应onShow，这个一致，但 uni-app 页面里使用options接收参数时——原生接收options的方式是onLoad(options)，uni-app 里需要写成onLoad(options)，两者看似相同，实际 uni-app 会把参数做一层序列化，数字会变成字符串，要手动Number()。第二，请求 API 名不同。原生wx.request在 uni-app 里最好统一用uni.request，虽然 uni-app 也兼容wx.前缀，但在小程序之外的环境如 H5 就不兼容了。第三，UI 组件体系。

原生小程序写view和text，uni-app 则使用 Vue 风格的组件写法，标签名是view一致，但事件绑定从bindtap变成@tap。最省事的迁移路径是：保留原生页面，把工具层utils/api.js抽出去，直接用uni.request替换wx.request，页面暂时不重写。这样迁移成本被控制在最小范围。

5. 微信小程序 AI 项目避坑手记：5 个高频问题与排查步骤

做 AI 小程序期间，总结出 5 个最容易让人血压升高的地方。这些坑不是代码水平问题，大多是平台机制、环境差异和模型推理特性导致的，记录给后来人当参考。

5.1 请求失败 errMsg: request:fail 与“不在合法域名列表”

现象：模拟器上请求正常，真机预览时请求直接失败，控制台里出现request:fail。这个报错并不精确，真正的原因被包了一层。

原因：真机上，小程序只能请求https协议，并且域名必须在后台的“服务器域名”白名单里。你的 AI 接口如果只是一个 IP 地址，或者没有备案的域名，真机一律拦截。有时候模拟器也能复现，因为开发者工具里勾了“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，但这个开关只对开发工具生效。

解决：到微信公众平台后台添加request合法域名，域名必须支持 HTTPS 且证书有效，国内服务器没备案基本不可能通过。如果你想快速验证，可以用腾讯云或阿里云的函数计算托管 AI 服务，域名自动生成，也大概率带证书和备案。应急方案是打开开发者工具的“真机调试”而不是“预览”，这个模式保留了不校验域名的能力，适合开发期联调；但体验版阶段必须把域名配上。

5.2 缓存设了不生效：什么时候用 wx.setStorageSync

现象：页面里调用了wx.setStorageSync('userInfo', data)，但重新打开小程序后数据丢了，或者读取到的是一份旧数据。

原因：AI demo 里最常见的误用是把整个模型返回结果塞进缓存，比如把图片识别的识别结果、base64 图片数据写进 storage。微信 storage 的总容量是 10MB，单个 key 上限 1MB。如果你的识别结果很大（常见的返回带image_url和大量冗余字段），超过 1MB 写入就会失败，而且不会抛运行时异常，只在控制台打一条警告。

解决：只缓存必要字段，图片本身不要缓存。常见做法是缓存的对象精简到{ label, confidence, timestamp }。同时注意 storage 的异步版本wx.setStorage与同步版本wx.setStorageSync的区别，前者可以带成功回调，后者直接阻塞。在 AI 场景里，我习惯用异步版本，因为它不会卡住页面首次渲染。

5.3 iOS 静音下没有声音：音频组件的静音开关

现象：安卓上播放 AI 语音回复正常，同一份代码在 iOS 上声音是从听筒出来或者干脆没声音。

原因：微信小程序的音频默认走“扬声器”，但跟随系统的“静音”开关。iOS 上物理静音键一旦拨到静音，wx.createInnerAudioContext()创建的所有音频实例都会静音。安卓没有物理静音键，所以这个现象几乎只在 iOS 独有。如果你的 AI demo 涉及文字转语音或音乐播放，这一点特别恼人。

解决：在播放前调用wx.setInnerAudioOption({ obeyMuteSwitch: false })，让音频无视物理静音开关，继续从扬声器出声。这个参数在 iOS 上生效，安卓忽略。如果在某些低版本基础库上无效，可以降级为播放前wx.getSystemInfoSync().platform判断系统，只有 iOS 才设置。设置这个之后要注意，如果用户确实想静音，你反而会制造噪音，所以产品上要加一个“声音开关”，默认开启，用户可以手动关闭。

5.4 AI 响应耗时太长：超时时间、加载态与并发限制

现象：点击按钮后页面卡住 8 秒以上，用户多点两次，触发多个重复请求，最后页面崩掉或者请求全部失败。

原因：AI 服务推理耗时不是读本地代码，网络延迟、模型排队、GPU 资源抢占都会造成耗时波动。小程序端如果不限制并发、不设置超时，一旦有一个慢请求卡住，后续所有wx.request都会排队，内存和回调堆积，页面卡死。

解决：三层处理。第一层，在utils/request.js里给每个请求设置显式timeout，上面已经写过了。第二层，页面里加 loading 锁，核心代码如下：

let isLoading = false; function handleTap() { if (isLoading) return; isLoading = true; wx.showLoading({ title: 'AI 识别中...' }); recognizeImage(this.data.imagePath) .then((res) => { this.setData({ result: res }); }) .finally(() => { isLoading = false; wx.hideLoading(); }); }

第三层，请求队列本身要有限制。强烈建议在utils/request.js里维护一个计数器，同时进行的请求最多 3 个，超出则等待。这样服务器不会被打满，页面也不会因为无限请求而卡死。很多大作业翻车就翻在这里——一个人用没问题，但答辩现场网络一波动，并发一多，全部请求超时。

5.5 虚拟支付被拒 / 审核不过：AI 内容的合规边界

现象：小程序审核员反馈“涉及虚拟支付”“AI 生成内容未加标识”而被拒，代码本身没有问题。

原因：微信对虚拟支付管控严格，如果你在 demo 里做了一个“付费生成 AI 图片”“充值解锁识别次数”的功能，苹果端小程序是不允许直接挂支付组件的；安卓端也只能用微信支付，但需要相关类目资质。另外，AI 生成内容在 2023 年后要求在显著位置标识“AI 生成”，很多 demo 没有做这个细节。

解决：如果只是交作业，最简单是把付费入口去掉，改成“每日免费 3 次”+“分享解锁次数”，远离虚拟支付审核问题。如果确实要做收费，就只能引导到公众号或 H5 去做支付，小程序本身只做展示。AI 内容标识建议在结果页加一行灰色小字“本结果由 AI 生成，仅供参考”，既符合监管要求，也能规避 AI 幻觉带来的责任问题。这块不解决，你在开发工具里跑得再顺，审核那关也过不去。

6. 验证模型是否真正起效：一组日志和一个开关就够了

整个项目做完，最后一步是验证。很多 AI 小程序在 demo 状态下“感知不到模型存在”，因为开发者把返回写死了。验证的真实方法并不复杂：在请求封装层加入一个日志缓冲开关，默认开启，把每次请求的入参、耗时、返回结果的关键字段记录到一份全局数组里，并同时输出在控制台。这个开关的好处是你在答辩时可以现场展示“从点击到结果返回”的完整链路，也能在你不在 Wi-Fi 环境下排查问题。

我会在app.js里维护一个全局数组，命名为__aiLogs，在request.js的resolve和reject两个分支里写入一条记录：

const log = { time: Date.now(), path, request: data, response: res.data, costMs: Date.now() - startTime, }; getApp().__aiLogs.push(log); // 保守起见，日志数组长度超过 30 条时只保留最近 30 条 if (getApp().__aiLogs.length > 30) { getApp().__aiLogs.splice(0, getApp().__aiLogs.length - 30); }

这串日志就是你判断“ AI 在起作用”的证据：看costMs，如果每一条请求都稳定在 1 秒内返回，大概率是 mock 数据；如果波动在 3 到 10 秒，且返回内容随入参变化，那就是真实模型。我自己的习惯是每次交付前在开发者工具里点击一次按钮，盯着 Network 面板确认请求发到了真实域名、响应里有模型输出的结构化字段，再去准备答辩 PPT。如果你拿到了一个市面上的 demo，第一件事就是打开utils/api.js检查 BASE_URL，如果地址写的是localhost或127.0.0.1或根本没有，那说明 AI 能力是假的，需要先把这块补齐再谈其他。希望这个流程能帮你少走一圈弯路。

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