Cursor Origin 是什么、与 GitHub 有何不同、如何上手试用

简短回答

Cursor Origin 是 Cursor 自家的 git forge，2026 年 8 月 17 日起处于早期 beta。你可以创建存放在 Origin 上的仓库，用标准 git 克隆和推送，打开并合并 pull request，在 cursor.com/codebase 浏览和搜索代码，并让 Cursor 的云端 agent 在这些仓库上工作。你也可以把已有的 GitHub 仓库镜像到 Origin。在 Origin 托管的仓库上，Origin 是事实来源；在镜像仓库上，GitHub 仍是事实来源，Origin 只保留一份副本。

有四件事决定了大多数选择。第一，Origin 并非所有套餐都有：Cursor 的文档说它在 Free 和 Plus 上不可用，我们在 2026 年 10 月 30 日读到的定价页从 Premium 起列出它。第二，镜像不是双向的代码同步：代码从 GitHub 流入 Origin，只有 pull request 的讨论被描述为双向同步。第三，Origin 不同步 GitHub Issues，也不同步 GitHub Actions 的工作流和 secrets，所以 CI 要通过合作伙伴应用运行。第四，它是 beta，Cursor 明确说功能和权限界面可能会变。

本指南依据 Cursor 的发布更新日志、Origin 文档、Origin API 参考、Origin 落地页、定价页、Cursor 社区论坛帖子，以及两篇媒体报道（引用处均已标明为媒体报道）。本文写作时我们没有实际运行 Origin，Cursor 也没有公布我们能引用的性能、可用性或数据保留数字，因此文中不出现这类数字。如果你在考虑买哪个套餐，请结合阅读我们的 Cursor 定价与 X 订阅套餐指南。

Origin 何时发布

发布日期就写在 Cursor 自己的更新日志上。标题为 Origin Code Hosting 的条目在更新日志中位于 2026 年 8 月 17 日之下，同一天一名 Cursor 员工在社区论坛发布了公告，发帖时间为 UTC 17:42。更新日志正文写道：“Origin begins rolling out today in early beta on all paid plans.”论坛帖子补充说访问权限分批开放，所以一些付费账号没有立刻看到它。

媒体报道在日期上一致。VentureBeat 的报道标注为 2026 年 8 月 17 日，InfoQ 的链接位于其 2026 年 8 月归档下。本指南背后的调研没有找到更早事件（例如预览或候补名单公告）的一手日期。有一家行业网站报道称 Cursor 最早在 6 月 16 日宣布了 Origin，并计划在 8 月 11 日上线，一条 LinkedIn 转发则显示 Cursor 说过 Origin“今年秋季上线”并设有候补名单。我们无法把这两种说法对应到任何有日期的 Cursor 页面，因此请把 6 月的日期和 8 月 11 日的计划视为未经核实。据我们所知，Cursor 自己发布的唯一发布日期是 2026 年 8 月 17 日。

发布之后，Cursor 一直围绕 Origin 持续更新。更新日志显示，8 月 27 日的一项改动允许云端 agent 在没有任何已连接源码托管服务的情况下启动，然后把工作保存到 Origin 仓库；10 月 13 日推出了 Origin App Marketplace。两者都在下文介绍。

Origin 是什么

Cursor 自己的定义很简短：Origin 是“Cursor’s git forge for storing and sharing code”。forge 是团队工作流的服务端，仓库、访问控制、pull request 和代码审查都在那里。GitHub、GitLab 和 Bitbucket 都是 forge。Origin 是 Cursor 在这个品类中的产品，落地页称它是“a git forge for the agentic era”。

文档列出了早期 beta 中你能做的事：创建仓库，包括由 Cursor agent 创建；用标准 git 克隆、推送和拉取；镜像 GitHub 仓库；打开、审查和合并 pull request，并配有带审查者逐个浏览的 Code Tours；在 cursor.com/codebase 浏览和搜索代码；管理仓库和 codebase 设置；安装 Origin Apps；基于公开 API 创建私有 Origin App；连接自动化和云端 agent；以及安装 Origin CLI。仓库地址在浏览器中的形式是 cursor.com/codebase/{owner}/{repo}，用于 git 时是 https://origin.cursor.com/{owner}/{repo}.git。

在其他一切之前，必须有人认领一个 codebase 名称。这个名称就是命名空间，即每个仓库地址中的 {owner}。Cursor 的文档警告说，beta 期间命名空间一旦认领就无法更改或更新，所以要像为组织命名一样认真选择。团队中任何成员都可以在 cursor.com/codebase 认领，管理员可以随时在控制台中为团队停用 Origin。

