Cursor Start from Scratch 能直接上线吗？2026 验收清单

症状：浏览器预览已经成功，但你不知道项目能不能交给团队和用户。
最快解法：先把它当原型验收，再完成建库、全新环境重建、CI、安全隔离、人工审核与回滚验证；涉及 Xcode 或 macOS 的项目，必须转入独立 Mac 环境。

最后更新于 2026 年 9 月 2 日，功能状态核实自 Cursor 官方更新日志、Origin 官方文档 与 Cloud Agents 官方文档。

这篇文章适合三类人：没有现成仓库、想快速验证产品想法的独立开发者；准备让 Cursor Cloud Agents 创建新项目的创业团队；以及负责 CI、权限和 macOS 构建节点的平台工程师。如果你只是做一次性演示，可以少做几项；如果项目要承载真实用户、敏感数据或持续交付，就不能把“页面能打开”当成上线结论。

先把“原型通过”和“生产通过”拆开

Cursor 在 2026 年 8 月 27 日的更新中确认，Cloud Agents 可以在没有连接第三方源代码仓库的情况下从头开始生成项目，随后保存到 Cursor Origin 仓库，并在浏览器中预览云端执行环境。Origin 官方文档同时说明，该服务仍处于 early beta。相关能力与状态应以 Cursor 官方更新日志 为准。

这解决的是“从哪里开始写代码”的问题，不是“代码是否已经适合长期运行”的问题。你在启动生成前，先为项目写下 4 个边界：

• 交付类型：一次性演示、内部工具，还是对外生产服务。
• 技术栈：前端框架、后端运行时、数据库、构建工具和包管理器。
• 数据范围：公开样例数据、内部业务数据，还是用户身份、支付和其他敏感信息。
• 最终环境：普通 Linux 容器、托管平台，还是依赖 Xcode、Apple SDK、模拟器或 macOS 签名能力的 Mac 环境。

如果只是向投资人展示流程，“静态界面、核心路径可点击、演示数据可重置”可以作为原型门槛；如果要让真实用户注册、写入数据库或调用付费 API，就必须增加身份验证、错误处理、数据迁移、密钥管理和回滚证据。

这里的第一个退回条件很明确：生成结果只有浏览器里的临时预览，没有明确的代码目录、依赖文件、启动命令和数据说明，就退回到原型阶段，不进入正式建库。

先验证能否接管，再决定是否继续生成

首次生成结束后，不要马上继续让 Agent 添加功能，先做一次“交接测试”。找一名没有参与原始会话的开发者，或者隔离一个新的执行环境，只提供仓库文件和说明，观察对方能否完成以下动作：

1. 找到应用入口、服务端入口和配置文件。
2. 说清楚使用哪一种包管理器，以及依赖安装命令。
3. 在不读取原始 Agent 对话的情况下启动项目。
4. 找到数据库初始化、迁移、种子数据和外部 API 调用位置。
5. 解释哪些环境变量是必需的，哪些只是本地开发配置。
6. 根据提交历史定位某一项功能的变更范围。

Cursor 的 Cloud Agents 运行在隔离的云端虚拟机中，环境包含代码、依赖、启动命令和网络访问；这意味着 Agent 会话里的可用状态，不应自动被视为你团队本地或 CI 环境中的永久状态。云端执行环境的权限、网络和凭据边界，还需要按照 Cursor Cloud Agents 安全文档逐项核对。

你至少要保存这些交接材料：

• README：用途、启动、构建、测试和部署命令。
• 依赖锁定文件：例如 package-lock.json、pnpm-lock.yaml 或对应生态的锁文件。
• .env.example：只保留变量名和格式说明，不放真实值。
• 数据库迁移脚本和清理测试数据的方法。
• Agent 生成的关键变更说明，以及首个可运行版本的提交记录。
• 已删除的样例密钥、占位身份、默认管理员账号和测试用户数据。

如果关键逻辑只存在于提示词、会话上下文或某次云端运行状态里，代码就还没有完成接管。此时最危险的不是“少一份文档”，而是团队无法知道下一次重建时哪些行为会消失。

预览层、业务层与数据层必须分别验收

浏览器预览很适合发现界面问题，但它容易把端口转发、缓存和预置环境造成的成功误认为完整功能。你需要把验证拆成 4 层，并为每层保存证据。

第一层是静态界面。 检查路由、响应式布局、加载态、空状态、错误态和刷新后的页面入口。页面能显示不代表表单提交、权限判断和服务端数据已经生效。

第二层是服务端逻辑。 对正常输入、缺少字段、错误类型、重复提交和未授权请求分别测试。不要只在浏览器点按钮，还要直接调用关键 API，保存响应、状态码和服务端日志。

