谁在打造下一个 GitHub？代码、AI 与平台权力

GitHub 是人们存储、协作开发和发布软件的平台。它的基础是 Git，一种版本控制工具：记录文件修改，支持并行开发分支，并帮助合并不同的工作成果。Git 提供技术基础，GitHub 在其上增加问题报告、讨论、拉取请求和自动化流程等协作功能。

Git 于 2005 年诞生于 Linux 内核开发过程中。GitHub 成立于 2008 年，并于 2008 年 4 月 10 日正式向公众开放。十年后，微软以 75 亿美元收购该公司，并于 2018 年 10 月 26 日宣布完成交易。原本属于开发者的聚集地，成为软件世界的核心基础设施。Git、GitHub、Microsoft

到了 2026 年，突然感觉传统软件开发之外的人也几乎人手一个 GitHub 账号。有人做个小应用，有人做个人仪表盘，还有 AI 工具要求连接仓库。这是我刻意夸张的感受，并非关于非开发者的统计。不过，背后的变化确实重要：构建软件的门槛降低，底层基础设施则需要承担新的负载。

因此，我很关心谁会打造下一个 GitHub。Anthropic 重建了内部版本控制系统，Cloudflare 为新 Git 平台提供构件。与此同时，GitHub 的可靠性受到公开质疑。这里争夺的远不只是一个更好用的合并按钮，而是谁控制软件诞生、接受审查并走向生产环境的地方。

当用户也成为软件构建者

这种变化在今年之前就开始了。GitHub 的 Octoverse 2025 报告已记录超过 1.8 亿开发者，一年内新增用户超过 3600 万。据 GitHub 称，近 80% 的新开发者在第一周就使用 Copilot。这是厂商统计，不足以证明全部增长都由 AI 导致，却说明加入 GitHub 与 AI 工具之间的联系有多紧密。

过去，要做一个小工具，往往得先学会足够的编程知识，才能得到有用的起点。现在可以描述想法，与编程代理逐步实现。专业知识依然不可缺少，特别是涉及数据、权限和生产系统时。不过，从想法到第一个能运行的程序，距离确实缩短了。

我看到开源领域的巨大潜力：让文档更清楚、补充测试、排查故障、理解接口、重新拾起搁置的想法。这些都是 AI 加速开发的具体方式，但不能据此认定每个项目的质量都在提高。多一个仓库不等于多一套有人维护的软件，多一个拉取请求也可能让维护者更忙。

与其数代理生成多少行代码，我更关心有多少能被理解、验证和长期维护。代码产生得越快，瓶颈越容易转移到决定哪些修改值得留下的人与系统上。

状态页面上的“圣诞树”

页首图片展示的是 Marek Šuppa 制作的 The Missing GitHub Status Page。2026 年 10 月 15 日的截图显示，90 天内共有 65 起事件，平台可用性为 93.70%，而 Git Operations 为 99.55%。这些数字属于当时的截图，并非我新测得的当前可用性。

这个非官方页面从公开状态报告中重建时间区间，并合并重叠故障。平台总数汇集不同服务，不意味着每次事件中 Git 克隆、拉取请求和 Actions 都同时对所有用户不可用。因此，93.70% 不能直接解释成“GitHub 有 6.30% 的时间完全离线”。其含义取决于聚合方式及纳入的事件。

不过，图片确实触及痛点。版本平台已是生产链的一环。无法访问的审查、受阻的构建或异常 API，都可能在源代码完整保存在本地的情况下延误发布。对受影响的流程而言，需要正常运行的是整条链路。

这张图同样不能证明故障由 AI 引起。它解释了替代方案为何受到关注。具体中断的原因仍应依据对应的事件报告判断。

为什么必须区分 Git 与 GitHub

GitHub 故障本身并不说明 Git 数据模型有问题。有了完整本地副本，我仍能记录修改、对比历史版本、处理分支，无须平台供应商始终在线。这种独立性是我最看重的 Git 特性之一。

围绕仓库建立的服务则不同。如果审批、测试、产物和部署都依赖平台，仅有本地副本便不足以继续整个流程。代码可以是分布式的，工作流程却可能高度集中。