Origin 还有自己的命令行工具 origin，与 Cursor Agent CLI 是分开的。它负责登录、创建和删除仓库、注册 SSH 密钥、pull request 命令，以及一个 origin push local 命令，我们在镜像仓库一节解释它。Cursor 的文档说，用 CLI 登录也会设置好 git 凭据助手，所以之后普通的 git push 和 git pull 就能对 Origin 远端工作。

哪些套餐包含 Origin

套餐访问权限是读者问得最多的部分，也很容易弄错，因为 Cursor 的措辞变过。发布时的更新日志说“all paid plans”。论坛公告点名了 Pro、Teams 和 Enterprise。当前的 Origin 文档写的是：“Origin code storage is available on Premium, Super, Ultra, Teams, and Enterprise, and on the legacy Start, Pro, Pro+, and Ultra plans. It is not available on Free or Plus.”定价页与之相符，有一行功能叫“Code hosting via Origin”。下表综合了两者，时间为 2026 年 10 月 30 日。

除了这张表，还有三个细节。处于旧版隐私模式的 Teams 无法启用 Origin，需要先切换到 Privacy Mode。镜像 GitHub 仓库需要把 Cursor GitHub app 连接到所属组织或账号，并且在该仓库上拥有 GitHub 管理员权限。此外，定价页注明 Cursor 内的第三方模型按用量另行计费，这意味着套餐价格涵盖的是 Origin 功能，而不是在前沿模型上运行 agent 的费用。关于各套餐的价格和用量池如何运作，定价指南有更深入的说明。在我们读到的页面中，Cursor 没有为 Origin 的存储或带宽公布单独价格，VentureBeat 在发布时写的文章也说 Origin 的定价当时尚未公布。

Origin 托管仓库 vs GitHub 镜像仓库

这个区别决定了 Origin 的行为方式，也是大多数概述含糊带过的地方。Codebase 标签页中的仓库属于两种之一，名称旁边的图标会告诉你是哪一种。

Origin 托管仓库创建于 Origin，可以在网页界面用 New，用 origin repo create，或由 Cursor agent 创建。Cursor 的更新日志写道：“For Origin-hosted repos, Origin is the source of truth. Pushes land on Origin, and GitHub is not in the path.”这类仓库上的 pull request 留在 Origin，不会镜像到任何地方。

镜像仓库是通过 Sync from GitHub 复制到 Origin 的 GitHub 仓库。镜像文档说，镜像“copies a GitHub repository into Origin and keeps Origin updated as the GitHub repo changes. GitHub stays the source of truth.”向镜像仓库的 Origin 克隆地址推送，会进入 GitHub，GitHub 接受后 Origin 才更新。所以镜像最恰当的描述是：代码为 GitHub 到 Origin 的单向，只有 pull request 讨论有双向通道。

哪些会同步，哪些不会

按镜像文档，Git 历史、分支和标签包含在内，此外还有可以在 Origin 上浏览和搜索的代码、可以在 Cursor 中审查的 GitHub pull request，以及后续更新。GitHub Issues、GitHub Actions 工作流和 secrets 不包含在内。如果你靠 Issues 做规划，或靠 Actions 做 CI，它们仍留在原处。镜像页面引用的 Cursor Bugbot 文档部分还补充了一条相关说明：如果你只想要 GitHub PR 上的自动审查评论，Bugbot 可以做到，而无需迁移存储。

origin/ 分支命名空间

