做内部工具，Cursor 把数据库、登录和部署一起接走了

Cursor 昨天加了一个很容易让人手滑点开的按钮：让云端 Agent 直接把一个应用做出来、配上数据库和登录、挂到链接上，再发给同事。

这事听着像「一句话建应用」，但我觉得它真正改掉的，是许多内部小工具最尴尬的一段路。代码已经能跑，浏览器里也有个像样的界面，产品同学在群里问一句「能给个链接吗」，所有人突然安静。因为从 localhost 走到能交付，后面还有数据库、账号、域名、密钥和谁能把它关掉。这些活以前总要有人慢慢接手。

Cursor 的 Build Live Apps 把这段路并进了云端 Agent：它可以搭 Web 应用，按需创建 Postgres，接入 Cursor SSO，准备托管；通过检查并由人明确发布后，才会拿到一个可以分享的链接。对开启云端 Agent 的付费方案已经开放。

图：Cursor 官方发布页主视觉。本文没有实测该功能，下面的判断只基于官方公开说明。

我不太关心它能不能把一个待办清单再造一遍。Agent 现在把界面拼出来，已经不是最难的部分。更值得试的是：一支小团队要把「给自己人用的小工具」交出去时，能不能少一次手工搬运，又不把交付责任一起蒸发掉。

它接走的，不只是部署

过去做个内部报名表、销售看板或新人培训页，最顺的一段往往是写页面。卡人的地方在页面之后：项目放哪儿、数据放哪儿、同事用什么账号进来、链接会不会被转出去、有人把密钥写进环境文件时谁能发现。

Cursor 这次把这些事情排成了一条链。你可以从新仓库或已有的 Cursor Origin、GitHub 仓库开始；应用需要数据时，它会按需启动 Postgres；需要身份时，用 Cursor SSO；要发布时，选一个唯一域名。官方还说，发布前会跑确定性检查和 Agent 式检查，盯住把密钥写进应用文件、暴露凭据这类常见问题。检查没过，或者人没有明确发布，应用不会上线。

好家伙，IDE 终于开始碰交付链路里最容易被一句「你顺手弄一下」带过去的部分了。

但也正因为它把链路接得更顺，团队更容易误以为「上线」已经是一件纯技术动作。不是。对一个内部应用来说，生成页面只是开始；它一旦有数据、有登录、有 URL，就已经在替团队做权限和责任的选择。

第一扇门：数据能不能进去

官方写的是「按需启动 Postgres」。这很方便，也很容易让人把「有数据库」误读成「数据方案已经想清楚」。两者差得挺远。

如果只是无敏感信息的会议报名、团队知识整理，数据库可以是一个快速验证的容器。但一旦准备接真实客户资料、员工信息、付款状态或数据仓库，问题马上变成：哪些字段根本不该进这个应用？保留多久？谁能导出？删数据时是否有路径？从自己的系统接数据时，最小权限的读取账号在哪里管？

这里有个很笨、但很管用的判断：让 Agent 先做一版不接真实数据的可分享原型。页面、流程和权限边界先给同事走一遍，确认真的有人要用，再接数据源。这样你用它省掉的是脚手架和交付摩擦，不是把还没想好的数据责任塞进一个「请帮我上线」的提示词。

图：这四道闸门不是 Cursor 的官方界面，而是把发布前该问的问题画成一张检查图。

第二扇门：谁能进，谁能分享

Cursor 的默认思路是很清楚的：应用可按指定的人、群组或整个团队共享，并通过 Cursor 登录访问；个人方案还能公开分享。这比在 demo 服务器上临时塞一个弱密码靠谱得多，但它仍然需要一个团队自己的答案：这个工具到底是给十个人，给全公司，还是给外部客户？

这不是抠字眼。访问范围不同，页面里能出现的数据、上传的附件、日志里能保留的内容都不一样。尤其是内部工具最常见的第一版，往往先给熟人看，几天后就被转到另一个群。链接一旦成了工作流的一部分，再回头收权限，会比一开始少给一点权限麻烦得多。

