WorkBuddy开发指南：小程序、网站、云服务、Git并行开发一次讲透

上一篇聊了Buddy应用怎么用，这一篇换个角度——怎么在WorkBuddy里把东西做出来并发布上线。从微信小程序到网站应用，从云服务配置到Git分支管理，这套开发链路比很多人想象的完整得多。不需要本地搭环境，不需要买服务器，甚至不需要装微信开发者工具。

小程序开发：一句话生成，托管发布

WorkBuddy能根据需求直接生成微信原生小程序，账号始终归你所有。适合的场景很广：品牌展示、预约服务、活动报名、内部协作、轻量工具都行。

创建方式有三种：首页进“代码开发”选“小程序”；直接描述需求并写明“微信小程序”；或者把已有网页改成小程序。如果需要云服务，不用写技术方案，说清楚实际需求就行。比如“制作一个读书清单微信小程序，用户微信登录，阅读记录保存到云端”。

生成后对话里会出现产物卡片，右侧预览区看效果，继续对话改页面、改文案、改功能。注意一点：WorkBuddy里的预览和微信内实际运行可能有差异，微信登录这类能力需要发布为试用版或体验版后真机测试。

发布环节是重点。点击预览区右上角“分享”进入发布流程，WorkBuddy以微信第三方服务商身份接入你授权的小程序账号，代为完成代码上传、试用版生成、提交审核和版本发布。

三种版本的选择很关键：

试用版适合快速验证，不需要提前注册小程序账号，微信扫码关注服务号就能创建。但限制不少：14天有效，最多15人体验，不支持微信支付和直播，不能被搜索。一个微信号最多创建5个试用版。

体验版需要已有小程序账号，用于上线前调试和验收，不需要微信审核，但只有体验权限的用户能访问。

正式版才是对外长期运营的选择，需要完成备案并通过微信审核。

有个坑要避开：试用版不能直接转为正式版。创建试用版后仍可解绑重新选择发布方式，但如果确定要长期运营，建议一开始就绑定自己的小程序账号。

网站应用：全栈生成，链接即上线

网站应用和小程序走的是同一套云服务底座，但发布方式不同——生成后直接获得独立链接，任何拿到链接的人都能访问。

生成入口在“代码开发”下的“网站开发”或“Agent应用”。描述需求时说清楚三件事：谁用、完成什么操作、数据是否需要长期保存。比如“制作课程预约网站，学员选时间填姓名手机号，提交后名额减少，老师查看预约名单，记录保存到云端，完成后发布上线”。

如果应用需要AI能力，需求里写“接入大模型”就行，WorkBuddy会完成配置，不用自己申请API Key。

网站应用和“轻量发布”的区别值得注意：轻量发布适合把静态HTML快速变成在线链接，配合CSV做数据底座可以做轻应用；网站应用则适合需要用户注册登录、提交信息、区分角色的场景。简单判断：数据不常变、只是给人看，轻量发布够了；需要用户交互和数据持久化，选网站应用。

发布后修改应用，线上版本不会自动更新。需要重新打开分享面板点“更新”，或者直接在对话里说“更新发布”。链接保持不变，已分享出去的链接直接打开新版本。暂时不想公开就选“下线”，应用和云服务数据都会保留。只有确定不再需要时才删除，删除后数据无法恢复。

云服务：不用懂技术，但额度要心里有数

云服务是让应用“活起来”的关键——保存报名记录、支持用户登录、上传文件、查看数据统计。开启方式很简单：生成过程中WorkBuddy会主动询问，确认后自动配置，不用填技术参数。

四项核心能力：数据库存业务记录（报名、预约、订单、打卡），身份认证支持邮箱、手机验证码、微信登录，文件存储保存图片文档（单文件不超过20MB），数据统计看用户增长和注册趋势。

额度限制是每个人都要搞清楚的。 可开启云服务的应用数量和资源点按月消耗，按会员版本区分：

会员

应用数

单应用月资源点

体验版

10个

5,000

标准版

30个

25,000

高级版

50个

50,000

旗舰版

99个

150,000

资源点独立计算、按月刷新，用数据库、服务调用、文件存储时按实际用量消耗。有个细节：短信验证码提交至运营商即计费，即使未送达也消耗，但仅开启手机验证码登录功能本身不消耗资源点。

如果应用数达到上限，要么下线不用的应用释放名额，要么升级会员。

Git集成：分支可见，切换有退路

当工作空间包含Git仓库时，WorkBuddy把原本需要切终端或IDE才能做的Git操作搬进了对话界面。

新建任务页面直接显示当前分支，可以搜索切换本地或远程分支。切换时如果工作区有未提交改动，弹窗给三个选择：Commit到当前分支（默认，最安全）、Stash暂存、丢弃变更（需二次确认）。切换失败会完整回滚，不残留中间状态。

任务对话界面的状态栏实时显示当前分支，变化自动刷新。

Worktree并行开发：多个任务互不打架

这是真正提升效率的功能。当你需要同时推进新功能开发、bug修复、实验性方案，又不想它们互相污染时，Worktree Task用Git worktree原生能力为每个任务提供完全隔离的工作目录，同时共享分支和Git对象。

创建方式：输入任务指令后，如果工作空间有.git目录，输入框下方出现Worktree开关（默认关闭）。开启后选Base Branch（默认本地主分支），发送任务就开始创建。系统自动在~/WorkBuddy/Worktrees下建独立目录，基于Base Branch的HEAD新建任务分支，命名格式workbuddy/{基础分支}-{8位随机哈希}。

几个规则要记住：Base Branch创建后锁定不可改；任务分支在生命周期内不提供切换入口；创建时源工作区的未提交改动不影响新任务，新任务从Base Branch的HEAD开始。创建失败会自动回滚worktree和分支，不遗留半成品。

任务列表里Worktree Task有独特的fork图标标识，和普通任务明确区分。

一套底座，多种出口

把这几块串起来看，逻辑其实很清晰：云服务是底座，小程序和网站是两种发布出口，Git集成和Worktree是开发过程中的效率工具。

云服务由腾讯云CloudBase承载，每个开启云服务的应用运行在独立的CloudBase环境中，数据和资源天然隔离。小程序和网站共享同一套多租户体系、权限模型和计量口径，接入新终端形态不需要新的后端方案。

对非专业开发者来说，这意味着一个过去需要专业团队数周才能上线的东西，现在从一句话开始、以分钟计。对有一定技术背景的人，Git集成和Worktree并行让AI辅助开发不再是“单线程玩具”，可以真正融入工程流程。

实操建议：第一个项目从小程序试用版或轻量发布开始，跑通“生成→预览→发布→修改→更新”的完整循环。熟悉后再碰云服务和Git并行。别一上来就搞复杂任务，WorkBuddy的能力边界需要你亲手摸一遍才清楚。

你在WorkBuddy里做过什么应用？发布过程中踩过什么坑？评论区见。