
## 摘要

2026 年 11 月 5 日，Cursor 上线"Build Live Apps"：云 Agent 可以按一句话需求搭出 Web 应用、开 Postgres 数据库、配好 SSO 登录、部署到一个可分享的链接。发布前会跑确定性与智能体两类安全检查，必须由人显式点击发布才会上线，团队管理员能看到每个应用与密钥、能加审核规则、能下架。这套设计给了测试团队一个清晰的观察点：**当 Agent 从"改代码"跨到"发布系统"，门禁该测哪几段。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/4f60df9d89578afc05f725868bd89c7f.png)



2026 年 11 月 5 日，Cursor 在更新日志里发布了一个叫 Build Live Apps 的功能。一句话概括：告诉云 Agent 你想做个什么应用，它会把应用搭出来、需要数据库就开一个 Postgres、把登录接在 Cursor SSO 后面、然后部署到一个你可以分享出去的链接上。

官方的说法很直白：Agent 让写代码变便宜了，但用户搭的大部分工具从来没离开过 localhost。这次要解决的就是这一段。

这篇文章不讨论这个功能好不好用。它值得测试从业者关注的，是它把一个很少见的动作摆到了台面上：**让一个自动系统走到"发布上线"这一步，然后设计门禁去卡它。**

### 一、先看清它自动做了哪些有后果的动作

很多人看到"AI 帮我做个应用"会以为这只是一种更快的脚手架。实际上它自动完成的是一串**带后果的决策**：

- **开数据库**：如果应用需要持久化，Agent 会自己去开一个 Postgres。这意味着数据结构是它定的，表怎么建、字段怎么存，可能没人复核过。
- **配认证**：登录接到 Cursor SSO 后面。这决定"谁能打开这个应用"——默认是登录后的团队成员，个人计划可以公开分享。
- **申请密钥**：如果应用要连内部系统（比如数据仓库），Cursor 会向用户索取所需的密钥。文档里写明 Agent 看不到密钥值本身，团队密钥通常由管理员创建。
- **部署与分配地址**：发布时用户选一个唯一域名，之后拿到一个可用链接，域名后续可改。
- **落地到独立托管账号**：官方文档说每个应用跑在为该团队（或个人）单独创建的托管账号里，与其他团队/用户的账号隔离。

把这五件事连起来看，会发现一个特点：**它们都不是"代码对不对"的问题，而是"权限和可见性对不对"的问题。** 而后者恰恰是传统测试最薄弱的部分——因为它不体现在功能上，体现在配置里。

### 二、官方给了四道门，但这四道门本身要被测

从更新日志和文档里能提取出四层保护，逐条看它们各自防什么、以及作为测试要验证什么：

| 门 | 官方做法 | 它防什么 | 你要验证什么 |
|---|---|---|---|
| 安全扫描 | 确定性与智能体两类检查，覆盖应用文件里写了密钥、凭据暴露等常见问题 | 把秘密硬编码进代码 | 扫描能不能抓到变体（密钥拼在字符串里、写在注释里、放进配置文件） |
| 显式发布 | 检查不通过就不许发；通过了也要人主动点发布 | 自动上线 | 绕开界面的发布路径（API、脚本）是否同样被拦 |
| 管理员可见 | 团队管理员能看到每个应用和密钥、能加审核规则、能批准被拦下的发布、能下架 | 失控扩散 | 管理员"能看到"是否等于"能看到全部"，包括个人密钥创建的应用 |
| 访问可见性 | 三种分享范围：指定人/组、整个团队、公开；团队版默认关闭公开分享 | 越权访问 | 可见性变更后，旧链接是否立刻失效 |

这四层里，第一层和第二层是"技术门禁"，第三层第四层是"治理门禁"。两者的测试方法完全不同：前者靠构造输入去打，后者靠**穷举状态转换**。

一个具体的漏洞形状：如果一个应用最初设为"团队可见"、被某人分享出去，之后管理员把可见性改成"仅指定人"，那个已经被分享出去的链接还会不会有效？这类"状态改变后旧凭据是否失效"的问题，自动生成的应用里特别容易出现，因为 Agent 在生成时通常只实现了"当前状态的判断"，没实现"状态变更时的清理"。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/d4f5a260df0ca7f5b4821196af253b0f.png)



### 三、最该补的一类用例：越权路径

这类产品有一个很典型的失败模式，值得单独说：**功能完全正常，权限错了。**

Agent 生成应用时，它的目标是"让这个应用能跑起来"。于是它会把所有让它跑起来的东西都做对：页面能打开、数据能存、登录能用。但它不一定把"不该发生的事"堵住——因为没人要求它堵。

所以用例要反过来写，写"必须失败"的那些：

**用例一，未登录直连。** 所有需要登录的接口，在无凭据时是否一律拒绝，而不是只在前端跳走。很多自动生成的应用只做了前端守卫。

**用例二，跨团队数据隔离。** A 团队的应用能不能查到 B 团队的数据。这一条的测试成本不低（要造两个团队），但它是"托管隔离"这类宣称的验收方式——官方说托管账号是隔离的，这个"隔离"必须被验证过才成立。