所以我会把「分享对象」写进发布任务，而不是等最后弹出域名框再想。比如，原型阶段只允许一组明确的测试者；需要公开的页面，把能识别个人、客户或业务进度的信息全部拿掉；要给跨团队用，先确定一个能说明用途和负责人名字的入口页。它们都不华丽，但能让一个链接不至于变成没人负责的公共走廊。

第三扇门：密钥给 Agent，还是给环境

官方特别提到：如果应用要连数据仓库等系统，Cursor 会向你索要所需的密钥；发布前的检查也会发现写进文件的密钥或暴露凭据。这个设计方向没问题，至少它没有把「把 token 贴进 prompt」包装成聪明做法。

不过检查能抓常见错误，不等于它替你决定了授权范围。密钥真正麻烦的地方不是有没有藏在代码里，而是它能读什么、谁拥有它、什么时候轮换、应用停掉后谁来收回。一个只读、只允许测试数据的凭据，和一个能改生产库的服务账号，在 Agent 看来都可能只是「连接需要的 secret」，在人这里却不是同一种风险。

可以把这句话当成发布前的硬要求：让云端 Agent 拿到完成当前任务所需的最小权限，不让它替你承担权限设计。

这也给了产品和工程一个很具体的分工。Agent 负责把连接接起来、把检查跑起来、把失败信息报回来；人负责定义哪些系统能连、哪个账号能用、谁是 owner、多久复核一次。前者擅长跑流程，后者还不能外包。

第四扇门：谁有权按下下线

这次发布里有个我很喜欢的细节：团队管理员能看到所有应用和密钥，可以追加安全审查规则、批准被拦下的发布，也可以取消发布任意应用。

这不是一个可有可无的企业版功能。内部工具最容易出现的结局，就是发出去以后没人再碰，但它还带着一个域名、一个数据库和几份凭据继续活着。功能本身不一定有错，问题是它已经脱离了原来做它的人。管理员可见、可下线，至少给团队留了一根能拉回来的绳子。

如果你准备试 Build Live Apps，我建议把第一次任务写得比「帮我做一个 XX 系统」稍微啰嗦一点。下面这段不是 Cursor 的官方语法，只是一份给云端 Agent 的发布任务简报，可以直接改掉方括号里的内容：

请为【目标用户】做一个【内部工具】原型。
只使用【测试数据／允许的数据源】，不要接入真实客户或生产数据。
访问范围仅限【测试群组】，不要公开分享。
需要外部连接时，列出所需权限和密钥 owner，先等我确认。
发布前输出：数据清单、访问范围、密钥清单、回滚和下线负责人。
未收到我明确确认前，不要发布。

它看起来像是多加了几行字，其实是在把四次拍板提前。这个动作对 Agent 的帮助也很直接：它不用猜哪些东西能碰，失败时也知道该向谁要决定。

现在该不该用

我的答案是：可以从低风险、内部、可撤回的工具开始用，而且很值得用。活动报名、工位安排、培训入口、销售辅助看板，这些正好也是 Cursor 官方列出的场景。它们共同的特点是，需求能用几句话说清，先给少量同事用就有价值，做错了也能下线重来。

但别把它当成「省掉产品和工程判断」的捷径。官方没有在这份发布说明里披露托管和数据库的用量额度、地区可用性、检查的完整覆盖面，也说 GitLab 等其他 Git 平台还在路上。这些都该在接真实业务前继续核实，而不是被「一键上线」四个字盖过去。

真正让人舒服的，不是 Agent 把本地 demo 变成链接，而是你知道这个链接里有什么、谁能进、谁能关。把这几件事写清后，才放心让它跑快一点。

你们团队里最想从 localhost 推出去的那个小工具，四道闸里最先卡住的是数据、权限、密钥，还是下线权？

小岛AI