WorkBuddy零基础开发微信小程序：从想法到上架完整教程

很多人打开AI工具后，只会问几个简单问题，明明工具很强，最后却被用成了普通聊天软件。这期B站教程给出的思路值得借鉴：用WorkBuddy这类桌面AI智能体，不写代码也能做出一个能上架的微信小程序。案例本身很有画面感——给一张照片录一段声音，生成一张底部带声波条和小程序码的图片，别人扫码就能听到你留在照片里的声音。

WorkBuddy到底是什么

WorkBuddy被定位为「国内平替版的Codex」，界面布局和操作逻辑与主流AI大模型类似，但本质完全不同。传统网页AI只是问答工具，没有操作本地文件的权限，看似你在用AI，实际是你在给AI打工——生成的建议还得靠你自己用鼠标键盘去执行。

WorkBuddy是一个桌面AI智能体（Agent），核心价值在于能直接操作本地电脑完成真实办公任务：批量整理文件、开发简单网站、发送飞书/钉钉消息，你只需要检查最终交付结果。用视频作者的比喻，如果Codex是「特种兵」，需要专业指挥官制定详细作战方案；那么WorkBuddy就是「大学生特种兵」——也许处理不了极复杂任务，但简单任务交给它绰绰有余，而普通职场人指挥「大学生」远比掌管「特种兵」轻松。

它的另一个优势是低门槛与低成本：装好即用，不需要配置环境、不用敲命令行；每日赠送积分，遇活动还能领几千积分，坚持签到基本够学习使用。相比之下Codex是订阅付费制，且更偏向海外生态，对国内飞书、钉钉、企业微信、腾讯文档的支持有限。

Codex是OpenAI推出的代码生成与执行系统，能够根据自然语言描述自动编写、运行和调试代码，但它主要面向有一定开发基础的用户，需要用户理解代码结构并能验证输出结果。更重要的是，Codex本身并不直接操作用户的本地操作系统环境，生成的代码仍需用户手动部署执行。「AI智能体（Agent）」这一概念与之不同：Agent不仅能生成内容，还能感知环境、调用工具、执行一系列连续动作以完成目标任务，整个过程具备一定的自主决策能力。WorkBuddy作为Agent的核心区别就在于此——它能直接调用本地文件系统、触发网络请求、操作第三方应用接口，用户下达目标后，Agent自行规划步骤并逐步完成，而非仅输出文字建议等待人工接手。

90%的人第一步就走错了

作者反复强调一个关键认知：真正落地的第一步不是下指令，而是「聊清楚」。上来就一句「帮我做个小程序」，AI只能瞎猜，产出必定是垃圾。

正确做法是先在WorkBuddy上开启「追问模式」，把模糊想法和AI聊透。比如作者的提示词大意是：「我想做一个把声音附着在照片里的小程序，现在只是模糊想法，请你从产品出发，帮我捋一下有哪些必须想清楚的问题。」注意——不是让AI给答案，而是让它把问题问全：谁会用、为什么用、什么场景下分享、别人收到后怎么打开、第一版哪些功能必须做、哪些先砍掉。经过几轮沟通，模糊想法才会变成可落地的产品思路。

有了产品思路也别急着设计。第二步让WorkBuddy同时完成两件事：整理一份精简需求文档，并对需求做技术可行性评审。像「小程序码怎么携带Sound ID」「音频怎么上传存储和审核」「用户怎么登录」「图片和声波怎么合成」这些问题必须在开发前想清楚，否则后期改的就不是一个按钮，而是整套架构。

设计稿是验收标准，不是参考图

可行性方案通过后才进入设计环节，这也是作者认为「最值钱却最常被跳过」的一步。他先让AI根据产品方案写一份专门给UI设计模型使用的提示词，然后在WorkBuddy新开绘画、切到「设计创意」、选择「移动端App」并开启AI生图，把提示词完整发进去，就能得到一整套可交互的高保真稿——不是单页，而是全部页面。

作者提醒：这一步一定要把高保真改到满意为止。设计稿不是给AI的参考图，而是后面验收前端的「标准答案」。设计阶段没定下来，AI写代码时只能自己猜。

上架前的账号与后端准备

趁设计稿生成的时间，把账号和后端环境搞定，这里有几件必办事项：

• 注册小程序：在微信公众平台注册，注册前先确认目标分类。个人注册的分类相对有限，全做完却无法上架就麻烦了。案例中的小程序属于工具类图片子类，个人即可注册。注册后在「开发管理-开发设置」拿到AppID，这是后面一切的身份证。
• 开通腾讯云CloudBase：作为后端服务器，最终发布给他人使用必须有服务器。视频提到腾讯有扶持政策，可在「小程序成长计划」里领取token和CloudBase资源。
• 装CloudBase插件并连接WorkBuddy：装好后，AI写代码时才能真正去建表、写云函数、传文件，而不是给你一堆跑不起来的伪代码。
• 安装微信开发者工具：WorkBuddy写出的代码不是在聊天窗口看一眼就完事，需要导入开发者工具编译、预览、真机调试和上传。