第三层是持久化数据。 完成一次写入、读取、修改和删除，再重启预览环境或重新打开应用，确认状态仍然符合预期。若刷新后数据消失，或者数据库只存在于 Agent 的临时容器，就不能进入对外试点。

第四层是外部服务。 分别测试 API 超时、返回空数据、权限失效和速率限制。将第三方服务全部替换成模拟响应后再跑一遍，确认应用不会因为外部服务暂时不可用而泄露密钥、卡死请求或返回错误成功状态。

建议每次验证都保留 4 类材料：构建日志、测试输出、失败截图或响应、对应的代码提交。没有失败记录并不代表系统稳定，只能说明你还没有覆盖到失败路径。

对于需要进一步治理的团队，可以结合 AI Coding 原型转生产的验收思路，把演示结果转化为可复现的构建输入，而不是继续堆叠提示词。

建立 Origin 仓库后，代码责任才真正出现

当原型达到“值得保存”的程度，再执行 Create repo，把项目保存为 Cursor Origin 仓库。官方更新日志说明，创建时可以选择自定义名称，并设置 private 或 internal 可见范围；Origin 文档列出的能力包括标准 Git 的 clone、push、pull、拉取请求、代码浏览，以及与 Vercel、Depot、Buildkite 等集成。

建库时不要只检查仓库是否出现，还要确认责任链：

• 谁是仓库所有者，谁负责首个基线版本。
• 哪些成员可以读取、提交、审核、合并或修改集成配置。
• Privacy Mode 是否符合团队政策。
• 生产分支是否受到审核或状态检查约束。
• Agent 创建的提交和拉取请求是否能被追踪。
• 出现错误时，谁有权限回退到上一个可用版本。

随后用标准 Git 流程做接管验证：

git clone <origin-repository>
cd <project-directory>
git checkout -b acceptance/baseline
git status
git add .
git commit -m "acceptance: establish baseline"
git push origin acceptance/baseline

再从一个全新目录重新克隆，检查提交是否完整、锁文件是否存在、构建产物是否没有被错误提交。标准 git clone 会建立远程跟踪分支并初始化远程配置，代码能否脱离原始 Agent 会话被克隆和恢复，是项目可维护性的最低证明。具体行为可对照 Git 官方 clone 文档。

Cursor 的安全文档还说明，Cloud Agents 的访问权限继承触发用户已有的代码权限，不会因为启动 Agent 自动扩大仓库访问范围；团队可以通过授权范围、Protected Git Scopes 和仓库阻止列表进一步收口。Privacy Mode、秘密注入和网络出口策略也应在团队层面核对，而不是由单个开发者凭感觉决定。

CI 重建与 Mac 验证，决定项目能不能离开预览

正式接入 CI 前，先模拟一个“没有 Agent 缓存”的环境。执行顺序建议如下：

1. 使用全新的工作目录或临时执行节点。
2. 只从 Origin 仓库拉取代码，不复制原始云端工作区。
3. 按锁文件安装依赖，禁止依赖本地全局包。
4. 执行格式检查、类型检查、单元测试和生产构建。
5. 执行依赖漏洞扫描、密钥扫描和敏感文件检查。
6. 用空白环境变量启动，再按最小权限注入测试凭据。
7. 保存构建日志、测试结果、扫描报告和生成物摘要。

CI 的门禁不应只有“构建成功”。至少把以下结果分开记录：代码质量、功能测试、安全扫描、依赖安装、数据库迁移和发布前检查。某一项失败时，流水线应阻止合并，并告诉审核者是代码问题、环境问题还是权限问题。

如果最终目标是 Web 服务，可以将 Origin 或正式代码仓库连接到部署平台，用预览环境承接拉取请求，用生产分支承接正式发布。以 Vercel 的 Git 集成为例，官方文档说明，分支推送和拉取请求可以触发预览部署，合并到生产分支后再生成生产部署；预览与生产还可以使用不同的环境变量。相关流程见 Vercel Git 集成文档。

但你仍要做一次发布前验证：检查实际提交、构建日志、环境变量、关键接口和错误日志，再决定是否提升到生产。发布后还要确认旧版本仍可恢复，不能只验证“新版本已经部署”。平台的部署、日志、生产提升与回滚操作，应纳入团队自己的发布记录，而不是依赖某一名开发者记忆。

