Cursor 能把销售表格变成在线应用。发布链接后谁来维护？

周一早上，销售主管想在一个页面里看到哪些客户需要跟进。数字在电子表格里，分配规则在另一个标签页里，每个人手上的副本还有些出入。开发人员一个下午就能做出实用的看板。销售主管开口要链接时，第一个棘手的问题才出现。

开发环境 Cursor 的厂商 Anysphere 于 2026 年 11 月 5 日发布了 Live Apps。你可以请 Cursor 云端智能体构建 Web 应用，由 Cursor 配置托管和身份验证，并在应用需要时配置 Postgres 数据库。安全审查通过并执行发布操作后，应用就有了在线 URL。该功能面向已启用云端智能体的付费方案。代码可以来自新建或已有的 Cursor Origin 或 GitHub 仓库。 Cursor 发布公告

原本靠传电子表格副本和每周发消息维持的流程，现在可以用内部应用来承载。原型也更容易变成同事每天依赖的工具。以销售看板和入职门户为例，可以看看什么情况下适合迈出这一步，以及谁能查看、修改应用内容或停止服务。

按下部署按钮，下一项工作才开始

按 Cursor 的流程，需要明确提出构建应用，并使用云端智能体。本地编程会话仍然可以修改源码，但 Cursor 文档里的 Apps 工作流要通过云端智能体运行。从零开始可以在 Cursor Origin 新建仓库。如果团队已经在受支持的仓库里有应用，也可以用已有代码。Cursor 负责配置应用资源，发布者负责选择 URL 并决定何时共享。 Apps 设置与部署文档

从源代码到可用链接的过程，分别标出了访问对象和数据来源。Telli.sh 原创图。

Cursor 介绍了两类发布前审查。基于规则的检查会识别文件里直接写入密钥等已知问题。AI 安全审查会检查应用源码中是否有严重隐患。据 Cursor 介绍，团队管理员可以添加自己的规则，查看团队的应用和密钥，并取消应用的发布。某些被 AI 审查拦下的发布也可以由管理员批准。遇到恶意代码、硬编码密钥或凭证暴露，Cursor 仍会阻止发布。至于应用究竟需要哪些凭证，决定权还在应用负责人手里。 Cursor 发布公告 · Apps 安全和管理文档

假设某个应用的首页只显示销售汇总，而详情接口会返回所有客户。销售经理登录后，页面上的信息范围看起来合适。但同事可能猜到详情页 URL，或直接向后端查询表格里看不到的区域。部署审查可以发现实现缺陷。区域权限以团队的访问策略为准，发布测试也要用对应角色来验证。

链接上线后，这些选择就会影响日常工作。同事把链接存进书签后，一份打不开的报表可能拖住整个早会。如果决定和审批只记录在这个应用里，数据库也就成了业务流程的一环。应用再小，数字不对时也得有人解释发生了什么。

从只能读取的销售看板做起

假设销售运营团队需要查看两个区域的商机进展。第一个版本可以只显示各阶段的商机数量、最近刷新日期，以及跳转到 CRM 记录的详情链接。先用虚构的客户验证界面。展示正确后，给应用配置一份只能读取受限报表或数据库视图的凭证，视图里只放看板所需字段。分配和备注继续由 CRM 管理。这样首版无需修改业务记录，核对汇总数字时也有独立来源。

Cursor 的 Apps 文档说，可以在设置应用时或在 Apps 控制面板里录入数据仓库等外部资源的密钥。Cursor 表示智能体看不到密钥的值。应用上线后发出请求时，凭证的权限仍然重要。把连接留在服务端代码里，缩小可执行查询的范围，再检查生成的页面和网络响应是否泄露了本应留在服务端的字段。所谓只读密钥，只有对应账户确实只能读取指定数据时才有用。 Cursor Apps 密钥文档

用三种身份试用销售看板。目标用户应该看到正确的汇总和更新时间。另一个区域的同事，即使修改链接或请求，也只能看到应用策略允许的记录。没有被共享的人应该在任何数据返回前就被拒绝。第二种情况尤其值得验证，因为应用只有开发者自己测试时很容易忽略。

核对时使用从权威系统取出的固定快照。记录时间区间、时区、计入规则和各区域预期的准确总数。图表里好像少了周一的商机，原因可能只是统计周期理解不同。首轮测试还要覆盖空结果、上游超时和刷新停滞。明确展示最近一次成功更新时间和错误信息，能让使用者区分系统故障与真实的商机下滑。

入职门户需要保存什么，逐项决定

如果门户只链接到现有规章页面，可能用不到新数据库。可交互清单则需要保存状态。Cursor 可以按应用需求配置 Postgres，因此做第二版更容易。使用之前，先列出真正需要持久化的值。清单步骤 ID、完成时间和已认证用户的稳定标识可能就足够了。复制主管的笔记、政府签发的证件或员工住址，会增加风险，却不能改善清单。 Cursor Apps 资源文档

把员工完成流程时需要的信息，与协调人员管理流程时需要的信息分开。员工可以把自己已读的必读资料标为完成。协调人员可能需要查看同一批员工有哪些项目逾期。对协调人员视图使用单独的权限规则，并独立审查其查询。共用登录页面能让两种视图看起来一致，但背后需要的访问权限不同。

