摘要
2026 年 11 月 5 日，Cursor 上线"Build Live Apps"：云 Agent 可以按一句话需求搭出 Web 应用、开 Postgres 数据库、配好 SSO 登录、部署到一个可分享的链接。发布前会跑确定性与智能体两类安全检查，必须由人显式点击发布才会上线，团队管理员能看到每个应用与密钥、能加审核规则、能下架。这套设计给了测试团队一个清晰的观察点：当 Agent 从"改代码"跨到"发布系统"，门禁该测哪几段。
2026 年 11 月 5 日，Cursor 在更新日志里发布了一个叫 Build Live Apps 的功能。一句话概括：告诉云 Agent 你想做个什么应用，它会把应用搭出来、需要数据库就开一个 Postgres、把登录接在 Cursor SSO 后面、然后部署到一个你可以分享出去的链接上。
官方的说法很直白：Agent 让写代码变便宜了，但用户搭的大部分工具从来没离开过 localhost。这次要解决的就是这一段。
这篇文章不讨论这个功能好不好用。它值得测试从业者关注的，是它把一个很少见的动作摆到了台面上：让一个自动系统走到"发布上线"这一步，然后设计门禁去卡它。
一、先看清它自动做了哪些有后果的动作
很多人看到"AI 帮我做个应用"会以为这只是一种更快的脚手架。实际上它自动完成的是一串带后果的决策：
- 开数据库：如果应用需要持久化，Agent 会自己去开一个 Postgres。这意味着数据结构是它定的，表怎么建、字段怎么存，可能没人复核过。
- 配认证：登录接到 Cursor SSO 后面。这决定"谁能打开这个应用"——默认是登录后的团队成员，个人计划可以公开分享。
- 申请密钥：如果应用要连内部系统（比如数据仓库），Cursor 会向用户索取所需的密钥。文档里写明 Agent 看不到密钥值本身，团队密钥通常由管理员创建。
- 部署与分配地址：发布时用户选一个唯一域名，之后拿到一个可用链接，域名后续可改。
- 落地到独立托管账号：官方文档说每个应用跑在为该团队（或个人）单独创建的托管账号里，与其他团队/用户的账号隔离。
把这五件事连起来看，会发现一个特点：它们都不是"代码对不对"的问题，而是"权限和可见性对不对"的问题。 而后者恰恰是传统测试最薄弱的部分——因为它不体现在功能上，体现在配置里。
二、官方给了四道门，但这四道门本身要被测
从更新日志和文档里能提取出四层保护，逐条看它们各自防什么、以及作为测试要验证什么：
| 门 | 官方做法 | 它防什么 | 你要验证什么 |
|---|---|---|---|
| 安全扫描 | 确定性与智能体两类检查，覆盖应用文件里写了密钥、凭据暴露等常见问题 | 把秘密硬编码进代码 | 扫描能不能抓到变体（密钥拼在字符串里、写在注释里、放进配置文件） |
| 显式发布 | 检查不通过就不许发；通过了也要人主动点发布 | 自动上线 | 绕开界面的发布路径（API、脚本）是否同样被拦 |
| 管理员可见 | 团队管理员能看到每个应用和密钥、能加审核规则、能批准被拦下的发布、能下架 | 失控扩散 | 管理员"能看到"是否等于"能看到全部"，包括个人密钥创建的应用 |
| 访问可见性 | 三种分享范围：指定人/组、整个团队、公开；团队版默认关闭公开分享 | 越权访问 | 可见性变更后，旧链接是否立刻失效 |
这四层里，第一层和第二层是"技术门禁"，第三层第四层是"治理门禁"。两者的测试方法完全不同：前者靠构造输入去打，后者靠穷举状态转换。
一个具体的漏洞形状：如果一个应用最初设为"团队可见"、被某人分享出去，之后管理员把可见性改成"仅指定人"，那个已经被分享出去的链接还会不会有效？这类"状态改变后旧凭据是否失效"的问题，自动生成的应用里特别容易出现，因为 Agent 在生成时通常只实现了"当前状态的判断"，没实现"状态变更时的清理"。
三、最该补的一类用例：越权路径
这类产品有一个很典型的失败模式，值得单独说：功能完全正常，权限错了。
Agent 生成应用时，它的目标是"让这个应用能跑起来"。于是它会把所有让它跑起来的东西都做对：页面能打开、数据能存、登录能用。但它不一定把"不该发生的事"堵住——因为没人要求它堵。
所以用例要反过来写，写"必须失败"的那些：
用例一，未登录直连。 所有需要登录的接口，在无凭据时是否一律拒绝，而不是只在前端跳走。很多自动生成的应用只做了前端守卫。
用例二，跨团队数据隔离。 A 团队的应用能不能查到 B 团队的数据。这一条的测试成本不低（要造两个团队），但它是"托管隔离"这类宣称的验收方式——官方说托管账号是隔离的，这个"隔离"必须被验证过才成立。
用例三，公开分享的边界。 团队版默认关闭公开分享，但管理员可以打开。那么打开之后，一个公开应用暴露了哪些数据？有没有一条"公开应用里不该出现团队内部数据"的规则？
用例四，密钥的可见范围。 文档说 Agent 看不到密钥值。那测试要验证的是：应用运行时能不能正常使用密钥（功能对），以及应用出错时错误日志里会不会把密钥打出来（安全对）。"Agent 看不到"和"日志里没有"是两件事。
用例五，下架后的残留。 管理员下架一个应用之后，它的数据库还在吗？数据保留多久？域名是否立刻失效？这类"删除后残留"的问题在任何自助发布系统里都出现过。
四、这类功能真正的测试难点：不可枚举
传统测试的假设是"系统行为由代码决定，所以我可以读完代码再设计用例"。自动生成的应用打破了这个假设——每个应用都是现场生成的，你没法预先枚举。
这带来三个实际困难：
第一，用例不能按"应用"写，只能按"机制"写。 你没法给每个生成的应用单独设计用例，但你可以定义一组机制级约束：任何生成的应用都必须满足"接口无凭据一律拒绝""跨团队数据不可见""公开应用不含内部数据"。这些约束可以做成自动化检查，对每个新生成的应用跑一遍。
第二，检查必须在生成之后、发布之前。 一旦应用上线，数据可能已经进去了、链接可能已经发出去了。这个时间窗口很窄，所以检查必须是自动的、快的。
第三，样本会不断变化。 今天验证通过的一组机制约束，在 Agent 升级之后可能不再成立（它可能换了一种脚手架、换了一种鉴权写法）。所以这套检查需要定期用新生成的应用重新跑，而不是验证一次就归档。
五、边界与不确定的地方
按惯例要说清楚哪些是官方的、哪些是我的推断。
官方的部分：功能存在、依赖云 Agent、安全扫描分确定性与智能体两类、必须显式发布、管理员能看应用与密钥/能加规则/能批准被拦下的发布/能下架、三种可见性、团队版默认关闭公开分享、托管账号隔离。这些都能在更新日志与文档里找到。
官方没说的部分：托管与数据库的价格与配额未公布（公开资料里明确提到这一点）；托管背后的云服务商与区域也未说明——对有数据驻留要求的公司，这是个必须先问清的问题；本地 Agent 不支持这条路径。
我的推断：第三、四节的用例与机制约束是本文提出的方法，不是官方保证。特别是"公开应用里不该出现内部数据"这条，属于产品方应当自定的规则，官方文档里没有对应承诺。
写在最后
这类功能最容易被低估的地方，是它把"发布"这个动作从人手里拿走了一部分，但没有把"发布意味着什么"这件事也一起拿走。
人发布一个东西，心里大致知道它会带来什么后果：谁会看到、数据存哪、出问题谁负责。Agent 做这件事的时候，这些判断要么被写成了规则，要么就不存在。
测试在这个位置上的作用很具体：把"发布意味着什么"逐条写出来，然后验证每一条真的成立。 四道门能不能拦住，五条用例能不能过，比"这个功能好不好用"重要得多。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