所以有两个不同要求：平台必须可靠，版本控制也必须适应数据规模和工作方式。换一家托管商不会自动解决所有扩展问题；平台一段时间表现不佳，也不足以单独证明应彻底替换 Git。

Anthropic 为非同寻常的规模打造 Scion

Anthropic 报告称，2026 年 5 月每天合并约 2500 项修改，9 月则超过 3 万项。主分支历史接近 100 GB，压缩工作副本超过 25 GB，仅 CI 每天就执行约 2500 万次检出。文中每天超过 600 PB 的传输量，是对简单粗暴地完整获取数据的推算，并非实际测量的日流量。

它的答案叫 Scion。Anthropic 描述了一次历时五个月的迁移，同时还构建了审查工具 Antique 和其他内部基础设施。Scion 假设客户端持续在线，把版本操作放到服务器上，按需加载文件，并通过 API 直接回答许多问题。任务便不必为每次查询都准备本地仓库副本。

Anthropic 自己划定的边界非常重要：Scion 不是通用 Git 替代品，也不是宣布面向所有人的公共 GitHub。它针对超大单体仓库和自身代理负载，也希望把经验分享给现有 Git 生态。因此，“Anthropic 打造下一个 GitHub”至多形容技术方向上的转变，而非一个已经可用的竞争产品。

小客户端为何能带来大变化

无需达到 Anthropic 的规模，也能理解这种架构思路。假设某个自动任务只需检查一个配置文件在两个版本之间有没有变化，它需要的只是一个具体答案。建立庞大的本地环境，可能比检查本身更费资源。

单次任务的额外成本或许不起眼；大量短生命周期环境不断重复初始化、传输和清理，就可能占用相当多资源。只返回所需数据的服务会改变这笔账。这是架构权衡，不是每个小仓库都需要集中式版本服务器的证据。

代价是更依赖远程服务的可达性。把更多工作交给服务器，就必须认真处理其故障、权限、恢复能力和容量限制。少存一些本地数据很方便，直到远端不再响应。

我喜欢这种对惯常假设的反思，但不会把它变成普遍建议。对规模不大的项目，完整的本地 Git 历史可能正好兼顾简单、速度和独立性。

Cloudflare 保留 Git，让仓库可编程

Cloudflare 的 Artifacts 走了另一条路。4 月介绍的服务提供兼容 Git 接口的版本化存储，允许通过 API 创建、导入和分叉仓库，也能使用普通 Git 客户端。Cloudflare 提议为项目、任务或代理会话分别建立仓库，保存版本化的代码与上下文。底座可以通过程序配置，而不是把每个仓库都当作需手工搭建的永久工作场所。

Git 兼容性因此具有战略价值。既有工具和熟悉的流程降低采用门槛。新产品可以先解决协作问题，不必同时推广一套全新的版本协议。

10 月，Cloudflare 宣布向付费 Workers 套餐客户开放公测。较新的集成将 Artifacts 接入 Workers Builds 和预览环境，事件可以触发自动审查，仓库专用令牌则限制访问范围。Cloudflare 明确邀请其他人在 Workers 和 Artifacts 之上构建下一代 Git 平台。这是具有平台野心的基础设施，还不是拥有同等社交与组织生态的完整 GitHub。

我觉得关键差别在于边界。Anthropic 优化自己的超大开发系统，Cloudflare 则为别人的产品提供基础。人与代理如何交互、如何共同作决定，仍然是另一个产品问题。

这些公司为何想占据这个位置

Anthropic 已明确说明的直接动机，是内部瓶颈。研究和产品开发若要等待版本操作，就会损失时间和计算资源。即使 Scion 永远不成为公共产品，更好的内部基础设施也有价值。

此外，我认为它有战略动机，让编程代理在更长的流程中发挥作用。能写函数的模型有价值；能理解项目、准备可审查修改、融入现有基础设施的代理，可以更深入日常工作。这是我的商业分析，不是 Anthropic 确认的 Scion 商业化计划。

Cloudflare 与基础设施业务的关系更直接。应用在 Workers 上运行，开发数据又放在 Artifacts，就有更多流程进入同一平台。Cloudflare 说明 Artifacts 按操作次数和存储量收费。更多代理可能意味着更多仓库、访问和计算。具体流程是否划算，仍取决于实际用量。

