Cursor一夜“干掉了”GitHub

今天，全球程序员共同经历了一次令人咋舌的事件。美东时间上午9点40分，GitHub遭遇了全面瘫痪，连带其AI助手Copilot也全线失效。这次故障持续了整整7个小时，其中核心服务中断了3个小时，导致众多程序员的工作被迫暂停，他们无法下载代码或使用AI功能。巧合的是，就在同一天，Cursor正式向GitHub发起挑战！自从与SpaceXAI合并后，Cursor团队推出了一款全新的“代码托管平台”——Origin。Origin究竟是什么？以下是一些要点：从今天开始，Origin的测试版将向所有Pro/Teams/Enterprise付费用户开放使用。最初，人们以为Cursor的目标是取代VS Code，但现在看来，GitHub才是 Cursor 真正的“猎物”。几乎在同一时刻，微软股价暴跌超过3%，超过1120亿美元的市值瞬间蒸发。Cursor版GitHub，正式上线了。Origin并非仅仅是“Cursor的代码副本”，而是一个完整的git托管平台。在早期测试版中，Origin具备多种功能——建立仓库、使用标准git进行clone/push/pull操作、从GitHub同步仓库、在浏览器中浏览和搜索代码、发起PR、进行代码审查、合并代码以及管理权限。可以说，Origin几乎重新实现了GitHub的所有核心功能。使用方法也十分简单，只需在新的Codebase标签页中点击“+New”即可创建仓库。页面会直接提供安装CLI的指南以及如何将本地项目推送到云端的信息。首次为codebase命名的部分，将作为每个仓库网址的一部分，例如cursor.com/codebase/acme-corp。AI自动合并，人类审查成为多余的功能。与GitHub相似，Origin中的每个代码仓库都设有PR，其主要亮点功能有三点：堆叠式PR允许将一个大变更拆分成多个小PR，并按依赖关系堆叠，Origin通过可视化依赖图进行展示。这对于Agent来说至关重要。Agent天生倾向于进行大规模代码修改，一次可能修改50个文件。如果全部塞入一个PR，人类审查者可能会直接看到相关页面。堆叠式PR将这个问题分解开来。一个仓库内有10个Agent各自修改了一批代码，并分别提交了PR，而CI结果显示全部为绿色。但问题随之而来：应该先合并哪个？合并一个后，剩余9个的测试结果是否还可靠？传统GitHub在面对这种局面时，会非常棘手，常常出现合并冲突、CI重跑、反复rebase的情况。Origin的合并队列能够自动排序和检测冲突，确保主干始终保持CI为绿色。更厉害的是，Origin在合并层内置了AI引擎，可以直接自动解决跨多个文件的冲突，甚至无需人工介入。GitHub的审查状态本质上是为人类设计的，仅是一个带有评论的绿勾。Agent想要判断一个PR是否可以合并，需要解析评论内容。Origin则将审查状态设计成了结构化的API，Agent可以直接读写，无需猜测。一个按钮，即可将GitHub上的项目全部迁移过来。最重要的是，Origin支持直接镜像GitHub仓库。git历史、分支、标签都会完整迁移过来，而且PR还可以实现双向同步。在同步过来后，GitHub仍然是权威的数据源（source of truth）。简单来说，同一份代码可以存在于多个地方，但必须有一个最终裁决者：出现分歧时以谁为准、CI从何处拉取、上线部署时认哪一份。在过去的二十年中，全球绝大多数团队的“权威数据源”都控制在GitHub手中。Origin的推出彻底改变了这一格局。只需点击“Detach from GitHub”，Origin就会成为真正的“代码大本营”！这足以证明，Origin并非仅仅是给GitHub套上了一层Cursor的外壳，而是在真正地构建自己的“地基”。这一次，Origin还打通了App生态，首批接入了Vercel、Depot、Buildkite等服务。Vercel负责每个PR自动生成预览部署；Depot和Buildkite则负责处理CI流程。