Cursor Origin 与 GitHub 怎么共存：镜像、PR 与集成三条线
先把这篇文章的依据讲清楚，免得读者带着错误期待往下看：GitHub 本身的官方文档不在我们的事实源里。本文只依据 Cursor 官方文档（cursor.com/docs）写明的内容，讲 Origin 这一侧如何描述它与 GitHub 的关系——镜像往哪个方向流、拉取请求怎么对应、集成层各自管到哪。我们不评判 GitHub，也不对两边做优劣排名。 凡是需要 GitHub 官方口径才能下的结论，本文一律不写。
还有一条必须放在最前面：Cursor 官方文档在 Origin 的每一页页首都写着 Origin 目前处于 early beta（cursor.com/docs/origin）。文档自述这一阶段能做的事是：创建仓库、用 git 推拉、从 GitHub 镜像、浏览与搜索代码、开启与合并拉取请求、与 Cursor 团队共享。仓库设置页（cursor.com/docs/origin/settings）还写明 Permissions 与 Rules and Protections 这两块正在重做，「标签与布局在 early beta 期间可能变化」，同页也写明 Rules and Protections 的可用控制项在 early beta 期间可能扩充。所以下面提到的任何设置项名称，都要按「文档当时的口径」来读。
第一条线：镜像的方向决定谁是权威
cursor.com/docs/origin/mirror-github 这一页把方向写得很直白：镜像是把 GitHub 仓库复制进 Origin，并随 GitHub 仓库变化持续更新 Origin。它给的适用场景也很具体——代码已经在 GitHub 上，而你想在这份历史上用 Origin 的浏览、搜索与 agent 工作流。
前置条件这一段不要跳过，文档列了三条：账号所在计划需具备 Origin 访问权限（Origin 概览页 cursor.com/docs/origin 写明 Origin 代码存储在 Pro、Teams、Enterprise 计划上提供，免费计划不提供，且分阶段开放，符合计划条件也未必立刻可见；该页还写明处于 legacy privacy mode 的团队无法启用 Origin，需先切到 Privacy Mode）；Cursor 的 GitHub app 已连接到拥有该仓库的组织或账号；以及你在源仓库上具备 GitHub admin 权限——文档明确注明这一条是启用镜像所必需的。第三条最容易卡住：一个只有写权限的成员是发起不了镜像的。
同步范围这张表值得原样看一眼，它是后面所有判断的地基：
| 会同步 | 不会同步 |
|---|---|
| Git 历史、分支与标签 | GitHub Issues |
| 可在 Origin 上浏览与搜索的代码 | GitHub Actions 的 workflow 与 secrets |
| 拉取请求，双向同步 | |
| 持续更新，使 Origin 保持新鲜 |
表的右列比左列重要。文档紧跟着一句说明：issue 与 CI 配置留在 GitHub，除非你在别处重建它们。也就是说，镜像搬的是代码与协作记录，不搬你围绕 issue 和 Actions 建起来的那套自动化。
方向感最关键的一句在「After you mirror」里：你可以从 Origin 克隆，也可以往 Origin 推——推到已同步仓库的提交会穿透回 GitHub，GitHub 仍然是 source of truth。这句话解释了很多困惑：镜像状态下 Origin 不是一个只读副本，但它也不是权威，它更像一个可写的前置面。
真正翻转方向的动作是 Detach。官方文档写明在仓库 Settings → General 的 Danger Zone 下选择 Detach from GitHub：同步停止，Origin 副本变成独立的 Origin 托管仓库，Origin 成为 source of truth，往 Origin remote 的推送不再流向 GitHub；同时文档也写明「你的 GitHub 仓库不受影响」。这是一个单向的心智切换点，做之前先想清楚有没有别的系统还在盯着 GitHub 那一侧。
顺带一提，如果 Origin 上的浏览结果看起来是旧的，mirror-github 页给的排查动作是三条：确认 GitHub app 仍有访问权限、确认你仍是源仓库的 GitHub admin、从 cursor.com/codebase 重新执行 Sync from GitHub 或在 Settings → General 查看同步状态。注意这三条全是权限与状态的确认动作，文档没有给出任何同步延迟的时间承诺，我们也不替它推断。
第二条线：拉取请求的两种命运
cursor.com/docs/origin/pull-requests 把 PR 分成了两类，差别不在功能而在归属：
- 镜像自 GitHub 的仓库：你可以像操作 Origin 拉取请求一样查看和交互 GitHub 的拉取请求，你的改动会同步回 GitHub。
- 直接在 Origin 上创建的仓库：其拉取请求留在 Origin，不镜像到任何地方。
这两句是原文的核心对应关系。它意味着：镜像仓上的评审可以在 Origin 侧做而不脱离 GitHub 的记录；而 Origin 原生仓上的评审，GitHub 那边是看不到的。团队里如果还有人只看 GitHub，这一条会直接咬到你。
PR 页面本身，文档列了四个标签：Activity（打开、评论、评审、状态变更等按顺序排列的活动）、Commits（PR 中的提交，可打开查看各自 diff）、Checks（分支的 check 运行与状态，结果以 head commit 的 checks 形式呈现）、Files Changed（文件 diff，可在行上评论并提交评审）。除了这四个标签，文档还写明可以请求评审者、提交评审、在 PR 或具体行上评论，并在评审与 CI 满足后合并；Origin 会呈现合并冲突以便合并前解决。
命令行侧，cursor.com/docs/origin/cli/reference/pull-requests 给了 origin pr 的完整子命令。目标解析规则是从当前检出的 origin git remote 推断仓库，可用 -R, --repo 以 org/name 形式覆盖；多数子命令接受可选的 [target]，数字表示 PR 编号，其它内容按分支名解析，省略则取当前分支的 open 或 draft 拉取请求。文档给的三行示例是：
origin pr view 13 # pull request 13
origin pr view my-branch # pull request for my-branch
origin pr view # pull request for the current branch
有两处细节容易踩：一是 origin pr create 的 --status 选项，文档写明取值为 draft 或 open，默认是 draft——这是文档写明的默认值，随版本可能变动，但如果你以为敲完命令就是一个待评审的 PR，就会白等；二是 origin pr refresh，文档说明「推送到 head 分支本身就会快照出新版本」，只有当 origin pr view 或 origin pr checks 仍报告上一个 head commit 时才需要跑它，且在已匹配最新版本时它什么也不做。
要在脚本里做门禁，文档直接给了一条：origin pr thread list --unresolved --json id --jq length，用于判断「所有评审线程是否都已解决」。要把创建流程拼起来，可以这样组合：
origin pr create --push -t "Fix CI" -B main --status open
origin pr checks --watch
以上为按官方文档中的参数语义组合的示例，未经实测，以官方文档与 --help 的实际输出为准。
第三条线：集成层各自管到哪
cursor.com/docs/integrations/github 列出了 Cursor GitHub app 请求的权限及其用途，与镜像和 PR 直接相关的是这几行：Repository access（克隆代码并创建工作分支）、Pull requests（创建 PR 并留下评审评论）、Checks and statuses（报告代码质量与测试结果）、Actions and workflows（监控 CI/CD 流水线并从 PR 触发 CI 重跑）、Administration（读取分支保护与必需 check 规则以判断 PR 可合并性）。这张表能帮你回答一个常见质疑——为什么它要读 Administration？文档自述的理由就是判断可合并性，不是别的。
cursor.com/docs/origin/integrations 则说明 Origin 与 Automations 和 Cloud Agent 一起工作：把 automation 指向 Origin 仓库的方式，与指向已连接的 GitHub 或 GitLab 仓库相同。文档列的常见触发是「推送到分支」（例如推到 main 或 master）以及「拉取请求已打开」「拉取请求已推送」等 PR 事件；创建入口写明为 cursor.com/automations、Agents Window 或 /automate skill。Cloud Agent 可以在 Origin 仓库上克隆、建分支、提交、推送并开启拉取请求，使用的是你 Cursor 账号的 Origin 访问权限。
最容易被忽略的一条边界在仓库设置页（cursor.com/docs/origin/settings）：early beta 阶段 Apps 可连接的第三方工具文档列了三个——Vercel、Depot、Buildkite——而文档明确写明 Depot 与 Buildkite 仅适用于 Origin 托管的仓库，不适用于从 GitHub 镜像的仓库，镜像仓库的 CI 留在 GitHub。这与前面「Actions 的 workflow 与 secrets 不同步」是同一件事的两面。
从你的处境倒推
把上面三条线接起来，决策路径其实只有四个岔口：
你只是想让 GitHub 上的 PR 有自动评审。 那就别动存储。mirror-github 页有一节标题就叫「When not to mirror」，文档写明：如果你只想要 GitHub PR 上的自动评审评论，Cursor Review 与 Bugbot 可以在不搬动存储的前提下做到；镜像是为了「Origin 托管的代码存储、浏览与拉取请求」。
你想要 Origin 的浏览、搜索与 agent 工作流，但 GitHub 必须继续当权威。 这正是镜像的设计位置：推到 Origin 会穿透回 GitHub，PR 双向同步，GitHub 保持 source of truth。代价是 issue 与 Actions 配置不跟过来。
你想让 Depot 或 Buildkite 在这个仓库上跑 CI。 那么镜像形态不成立，文档写明这两个只在 Origin 托管仓库上工作。要么保持 CI 在 GitHub，要么走 Detach 让 Origin 成为权威——后者是个单向决定。
你的日常流程重度绑定 issue 与 Actions secrets。 镜像不搬这两样，文档的原话是它们留在 GitHub「除非你在别处重建」。这不是一个可以边做边看的迁移，先算清楚重建成本。
至于评审在哪一侧做体验更好、同步会滞后多久、两边的可用性如何、迁移要多长时间——这些维度我们没有依据，不比。GitHub 的官方文档不在本文事实源内，Cursor 文档也没有给出任何延迟、吞吐或可用性的说明。另外，GitHub Enterprise Server 与 Origin 镜像之间是什么关系，cursor.com/docs/integrations/github 的 GHES 一节讲的是 Cursor 连接 GHES 的注册与网络方式，没有写明 GHES 仓库能否镜像进 Origin，我们也就不写。
Windows 侧要单独说一句
Origin CLI 的安装页（cursor.com/docs/origin/cli）标题写的是「macOS, Linux and Windows (WSL)」，给的安装命令是：
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
也就是说，Windows 上文档给出的路径是 WSL，原生 PowerShell 或 cmd 的安装方式，官方文档没有说明这一点。文档写明安装后二进制位于 ~/.local/bin/origin，若提示 command not found: origin 需把该目录加进 PATH，并分别给了 zsh 与 bash 的写法。装好后用 origin --version 验证，用 origin auth login 登录；文档还写明登录同时会配置 git credential helper，因此针对 Origin remote 的 git push 与 git pull 无需额外设置。
如果你不想在 Windows 上装 CLI，纯 git 这条路是通的：cursor.com/docs/origin/git 给出 HTTPS 克隆地址形如 https://origin.cursor.com/{owner}/{repo}.git，用标准 git 操作即可；只是文档提示首次 git 操作前需先 origin auth login，这一步仍落在 CLI 上。同一页还给了「评估期两边并行」的写法：
git remote set-url --add --push origin git@github.com:acme/checkout.git
git remote set-url --add --push origin https://origin.cursor.com/acme/checkout.git
文档同时提醒，若要从 GitHub 完整复制历史进 Origin，更推荐用镜像而不是这种双推。上述地址中的 acme/checkout 是官方文档中的示例值，换成你自己的 {owner}/{repo}。
最后是验证：镜像是否生效，官方文档写明可在仓库 Settings → General 的 Sync Status 查看，已同步的仓库会显示 Origin 为 mirror、GitHub 为 source，并带有指向源仓库的链接；直接在 Origin 上创建的仓库不显示同步状态。这一处是判断「我现在到底处在哪种形态」最直接的依据。
Origin 处于 early beta，上面每一处设置项名称、命令与默认值都随版本变动，请以官方文档最新内容为准。
本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。
该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现；
我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。
该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。
本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。
本文对照的是同一产品内的两种形态，依据均为上述官方文档，不对两种形态做优劣排名， 选型结论只在官方文档写明的能力边界内成立。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。