克隆、推送和拉取文档描述了一个为应对 GitHub 故障而设计的功能。在镜像仓库上，名称以 origin/ 开头的分支只存在于 Origin。它们永远不会从 GitHub 同步进来，也永远不会同步到 GitHub，而且 Origin 不会导入名为 origin 或 origin/... 的 GitHub 分支，所以 GitHub 上的分支不会覆盖你仅存于 Origin 的工作。origin push local 命令通过添加一个名为 origin-local 的远端来写入它们，该远端指向克隆地址的 /local 路径。文档带来两条限制：origin/* 分支不能作为 GitHub pull request 的 head；/local 是按仓库启用的，所以如果你的仓库没有开启，git 可能报告仓库未找到。Git LFS 批量请求不会故障转移，首次同步尚未完成的仓库仍然需要 GitHub。

这是对“应对故障”这一卖点的实际回答。它能让你在 GitHub 不可达时继续读取并在某个分支上工作。但它不能让你合并到由 GitHub 持有的默认分支，因为那个分支仍然在 GitHub 上。

可见性，以及谁能看到同步的仓库

发布时的更新日志说，对同步仓库拥有读或写权限的人都可以在 Cursor 中查看它。论坛上 Cursor 员工的一条回复澄清了一个常见的绊脚石：同步的仓库从 GitHub 继承可见性，所以私有的 GitHub 仓库到这边是 Private，只有同步它的人以及被授予访问权限的人能看到。队友会看到一个空的 codebase，提示他们选择要同步的仓库。要共享它，同步它的人或仓库管理员需要打开 Settings, Permissions，把可见性改为 Internal 或授予特定的人访问权限。这条回复是 Cursor 员工的论坛帖子，不是文档页面，所以请在你自己的账号里确认。

Pull Request

每个 Origin 仓库都有 pull request。pull request 文档描述了每个 PR 上的四个标签页：Activity 是按顺序排列的时间线，Commits，Checks 显示 head commit 上的检查运行和状态，Changes 显示 diff，你可以在那里评论代码行、提交审查，或切换到使用 Code Tours 的 Tour 进行引导式浏览。你可以请求审查者，在审查和 CI 满足条件后合并，Origin 还会显示合并冲突，让你在合并前解决。当仓库规则要求审查时，有写权限者提交的 Request Changes 审查会阻止合并，直到该审查者批准，或有写权限者驳回它。

要从终端打开一个 PR，先推送一个分支，然后在仓库 Code 标签页使用创建 pull request 的流程：

git checkout -b my-change
git push -u origin my-change

在镜像仓库上，Pull Requests 标签页显示 GitHub 的 pull request，你可以在 Cursor 中审查它们。更新日志说，在 Cursor 中发布的评论会出现在 GitHub，GitHub 上的表情回应或回复会在数秒内显示在 Cursor，并且在 GitHub 上分配给你的审查可以在 Cursor 中审查并合并。除了要求审查的仓库规则之外，Cursor 的文档对 Origin 托管仓库上的合并方式或分支保护着墨很少，所以在依赖某个必需的工作流之前，请先确认它能被表达出来。

Agent 与自动化

Origin 的卖点是：代码、pull request 和 agent 同处一地。更新日志说你可以就正在浏览的代码向 Cursor 提问，它可以回答、做修改、更新 PR 或推送分支。agent 文档在三个方面补充了细节。

• 云端 agent可以对 Origin 仓库克隆、建分支、提交和推送。在 Origin 上创建的仓库上，它们打开 Origin pull request；在镜像的 GitHub 仓库上，它们打开 GitHub pull request。Agent 使用你 Cursor 账号的 Origin 访问权限。
• 自动化按计划或在源码托管事件触发时运行云端 agent。针对 Origin 仓库有文档记录的触发器包括推送到 main 之类的分支、pull request 被打开、pull request 被推送及相关 PR 事件，以及 pull request 上的标签变化。
• 本地 agent在 Cursor 中可以用 CLI 创建 Origin 仓库：安装、登录、origin repo create、设置远端并推送。对于其他编码 agent，origin agent setup 会安装一个技能，让 agent 去读取 origin agent prompt，这是一份针对你所装 CLI 版本编写的使用指南。

8 月 27 日的一项相关改动让你一开始就不需要任何 forge。在云端 agent 的仓库选择器中选择 Start from scratch，就可以在没有连接任何源码托管服务的情况下给 agent 下指令；Cursor 会在后台创建一个 Origin 仓库，并有一个 Create repo 按钮，用自定义名称和 Internal 或 Private 可见性保存结果。从那里发布一个线上网址需要 Vercel 账号。这是一手信息，更新日志上有日期，也是 Origin 作为 agent 产出的默认归宿而非 GitHub 附加件的最清晰例子。

有一点要记住：论坛用户在发布时反馈，agent 面板在一些 GitHub 同步的仓库上不工作，而在直接创建于 Origin 的仓库上可用。一名 Cursor 员工请他们提交 bug 报告，我们无法确认是否已修复。由于 Cursor 的文档说云端 agent 在镜像仓库上也能工作，在假定两者一致之前，请先在镜像仓库上测试 agent。关于这如何融入 Cursor 更广泛的 agent 工作，我们的用手机运行 Cursor、Kiro 和 Codex 的指南（英文）讲了远程控制这一侧。

应用与集成

发布时，更新日志点名了三个集成：Vercel、Depot 和 Buildkite，从 codebase 设置中安装，并显示在仓库的 Apps 标签页上。连接 Vercel 后，每个 pull request 会得到一个预览部署，合并时发布到生产环境。Depot 和 Buildkite 负责 CI：两者都能运行你已有的 GitHub Actions 工作流，Buildkite 还能运行其原生流水线。文档把这三者列为第三方应用的例子，并补充说你可以为自己的团队创建内部应用来调用 API。

2026 年 10 月 13 日，Cursor 宣布了 Origin App Marketplace。其更新日志说，Origin 集成了合作伙伴的 20 多个应用，包括 Cloudflare、Linear、Sentry 和 Socket Security，并且市场向公众开放提交。

发布一个应用，Cursor 给出的步骤是：在你的命名空间中创建应用（构建期间保持私有），基于 Origin API 构建，将其设为公开并提交，附上 slug、建议的标签，以及展示安装、卸载和核心流程的演示视频，然后等待审核。我们没有测试任何市场应用，列在市场里并不能说明一个应用好不好用。

Origin API

Origin 有一套公开的 REST API，文档标注为早期 beta 且“subject to change”。参考文档给出的基础地址是 https://api.cursor.com/v1/origin，并提供完整的 Markdown 参考和 OpenAPI 3.1 规范。应用用你生成的密钥签名的 app JWT 进行认证，并将其换成安装访问令牌；此外还有用户认证的 CLI 请求和 Git HTTPS 认证。参考文档涵盖速率限制、分页和错误，以及一节关于用 scope 代表用户操作的内容。

参考索引中的端点分组显示了一个 forge 已经开放了多少：应用与安装；仓库（列出、创建、更新、删除、分支、tarball 和 Sync Mirror）；check run、suite 和 annotation；commit、比较和内容，包括 Grep Contents；blob、tree 和 ref 等 git 数据；grant；入站 IP 允许列表；标签；ruleset；SSH 证书颁发机构及证书要求设置；以及一长串涉及评论、审查、审查者、自动合并、可合并性和搜索的 pull request 端点。Webhook 涵盖仓库推送、pull request、评论、审查、check run 和安装事件，支持签名验证、重试和自动禁用。

有一条规则会影响镜像仓库上的自动化。镜像仓库参考说，在镜像仓库上只适用五个 scope（metadata read、members read、contents read、mirror read 和 mirror sync）。其他所有 scope 都返回 403，pull request、审查、评论、check 和 ruleset 都被拒绝，通过 Git HTTPS，安装可以克隆、获取、拉取和下载 LFS，但不能推送。更改镜像的状态、重试失败的首次同步或将其分离，属于用户凭据操作，应用安装无法执行。API 还列出了一个 Origin Migration API，用用户访问令牌调用，用于在 GitHub 和 Origin 镜像之间迁移仓库。如果你要开发应用，请预期它在镜像仓库上以只读为主。

参考文档中出现的功能，如 IP 允许列表、ruleset 和 SSH 证书颁发机构，只是 API 参考条目。我们没有找到介绍对应网页界面的文档页面，也没有测试过，所以不要仅凭参考文档就认为它们已可用于生产。

Origin vs GitHub vs GitLab

对比需要先说一个前提。下表中 Origin 一列来自 Cursor 的文档，抓取于 2026 年 10 月 30 日。GitHub 和 GitLab 两列描述的是这两款产品众所周知的长期能力，本文没有重新抓取，所以在依赖这些细节之前，请到各厂商文档中确认。对于任何厂商的可用性、速度和价格，我们都没有写，因为我们没有可比较的一手数字。

有两点值得强调。Origin 目前不支持 GitLab 作为同步来源：有论坛用户询问时，一名 Cursor 员工回复说近期没有计划。这是 8 月 18 日的论坛回答，所以在据此排除 Origin 之前请再确认一遍。而且这个对比只在一个维度上偏向 Origin，即 agent 与代码处于同一界面。在 forge 成熟度、内置 issue 跟踪、内置 CI 和自托管方面，成熟的 forge 都远远领先于一个 beta。对一款上线头几个月的产品来说这很正常，也正是镜像优先的模式之所以重要的原因。关于 Cursor 在编辑器一侧策略的简明看法，见我们的 Cursor vs Antigravity 对比。

如何上手，分步说明

风险最低的试用方式是先用一个一次性的 Origin 托管仓库，再镜像一个不重要的 GitHub 仓库。下面的任何步骤都不会碰到你的生产仓库。

第 1 步：确认访问权限

确认你的套餐是 Premium、Super、Ultra、Teams、Enterprise 或有资格的旧版套餐。如果在 Team 中，确认你没有处于旧版隐私模式，且管理员没有停用 Origin。访问权限分批开放，所以如果 cursor.com/codebase 还没有显示 Get Started 流程，你可能还在等待推送。

第 2 步：认领 codebase 名称

打开 cursor.com/codebase，选择 Get Started 并按设置流程操作。因为 beta 期间命名空间无法更改，不要在团队账号上认领临时的名称。如果你只是想试验，用个人账号可以避免占用团队的名称。

第 3 步：安装 CLI 并登录

CLI 文档给出了适用于 macOS、Linux 和 WSL 下 Windows 的一行安装命令，以及原生 Windows 的 PowerShell 安装命令：

# macOS, Linux, Windows (WSL)
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin --version
origin auth login

# Windows (PowerShell)
irm https://downloads.cursor.com/origin/install.ps1 | iex

安装程序会把 origin 放进 ~/.local/bin，所以如果你的 shell 提示 command not found，请把该目录加入 PATH。把网络上的脚本通过管道交给 shell 是常见做法，但值得先看一眼；你可以先读脚本，或者如果想避开 CLI，就用仓库创建界面和普通 git。登录会打开浏览器流程并设置 git 凭据助手。

第 4 步：创建一次性仓库并推送

在界面中选择 New，输入名称，如果仓库属于团队则选择 Internal 或 Private（个人仓库始终是 Private），然后创建。或者用 CLI，再推送一个已有项目：

origin repo create my-origin-test
git remote add origin https://origin.cursor.com/{owner}/my-origin-test.git
git push -u origin main

如果走 SSH，用 origin ssh-key add 注册一个公钥，并在首次连接时，先把 SSH 客户端打印的主机密钥指纹与 git 文档页面上的指纹对照，再回答 yes。文档说，如果不一致，或出现主机密钥已更改的警告而又没有公告过轮换，就说明连接没有到达 Origin，应当停止。

第 5 步：打开 pull request，让 agent 在上面工作

推送一个分支，从 Code 标签页打开 pull request，并试试 Changes 标签页的 Tour 视图。然后从 Codebase 标签页给仓库挂上一个云端 agent，让它做一个小改动，或回答一个关于代码的问题。记下它能顺利完成哪些任务，以及消耗了多少用量，因为 agent 运行会占用你套餐的用量池或按量计费的模型。

第 6 步：镜像一个不重要的 GitHub 仓库

在 cursor.com/codebase 选择 Sync from GitHub，选好组织和仓库并确认。你需要在该组织上安装 Cursor GitHub app，并在该仓库上拥有 GitHub 管理员权限。同步完成后，在 Settings, General 中检查同步状态，并确认队友能看到什么（见上文的可见性说明）。把 Origin 副本的分支与 GitHub 对比，并测试你关心的 agent 流程和应用集成在镜像上是否可用，因为文档说那里的 agent 打开的是 GitHub pull request。

第 7 步：连接一个应用，然后做决定

从 codebase 设置中安装一个应用，例如 Vercel 或 Buildkite，并观察 pull request 上发生了什么。如果一周后你不再依赖 Origin，也没有什么需要回退：在 Settings, General 中分离镜像（GitHub 仓库不受影响），并用 origin repo delete org/name 删除一次性仓库。唯一会保留下来的是已认领的命名空间。

风险与未解问题

Origin 还很年轻，对团队负责人重要的几个问题，Cursor 的文档里并没有回答。发布时的媒体报道提出了其中一些。这些是媒体和社区的说法，已按此标注。

• 数据处理。我们在文档中找到的唯一一条数据声明是：Origin 遵循命名空间所有者的 Privacy Mode。VentureBeat 在发布当天写道，Origin 的数据保留、数据驻留、训练使用和子处理方条款尚未公布。一名 Cursor 员工在回答论坛上关于隐私的提问时，指向了 Privacy Mode，并说会把它加进文档。如果你处理的是受监管的代码，请在存入之前向 Cursor 索取书面条款。
• 对部分组织默认开启。更新日志说，Origin 向所有付费套餐用户推出，“except enterprise orgs whose admins opt out.”VentureBeat 指出，这读起来像是 opt-out。无论你是否打算使用 Origin，管理员都应该有意识地决定组织的立场。
• 功能缺口。不支持 GitLab 同步（8 月 18 日的论坛回答）。子模块在推送和同步上可用，但 8 月 30 日一条员工回复列出了缺口：网页浏览器无法点进子模块，PR 审查对子模块更新显示占位符，云端 agent 不会自动拉取子模块内容。
• 可靠性。据我们所知，Cursor 没有公布 Origin 的可用性或 SLA 数字。媒体指出 GitHub 在发布当天发生了一次长时间故障；这个巧合并不能说明 Origin 自身的可用性。InfoQ 的报道与更新日志一样，描述的是一个范围很窄的早期功能集。
• 锁定。beta 期间命名空间是固定的；Origin 原生仓库使用标准 git，这使 git clone 成为实际的退出方式。我们读到的文档没有说明 Origin 托管仓库上的 pull request 历史可以导出。
• 所有权。VentureBeat 报道称 Cursor 现在隶属于 SpaceX 的 SpaceXAI 部门，定价页也说订阅由 X Subscription Corp. 销售。我们把它作为来自媒体和定价页的背景信息引用；我们没有核实任何公司条款，也不对其如何影响数据处理作出判断。

谁该试用

已经在别处为 AI 编码用量付费的团队，可能会觉得与其他厂商计费模式的对比是有用的背景；我们的 GitHub Copilot AI credits 指南解释了 GitHub 自己的按量计费如何运作，而 Cursor 模型中与 Grok 和 SpaceXAI 相关的一侧，则在我们的 Grok 4.5 与 Cursor 发布文章中介绍。

本文的局限

• 我们在 2026 年 10 月 30 日读了 Cursor 的页面，但没有使用 Origin，所以关于行为的一切都是文档所述，而非实测。
• Cursor 的 Origin 文档标注为早期 beta，并说界面和控件可能会变，所以套餐访问权限和功能列表可能发生变化。
• 我们没有找到一手的性能、可用性、存储上限、仓库大小上限或 Origin 专属价格，因此一概不报告。
• 对比表中的 GitHub 和 GitLab 两列没有重新抓取。任何决定都请以厂商文档为准。
• 关于可见性、GitLab 和子模块的细节使用了 Cursor 员工的论坛回复。它们是真实的一手声明，但不属于正式文档。
• 6 月 16 日的预先公告和原定的 8 月 11 日发布来自一家行业网站和一条 LinkedIn 转发，未经核实。
• Origin API 参考列出了 IP 允许列表、ruleset 和 SSH 证书颁发机构；我们没有核实对应的界面，也没有测试任何端点。

结论

Origin 是一个可信的 beta 版 forge，有一个鲜明的想法：仓库、审查和 agent 共享同一个界面，agent 可以从零开始，把结果落到 Origin 仓库里，完全不需要第三方源码托管。对 Cursor Premium 或更高套餐的用户来说，试用一个 Origin 托管仓库只需几分钟，也很容易撤销。对使用 GitHub 的团队来说，镜像是以低承诺的方式去看在 Cursor 里做审查是否更好，因为镜像让 GitHub 继续当家。

在功能上它还不是 GitHub 的替代品，而尚未公布的数据条款是在敏感代码进入之前必须先解决的事项。把它当作一个有明确退出方式的实验：分离镜像，删除测试仓库，把 git 当作你的安全网。一个月后请再查看文档，因为 Cursor 说过 agent 原生功能还在后面。

常见问题

来源

来源检查于 2026 年 10 月 30 日。

• Origin Code Hosting：Cursor 更新日志，日期 2026 年 8 月 17 日（发布、仓库、GitHub 同步、PR、应用、推出范围）
• Cursor 更新日志列表：Origin App Marketplace（2026 年 10 月 13 日）和 Start from scratch（2026 年 8 月 27 日）
• Origin 文档概览、克隆、推送和拉取、镜像 GitHub 仓库、创建仓库、安装 CLI、Pull request、Agent 与自动化和 Codebase 设置
• Cursor Origin API和镜像仓库参考
• cursor.com/origin和 Cursor 定价（套餐表截至 2026 年 10 月 30 日）
• Origin Code Hosting，Cursor 社区论坛：员工公告和回复（2026 年 8 月 17 日至 30 日）
• 媒体报道，已标明：VentureBeat，2026 年 8 月 17 日和 InfoQ，2026 年 8 月

相关阅读：Cursor 定价与 X 订阅套餐、Cursor vs Antigravity、用手机运行 Cursor、Kiro 和 Codex（英文）以及 GitHub Copilot AI credits 指南。