在 AI 编程工具已经非常普及的 2026 年，代码托管这个原本普通到甚至有点无聊的领域，突然杀进了一个新选手。
今天凌晨，刚被 SpaceX 以 600 亿美元收购不久的 Cursor 推出了自家代码托管平台 Origin，并向 Pro、Teams 和 Enterprise 付费用户开放早期测试。几乎在同一时间，GitHub 再次遭遇全球性大规模故障：API、Actions、Pull Request、Issues 等核心功能长时间、大面积宕机，连企业常用的单点登录和 Copilot 也一度失效。
在全球最大的代码托管平台发生大规模故障的时候，Cursor 就宣布推出 Origin，这个时间点对 GitHub 来说有点雪上加霜，也多少让 GitHub 的面子有点挂不住。
在代码托管这一块，我们还需不需要另一个 GitHub 呢？
01
Cursor 推出的 Origin 到底是什么？
图源：Origin
在功能上，Origin 就是一个「基于 Git 的代码托管平台」，开发者可以在浏览器里的 Codebase 页面创建仓库，通过 Origin CLI 进行 clone / push / pull，管理权限、查看提交历史、浏览代码，打开和合并 Pull Request，这些是任何一个 Git forge 都必备的功能了。
Cursor 在这个基础之上，也给 Origin 带来一些稍显不同的功能。
图源：Origin
首先，Origin 把代码、PR 和 agent 被放在了同一个工作平面里。Origin 的每一个代码仓库中，现在都集成了一个 agent，开发者在编辑器里浏览某个文件或 PR 的同时，可以直接调用 Cursor 的 agent 提问、让它修改代码、根据评论批量改动，开新分支、推送更新。
其次，Origin 在发布当天就宣布与 Vercel、Depot、Buildkite 集成。Origin 仓库上的每个 PR 都可以在 Vercel 上自动生成预览环境，合并后触发生产部署；Depot 和 Buildkite 则负责执行 CI 流水线，而且可以原封不动执行现有的 GitHub Actions 工作流，开发者不用重写构建脚本。对于已经在使用 GitHub Actions，有自己配套设置的团队，这也降低了尝试 Origin 的门槛。
图源：Origin
最后一个，也是目前看起来最聪明的一个功能，就是 Origin 允许 GitHub 继续作为「事实上的源仓库」。团队可以将 GitHub 现有的代码仓库同步到 Origin 中，开发者的 Push 依旧是发往 GitHub，Origin 主要的作用就是维护一份实时更新的镜像仓库，上游 GitHub 仓库有新的提交，Origin 会实时同步；在 Origin 上发起的评论和代码审查，会双向同步回 GitHub，反之亦然。权限也直接沿用 GitHub 的读写配置，Origin 不会再造一套新的权限系统。
这也意味着，对于大多数团队来说，短期内可以继续使用熟悉的 GitHub，不需要迁移项目，把 Origin 当作一个项目的备份仓库就可以了。开发者照常使用 GitHub 的同时，仓库被镜像到 Origin 上，还可以享受 Cursor 带来的 AI 编程等功能，如果不满意，可以随时换回 GitHub。
02
AI 把开发量推上新高，GitHub 有些跟不上了
回到 GitHub 这次事故，官方的服务状态页面显示，从北京时间昨晚开始，GitHub.com 的多个服务出现约 20% 的错误率，包括网站访问、API 请求、Issues、Pull Requests、Actions、Pages、Webhooks 等。对部分仓库内容下载和文件访问，错误率更是来到了 50%。企业身份认证相关的 SAML、OIDC、SCIM、Team Sync 也全部受影响，连 Copilot 的可用性都被标记为降级。
图源：GitHub
这一轮波动持续了七、八个小时，到今天早上才被标记为「已解决」。在此期间，X、Reddit 等社交平台上都能看到开发者各种怨声载道的帖子，甚至有开发者一开始不知情，以为自己的仓库被删了。
图源：网络
这已经不是 GitHub 第一次因为服务出现故障而被送上热搜了。过去一年，GitHub 已经把宕机当做日常了。2025 年整体可用性已经跌破 90%，而今年还跌到 80% 左右。这个数据对 99.9% 和 99.99% 的稳定性目标比，肯定是不能接受的数字。
图源：网络
在这次宕机前，包括 Mitchell Hashimoto 和 Armin Ronacher 在内的很多知名开发者，也都因为 GitHub 不够稳定，宣布要放弃这个平台，转而寻求其他替代方案。
图源：GitHub
回顾过去这些年 GitHub 平台的稳定性，如今的 GitHub 到底发生了什么呢？
图源：X
相信 GitHub 首席运营官 Kyle Daigle 在 X 上公开的这组数字能说明一定情况。2025 年全年 GitHub 上大约有 10 亿次提交，而 2026 年春天已经达到了惊人的「每周 2.75 亿次」，如果按照这个趋势，GitHub 一年的提交次数将达到 140 亿次以上。GitHub Actions 的使用量也从 2023 年的每周 5 亿分钟，涨到 2025 年的每周 10 亿分钟，再到今年每周 21 亿分钟。
背后的原因也很明显，就是 AI。
AI 编程助手、自动化的 agent、大量 vibe coding 项目，把过去开发者“古法编程”几年才能产出的代码和提交数量，在短时间里放大了好几个数量级。GitHub CTO 在此前的技术文章中坦言，平台不得不把规划从「扩容 10 倍」调整为「面向 30 倍规模」设计，并且承认在负载隔离、故障模式消除和流量削峰方面做得远远不够。
简单说，GitHub 目前的平台架构、服务器冗余和算力，既要承受 AI 带来的远超以往数量的提交和并发，也要承受自己 AI 编程工具 GitHub Copilot 的成功带来的反噬。而这次长达数小时、几乎波及所有核心服务的宕机，只是将过去一年已经发生多次的问题又集体复现了一次。
03
Cursor 真正想要的，可能不只是另一个 GitHub
那么 Cursor 为何要在这个时间点推出 Origin？仅仅是因为看到了 GitHub 不再可靠的问题吗？
显然不止如此。
Cursor 负责写代码，Origin 负责托管代码，算是产品线的自然延伸，但能够写代码的工具太多了，Cursor 本身的特点还是以 AI 为中心，而能够让开发者持续留在 Cursor，不换其他工具的理由，肯定得是 Cursor 的 AI 足够好，并且能变得更好。
除了模型本身，开发者跟 Cursor 交互时产生的上下文与反馈（代码结构、提交历史、PR 评论、构建结果、线上报错、回滚记录等），这些同样也是极其宝贵的数据。
图源：Origin
今天这些数据大多都汇集在 GitHub 上，一旦 Origin 能够托管部分仓库，Cursor 就有机会把为什么修改、AI 提出了什么建议、开发者接受了什么、拒绝了什么、PR 为什么被修改、测试为什么失败、最终什么代码进入生产环境等一系列开发者行为都纳入自己的系统中。对于任何一家做 AI 编程工具的公司来说，这就等同于掌握了一个高质量、实时更新的「开发者行为数据」资料库。
站在 Cursor 的角度，如果继续完全依赖 GitHub，就意味着永远只能做「开发者生态的下游」，迟早在某个时间点会遇到发展的天花板，虽然现在说 Origin 能否做大做强还为时过早，但至少给 Cursor 提供了一个新的发展方向。
04
Origin 会如何使用开发者数据？这是必须提前问清楚的问题
既然 Cursor 通过 Origin 掌握了更多的代码和开发者交互行为，它会不会、以及在什么条件下，用这些数据来训练或微调自家的模型和智能体？
虽然 Cursor 的官方文档只写明，Origin 遵循仓库所有者的隐私设定，关于数据保留期限、地理位置、是否用于模型训练、是否会与第三方共享、以及 SpaceX 收购之后数据如何在内部不同业务之间流动，这些关键问题，目前都没有看到详细的对外说明。
但鉴于 Cursor 和 SpaceX 在安全事件响应上的历史表现，相信他们肯定会用开发者的数据训练 AI。
此前安全公司 Mindgard 就披露，Cursor 在 Windows 环境下会无提示执行仓库根目录中的恶意 git.exe，这一仓库投毒问题在 2025 年底就被报告，但 Cursor 认为不在漏洞奖励计划范围内，迟迟未发布补丁，也没有为此申请 CVE 编号，对于一个如今尝试托管大量代码的平台来说，「不及时修复已知安全漏洞」本身就是一个需要在安全性评估中认真考虑的问题。
图源：Cerelab
而 SpaceX 同样如此，前段时间发布 Grok 4.5 同期推出的 Grok Build 命令行工具在执行任务时，就会把开发者整个代码仓库打包上传到 xAI 云端，其中不仅包括完整 Git 历史，还连同已经提交到仓库里的秘钥、API Key 等敏感信息也会一起打包发送。上传的数据量远超任务实际需要的数量，有报告估算，上传的数据量是任务所需数据的 2 万多倍。
在这样的背景下，对开发者，尤其是对安全要求极高的企业在使用 Origin 前，自然会提出一连串问题：Cursor 是否会把托管在 Origin 上的代码或交互记录，用于训练 Grok 之类的大模型？这些行为是默认开启还是需要主动授权？数据在团队注销或迁移后能否彻底删除？这些问题没有答案，就很难通过企业的安全、合规审查。
05
结语
对开发者个人来说，Origin 的出现至少提供了一个可用的备选方案，可以在不抛弃 GitHub 的前提下，尝试一种更适合 AI 协作的新托管形态；对团队和企业来说，Origin 会如何使用这些数据暂时还不明确，虽然对 GitHub 有诸多不满，但也不能盲目信任这个新平台。
GitHub 当前的困境本质上仍然是一个「工程问题」。平台的架构、服务器冗余和算力显然还不足以从容应对 AI 带来的增长，但理论上，通过限流、隔离、做好负载，或者是增加冗余，都可以把整体的稳定性重新拉回到一个可接受的区间。
而 Origin 今天才刚刚上线，目前也只面向付费用户，平台的问题还没有真正暴露，未来一旦用户数量上来，AI 提交的代码激增，Origin 就一定会比 GitHub 做得更好吗？这似乎也不一定。
