Cursor推出Origin代码托管平台，GitHub宕机暴露AI编程竞赛中的机会（阅读需16分钟）

# Cursor推出Origin代码托管平台，GitHub宕机为AI编程竞赛开启窗口 来源：https://venturebeat.com/infrastructure/cursor-launches-origin-code-hosting-platform-as-github-outage-exposes-opening-in-ai-coding-race Cursor (https://cursor.com/) 周一上午开始向付费用户推出其自有代码托管平台 Origin (https://cursor.com/changelog/origin-code-hosting)。约三个半小时后，GitHub 状态页面亮起警报，随后是持续六小时四十二分钟的全球性服务降级——据 GitHub 事件日志 (https://www.githubstatus.com/) 显示，拉取请求、议题和 API 的错误率接近 20%，归档和原始文件下载的错误率则接近 50%。企业级单点登录也随之中断：SAML、OIDC、SCIM 配置和团队同步全部失败。Copilot 也未能幸免。 开发者社区发挥了它一贯的作风。 “你现在可以在 Cursor Origin 中托管你的代码库，并通过 Cursor Origin 部署到 Vercel，而 Cursor Origin 本身也托管在 Vercel 上，”Vercel 首席执行官 Guillermo Rauch 在 X (https://x.com/rauchg/status/2089409162270965858) 上发帖表示。“而且与 GitHub 不同，它是在线的 😁” 当被问及为何微笑时，Rauch 回答：“试图缓解一下当前状况。我们自己也因为 GitHub 现在而被困住了！” 在 Cursor 工作的 Matt Palmer (https://x.com/mattyp/status/2089400829933666599) 转发了自己公司的发布消息，并留下了当天最妙的一句话：“我们本打算早点发布的，但 GitHub 宕机了。” 换句话说，GitHub 的宕机延迟了其竞争对手的发布。 产品发布通常几周前就已锁定，没有证据表明 Cursor 特意安排了这个时机。但这一巧合对公司极为有利，因为它戏剧化地呈现了 Origin 旨在论证的观点。十八年来，选择在哪里托管团队的源代码是工程团队做出的最无趣的决定。Cursor 认为 AI 智能体已让其重新变得有趣——对于技术决策者而言，这才是真正的新闻。不是一个新产品，而是一个附带治理问题的新采购问题。 ## **Origin 内部：Cursor 的代码托管平台究竟做什么** Origin (https://cursor.com/changelog/origin-code-hosting) 位于 Cursor 内部的新“代码库”选项卡 (https://cursor.com/learn/understanding-your-codebase) 中。团队为一个代码库命名（该名称会成为其 URL 的一部分），然后通过命令行推送代码。之后，他们就能获得代码托管平台（forge）预期的功能——封装 Git 并处理存储、权限、检查和合并的服务层。每个代码库都包含拉取请求：时间线、提交、检查和文件变更。审阅者阅读差异，留下评论并合并，无需打开浏览器标签页。 Cursor 围绕该机制构建的部分值得研究。智能体现在与代码以及它们正在修改的拉取请求处于同一工作界面。“你的代码、拉取请求和智能体现在位于同一处，”更新日志 (https://cursor.com/changelog/origin-code-hosting) 写道。开发者可以就屏幕上的文件提问，将审阅评论交给智能体并让它在原地修改拉取请求，或者让它推送一个分支——所有操作都在编写代码的编辑器内完成。 发布首日即集成了三项服务，合作伙伴的选择颇具深意。Vercel 为每个拉取请求生成预览部署，并在合并时发布到生产环境，该功能已在 Pro 和 Enterprise 客户中提供公开测试版，其开发者账户 (https://x.com/vercel_dev) 表示。Depot 和 Buildkite 运行持续集成，关键在于，两者都能原封不动地执行现有的 GitHub Actions 工作流。Buildkite 还在其上增加了原生流水线。 这个兼容层就是整个策略的缩影。Cursor 并未要求团队重写其构建系统、重新培训工程师或替换其部署管道。它只是要求他们尝试另一个查看其现有代码的窗口——这个请求更容易获得批准。 公司表示，更多合作伙伴即将到来，而首批加入的正是平台团队在评估 Origin 是否能承担实际工作时所看重的对象。一个没有部署和持续集成的代码托管平台只是代码查看器。一个能运行你现有 Actions 工作流并将预览部署到你已付费的 CDN 的代码托管平台，才是一个候选者。 ## **为何让 GitHub 保持为事实来源是 Origin 最明智的设计选择** 这是企业买家应最仔细研究的决策，因为它决定了 Origin 能否通过安全审查。 Cursor 并不要求你离开 GitHub。连接一个 GitHub 组织，选择代码库，它们就会与 Origin 原生的代码库并列显示。“推送仍然会发往 GitHub，对于在那里启动的任何内容，GitHub 仍是事实来源，”更新日志写道。访问权限镜像 GitHub 现有的读写设置，而非建立一个并行系统。拉取请求对话双向同步——在 Cursor 中评论会发布到 GitHub；在 GitHub 上回复或反应，几秒内就会出现在 Cursor 中。 这是一个经典的楔子，而且执行得非常出色。源代码控制的“推倒重来”式迁移是工程团队可以承担的最高风险项目之一。它涉及持续集成、合规证据、审计跟踪、分支保护规则、工具链中的每个集成以及每位工程师的肌肉记忆。几乎没有首席技术官会为一款处于早期测试版的产品批准这种操作。 一个主要只读的镜像，同时保持 GitHub 的权威性，则无需如此复杂。尝试成本为零，放弃也不会破坏任何东西，并悄然将开发者花费工作时间的地方重新定位。如果 Cursor 的审阅体验确实更优——Cursor 确实投入了真金白银来确保如此——那么事实来源最终将追随关注度。 这笔钱花在了 Graphite (https://cursor.com/blog/graphite) 上，这是一家代码审阅初创公司，Cursor 于 2025 年 12 月收购，据 Axios 报道，收购价远高于其 2.9 亿美元的 B 轮估值 (https://www.axios.com/pro/enterprise-software-deals/2025/12/19/cursor-buys-code-review-platform-graphite)。Graphite 构建了堆叠式拉取请求，这种工作流让开发者无需等待批准即可持续交付依赖性变更。在宣布这笔交易时，Cursor 写道 (https://cursor.com/blog/graphite) “编写代码与协作代码之间的界限感觉越来越随意”，并承诺“一些我们还不能分享的、更激进的想法”。Origin 就是这个激进的想法。Graphite 联合创始人 Tomas Reimers 在 Cursor 首届 Compile 大会上揭晓了它，并领导其开发。 ## **AI 智能体如何将代码审阅变为软件的新瓶颈** 支持“智能体原生”代码托管平台的论点基于一个容易陈述、且在这个市场中罕见地有充分证据支持的主张：编写代码不再是瓶颈，审阅和集成代码成为了瓶颈。 谷歌的 2025 年 DORA 报告 (https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)（基于近 5000 名技术专业人士的数据）发现，90% 的开发者现在在工作中使用 AI，平均每天使用两小时，超过 80% 的人表示 AI 提高了他们的生产力。但 AI 采用与软件交付吞吐量呈正相关，与交付稳定性呈负相关。产出更多，故障也更多。报告作者将 AI 描述为“放大器”，它“放大了高绩效组织的优势，也放大了挣扎组织的机能障碍”。 信任未能跟上数量的增长。Stack Overflow 的 2025 年开发者调查 (https://survey.stackoverflow.co/2025/ai)（覆盖 177 个国家的 49,009 名受访者）发现，84% 的人正在使用或计划使用 AI 工具，而对其准确性的信任度从一年前的 43% 下降到 33%，不信任度则从 31% 上升到 46%。三分之二的人将“AI 解决方案几乎正确，但又不完全正确”列为他们的首要挫折。GitLab 由 Harris 调查的第九届年度 DevSecOps 调查 (https://about.gitlab.com/press/releases/2025-11-10-gitlab-survey-reveals-the-ai-paradox/)（针对 3,266 名实践者）量化了这种操作负担：73% 的人遇到过“氛围编码”（vibe-coded）输出的问题，70% 的人表示 AI 使合规管理变得更困难，只有 37% 的人愿意让 AI 在没有人工审阅的情况下处理日常任务。 无论如何，数量仍在攀升。GitHub 的 Octoverse 2025 (https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/) 统计显示有 1.8 亿开发者、6.3 亿代码库，每月合并 4320 万个拉取请求，同比增长 23%。而 RuntimeWire 报道 (https://runtimewire.com/article/cursor-builds-origin-to-host-code-from-fleets-of-ai-agents-launching-today) 的一个内部数据最能解释 Origin 存在的理由：在 Cursor 内部合并的拉取请求中，有 35% 是由在云虚拟机中自主运行的智能体发起的。 一个为人类构建的代码托管平台假设一个拉取请求代表人类意图，由你可以询问其意图的人发起。一旦三分之一的合并变更来自软件，队列就不再是一场对话，而变成了一个调度问题。这是一个真实的架构论点，也是 Cursor 拥有的最有力优势。 ## **GitHub 的可靠性危机给了 Cursor 一个无需争取的机会** 替代方案的供给侧论点更简单：GitHub 一直不可靠，其高管自己也这么说。 LeadDev (https://leaddev.com/software-quality/whats-gone-wrong-at-github) 的一项分析统计了 2025 年 5 月至 2026 年 4 月间的 257 起事件，其中 48 起是重大事件——大约每周一次重大中断。2 月是有记录以来最糟糕的一个月，发生了 37 起事件。仅 GitHub Actions 在十二个月内就出现了 57 次故障。首席技术官 Vlad Fedorov 曾表示，该平台“并非为当前所需的规模而构建”，必须为 30 倍于当前的负载进行设计。在 InfoQ (https://www.infoq.com/news/2026/04/github-outages-scaling/) 报道的一篇 4 月工程博文中，公司承认“未能达到自身的可靠性标准”，并列举了快速增长、紧密的架构耦合和不足的负载分流作为原因。周一的宕机是 GitHub 状态页面在十五天内的第七次事件。 疲惫感显而易见。“GitHub 真的感觉不是为智能体时代构建的，”一位开发者在 Origin 上线时表示，“它宕机太频繁了，但直到现在，还没有太多真正的替代方案。” 叛离在 Origin 诞生之前就已开始。Zig 编程语言于 2025 年 11 月迁移到了 Codeberg (https://ziglang.org/news/migrating-from-github-to-codeberg/)，理由之一是 Actions 故障。4 月，Mitchell Hashimoto 宣布 Ghostty——一个拥有超过 52,000 颗星的终端模拟器——也将离开 (https://mitchellh.spicytakes.org/post/2026-04-28-ghostty-leaving-github)，指出近乎每日的宕机阻塞审阅和持续集成长达数小时。而 The Information 在 3 月报道称，微软持有大量股份的 OpenAI 开始构建自己的 GitHub 替代方案，部分原因是宕机导致其工程师无法提交代码数小时，Tom's Hardware 进行了转述 (https://www.tomshardware.com/tech-industry/openai-building-github-alternative-after-outages-disrupted-engineers)。 微软的组织架构也于事无补。Thomas Dohmke 于 2025 年 8 月辞去 (https://github.blog/news-insights/company-news/goodbye-github/) GitHub 首席执行官职务，且从未被接替；该部门的领导层被并入微软的核心 AI 组织，由执行副总裁 Jay Parikh 领导。在 5 月的一份报告中，The Information 写道，Parikh 曾警告副手 (https://www.theinformation.com/newsletters/ai-agenda/cursor-sees-opening-github-flounders)，来自 Cursor 和 Anthropic 的编程工具最终可能使 GitHub 过时。GitHub 自己对智能体时代的回应 Agent HQ (https://github.blog/news-insights/company-news/welcome-home-agents/)，允许客户在 GitHub 内部协调来自 Anthropic、OpenAI、Google、Cognition 和 xAI 的第三方智能体——这是一种连贯的策略，承认了智能体层的存在，同时保留了底层的基础设施。而 Origin 正是针对这层基础设施发起攻击。 ## **既然 SpaceX 收购了 Cursor，谁真正掌控着你的源代码？** 即使按照这个周期的标准，Cursor 的崛起也堪称非凡。它由四名 MIT 学生于 2022 年创立，Anysphere 在 2023 年 10 月从 OpenAI Startup Fund 获得了 800 万美元融资 (https://techcrunch.com/2023/10/11/anysphere-raises-8m-from-openai-to-build-an-ai-powered-ide/)，随后在估值 25 亿美元时融资 1 亿美元，估值 99 亿美元时融资 9 亿美元，并在去年 11 月以 293 亿美元的估值融资 23 亿美元。彭博社 5 月报道称，其年化收入为 30 亿美元，有超过 3000 家客户每年支付至少 10 万美元。 然后，在 Origin 发布前三天，彭博社报道称 SpaceX 完成了其对 Cursor 的 600 亿美元全股票收购——TechCrunch (https://techcrunch.com/2026/06/16/spacex-to-acquire-cursor-for-60b-in-stock-days-after-blockbuster-ipo/) 在 SpaceX 创纪录的 IPO 数日后、吸收 xAI 六个月后报道了这笔交易。Cursor 现在在一个名为 SpaceXAI 的部门内运营。上周五，这个要求托管你专有源代码的供应商，变成了一个拥有自身前沿模型部门、且其创始人并非以机构性谨慎著称的火箭公司的一部分。 Moor Insights & Strategy 的 Jason Andersen 在交易完成前的 6 月向 Tech Times (https://www.techtimes.com/articles/319031/20260624/cursors-github-rival-origin-new-spacex-model-raise-code-custody-stakes.htm) 提出了模型路由问题：“xAI 的模型及其对待安全护栏的方式与 Cursor 所代表的理念非常不同。” 那篇文章提出了首席信息安全官现在必须回答的问题。当一家公司同时控制着智能体编写代码的编辑器、代码托管的平台以及这些智能体运行的模型时，什么来规范它对代码的处理？ Cursor 尚未公布答案。RuntimeWire 在发布前指出，Origin 的定价、安全架构、数据处理条款和迁移工具均未公布，周一的更新日志也没有补充任何内容。它只说明 Origin “从今天开始面向所有付费计划用户开放，但管理员选择退出的企业组织除外。” 是“选择退出”而非“选择加入”——管理员应该读两遍这句话。 此外，还有既往记录需要权衡。7 月，Mindgard 的研究人员披露，Cursor 会在用户打开包含恶意 git.exe 的 Windows 项目根目录时立即执行它，没有任何提示——这是一个他们于 2025 年 12 月首次报告的代码库投毒漏洞。The Hacker News (https://thehackernews.com/2026/07/cursor-flaw-lets-malicious-cloned.html) 报道称 Cursor 拒绝修复，称在共享责任模型下该问题不在范围内，同时承认未能“及时与研究人员闭环”。没有发布 CVE。同类漏洞在 GitHub Copilot CLI、Google 的 Gemini CLI 和 OpenAI 的 Codex 中也未修补——但供应商拒绝修复的漏洞，对于一个其卖点本质上是“让我们托管你的代码库”的产品来说，是一个尴尬的脚注。 ## **工程负责人在将 Origin 纳入工具链之前应解决的问题** Origin (https://cursor.com/changelog/origin-code-hosting) 是一个测试版，而非迁移方案，将其作为测试版来评估是值得的。同步模式为平台团队提供了一种低风险的方式来衡量智能体原生审阅界面是否能缩短周期时间，而无需触及任何一条分支保护规则。但在任何权威内容迁移之前，有三件事需要解决。