用 OpenClaw 开发微信小程序：微信发需求，Agent 写代码，自动上线
目录
我每天的开发流程是这样的：
早上想了一个功能点，掏出手机给 Agent 发条微信。等我洗漱完，它已经把代码改好了，后端推到了微信云托管自动部署上线，前端构建出了可以上传的产物。我看一眼预览，觉得没问题就回个"行"。
这不是我在畅想未来。这是我这两周每天都在做的事。
整套流程听起来有点长，但拆开看就四步：Agent 懂小程序（靠 Skill）、Agent 自己改代码（靠 OpenClaw）、改完自动上线（靠云托管）、我通过微信指挥（靠微信插件）。下面挨个说。
Skill：让 Agent 懂小程序#
直接让 AI 写小程序代码，它能写，但写出来的东西经常不对——用错 API、选错框架、组件库不兼容，各种问题。
miniapp-stack 项目提供了四份 Skill 文件，相当于给 Agent 配了四本专业手册。Agent 装上之后，遇到小程序的问题会先翻手册再动手。
第一本：小程序开发手册。 微信、支付宝、抖音三家的 API 差异、生命周期、setData 性能坑、页面栈限制这些细节，全列在里面。比如 setData 不能在循环里频繁调用，要批量更新，这种坑手册里直接写好了。Agent 看了就不会犯。
第二本：UI 组件库手册。 Vant Weapp、TDesign、WeUI、NutUI、Ant Design Mini，主流的六个组件库，各自适合什么场景、组件数多少、兼容哪些平台、怎么装。Agent 搭页面之前先查一遍，根据项目情况选最合适的。
第三本：框架选型手册。 Taro（React 语法、跨端）、uni-app（Vue 生态、上手快）、MPX（性能最优、滴滴出品），各有各的好。手册里有选型决策树：只做微信就原生、团队用 React 就 Taro、要全端覆盖就 uni-app。Agent 不会给你乱选。
第四本：平台能力手册。 16 个平台的能力矩阵——哪家支持支付、哪家有云开发、包限制多少兆、审核要注意什么。做跨端发布时这本特别有用。
装法很简单，Skill 就是 Markdown 文件，放到 Agent 的 skills 目录下就行。OpenClaw、Claude Code、Codex 各有各的目录，我一向是四个 Agent 同步装。装完重启 Gateway，Agent 下次处理小程序任务时就会自动读这些文件。
效果很直接。之前跟 Agent 说"加个抖音支付"，它会瞎猜 API。装了 Skill 之后，它先查手册确认抖音的支付接口是 tt.pay，再看签名格式，然后才写代码。从泛泛而谈变成了查表办事。
OpenClaw：让 Agent 动起来#
OpenClaw 是这套工作流的核心。说白了他是一个跑在你电脑上的 Agent 运行时——接收指令、执行任务、调用工具、返回结果。
用 OpenClaw 开发小程序有个天然优势：小程序不能在浏览器里预览，传统开发得频繁切换开发者工具和编辑器。Agent 不需要 GUI，它读代码、改代码、跑构建验证就够了。每次改完跑一遍 npm run build，编译成功就算过了第一关。
具体怎么让 Agent 改代码，有两种方式。
第一种是手动发指令。 你告诉它需求，它读代码、改代码、跑验证、提交。跟在终端里用 Claude Code 差不多，只不过通过 OpenClaw 走。
第二种是 Loop 模式。 这是更有意思的玩法。你把需求写进项目里的 .loop/goal.md 文件，配一个 cron 定时触发，Agent 到点了自动醒来读目标文件，执行任务，跑验证，写结果。
两种方式可以混着用。Loop 负责日常迭代（比如批量补数据、逐页优化 UI），手动发指令负责即兴需求（比如今天突然想加个功能）。
Agent 改完代码后会自己做验证——构建通过、类型检查通过才提交推送。不是改完就完事，得跑通三条命令才算数：npm run build、tsc --noEmit、npx tsx scripts/compile-all.ts。三条都绿了才 push。
自动发布：前后端各走各的路#
代码改完推上去之后，部署是自动的。
后端走微信云托管。 仓库关联了微信云托管之后，每次 push 到 main 分支，云托管会自动拉代码、Docker 构建、部署上线。整个过程不需要人干预。
这里有个细节值得提一下。我在 Docker 启动脚本里加了一行检查：makemigrations --check。它会看数据库模型有没有改了但没生成迁移文件的情况。如果有，直接拒绝启动。
为什么要加这个？因为 Agent 改后端模型的时候，经常改了代码忘了跑迁移。没有这道检查的话，生产环境的数据库结构就会跟代码不一致，出了问题非常难查。一行命令堵住了一个典型翻车场景。
前端走构建产物。 小程序的前端发布有个硬限制——必须通过微信开发者工具上传代码，这一步 CI 没法绕过。所以 Agent 能做到的是：把代码改好、构建出 dist/wx/ 目录里的完整产物。接下来你用微信开发者工具打开这个目录，点上传、提交审核。
听起来前端还得手动操作？其实可以借助 miniprogram-ci 这个工具做半自动上传，但最终审核环节还是得到微信公众平台操作。Agent 帮你把活干到上传前的最后一步。
如果你的项目同时有个管理后台或者展示网站（像我 miniapp-stack 本身是个 Next.js 网站），那还可以挂 Vercel，push 之后全自动部署、全自动预览，连看预览都不用开开发者工具。
微信：你的口袋指挥中心#
这是整套流程里用着最舒服的一环。
OpenClaw 有个微信插件，腾讯官方维护的，叫 openclaw-weixin。装上之后，你在微信里直接跟 Agent 聊天——发文字消息，Agent 就在你的项目里干活。
安装过程不复杂：一行命令装插件，扫码登录微信，配对审核，重启 Gateway。十分钟搞定。
装好之后，微信聊天框就变成了你和 Agent 之间的沟通通道。举几个我这段时间真实在用的例子。
场景一：通勤路上提需求。
地铁上刷小程序，发现首页列表少了个下拉刷新。给 Agent 发消息："首页列表加个下拉刷新，用微信原生的 onPagePullDownRefresh。"
Agent 收到后：读 Skill 确认微信下拉刷新的 API 规范，找到首页文件加上 onPagePullDownRefresh 生命周期，绑定数据请求逻辑，跑 npm run build 验证通过，提交推送。后端如果有改动，云托管自动部署。我到公司打开微信开发者工具一看，效果已经在那了。
场景二：午休发现 bug。
吃饭的时候用户反馈说某个页面在安卓上白屏。给 Agent 发消息："用户反馈 Android 上 XX 页面白屏，帮我排查一下。"
Agent 翻代码，发现问题出在一个 CSS 属性上——某个 webkit 前缀的属性安卓不支持。改掉，构建，推送。我午休完一看，修复版本已经准备好了。
场景三：晚上问进度。
躺床上发一句："今天 build 了几次？都过了吗？"
Agent 回复：今天构建了三次，全部通过。最后一次推送在 16:42，改了三个文件，提交记录是 xxx。云托管 16:45 部署成功。
不开电脑，不看终端，微信里全搞定。
有些人可能担心安全问题——Agent 能在微信里随便改代码？不会的。微信插件有白名单机制，只有你审核通过的人才能跟 Agent 对话。在群里 Agent 也只在被 @ 的时候才说话，不会主动插嘴。
一天的完整节奏#
把上面四块拼起来，一天的流程大概是这样的：
早上。 如果配了 Loop，Agent 到点自动启动，读目标文件开始干活。我起床后打开微信，看看昨晚和今早的迭代结果。没有配 Loop 也没关系，我直接发微信告诉 Agent 今天要做什么。
白天。 Agent 改代码、跑验证、提交推送。后端推上去之后微信云托管自动部署。前端构建产物备好，等我用开发者工具上传。想到什么新需求，随手在微信里说一句。
晚上。 Agent 发微信告诉我今天做了什么、构建有没有过、有没有遇到问题。我扫一眼，给反馈或者调整明天的方向。
整个过程里，我打开终端的次数屈指可数。大部分沟通在微信里完成，大部分执行 Agent 自己搞定。
实操：从零搭这套流程#
如果你想试，大致需要这些步骤。
装 OpenClaw。 参考官方文档，macOS 一行命令装好。openclaw gateway status 确认在跑就行。
建项目，装 Skill。 把 miniapp-stack 的四个 Skill 文件复制到 ~/.agents/skills/ 下面。四个文件分别是 miniapp-dev、miniapp-ui、miniapp-framework、miniapp-platform，都是 Markdown。复制完重启 Gateway。
配后端自动部署。 后端代码推到 GitHub，在微信云托管控制台关联这个仓库。选好分支和 Dockerfile 路径。之后每次 push 到这个分支，云托管自动构建部署。启动脚本里记得加 makemigrations --check，防止数据库不一致。
装微信插件。
npx -y @tencent-weixin/openclaw-weixin-cli install
openclaw channels login --channel openclaw-weixin
openclaw gateway restart
扫码登录，配对审核，完事。
开始用。 在微信里给 Agent 发第一条消息：
"帮我看看项目结构，告诉我现在前端用的什么框架、后端用的什么。"
Agent 读 Skill、翻代码，给你一个准确的回答。从这一刻起，你的微信聊天框就能指挥一个小程序开发流程了。
几个实用建议#
用了两周，有些经验值得说。
给需求要具体。 "首页优化一下"这种需求 Agent 改起来会跑偏。好需求的格式是：哪个文件、改什么、用什么方案。比如"首页列表加下拉刷新，用 onPagePullDownRefresh"，Agent 一发命中。
让 Agent 验证完再报告。 有时候 Agent 改完就说"搞定了"，但其实构建没过。养成习惯：每次让 Agent 报告的时候问一句"build 过了吗"。或者在项目配置里写死规则——不跑通验证不许说完成。
前期多看 diff。 刚开始用的时候，Agent 每次提交后都看一眼 diff。不用逐行看，扫一眼大概改了哪些文件、改动范围是否合理。等信任建立起来后可以减少频率。
善用 Skill。 Skill 是 Agent 和你之间的知识桥梁。项目特有的约定（比如设计 token、Store 命名规范、API 路径规则）也可以写进 Skill。Agent 读了就不会瞎猜。
小结#
小程序开发一直有个痛点：环境重、链路长、反馈慢。你得在开发者工具、编辑器、终端、后端控制台之间来回切。
这套工作流把链路打通了：Skill 让 Agent 懂小程序，OpenClaw 让 Agent 动起来，云托管和构建链路让代码自动上线，微信让你随时随地提需求。
Agent 干执行层的活——读代码、写代码、跑验证、推提交。你干判断层的活——定方向、审结果、提反馈。分清楚这两层，效率就上来了。
我不是在讲一个概念。这是我现在每天开发小程序的方式。
项目地址：miniapp-stack | GitHub: UltraVacuum/miniapp-stack