想把Cursor做的小工具发给别人使用，先别急着点发布。能在自己的预览里打开，和访客拿到链接后能用，是两件需要分别确认的事。尤其是团队内部工具，发布前就该想清楚谁能看到、能看到哪些数据。
Cursor在2026年11月5日的公告中介绍了Apps：从云端代理构建应用并部署，交付可访问的链接。下面按准备、预览、发布、验收的顺序说明怎么检查，适合准备尝试这项功能的个人用户和小团队。
先确认：账号有资格，而且用的是云端代理
根据Cursor Apps官方文档，功能适用于有cloud agents访问权限的付费套餐，本地代理不支持。个人方案可以公开分享；Teams和Enterprise默认关闭公开分享，需要管理员开启。私有和团队应用则需要Cursor登录，并受分享范围限制。
因此，找不到入口时，先看当前账号的云端代理权限，再看团队管理策略。不要仅凭“我已经付费”就判断应该能公开上线，也不要把本地项目启动成功当成Apps部署完成。具体费用、资源额度和地区可用性要另查自己的账号条件，不能从“支持部署”推成无限使用。
把第一次任务缩小到一个能验收的小工具
第一次可以从无需真实业务数据的工具开始，比如文章发布检查清单。先写出输入、输出和不该发生的行为，比只说“做一个好看的后台”更容易检查结果。如果需求总说不清，可以先参考把任务和限制讲清楚的提问方法。
下面是一份自拟需求示例，可以按实际用途改写：
请用云端代理构建一个文章发布检查清单应用。每条任务包含文章标题、检查项和完成状态；支持新增、勾选、筛选未完成项。先只用虚构示例，不连接网站后台，不导入真实用户资料。请先提供预览，说明哪些数据会保存、谁能访问，等我确认后再发布。
这里的重点是限制任务范围。一个只做检查清单的应用，不必顺手获得生产网站的写入权限。先把最小功能跑通，后面再决定是否需要账号系统或外部接口。
预览时检查流程，再决定是否发布
官方说明，应用准备好后会提供预览和发布入口；需要你主动选择发布，才会进入上线流程。发布时选择应用URL并运行检查，未通过会列出需要修复的问题。
预览阶段不要只看首页。用几条虚构记录走完新增、修改、筛选和刷新，观察内容是否按需求保留；再试空标题、很长的文字和重复提交。涉及保存、删除的功能，要确认操作范围，别让一个按钮影响所有记录。
把发现的问题写成“做了什么、出现什么、期望什么”，让代理逐项修复。例如：“新增任务后刷新，刚才的勾选状态丢失；期望刷新后仍保留。”这比“有问题，再优化一下”更便于复查。
分享范围决定该用谁的身份验收
准备给指定成员用，就按成员权限验收；准备给团队用，就找实际接收者确认；准备公开，才检查未登录访客能否使用。自己已经登录的浏览器能打开链接，不能证明其他人也能打开。
公开前尤其要看页面、列表和报错内容里有没有内部资料。不要为了让别人打开，就把原本应私有的工具改成公开。若它需要连接其他系统，先明确只读还是可写、能访问哪些记录，再按产品提供的凭据配置入口处理，不把密钥粘进需求示例或前端页面。
发布检查通过也不等于业务逻辑一定正确。比如只应看到自己的记录，却能看到别人的内容，这类问题仍要用不同权限身份验证。没有条件完成验证的功能，先缩小使用范围，别急着开放给真实用户。
拿到链接后，再走一次完整任务
把最终链接交给目标使用者，按真实使用顺序再检查一遍：能否进入、输入是否有效、结果是否正确、刷新后状态是否符合约定。在手机上还要看按钮是否好点、长标题是否挡住内容、表单能否完整提交。
如果卡在某一步，记录当前账号身份、访问范围和错误提示，再回到对应环节处理。第一次上线的目标可以很小：让指定的人打开一个边界清楚、结果可核对的小工具。等这一步可靠了，再加数据库连接和更多功能。
