WorkBuddy 能一句话生成微信小程序了，数据存在腾讯云 PG 里

WorkBuddy 能一句话生成微信小程序了，数据存在腾讯云 PG 里

作者：腾讯云数据库官方账号

来源：腾讯新闻

发布日期：2026-09-28 17:13

问AI · AI小程序语义搜与台账同库，PG怎样承载？

日前，WorkBuddy 的全栈应用生成能力多了一个新出口，继网页之后，它现在可以直接产出微信小程序。

对用户来说，这是一次形态扩展：应用的载体从浏览器里的一个链接，变成微信里的一个小程序码。对腾讯云数据库 PostgreSQL 来说，这是一次入口扩展：读写请求不再只来自网页前端，也会来自微信客户端里那些被扫码打开的小程序。

在 WorkBuddy 里，这串名词变成了对话的一部分：需求说清楚，Agent 判断这个应用要不要开云服务；确认之后，它替你完成代码上传、试用版生成、提交审核与发布。客户全程不需要打开微信开发者工具。

流程示意：

1. 一句话描述需求，选择小程序形态
2. Agent 判断需开启云服务，弹窗确认
3. 自动产出目标小程序，支持试用与正式发布
4. 腾讯云数据库 PostgreSQL 支撑，登录与打卡数据在云端持久化存储

1. 海量小程序，意味着海量数据库支持

过去，一套企业应用背后是一个由工程师精心设计、有容量规划、有 DBA 维护的数据库；现在，一个打卡小程序背后也是一套数据库——只是它在几秒内被创建，随时可能因为群里的一次转发突然爆量。

这就要求数据库这一层按 Agent 的节奏重新设计：

• 秒级供给：一个小程序一个独立环境，资源与数据天然隔离，创建与初始化全部通过 API 完成，没有人工开通动作；
• 无人值守：凭据按环境签发，Agent 直连自行建库建表，无需平台后端中转，异常流量不外溢到其他应用；
• 单库弹性：没人用的时候跑在低成本规格上，突然爆量就单独升配，超出额度自动转按量，业务不中断。

真正的变化在供给侧：生产这些小程序的不再是工程师，而是 Agent，而腾讯云数据库 PostgreSQL 承载小程序依然没有问题。

2. 程序里的数据，不止是几张表

这类小程序里有一部分天生带 AI：要能按语义搜、要能挂一份知识库、要能记住上一轮聊了什么。

我们没有让用户再去搭一层中间件，而是把这些能力直接做进了同一个 PostgreSQL 实例：向量、图谱、记忆与业务数据落在同一处，共用同一套权限、同一份备份与监控；大模型调用不必自行申请和管理 API Key，小程序里就能直接做智能问答和内容生成。

换句话说，做这类小程序，不必再外挂一个向量库、一个图库、一套记忆存储。

对门店巡检小程序来说，「翻出去年所有提到漏水的巡检记录」和「今天新增一条巡检台账」，调的是同一个库。

3. 终端形态会一直扩展，但后端模型不变

对数据库而言，接入新终端形态不需要新的后端方案。网页应用和微信小程序共享同一套多租户环境体系、同一套凭据权限模型、同一套资源计量口径——这是我们设计之初就确立的判断。

「每个应用一个独立后端、由 Agent 全权操作」，基础设施只需要设计一次。

如果你正在构建 Vibe Coding 产品、企业内部的 AI 开发平台，或任何需要「为每个应用提供一个后端」的产品，无论它生成的是网页还是小程序，数据库这一层我们可以支持：

• 一应用一环境：环境批量创建与回收，数据与资源天然隔离，单个应用的异常流量不外溢；
• 凭据按环境签发：Agent 拿到的是这个环境自己的凭据，直连建库建表，不必经由平台后端中转，权限边界由基础设施管理；
• 规格随时可调：升降配立即生效，超出配额自动转按量，业务不中断。

Agent 生产应用的速度还在变快，这些应用会长出更多表、更多向量、更多记忆。它们需要的数据库，要能在几秒内被创建、在无人看管时自我隔离、在爆量时被单独升配、在被放弃时被干净回收。

你人生中的第一个小程序，也许由 AI 生成；它背后的第一个数据库，可以由我们提供。

让 AI 负责 Coding，让腾讯云 Supabase（CloudBase for Supabase 版）负责后端，让腾讯云数据库 PostgreSQL 负责数据。

TencentDB