Cursor新功能：AI建应用，一键发布还带安全门禁

用AI写代码早已不是新鲜事，但大多数AI生成的应用都止步于本地开发环境——你可以在电脑上跑通，却很难真正发布出去。Cursor 最新推出的 Build Live Apps 功能，试图补齐这“最后一公里”。

从脚手架到上线：云代理包办全流程

根据 Harnesses and Agents Daily 在 YouTube 上的拆解，Cursor 的 Build Live Apps 允许云代理直接搭建应用脚手架，并在需要时自动启动一个 Postgres 数据库。接下来，代理还能配置登录认证，并将应用托管到云端，最终生成一个可分享的链接。

这套流程的意义在于，它把过去需要手动完成的部署环节——数据库配置、身份验证集成、主机托管——都收进了 AI 代理的执行范围。开发者不再需要离开 Cursor 环境去处理云服务商的控制台。

Postgres 是一种开源的关系型数据库管理系统（对象-关系数据库），以稳定性、标准兼容性和扩展性著称。在云原生开发中，它常被托管为服务（如 Supabase、Neon、AWS RDS），开发者无需自行维护服务器即可获得数据库实例。Build Live Apps 自动启动 Postgres，意味着代理会按需创建托管的数据库实例，并可能自动生成连接字符串、环境变量等配置，使应用具备持久化存储能力，这是从“本地能跑”到“可上线”的关键一步。

云代理（Cloud Agent） 指运行在云端、能调用工具并执行多步骤任务的 AI 代理，区别于仅在本地 IDE 中提供补全或对话的模型。它通常具备沙箱执行环境、网络访问和资源管理能力，可自主完成创建项目、安装依赖、配置服务等操作。Build Live Apps 依赖云代理来串联脚手架、数据库、认证与托管，因此该功能要求用户已启用云代理能力，而非仅使用基础代码生成。

发布前的安全闸门：不通过检查不上线

你可能没注意到，Build Live Apps 并没有为了追求“一键发布”而牺牲安全控制。据 Harnesses and Agents Daily 介绍，应用在发布前必须通过安全扫描，并且需要用户显式确认发布操作，否则应用不会对外公开。

这个设计回应了一个现实问题：AI 生成的应用可能包含不安全的依赖或配置，如果自动上线，风险会直接暴露给外部用户。把安全检查和人工确认设为强制步骤，能在自动化与可控性之间取得平衡。

团队治理：管理员看得见每一个应用和密钥

对于团队场景，Cursor 提供了管理侧的可见性。团队管理员可以查看所有已构建的应用以及每个应用涉及的密钥（secret）。这意味着 AI 生成的应用不再是散落在个人账户里的黑盒，而是纳入团队监管范围。

在 AI 辅助开发的语境下，这一点的价值容易被低估。当应用创建变得更容易，团队中可能出现大量由个人快速生成的小工具，如果缺少统一视图，密钥泄露或资源滥用会很难追溯。管理员的全局查看能力至少提供了一层审计基础。

Secret（密钥） 在应用部署语境中，指 API Key、数据库密码、OAuth 客户端密钥等敏感凭据。它们通常不应硬编码在代码库中，而应通过环境变量或密钥管理服务注入运行时。管理员能查看每个应用涉及的密钥，便于发现硬编码或过度授权问题；但可见性本身不等于轮换与最小权限，团队仍需配合密钥生命周期管理，才能降低泄露风险。

仓库托管与套餐门槛

代码仓库方面，Build Live Apps 目前支持存放在 Cursor Origin 或 GitHub 上，开发者可以根据团队习惯选择。功能本身覆盖在已启用云代理的付费套餐中。

这也明确了 Build Live Apps 的定位：它不是免费层的尝鲜功能，而是面向已经为云代理能力付费的用户。对于正在评估 Cursor 团队方案的开发者来说，这项功能是否纳入套餐，可能影响到采购决策。

这项功能改变了什么

AI 编程工具的竞争焦点正在从“生成代码的质量”向“交付完整应用的效率”迁移。Cursor 的 Build Live Apps 把部署、数据库、认证、托管和安全管理打包进同一条链路，对于原型验证和内部工具开发场景，能显著减少从想法到可分享链接的摩擦。

但需要注意，自动化程度提高也意味着开发者需要更理解安全确认环节的含义——点击发布之前的审查，仍然是最终责任人。

常见问题

Build Live Apps 能自动创建数据库吗？ 可以。云代理在需要时会启动 Postgres 数据库。

应用会直接上线吗？ 不会。需要通过安全检查并由用户显式发布。

管理员能看到哪些信息？ 团队管理员可以查看所有应用及其密钥。

仓库可以存在哪里？ 目前支持 Cursor Origin 或 GitHub。

哪些套餐可以使用？ 已启用云代理的付费套餐。