Cursor 新增应用发布：把 AI 原型变成同事可用的内部工具

11 月 5 日，Cursor 推出直接构建和发布在线应用的能力，把数据库、登录与托管接入云端 Agent 的工作流程。对已经用 AI 写出页面、却还要自己安排部署和同事访问的小团队，它补上了从原型到实际使用的一段路。本文用一个内部报名工具，讲清新流程如何运作、适合什么项目，以及上线前仍要亲自验证哪些行为。来源：Cursor 发布说明

原创 AI 概念插画，纸艺建筑、人物与登录入口均为示意，不代表产品界面或实际部署结果。

[配图建议：一个折叠纸窗沿小径连接到有登录入口的共享工作室，数据库与钥匙融入建筑 + 桃色、淡紫与靛蓝的微缩纸艺风格。]

一、新增的是交付流程，入口在云端 Agent

一个能在自己电脑上打开的报名页，交给同事之前，还要回答几个问题：数据存在哪里？链接从哪里来？换一台电脑能否访问？谁能看到报名名单？

Cursor 这次将这些环节放进同一条流程：明确告诉云端 Agent 要构建应用，准备好后预览，再选择发布。需要数据库时，系统会配置 Postgres，并安排应用托管和登录。它面向可以使用云端 Agent 的付费计划，本地 Agent 不是这个功能的入口。来源：Apps 使用说明

对已有项目，也要先确认仓库入口。发布公告列出 Cursor Origin 和 GitHub 的新旧仓库，GitLab 等其他 Git 提供商的应用部署支持仍在后续计划中。来源：支持范围

这里不要把两件事混在一起：云端 Agent 能连接哪些代码仓库，与 Apps 发布链路支持哪些仓库，并不自动相同。团队若已有固定托管和交付流程，应按这次具体功能的范围判断接入条件。

它最直接的价值，是减少“小工具写好了，却没人能稳定打开”的交接工作。开发者可以更早让真正的使用者试一条完整流程，而不只是看一张漂亮截图。

[配图建议：从页面原型依次走到数据库、登录和在线链接，最后由另一位同事打开 + 连贯的纸艺路径插画，避免画成已经完成的真实项目。]

二、拿报名工具举例，先定义一条真正能用的流程

假设团队每周组织内部分享，想让同事选择场次并报名。一个好看的列表页只是开头，真正的需求至少包括：报名写入后再次打开仍存在；重复点击不会产生多条相同记录；负责人能够确认名单。

可以先把任务这样交代给 Agent：

构建一个内部分享报名应用。先使用虚构的场次和人员数据；同事登录后选择场次报名，刷新后仍能看到自己的报名状态。请同时展示数据结构，并说明重复报名怎样处理。

这是本文自拟的需求示例，不是已经运行通过的提示词。它刻意把重点放在可核对的结果上，让“页面做出来”对应到“报名被保存”。

Cursor 文档说明，应用会部署到为团队或个人创建的独立托管账户，需要时自动配置数据库。这个流程减少了手动拼装基础设施的步骤，但数据字段、重复记录规则和异常提示，仍要落实在应用里。来源：应用运行机制

对报名工具，可以让一位同事完成报名，另一位负责人查看记录，再刷新页面、重新登录和重复提交。这样得到的反馈，比单独检查按钮能否点击更接近日常使用。

云端开发环境也要与已部署应用分开理解。前者是 Agent 读取仓库、安装依赖和运行测试的地方；后者是同事打开链接时实际访问的应用。官方环境说明强调，Agent 需要正确的依赖、工具和服务连接才能验证代码。来源：云端开发环境

[配图建议：同事报名、记录写入、负责人查看三个场景形成闭环，旁边单独画开发环境 + 分镜式产品流程插画，示例信息全部虚构。]

三、有登录入口，还要验证名单究竟对谁可见

Apps 可以只分享给指定人员或组，也可以分享给整个团队；私有与团队应用需要 Cursor 登录。公开分享则允许持有链接的人访问。Teams 和 Enterprise 默认关闭公开分享，管理员可以调整这一设置。来源：共享范围

回到报名场景，这对应三种不同决定：

能进入应用，与能修改某条记录，是两个层次。例如，所有同事都能报名，不代表每个人都应删除别人的报名；组织者能看完整名单，也不代表名单必须出现在普通用户页面上。

SSO 解决了身份入口，业务权限仍应按你的需求验证。试点时至少用两个角色检查一次：普通成员能做什么，负责人额外能做什么。不要只用创建者自己的账户完成所有验收。

如果应用还要连接现有数据系统，Apps 会通过专门入口接收所需密钥。文档称 Agent 看不到这些密钥值，团队管理员则可以集中管理应用和密钥。来源：Apps 密钥机制

这有助于把凭据从聊天和源码里分离出来，但应用仍会使用相应权限访问数据。第一次试用报名工具，可以先用独立测试数据，把数据库规则和角色行为确认清楚，再决定是否连接真实业务系统。

[配图建议：同一应用有普通成员与负责人两条访问路径，公开页面与内部名单分开 + 门与房间的空间隐喻插画，不用一把锁代表所有权限都已解决。]

四、发布前检查是入口，发布后验收要走完整一遍

常规发布流程中，Cursor 会运行确定性检查与 AI 安全审查；检查发现问题时，先修复，再重新发布。应用不会在创建完成后自动对外上线，还需要操作者明确选择发布。来源：发布流程

Apps 文档还列出每次发布都会执行的检查，包括阻止代码中的密钥和凭据文件，并排除 .env 文件及 source map。管理员可以添加审查规则，并审批部分被拦截的发布，但硬编码密钥等情况不能用这种审批绕过。来源：检查与管理控制

这些检查关注常见发布问题。对报名工具，负责人还需要确认：

• 保存是否有效：报名之后刷新、重新登录，记录是否仍在？
• 角色是否正确：普通同事能否操作本应只有负责人能改的内容？
• 状态是否一致：重复报名、取消报名、场次关闭后，页面与数据库是否一致？
• 交接是否清楚：谁维护场次，谁处理错误，谁决定调整共享范围？

这不是要把小工具试点变成大型上线项目。先用虚构数据完成一条完整路径，再交给少量真实使用者，通常更容易判断收益：究竟减少了多少来回部署与解释，还是新需求主要卡在数据和权限设计上。

适用性也应从这里判断。已经有明确内部需求、并愿意采用 Cursor 登录与托管路径的团队，容易开始试点；必须沿用特定仓库、运行环境或身份系统的项目，则应先核对这些前提。工具把一些步骤接起来，项目的完成标准仍由使用者决定。

[配图建议：一张发布检查单旁，另一张记录实际访问、保存和角色测试的验收单 + 清爽的编辑插画，所有结果栏留空，不伪造检查通过截图。]

今天先让一位同事走完一次报名

Cursor Apps 把 AI 生成应用向团队交付推进了一步。想做内部工具的团队，可以先选一个小需求，用测试数据、小范围共享和明确的角色规则验证；已有复杂交付约束的项目，先确认入口是否适配。今天就找一位同事，让他从打开链接到完成报名走一遍，再根据真实卡点决定下一步。你的原型最常停在哪一环：发布、数据保存，还是别人根本不知道怎么用？

[配图建议：两位抽象人物分别扮演构建者与试用同事，中间是一条完整的报名路径 + 温暖的纸艺工作室风格。]

资料核查截至北京时间 2026 年 11 月 6 日；功能发布日期沿用 Cursor 官方标注的 11 月 5 日。本文为一手资料分析，未登录试用、未部署应用，报名场景和提示词均为自拟示例；封面为原创 AI 概念图。