用一条提示词生成可上线的微信小程序：WorkBuddy实操全记录

一条提示词能不能做出一款能扫的微信小程序我这次是亲测下来了能而且整个链路比我预想的顺。最近我用 WorkBuddy 从零写了一个工具类小程序过程非常像带了个上手极快、偶尔需要盯一盯的实习生——它会按我的提示词把工程框架、页面、样式一起铺出来剩下的工作主要是检查、调错和善后。今天就按我实操的路径把从提示词、生成代码、导入开发者工具到最终扫码上线的全过程完整拆一遍。我不会跟你聊太多概念直接说清楚这条提示词怎么写、WorkBuddy 生成出来的代码长什么样、在微信开发者工具里要改哪几个点、提交审核会被哪些地方卡住。全程都是能直接抄作业的内容哪怕你没写过前端照着走也能把一个小工具类小程序弄上线。1. 为什么我把一条提示词当剧本而不是从空白工程开始1.1 这条提示词解决的核心问题做微信小程序最大的门槛不是功能复杂而是“空白页焦虑”。传统流程里你要先跑通一串前置动作注册账号、创建 AppID、下载开发者工具、新建项目、选模板、理解 app.json 里怎么注册页面、知道 .wxml/.wxss/.js/.json 四个文件各自干什么。这一套下来对于没写过前端的人基本当天就放弃了。AI 辅助开发的逻辑是把你从“从零手写”变成“生成后修改”。微信小程序本身有一套非常固定的工程规范恰恰适合让大模型代劳。WorkBuddy 本质上就是预置好了这套规范你只需要告诉它要做什么它就能按规范把目录、路由、页面、基础交互一次性铺开。我这次最直观的感受是初始化成本从小时级降到了分钟级我可以把省下的精力全部放在功能逻辑和上线细节上而不是在脚手架里打转。1.2 和传统开发流程的对比为了让你更直观地看差异我把两条路径放在一起对比环节传统开发流程WorkBuddy 流程项目初始化手动创建工程、下载模板、配置 app.json提示词生成完整工程骨架页面搭建手写 WXML、WXSS、JS逐个注册页面生成页面文件并自动注册路由基础交互手写事件绑定、数据缓存、列表渲染生成可运行的基础交互代码调试与修改从零排查交互逻辑审查提示词生成逻辑做局部修正上线准备手动配置后台、域名、隐私同样需要手动配置但代码层面省了大半你会发现WorkBuddy 并没有跳过“上线配置”“后台设置”这些硬性环节它帮你省掉的是最耗时、最劝退的编码初始化和页面搭建。后端存储、支付、复杂权限这类内容它也能生成框架但架构决策仍然要你自己拿主意。换句话说它降低的是“把想法变成第一个可用版本”的成本而不是替代所有工程决策。1.3 这个方案适合谁我身边问这个问题的朋友大致是三类人。第一类是想快速验证一个产品灵感不知道要不要投入开发的人第二类是产品经理或运营有清晰的需求描述能力但不熟悉前端技术第三类是本身有前端基础但被重复搭建页面磨得不耐烦的老手。对这三类人用提示词生成第一版再手工微调都比我之前推荐的“先学一个月前端再动手”高效得多。但我也要给你提个醒如果你要做的是强交互、高定制动画、复杂实时通信的项目AI 生成只能当起点不能直接当终稿。工具类小程序、内容展示类小程序、简单工具链是这条路线最舒服的区间。2. 准备工作把账号和提示词都备齐2.1 账号、工具与 AppID在生成代码之前有两件事必须提前做好不然代码生成完会卡在“导入工程”这一关。第一注册一个小程序账号。个人开发者注册个人主体即可路径是微信公众平台在“注册”里选小程序按指引填邮箱、身份证信息审核非常快基本当天能过。第二下载微信开发者工具这是微信官方 IDEWindows 和 macOS 都有安装包用同一个账号扫码登录就能用。注册完成后在“开发管理 - 开发设置”里能看到 AppID。这个参数我建议你提前复制到备忘录里因为后面导入工程时要填WorkBuddy 生成的代码里一般也会留一个占位符你需要替换成自己的。很多人生成完代码急着导入结果因为 AppID 没换成自己的预览时报错来回折腾半小时完全没必要。2.2 提示词为什么不能直接写“帮我做一个小程序”我第一次用这类工具时写的是“帮我做一个待办清单小程序。”结果是灾难现场——它给我生成了五六个页面包括登录、个人中心、统计报表甚至一个积分商城入口。原因是模型不知道你的真实范围边界你给一条模糊需求它就会按“常见小程序”的样子自由发挥把能有的功能全给你铺上去。所以提示词写作的核心不是“把需求说清楚”而是“把边界锁死”。你要告诉它一共有几个页面每个页面要展示什么支持哪些操作数据存在哪里长什么样。有了这些约束它生成的代码才不会跑偏。2.3 我用的可复用提示词模板下面这份模板可以直接复制进 WorkBuddy里面的需求描述你可以按需替换你是一名微信小程序前端工程师请用原生微信小程序实现一个「待办清单」小程序。 页面要求 1. 首页展示待办列表支持新增待办、勾选完成、长按删除 2. 新增页输入框 保存按钮保存后返回首页并刷新列表 3. 设置页展示当前待办数量提供“清空全部”按钮并二次确认。 交互要求 - 数据使用 wx.setStorageSync 本地持久化刷新或重启后不丢失 - 新增待办后自动刷新首页 - 删除操作需通过 wx.showModal 二次确认。 视觉要求 - 主色使用 #07c160微信绿列表使用卡片样式 - 空状态显示“暂无待办点击右下角新建”。 技术约束 - 使用原生小程序语法不要引入第三方组件库 - 微信 API 统一使用当前最新推荐写法 - 生成完整 app.json 路由配置。你可能注意到我特别强调了“数据存在本地”因为很多人写提示词时不会管数据层而模型默认会给所有小程序配云开发导致你后面要开通云服务、创建云函数完全是凭空增加复杂度。个人工具类项目用本地缓存就够了先把核心流程跑通再考虑多端同步。3. 实操全过程从提示词到能跑的工程3.1 WorkBuddy 生成出来的工程结构点击生成后WorkBuddy 的输出是一个标准的小程序工程目录。我第一次拿到时第一反应是“居然真能生成得像模像样”目录结构很规范. ├── app.js ├── app.json ├── app.wxss ├── project.config.json └── pages ├── index/ │ ├── index.js │ ├── index.wxml │ ├── index.wxss │ └── index.json ├── add/ │ ├── add.js │ ├── add.wxml │ ├── add.wxss │ └── add.json └── settings/ ├── settings.js ├── settings.wxml ├── settings.wxss └── settings.json这里我解释一下每个文件的职责方便你判断生成结果够不够。app.json 是整个小程序的路由表pages 数组里列出的每一个路径都对应一个页面。页面目录下四个文件分工很明确.wxml 是页面结构.wxss 是样式.js 是逻辑和数据.json 负责页面级配置。如果 app.json 里注册了一个路径但对应目录不存在编译会直接报错。所以拿到生成代码后第一件事就是对照 app.json 检查 pages 目录下是否所有引用都存在。3.2 三轮迭代修改把生成代码改成能用的代码生成只是开始真正让它变成一个能安心上线的版本我做了三轮修改。第一轮是整理页面结构。我的提示词写了三个页面但 WorkBuddy 只生成了 index 和 add 两个settings 目录压根没有app.json 里也没注册。这种情况不用重新生成我已经录入过只需要手动创建 settings 目录补上四个文件并在 app.json 的 pages 数组里加上pages/settings/settings即可。第二轮是事件绑定的修正。AI 生成的列表删除逻辑有时会直接写成bindtapdeleteTodo没有处理当前点击的是哪一条数据。这时候接收事件参数需要用e.currentTarget.dataset.id拿到对应项否则要么删错要么永远只删第一条。如果你看到生成的代码里 deleteTodo 函数没有读取 dataset需要自己补上。第三轮是过时 API 的替换。我的需求里涉及“用户信息”WorkBuddy 生成代码时用了wx.getUserProfile这个老接口。这个接口在最新版本已经被收紧了弹窗授权逻辑经常失效正确的做法是改用“头像昵称填写能力”在页面上放一个button open-typechooseAvatar让用户选择头像再用input typenickname让用户填写昵称。这是最近几年微信改版后最稳的做法。3.3 导入微信开发者工具并跑起来打开微信开发者工具选择“小程序 - 导入”目录指向 WorkBuddy 生成的那个文件夹AppID 填你自己注册的那个点击导入。这里有一个特别常见的坑如果导入后提示“未找到 app.json”大概率是目录层级选错了。WorkBuddy 生成时可能把工程文件放在某个子目录里你需要导入的是包含 app.json 的那一层而不是最外层套娃目录。导入成功后先在模拟器里完整跑一遍核心链路新增一条待办、返回首页看列表是否刷新、勾选完成、长按删除、确认弹窗、再清空全部。这个过程中如果控制台报红色错误优先看是 JS 语法错误还是 WXML 绑定错误。只要这三轮逻辑都走通你的本地开发阶段就已经结束了可以往上线推进。4. 从二维码到正式上线我走的完整提审链路4.1 真机扫码预览第一次白屏如何解决在开发者工具右上角点击“预览”会生成一个二维码手机微信扫码后就能在小程序里进行真机体验。这个环节我第一次踩了白屏的坑手机打开后一片空白模拟器里明明一切正常。后来排查发现是基础库版本和域名校验的问题。开发者工具里有个“详情 - 本地设置”默认会勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”模拟器环境下不受限制但真机预览会走真实域名校验如果你的代码里有wx.request请求非 https 接口会被直接拦截表现就是白屏。临时解决办法是在本地设置里勾上“不校验合法域名”再重新预览正式解决办法是去小程序后台把请求域名加到服务器域名白名单里。如果你像我一样用的是纯本地缓存存储代码里没有网络请求那白屏多半是基础库版本问题把调试基础库调低一点或者检查 console 里有没有 API 不兼容的报错。4.2 后台配置服务器域名、隐私保护指引真机跑通后不要急着提审还有两个后台配置必须处理。第一个是服务器域名。在微信公众平台的后台“开发管理 - 开发设置 - 服务器域名”里可以配置 request 合法域名。这里只支持 https不支持 IP 和端口。如果你的小程序没有发起任何外部网络请求这个配置可以跳过但一旦后续加了接口调用必须提前配置否则线上版本请求会被拦截。第二个是用户隐私保护指引。这个要比很多人想得要重要。现在提审强制要求你声明收集了哪些用户信息哪怕只是头像昵称也要在“设置 - 服务内容声明 - 用户隐私保护指引”中如实填写。我第一次提审就被驳回了原因就是隐私保护指引里没有完整声明头像昵称的用途。修改后重新提交很快通过。如果代码里涉及wx.getUserProfile、wx.getLocation、wx.chooseImage等敏感接口后台指引里必须逐项声明并且在代码里做好隐私弹窗或按钮触发的逻辑否则审核仍然会被卡。4.3 提交审核与正式发布所有配置完成后回到开发者工具点右上角“上传”按钮填写版本号和备注信息。然后到小程序后台“版本管理”里可以看到刚上传的开发版本点“提交审核”。提交审核时有两个细节要留意。一是类目选择个人主体的小程序建议选“工具 - 效率”或对应你真实功能的类目不要为了蹭流量乱选医疗、金融类目那基本会被拒绝二是审核备注一定要写清楚“该小程序的主要功能是什么、如何操作”审核员会按你的描述走一遍核心流程能跑通、不违规自然放行。我这次从提交审核到通过大概花了几个小时没有遇到排队严重的时段。审核通过后回到版本管理里点“发布”小程序就正式上线了。从生成代码到最终发布我全程大概用了一个下午加一晚上这个速度放在以前是没法想象的。5. 常见问题与排查实录5.1 编译报错类我用表格整理了这次实际遇到的编译问题以及对应的处理方式你可以直接对照排查报错现象可能原因处理方式找不到 app.json导入目录层级不对导入包含 app.json 的外层目录page “pages/add/add” not foundapp.json 注册了页面但目录缺失检查 pages 目录补建页面文件Component is not found误用了自定义组件路径检查 json 文件中的 usingComponents 配置WXML 语法错误事件绑定或模板语法不符按 console 提示定位到具体 wxml 行号这类问题的共性特征是app.json 里的页面注册信息与实际文件结构不一致。AI 生成的代码通常不会给你少文件但手工或跨版本情况容易漏所以第一轮排查永远先对齐“路由表”和“目录表”。5.2 接口与授权失败接口和授权问题在高版本基础库里尤其多我整理了三个高频场景wx.getUserProfile is not a function这是接口已收紧或基础库版本太低导致。处理方式是放弃旧接口改用头像昵称填写能力。wx.request fail url not in domain list说明请求的接口域名没有配置到后台合法域名列表开发阶段可以临时勾选“不校验合法域名”上线前必须补配置。还有setStorageSync报错一般是因为本地缓存空间不足单个 key 有容量上限注意减少存储量。排查授权类问题时先区分清楚是“权限弹窗没出现”还是“接口调用失败”。弹窗没出现通常是隐私授权声明没做接口调用失败通常是域名、AppID 或基础库问题这两个方向不要搞混。5.3 上线审核被驳回的三种高频原因网上很多人抱怨审核严格其实大部分驳回都是可以提前规避的。我总结出三类高频原因。第一类是类目与功能不匹配。个人主体的小程序如果涉及资讯、社交、直播等类目很容易被拒因为个人主体通常只能选部分工具、教育、生活服务等类目。选类目前先查一下小程序后台的类目资质要求。第二类是占位内容和测试数据。审核员会真实操作你的小程序如果首页写的是“测试数据”或“演示内容”他们会怀疑你的产品没有完整功能。上线前把默认数据清空改成空状态引导或者填入真实可用的内容。第三类是隐私协议不完整。只要涉及用户信息哪怕只是头像昵称后台隐私保护指引漏填就会被驳回。不要只填一个笼统的“收集用户信息”要把收集的字段、用途、使用场景写清楚。6. 如果重做一遍我会在提示词阶段先做这三件事6.1 把“不要做什么”也写进提示词踩过一次模型自由发挥的坑之后我现在的提示词都会加一句“不要添加无关页面”“不要预留假数据”“不要使用第三方组件库”。AI 生成的代码在没有约束的时候会按“典型完整产品”的样子塞功能你后期清理代码的时间可能比节省下来的时间还多。正向需求描述重要反向边界描述同样重要这一条能帮你省掉大量无意义的删改。6.2 先完成最小可运行版本再扩展功能我这次是一口气生成三个页面过程中出现了页面缺失、路由不一致的问题。如果重新做我会在提示词里只保留“待办列表 新增 删除”这个最小闭环跑通之后再对 WorkBuddy 说“添加一个设置页显示待办数量增加清空全部按钮”一次加一个功能。这样每一轮迭代的变量最小出了问题也能快速定位对个人项目来说效率反而更高。6.3 无论用工具还是手写数据边界都要提前想清楚很多 AI 生成的小程序失败在数据层没有提前决策。我用本地缓存做待办是因为单设备场景完全够用但如果想做多设备同步就必须在上线前切换到云开发或自建后端 API这个切换基本等于重写数据层。建议你在第一次写提示词时就明确写出“数据保存方式是什么”。个人工具类直接写“本地缓存”后续再加同步能力时再让模型按新架构重构相关模块。提前想清楚数据边界能避免后期为架构问题返工。这条流程跑通之后我最大的体会是写提示词本身也是一种开发能力它决定了 AI 生成代码的上限。工具负责铺路但方向和边界必须由你自己把控。如果你也有一个放在脑子里很久的小程序想法照着这个流程先跑通一个最小版本再考虑怎么做得更完整可能比一直等自己“准备好”更有效。