8 月 27 日，Cursor 在 changelog 中上线了一个看似不起眼的功能更新：Cloud Agents 不再需要连接 GitHub 或其他第三方 SCM 提供商，用户可以直接从零开始，prompt 之后自动创建 Cursor Origin 仓库。

这个功能在嘈杂的 AI 工具发布潮中容易被忽略。但如果我们把它放在 Cursor"self-driving codebases"的长期愿景里看，它标志着一次重要的战略转向。

为什么这个更新重要

传统编程工具对 GitHub 有强依赖。即使是 AI 辅助编程工具，也假设你有一个既存的代码仓库。从零开始写代码？先建 repo、先初始化项目结构——这些"准备工作"在传统工作流里是不可跳过的。

Cursor 的"Start from scratch"打破了这个假设。用户只需要描述想做什么，Cursor 自动创建项目、写入代码、运行构建，最终可以一键发布到 Vercel 获取公网 URL。这不是编程辅助，这是编程替代的雏形。

更深层的变化在于产品定位的迁移：从"IDE 插件"到"应用平台"。Cursor 不再只是帮你写代码的工具，而是接管从想法到可访问应用的完整链路。用户甚至不需要知道什么是 Git、什么是 npm start。

技术实现：Origin 托管的战略价值

Cursor 在背后创建了"Origin repo"——这是他们自建的代码托管服务，8 月 17 日的 changelog 已经预告了 Origin Code Hosting 的推出。

自建托管服务的原因很实际：

  1. 消除第三方依赖：GitHub 的 API 限制、认证流程、仓库可见性规则都是约束。自有托管可以让 Cursor 完全控制 Cloud Agent 的代码存储和检索逻辑。
  2. 与 AI 工作流的深度集成：传统的 Git 仓库是为人设计的——提交历史、分支模型、PR 流程。AI 生成代码的节奏完全不同，传统的版本控制模型并不天然适配"Agent 大量生成、人类审批"的场景。Origin 可能针对 AI 工作流做了定制。
  3. 数据飞轮：代码托管与 AI 能力形成闭环。Cursor 可以分析自身的代码生成质量、在不同项目类型上的表现，这些数据可以用来改进模型路由和 agent 行为。

行业影响：打破 GitHub 护城河

GitHub 长期以来是开发者生态的"守门人"。Copilot、Claude Code 等工具都以 GitHub 为基础构建工作流。Cursor 选择自建托管并支持无 repo 启动，意味着GitHub 不再是 AI 编程工具的必要条件。

这对竞品是一个压力测试。GitHub 生态是微软的护城河之一。当工具厂商开始绕开这道护城河，意味着市场正在寻找更灵活的集成方式。

同时，"一键发布到 Vercel"的集成也值得关注。Cursor 正在将部署环节也纳入自动化链路。写代码 → 构建 → 部署，这条路被 Cursor 和 Vercel 的深度集成打通了。

工作流的范式转移

从用户视角看，这个功能带来的变化是：

以前：有想法 → 打开 IDE → 创建项目 → 初始化 Git → 写代码 → commit → push → 部署

现在：有想法 → 告诉 Cursor → 预览效果 → 发布

中间所有步骤都被 Cursor 接管。这个变化的核心价值不是"省时间"，而是降低了对开发者角色的技能要求。不需要熟悉项目模板、不需要理解构建系统、不需要知道如何配置 CI/CD——Cursor 把这些都封装掉了。

总结

"Start from scratch"不只是功能更新，它是 Cursor"self-driving codebases"愿景的具体落地。这个功能意味着：AI 编程工具的门槛正在从"会编程"降低到"有想法"。对于专业开发者，这意味着工作流加速；对于非技术用户，这意味着一个新的入口。

随着 Origin 托管的成熟和 Cloud Agents 能力的扩展，Cursor 的边界正在从"IDE 里的 AI 助手"扩展到"从想法到上线的一体化平台"。这场竞争的下一阶段，比的不只是模型能力，而是产品化能力和生态整合深度。