同一个内部应用的三类访问检查。Telli.sh 原创图。

小规模试点可以先用一个虚拟员工和一位测试协调人员，不必保存真实入职信息。将本应失败的操作作为明确的发布门槛。即使员工修改浏览器请求里的 ID，也不能覆盖别人的完成状态。接着试着重复完成同一个步骤，确认系统保持同一状态，没有生成重复进度。这样可以在无需同事提供真实信息的情况下检查应用行为。

这类应用适合留一份交接清单。写清楚新协调人员如何获得访问权限、在哪里更新指南、谁能取消离职员工的权限，以及已有完成记录怎么处理。还要约定变更失败时如何恢复所需状态。Cursor 可以配置数据库，团队仍要为这张清单决定恢复办法和保留期限。

人员邀请和集成密钥各有用途

Cursor 现行的 Apps 文档列出三种共享方式。仅限邀请的应用对所有者和获邀且已登录的用户或群组开放。团队共享可以让整个已登录的 Cursor 团队访问。公开应用允许任何知道 URL 的人访问。Teams 和 Enterprise 默认关闭公开共享，管理员可以启用。发布公告重点提到了个人方案的公开共享。单凭 URL 能打开，很难判断实际受众。请到 Apps 控制面板核对当前的可见范围。 Cursor Apps 共享文档

同一份文档还介绍了用于自动化请求的 API 密钥。密钥通过 HTTP 请求头传递，请求会被标记为自动操作，而非归属于某个具体人员。脚本调用应用时很方便，但调查异常请求的方式也会随之改变。如果应用同时支持人员会话和 API 密钥，要确认自动化只能执行所需操作，并记录密钥在哪里使用、由谁轮换。如果所有关键操作都由同事打开链接发起，首轮试点可以只开放人员访问。 Cursor Apps API 密钥文档

应用读取数据仓库时，有三道边界需要测试。Cursor 控制链接对哪些人可见。应用控制这些人能执行什么操作、读取哪些记录。上游系统决定应用的服务凭证能读什么。某一层的错误可以由其他层限制影响。内部看板只需要汇总后的商机数量，却拿到了查询整个 CRM 的凭证，小小的应用缺陷也可能造成严重后果。

测试可以很简单。在新的浏览器会话里，分别以获邀者、已登录但无访问权限的同事、未登录的访客打开在线链接。用获准访问的会话分别请求一条应可见的记录和一条其他区域的记录。如果脚本使用密钥，确认不带请求头会失败，已撤销的密钥也会被拒绝。这些是不同的检查，各自能发现不同的错误。

缩小首次发布范围，可以加快审查

1. 选择一项工作和一个明确的用户群。做看板时，请智能体用虚构记录给出按阶段划分的每周商机总数、可见的刷新时间和 CRM 跳转链接。做门户时，用虚拟员工账号建一张小清单。
2. 启动云端智能体，明确提出要构建应用。选择未来负责人有权限访问的仓库。把第一次修改控制在负责人能解释路由、数据模型和错误处理的范围内。
3. 明确哪些状态需要保存，哪些请求可以写入。虚构数据流程通过后，再在应用设置里配置受限密钥。请智能体指出密钥的使用位置，以及访问对象的权限在哪里检查。
4. 运行发布审查并检查报告。选定 URL，执行发布操作，只共享给合适的最小用户群。请大家开始依赖应用之前，先用线上链接实测应该放行和应该拒绝的请求。
5. 记录应用负责人、调用的上游服务和能下线应用的人。修改可见范围、连接器或凭证后，重复一轮小规模验证。准备一条备用链接或一套替代流程，让同事在新应用暂不可用时还能继续工作。

首次上线的范围可以小于智能体能构建的功能。每天早上提供一个可信数字的看板，可能比一套有六个视图、却常被质疑算法的工作台更有用。入职门户即使推迟协调人员视图，只要清单维护得好，也能减少重复沟通。从小处做起，还能让负责人观察实际会出现哪些变更、权限申请和支持问题。

用普通的一周评估效果。看看没人提醒时大家会打开应用多少次，质疑数字时能否找到原始来源，出现问题后负责人多久能修复。每天省几分钟，也可能足够证明在线应用值得维护。如果大家仍然依赖电子表格做最终确认，就找出新应用还有哪项结果没能让他们信任。

Cursor 的改动让这类试验更容易启动。11 月 5 日的公告把构建、数据库、身份验证、托管和共享链接纳入同一流程。过去，找不到托管负责人或者迟迟做不出登录页，就可能让试验停下来。基础设施齐备后，主要工作转向说明清楚受众、数据和发布条件。最终有用的是一个同事会打开、也有人知道怎么维护的链接。 Cursor 发布公告

来源

• Cursor Live Apps 发布公告，2026 年 11 月 5 日
• Cursor Apps 文档，涵盖设置、共享和管理控制

---

想把内部工具背后的讨论和决定保存成可检索的记录，可以创建 Telli.sh 账号。