腾讯云CloudBase（Cloud Base，也称云开发）是腾讯面向小程序和Web应用提供的一体化后端云服务，包含云函数（Serverless函数计算）、云数据库（NoSQL文档型数据库）和云存储（对象存储）三大核心能力。对于没有服务器运维经验的开发者而言，CloudBase最大的价值在于「免运维」——不需要购买和配置服务器、不需要手动安装数据库、不需要处理域名备案与HTTPS证书，代码直接上传到平台即可运行。云函数按调用次数计费，低频使用场景下成本极低甚至在免费额度内可完全覆盖。AppID则是微信生态中每个小程序的唯一身份标识，类似于网站的域名，所有与微信服务器的通信、用户登录鉴权以及云资源的关联都依赖它来完成，因此必须在开发最初阶段获取并配置到项目中。

让AI真正写出前后端完整产品

高保真确定后，再让WorkBuddy生成一份能真正指导开发的文档。这份文档相当于产品经理、设计师和工程师之间的共同语言——没有它，AI会边写边猜；有了它，AI才知道页面、数据和云函数之间怎么连接。

接着新开绘画切到「代码开发模式」，把设计稿和开发文档一起丢进去。这里有两个关键点：

1. 把技术边界说死：想要原生小程序就明确写「原生」，否则AI可能擅自换成其他跨端框架。
2. 让WorkBuddy真正连接CloudBase：把用户声音记录存进数据库，照片、音频、SVG资源存入云存储，登录、生成、查询、删除、播放和内容审核由云函数处理。这样做出来的才是前后端完整产品，而非只能本地演示的静态页面。

第一版生成后，用微信开发者工具打开项目目录、填入AppID、编译，然后依次检查四件事：页面能否正常进入、控制台有无报错、云函数和数据库是否真实返回、手机端录音/相册保存/分享能否正常授权。

「原生小程序」与「跨端框架」的区别值得单独说明。原生小程序指直接使用微信官方提供的WXML、WXSS、JavaScript和微信专属API编写，与微信底层深度集成，调试工具支持最完整，审核通过率也相对稳定。跨端框架（如Taro、uni-app）则允许用React或Vue等前端语法编写一套代码后编译为多个平台（微信小程序、支付宝小程序、H5等），适合需要多端发布的团队。对于首次上架的个人开发者而言，跨端框架引入了额外的编译层，报错信息更难定位，部分微信新API的支持也存在滞后，AI生成的代码质量同样更难把控。因此在对AI明确「使用原生框架」，能有效避免AI擅自选用跨端方案导致后期调试困难。

迭代调优与提交审核

第一版大致还原需求后，通过自然语言与WorkBuddy多轮沟通优化即可。作者的经验是「一轮只解决一类问题」：先修运行错误，再修功能闭环，最后修视觉还原。

常用三种改法：截图圈问题（把异常界面截图圈出，说「这里空白了」）、描述现象+贴报错（把控制台报错原文贴给它）、直接下指令（如「循环按钮颜色改成微信绿」）。每改完一轮让WorkBuddy自检，再回开发者工具重新编译，模拟器跑通后用真机测试全部功能。

测试通过后先做上线检查，在开发者工具上传并填写版本号与备注，进入公众平台版本管理，把开发版设为体验版再做一轮完整验收。随后补齐上架资料：名称、logo、简介、主体认证或备案、隐私保护指引等，这些信息必须与小程序实际功能一致。

若审核被驳回，别只对AI说「审核没过」，要把驳回原文和对应页面截图一起交给WorkBuddy让它修改。审核通过后在版本管理里点击发布，一个从想法开始的小程序才算真正上架完成。

微信小程序审核是上架流程中最容易出现意外卡点的环节。审核方关注的核心维度包括：功能描述与实际体验是否一致、是否存在诱导分享或虚假信息、涉及用户数据（如麦克风、相册）的权限申请是否在隐私保护指引中有明确说明，以及内容是否符合微信平台运营规范。对于涉及音频上传的小程序，内容审核能力（即是否接入了第三方或腾讯自有的音频内容安全接口）也常被重点核查。驳回通知通常只给出条款编号和简短描述，缺乏具体指向，这也正是需要把驳回原文和对应页面截图同时提供给AI的原因——让AI有足够上下文才能准确定位修改点，而非只凭「审核没过」四个字盲目猜测问题所在。

从「AI提问者」到「AI管理者」

这套流程背后的思维转变才是核心。作者点破了一个扎心事实：学了一堆提示词工资却没涨，因为「提示词的本质只是建议，建议不值钱，执行才值钱」。WorkBuddy的意义正是把建议变成执行。

使用它需要破除三个常见误区：它不是ChatGPT的桌面聊天版，而是能读文件、调工具、自动执行任务的Agent；不是必须直接学更强的Codex，普通职场人先用WorkBuddy把工作落地，不够用了再进阶；也不是功能多就难学，难点不在界面，而在于把「向AI提问」的思维切换成「向AI下命令让它操作电脑」。

一句话总结：你是管理者，WorkBuddy是员工，电脑是你的公司。当你能用这个视角去指挥AI，六分钟搭一个小程序就不再是标题党，而是可复现的工作流。