若项目涉及 iOS、macOS 或其他 Apple 工具链，浏览器预览只能证明 Web 层或模拟层可运行，不能证明最终产物可以构建、签名和分发。Apple 官方文档明确使用 xcodebuild 完成归档和 exportArchive 导出签名产物，因此这类项目应在隔离的本地或云端 Mac 中完成实际构建验证，而不是继续依赖普通云端 Agent 环境。具体命令与流程可参考 Apple 官方归档与导出文档。

如果你需要把这一步做成长期节点，可以先阅读 云端 Mac 的 Xcode 持续集成环境部署，重点确认 Xcode 版本、证书、签名权限、缓存策略和构建产物交付方式。

用可勾选清单决定发布、试点还是退回

不要用“看起来不错”做最终判断。你可以在发布单中复制下面的清单，逐项勾选并附上证据链接、日志或提交编号：

代码接管

• [ ] 另一名开发者可以不读取原始 Agent 会话，独立克隆项目。
• [ ] README 写清楚安装、启动、测试、构建和部署命令。
• [ ] 依赖锁定文件、迁移脚本和配置说明已进入仓库。
• [ ] 关键业务逻辑不依赖临时提示、云端缓存或未保存状态。
• [ ] 首个基线版本已经人工审核并留下提交记录。

任一项未勾选： 只能继续作为原型使用，不能交给正式开发团队。

功能与环境

• [ ] 正常输入、异常输入、重复提交和未授权请求均已测试。
• [ ] 刷新、重启、数据库重新连接后，状态仍符合预期。
• [ ] 外部 API 超时、空响应和权限失效均有处理。
• [ ] 全新环境可以按锁文件安装依赖并完成生产构建。
• [ ] CI 不依赖原始 Agent 工作区中的缓存或全局工具。

只有界面预览通过： 说明静态展示可用，不说明服务端、持久化数据和发布环境可用。

权限、安全与发布

• [ ] 仓库所有者、成员权限、可见范围和 Privacy Mode 已确认。
• [ ] 样例密钥、默认账号、测试身份和敏感数据已清除。
• [ ] 格式检查、测试、安全扫描和发布前检查已接入 CI。
• [ ] 生产环境与预览环境使用了清晰区分的凭据和配置。
• [ ] 旧版本可以恢复，回滚操作已至少演练一次。
• [ ] 第一周的失败任务、人工修复、构建耗时和环境差异有记录。

全部勾选： 可以进入正式发布评审。
缺少 1—3 项但风险可控： 只进入内部或限量试点。
缺少密钥隔离、权限解释、可复现构建或回滚任一项： 直接退回，不扩大访问范围。

四个常见交接场景，分别采用不同放行标准

从零创建的项目可以先保留在云端 Agent 环境中，用于快速调整页面、验证流程和收集反馈；但只要需要长期维护，就应通过 Create repo 保存到 Origin，并用标准 Git 操作确认代码已脱离原始会话。保存代码不是终点，能否被其他人克隆、构建和修改才算完成交接。

Origin 项目在正式使用前，重点不是仓库名称是否正确，而是责任链是否完整：所有者、可见范围、成员权限、Privacy Mode、提交历史、拉取请求和回滚责任都必须有人确认。由于 Origin 仍处于 early beta，团队还应保留独立代码副本，并在能力或仓库策略变化时重新复核。

Cursor Cloud Agents 生成应用接入 CI 时，先从正式仓库拉取到全新节点，再安装依赖、运行测试、执行安全扫描和生产构建，最后才接入预览部署与生产发布。若目标环境需要 Xcode、Apple SDK、签名证书或 macOS 专属工具，就把相应阶段迁移到独立 Mac，而不是假设浏览器预览已经覆盖这些条件。

最后的放行条件：先证明能重建，再决定是否上线

Cursor Start from Scratch 的优势是缩短从想法到可交互原型的距离，限制也同样明显：原始 Agent 会话不是团队代码仓库，浏览器预览不是完整生产环境，云端临时状态不是可审计的构建输入。若项目直接停留在这三层之间，你会在后续遇到权限不清、环境漂移、密钥泄露、无法回滚和只能靠原作者修复的问题。

所以，在点击发布前，先把项目放进全新执行环境重建一次；如果它依赖 Xcode、Apple SDK 或需要持续运行的 macOS 构建节点，再转入隔离的云端 Mac 完成真实构建、签名和交付验证。对于短期原型、临时测试或需要独立 Mac 节点的 AI Coding 项目，租赁 MacPull 的 Mac 环境通常比临时改造个人电脑更容易控制环境边界；但长期稳定重负载、必须持有物理设备或需要固定本地外设的团队，仍应评估自购 Mac 或自建节点。你可以先查看 MacPull 的远程 Mac 方案对比，再决定是租赁验证环境，还是建立长期固定基础设施。

常见问题