集成还会形成黏性。迁移一个 Git 仓库通常相对容易；迁移由专用 API、代理流程、事件、权限、预览和部署组成的系统则困难得多。各部分配合得越方便，更换供应商所需的实际成本往往越高。

这些动机并不否定技术收益。服务可以解决真实问题，同时巩固供应商地位。正因如此，我希望在方便的集成变成无人质疑的依赖之前，看清两面。

代码的价值不只在程序文本

没错，训练数据也属于这场讨论。作为可能的战略利益，它值得关注；但拿它解释每一个新 Git 平台，就过于省事了。

仓库往往不只有当前答案。历史可能说明最初尝试了什么、哪项测试失败、审查为什么拒绝某次修改、最终接受了什么修正。对编程系统的开发而言，这种关联可能特别有价值：任务、尝试、反馈和可验证结果彼此相连。

举个虚构例子。代理要修复日期计算错误，第一份方案通过旧测试，却没通过新增加的跨年测试。审查者解释错误假设，下一次修改纠正它。学习价值不仅在最终代码，也在从看似合理的错误走向有根据的答案这一过程。供应商是否真的利用这些数据、是否有权利用，是另一个问题。

因此，生成代码成本降低，并不意味着代码价值消失。可靠需求、决策记录、好测试、维护经验和经过验证的协作运行仍需要投入。堆积生成文件无法替代这些。建议可以无限出现时，能证明某项建议确实解决问题的证据反而更有价值。

这是我对技术与经济潜力的判断。这里讨论的公告，并不能证明 Anthropic 通过 Scion 收集别人的私有仓库，也不能证明 Cloudflare 运行 Artifacts 是为训练自己的编程模型。

训练问题中必须区分什么

AI 对开发数据的兴趣并非纯粹假设。2026 年 3 月，GitHub 宣布自 4 月 24 日起，除非用户选择退出，否则某些个人 Copilot 套餐的交互数据将用于模型训练。它明确区分活跃的 Copilot 交互与静态存储的私有仓库内容，并表示不会为该目的普遍读取后者。Copilot Business 和 Enterprise 有不同保护规则。GitHub Copilot

Anthropic 则表示，默认不使用商业产品的输入输出训练模型。主动反馈及明确参加某些计划，可能采用不同处理方式。这不是针对所有个人套餐和设置的统一承诺。Anthropic

因此，对于新服务，我会具体追问：哪些内容只存储，哪些用于处理请求，哪些用于改进产品或训练？这是不同活动。代理为了处理代码必须读取代码，但这并不自动意味着可以把它长期融入模型。

“开源”也不能独自回答全部使用问题。代码公开可见、许可证、机密内容及服务条款需要分别考虑。在我看来，易懂的数据使用政策与实用 API 一样，都是产品的一部分。

下一个 GitHub 必须帮助作出更好的决定

最省事的未来想象，是无数代理无限生成代码，再由其他代理自动全部批准。我不信服。如果多个系统共享同一错误假设，相互同意也不会构成独立验证。

有用的平台应说清楚：修改完成什么任务、基于哪个版本、运行过哪些检查、由谁承担接受它的责任。并行修改可能各自看似正确，放在一起却造成破坏。更快合并并不会消除这个问题。

代理上下文也需要边界。任务描述、日志和配置可能包含不应进入任意仓库或外部运行环境的信息。持久保存代理会话，除了帮助开发，也创造了新的数据集合。其访问权限和存续时间应有意识地设计。

开源的人性一面同样关键：对维护者的信任、能理解的讨论，以及多年照顾项目的意愿。更快的托管可以支持这些工作，更多自动化活动本身却无法取代。

GitHub 遇到挑战，但继任者仍未确定

我认为重新质疑基础工具是健康的。如果 AI 让更多人能构建软件，我们也应问，原有平台还适不适合随之出现的工作。

Anthropic 展示专用的内部重建，Cloudflare 向新产品开放基础设施。GitHub 仍拥有成熟生态，替代者必须取代它，或有价值地补充它。新存储架构不会独自决定这场竞争。

对我而言，重要问题是：谁能让更多人与代理有效协作，同时保留可追溯性、独立性和数据控制权？这才是下一个 GitHub 的衡量标准。很大一部分商业价值，可能也正在这里。

下次见，
Joe