这两周的业余时间我基本全砸在了一个微信小程序上。用AI辅助开发从立项到提交审核最后数了数功能数量54个现在已经在微信正式上线。这个项目让我对AI辅助编程这件事有了很切身的体会它确实不能替代人的产品判断和架构设计但能把个人开发者的工程成本压缩到以前不敢想的程度。我做的不是那种灵感乍现做出爆款的故事更像一个一个人 AI把工程量打下来的实战样本。小程序做的是功能聚合把快递查询、汇率换算、房贷计算、垃圾分类、随机抽签这类高频但碎片化的需求全部收进同一个入口。一句话说清楚产品形态就是打开即用、无需登录的工具箱。这篇文章适合三类人看想用AI辅助做小程序但不知道怎么落地的已经在用AI写代码、但不知道如何组织一个完整项目的人以及单纯好奇50个功能到底靠什么堆出来的同行。下面我把产品规划、技术选型、AI用法、抓包调试、上线审核这些环节逐一复盘该给代码的给代码该给参数的给参数踩过的坑也一并写出来。1. 项目定调与架构50功能如何不变成一锅粥1.1 需求来源碎片化工具场景的真实痛点功能聚合类工具小程序不是新鲜物种早年已经出现过一轮大量同类产品死在堆砌感上——用户打开后不知道该点什么页面长得像官网的友情链接列表。所以项目启动之前我给自己定的调子是聚合可以但必须让用户一眼知道这里有什么、下一步要去哪。需求来源其实很朴素。我经常在微信群聊里看到这样的情况有人问明天穿什么衣服有人要换算鞋码有人甩一个快递单号让帮忙查。每一件事背后都是一次搜索、一次跳转、一次等待加载。对低频用户来说下载App太重单独搜一个小程序又觉得不值当。一个不需要登录、打开就能用的工具聚合页刚好能接住这些碎片需求。我顺手对身边几类人群做了个粗糙访谈没有大样本但方向足够明确整理出的高频场景有六类——日常生活查询、数字计算、职场实用工具、出行辅助、内容生成、趣味娱乐。后面50多个功能的需求来源基本就是从这六类往下拆的。这一步我刻意没有用AI因为产品方向这种东西AI只能辅助归纳不能替你判断。1.2 功能清单六类场景下的具体拆解先把54个功能列一部分出来不然50这个数字太虚。第一类生活查询类天气、快递查询、垃圾分类、节假日安排、黄历宜忌、身份证号解析、手机号归属地、今日油价、空气质量、潮汐表。第二类数字计算类房贷计算器、公积金计算、个税计算、BMI指数、年龄计算、日期差、单位换算、汇率换算、面积换算、油耗计算。第三类职场工具类二维码生成与解析、字数统计、JSON格式化、正则测试、Markdown预览、色号查询、图片压缩、简繁转换、语音转文字。第四类出行辅助类车牌归属地、限行查询、地铁图、航班动态。第五类内容生成类每日一句文案、藏头诗、智能对联、星座运势、谜语、冷笑话。第六类趣味娱乐类转盘抽签、骰子、硬币、石头剪刀布、缘分测试、生日密码。统计算下来54个。这类功能周期短、逻辑独立非常适合AI批量生成。定功能清单时我刻意控制了一个比例大约六成是纯前端就能算完的两成要调免费第三方接口两成需要云函数代理。这个比例直接决定了后面项目的复杂度和维护成本。1.3 架构设计组件复用与配置驱动的取舍54个功能如果每个页面都从零写工作量就是54倍个人开发者根本扛不住。我的应对策略是先拆共性再谈独特性。页面层我用的是模板页面加配置驱动的方式。所有功能被归类成三种页面形态纯展示型、输入计算型、交互互动型。三种页面结构固定不同功能之间只换数据源和逻辑部分。举个例子BMI计算和油耗计算在UI层面几乎一致——顶部输入区、按钮、结果展示区唯一区别是计算函数。这种情况下AI生成代码的效率极高因为任务变成了往模板里填东西。组件层复用了导航栏、表单输入组件、结果卡片、历史记录、分享按钮、广告位容器一共抽了8个公共组件。这里想提醒一句组件拆分粒度别太细拆到三四十个自建组件维护成本会爆炸。8个公共组件撑住54个页面这个粒度是我实际测下来觉得舒服的。数据层能做纯前端计算的绝不调接口需要外部数据的走云函数代理既避免跨域问题也避免把第三方接口密钥暴露在小程序包里。2. 技术选型原生小程序 云开发 AI编程工具2.1 原生、uniapp 还是 Taro为什么选了原生做一个小程序技术选型绕不开三件套原生微信小程序、uniapp、Taro。我直接说结论选了原生。最核心的原因原生小程序的AI训练语料比另外两个多得多。我实测的感受是让AI生成一个页面用微信原生语法写得到的代码可用率明显高于用uniapp语法写。原因不难猜微信原生语法在公开代码库、教程、问答社区里的出现频率高AI对它的理解更稳生成的代码bug更少。uniapp的优势是跨端。如果规划里要同时上支付宝小程序、抖音小程序它确实值得用。但我的需求只做微信端跨端能力是多余的反而要引入一层编译转换排查问题时多一个变量。Taro同理React语法确实好看但React在小程序里的心智负担有预期我不想给一个工具插件项目增加额外学习成本。在AI辅助开发的场景下这个决策的收益会被放大提示词里只要写微信小程序原生语法生成的代码基本能直接落地。如果选了uniapp你可能需要在一半以上的AI输出里手动纠正生命周期写法。2.2 云开发替代自建后端的理由后端选型我几乎没有犹豫微信云开发。理由非常个人——不想买服务器不想配域名备案不想处理SSL证书更不想半夜起来处理宕机。云开发提供了云函数、云数据库、云存储对这个小程序来说完全够用。实际用到后端能力的模块有这几个快递查询聚合第三方接口信息、二维码生成调第三方API并在云端返回、短链服务、语音转文字、以及后续要做的收藏同步。全部走云函数一个Node实例搞定。云函数开发有个细节值得单独说一下云函数的入口格式是exports.main async (event, context) {}。AI默认生成的Node接口很多是Express风格让它转成云函数格式时必须在提示词里写清楚这是微信云函数入口是exports.main否则每次都要手改。这个细节我第一次没注意连续被AI生成的Express代码坑了好几轮后来干脆专门写了一条提示词模板。2.3 AI编程工具的真实用法让AI写代码的正确姿势很多人以为AI编程就是甩一句话让AI把整个小程序生成出来我也见过不少被一次性生成整个项目案例坑惨的人。我的做法是分层使用AI而不是让AI接管全局。第一层产品层用AI整理功能清单、拆分用户故事、给页面信息架构提建议。这一层AI输出的是文字不是代码重点是利用它的归纳能力。第二层页面层让AI生成单页完整代码。提示词包含页面功能描述、数据结构、组件库名称、UI风格要求一次只做一个页面。第三层逻辑层让AI写纯函数比如计算、校验、格式化、解析。这类代码最容易指令明确正确率最高。第四层集成层让AI解释报错、辅助改Bug、把两块代码拼接在一起。这套分层下来真正做到了代码不是一个个字符敲出来的但架构是我定的需要交互设计的页面UI也是我调过的。这里有一个非常实用的提示词技巧让AI先生成页面骨架再填充细节。比如用微信小程序原生语法写一个输入框组件的wxml和wxss支持label和必填标记样式文件独立。一次需求只覆盖一个点产物明显比帮我写个完整的计算器页面这种宽泛要求干净很多。有一点必须泼冷水AI生成的代码质量参差尤其UI样式部分经常溢出或错位不要指望完全不看。我会让AI生成代码后自己过一遍关键逻辑再用微信开发者工具真机预览来验证视觉效果。3. 核心功能与页面的实现细节3.1 页面列表加载更多onReachBottom 与分页参数功能聚合类小程序列表加载更多通常在两个场景出现首页按分类展示功能列表时内容页展示成语、名言、谜语库这类数据时。首页的实现方式比较简单data里的list一开始只加载第一屏大概20个功能用户滚动到底部触发onReachBottom然后追加下一批。因为是纯本地数据不需要请求后端用一个简单分页游标就行Page({ data: { pageIndex: 1, pageSize: 20, hasMore: true }, onReachBottom() { if (!this.data.hasMore) return; this.loadMorePage(); }, loadMorePage() { const next this.data.pageIndex 1; // 从全量数据源中切出下一页 const nextList ALL_FUNCTIONS.slice((next - 1) * this.data.pageSize, next * this.data.pageSize); this.setData({ list: this.data.list.concat(nextList), pageIndex: next, hasMore: nextList.length this.data.pageSize }); } });两个坑需要注意。第一数据量特别少的时候别分页如果总共就30条数据还搞上拉加载用户会觉得这个产品很傻。我是因为有内容库要放进去才设计分页。第二onReachBottom需要在page.json里配合onReachBottomDistance使用默认值是50px。设计上要保证页面底部有足够高的占位空间否则内容还没滚到底事件根本触发不了。3.2 动态设置标题与导航栏适配工具型小程序的每个功能页进去后需要把顶部导航栏标题换成功能名。这样有两个好处用户知道自己在哪个工具里分享出去的卡片标题准确。实现方式很简单在页面的onLoad里读取路由参数然后调用接口onLoad(options) { const title options.title || 工具箱; wx.setNavigationBarTitle({ title }); }另一个容易忽略的细节是胶囊按钮右侧的适配。不同手机的导航栏高度不一样右侧胶囊按钮的位置也不同。最初我用了固定像素结果在部分安卓机上标题和胶囊按钮挤在一起。后来改成用wx.getMenuButtonBoundingClientRect()动态计算右侧留白才彻底解决。这段代码AI生成的原始版本只有固定像素我接手调成了动态版本。AI能搞定九成剩下的一成就是这种需要真机验证的适配细节。3.3 监听用户离开小程序会话统计怎么做监听用户离开这个需求是因为我想知道用户在每个功能页停留多久、什么时候退出。小程序提供的核心生命周期是App.onHide整个小程序切后台和Page.onHide页面被覆盖或收起。对工具小程序来说App.onHide比Page.onHide更值得关注。我的处理逻辑是在App.onHide里记录时间戳在App.onShow里计算本次会话时长再通过getCurrentPages()拿到当前页面路径最后把这个会话记录上报到云开发数据库。这里有个容易踩的坑用户按Home键切后台再切回来到底算不算一次离开如果只在页面级onHide里处理每次切后台都会重复记录数据会虚高。我的建议是统一在 App 级处理页面级逻辑只用于特定场景比如需要感知页面是否被扫码进入。电商类小程序还要考虑onHide里支付回调的防重问题我的工具类场景没有支付但这块大家做电商开发的时候一定要重视。3.4 顶部导航栏高度与安全区适配功能页有自定义导航栏需求时高度适配是跑不掉的坑。计算规则是状态栏高度 导航栏高度 胶囊高度大致等于windowHeight。实际开发中我直接用wx.getSystemInfoSync()拿状态栏高度再结合胶囊位置计算整体高度。底部安全区同样要处理。iPhone 的底部小黑条会遮挡操作按钮我在涉及按钮、弹窗的页面里统一加了padding-bottom: env(safe-area-inset-bottom);这套适配方案在老机型上不会炸因为env()在不受支持的浏览器里会被忽略页面只是少了底部留白而已不致命。4. 调试与抓包联调阶段的必修课4.1 Charles 抓包微信小程序的配置步骤开发联调阶段抓包几乎是躲不开的。我需要排查第三方快递API的返回结构是否正确、确认云函数代理后的响应格式是否符合预期、看图片链接是否被防盗链拦截。几十个功能对接不同接口全靠云开发日志效率太低这时候Charles就派上了用场。Charles是一款HTTP/HTTPS代理调试工具免费版足够个人开发使用。配置步骤不算复杂但每一步都不能漏电脑装好Charles打开 Proxy 菜单下的 SSL Proxying Settings勾选 Enable SSL Proxying添加 host 为*、port 为443这样放开全部HTTPS流量。手机和电脑连同一个局域网手机WiFi代理设为手动服务器填电脑的局域网IP端口填Charles默认的8888。手机浏览器访问chls.pro/ssl下载安装Charles根证书。iOS还需要在设置-通用-关于本机-证书信任设置里手动打开这个证书的信任开关这一步不打开抓到的全是乱码或直接失败。在微信开发者工具里勾选不校验合法域名或真机上打开调试模式才能完整看到小程序发出的HTTPS请求。这套流程请一定记牢联调的时候能省下大量时间。我见过好几个同事卡在证书装了但信任开关没开一个问题排查了几个小时。4.2 真机与开发者工具抓包的区别开发者工具和真机抓包的情况不太一样。开发者工具自带Network面板如果只是排查自己写的请求其实不一定需要Charles。工具里直接能看到请求url、headers、参数和响应够用。但真机调试是另一个世界。真机上跑的是真实环境容易出现开发者工具里正常、真机上请求失败的诡异问题。最常见的原因就是正式环境下的合法域名校验——小程序后台要求配置request合法域名没有配置的域名在真机上会被拦截。Charles这时候的价值就体现出来了你能抓到真机上小程序实际发出的请求确认请求是否被拦、是否带上了正确的headers和referrer。有一点要说明安卓7.0之后系统对用户安装的CA证书限制加强很多App默认不信任用户级证书。小程序环境也有类似限制遇到证书装了还是抓不到的包先别怀疑Charles坏了去查证书信任链和代理是否真的生效。我在模拟器和真机之间反复切换过结论是真机抓包前一定先确认代理设置和证书两个环节同时OK。4.3 抓包的正确用法定位问题、修复问题抓包真正的价值有三个。一是看第三方SDK秘密发出去的请求长什么样很多小程序会接入统计SDK、广告SDK出了隐私合规问题你肉眼根本看不到它们在请求什么二是看小程序实际请求的设备参数User-Agent、屏幕分辨率、网络状态这些信息在开发者工具里是模拟值到了真机才真实三是确认请求头缺失导致的接口403。我实际遇到过一次非常典型的案例云函数返回数据正常但小程序前端拿不到Charles抓包后发现云函数返回值里带了一个特殊字符在控制台日志里根本看不出来一抓包原形毕露处理掉就正常了。所以我的习惯是遇到任何代码看起来没毛病但结果不对的问题第一反应开Charles不要凭猜。抓包工具也有使用边界。它只能调试自己开发的产品不该用来绕过登录认证、伪造请求数据、薅第三方平台的接口。做开发调试和做破坏之间有一条很清晰的线别越过去。5. 上线审核与运营反馈5.1 从体验版到正式版的完整流程小程序从开发到上线流程是固定的注册小程序账号、选择类目、开发完成后在微信开发者工具里上传代码然后到 mp.weixin.qq.com 后台设置体验版、提交审核。审核时会同时过机器和人工两道关。个人开发者和企业主体能选的类目范围不一样这一点在功能和隐私策略设计阶段就要想清楚不然做完了因为类目不符被卡住返工成本极高。审核的核心检查点有三个类目是否匹配、隐私协议是否完整、页面里是否存在诱导分享或虚拟支付等违规行为。我个人的体验是首次提交审核大概用了半天到一天时间出结果。被拒之后修改再提审一般会比首次更快。整体节奏不算折磨人但前提是你提前把该准备的资料准备齐。5.2 审核被拒的两次血泪记录这次项目被拒过两次都值得记下来。第一次是星座运势功能。功能本身没有问题但我在类目选择里把它归类为占卜算命审核直接要求提供相关资质。后来改成了娱乐消遣类目删除了页面文案里预测这类敏感字眼改成参考、仅供参考才顺利过审。第二次是页面底部放了一个联系客服入口点击后跳转到公众号关注页。审核理由写的是页面功能与服务内容不符要求整改。后来改成小程序自带的客服消息按钮也就是wx.openCustomerServiceChat问题解决。这两次被拒让我总结出三条经验第一类目比功能数量重要得多功能再多也要确保每一个都能对上所选类目第二提审前自查极限词文案里不要出现最、第一、全网这种绝对化表达第三隐私协议必须写清楚收集了哪些数据、用在哪里我用了云开发存用户openid这一步逃不掉。5.3 第一批用户的反馈与迭代方向上线后的第一批用户基本都是熟人这个不需要讳言。个人开发者的冷启动本来就靠私域。但真正有价值的反馈恰恰来自熟人因为他们会真实地使用然后在聊天里吐出一句要是有XX功能就好了。印象最深的一个反馈是有用户以为快递查询需要先登录注册结果发现打开就能用后使用频次明显高于其他功能。这个反馈佐证了我前期无感使用的判断——对工具类小程序来说能不能去掉登录授权这一步直接决定了用户留存。后面增加新功能时我把能否不授权就完成核心体验作为首要考量。迭代方向我也基本明确目前正在做的是收藏常用功能和自定义排序让用户把自己高频的工具钉在首页顶部。再往后是历史记录记录用户最近查过什么减少重复输入。数据类功能比如快递、天气要保证第三方数据源的稳定性这也是一个长期维护点。6. 复盘心得与给后来者的几点建议把整个过程串起来看AI辅助开发最大的收益不是写字速度变快了而是把大量重复劳动压缩后把真正的时间还给了产品设计。54个功能如果全部手写我可能要花一个半月最终大概率烂尾用AI辅助加上合理的组件复用两周出头就上了线。这个速度在一年前是不敢想的。但有几个认知必须说透。第一AI生成代码的可用率不是100%逻辑层大概九成可用UI层只有七成左右必须人工过一遍关键逻辑。第二功能数量不是核心竞争力单一功能的流畅才是。54个功能如果有5个体验稀烂整体评价就会被拉垮。所以我的原则是每个功能上线之前反复走一遍主流程宁可少一个功能不让一个功能是半成品。如果让我给后来者一个最直白的建议第一次做小程序不要追求50个功能做12个就够。把12个功能跑顺、跑稳比做50个功能然后被维护成本拖垮要划算得多。我这次敢上量是因为用了模板化架构加配置驱动AI只是在模板里填内容的工人不是设计者。最后再分享一个小技巧云开发日志在排查问题时很有用但云函数打印日志要控制detail级别不然调试信息会全部写到数据库里越积越多既费存储又拖慢查询。我后来统一在云函数入口做了日志级别控制生产环境只打error和warn调试信息单独开一个开关这样排错和稳定性能兼顾。这个细节看起来不大但实际用下来很值。