**用例三，公开分享的边界。** 团队版默认关闭公开分享，但管理员可以打开。那么打开之后，一个公开应用暴露了哪些数据？有没有一条"公开应用里不该出现团队内部数据"的规则？

**用例四，密钥的可见范围。** 文档说 Agent 看不到密钥值。那测试要验证的是：应用运行时能不能正常使用密钥（功能对），以及应用出错时错误日志里会不会把密钥打出来（安全对）。**"Agent 看不到"和"日志里没有"是两件事。**

**用例五，下架后的残留。** 管理员下架一个应用之后，它的数据库还在吗？数据保留多久？域名是否立刻失效？这类"删除后残留"的问题在任何自助发布系统里都出现过。

### 四、这类功能真正的测试难点：不可枚举

传统测试的假设是"系统行为由代码决定，所以我可以读完代码再设计用例"。自动生成的应用打破了这个假设——**每个应用都是现场生成的，你没法预先枚举。**

这带来三个实际困难：

**第一，用例不能按"应用"写，只能按"机制"写。** 你没法给每个生成的应用单独设计用例，但你可以定义一组机制级约束：任何生成的应用都必须满足"接口无凭据一律拒绝""跨团队数据不可见""公开应用不含内部数据"。这些约束可以做成自动化检查，对每个新生成的应用跑一遍。

**第二，检查必须在生成之后、发布之前。** 一旦应用上线，数据可能已经进去了、链接可能已经发出去了。这个时间窗口很窄，所以检查必须是自动的、快的。

**第三，样本会不断变化。** 今天验证通过的一组机制约束，在 Agent 升级之后可能不再成立（它可能换了一种脚手架、换了一种鉴权写法）。所以这套检查需要**定期用新生成的应用重新跑**，而不是验证一次就归档。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/04cb617b98c8e2a9bea9d89bd93a110f.png)


### 五、边界与不确定的地方

按惯例要说清楚哪些是官方的、哪些是我的推断。

**官方的部分**：功能存在、依赖云 Agent、安全扫描分确定性与智能体两类、必须显式发布、管理员能看应用与密钥/能加规则/能批准被拦下的发布/能下架、三种可见性、团队版默认关闭公开分享、托管账号隔离。这些都能在更新日志与文档里找到。

**官方没说的部分**：托管与数据库的价格与配额未公布（公开资料里明确提到这一点）；托管背后的云服务商与区域也未说明——对有数据驻留要求的公司，这是个必须先问清的问题；本地 Agent 不支持这条路径。

**我的推断**：第三、四节的用例与机制约束是本文提出的方法，不是官方保证。特别是"公开应用里不该出现内部数据"这条，属于产品方应当自定的规则，官方文档里没有对应承诺。

### 写在最后

这类功能最容易被低估的地方，是它把"发布"这个动作从人手里拿走了一部分，但**没有把"发布意味着什么"这件事也一起拿走**。

人发布一个东西，心里大致知道它会带来什么后果：谁会看到、数据存哪、出问题谁负责。Agent 做这件事的时候，这些判断要么被写成了规则，要么就不存在。

测试在这个位置上的作用很具体：**把"发布意味着什么"逐条写出来，然后验证每一条真的成立。** 四道门能不能拦住，五条用例能不能过，比"这个功能好不好用"重要得多。

>本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。


2026 年 11 月 5 日，Cursor 上线"Build Live Apps"：云 Agent 可以按一句话需求搭出 Web 应用、开 Postgres 数据库、配好 SSO 登录、部署到一个可分享的链接。发布前会跑确定性与智能体两类安全检查，必须由人显式点击发布才会上线，团队管理员能看到每个应用与密钥、能加审核规则、能下架。这套设计给了测试团队一个清晰的观察点：当 Agent 从"改代码"跨到"发布系统"，门禁该测哪几段。

它自己搭库、配登录、上线：中间那道门禁，测过吗

2026 年 11 月 5 日，Cursor 上线"Build Live Apps"：云 Agent 可以按一句话需求搭出 Web 应用、开 Postgres 数据库、配好 SSO 登录、部署到一个可分享的链接。发布前会跑确定性与智能体两类安全检查，必须由人显式点击发布才会上线，团队管理员能看到每个应用与密钥、能加审核规则、能下架。这套设计给了测试团队一个清晰的观察点：当 Agent 从"改代码"

测试

人工智能

安全

2026年11月5日，Cursor发布BuildLiveApps，云Agent按一句话需求搭建应用、开数据库、配认证并部署上线。功能设四层门禁：安全扫描、显式发布、管理员治理、访问控制。本文聚焦测试视角，解析越权路径、数据隔离、密钥泄漏等关键用例，探讨自动生成应用下机制级验证与状态变更清理的测试难点。

数据仓库

软件测试

数据结构

数据库

智能体

Agent

热销域名限时优惠，新客首年免费！


domain

腾讯云双十一大促

tcap

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

它自己搭库、配登录、上线：中间那道门禁，测过吗-腾讯云开发者社区-腾讯云

它自己搭库、配登录、上线：中间那道门禁，测过吗

它自己搭库、配登录、上线：中间那道门禁，测过吗

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