8月17日晚上（北京时间21:28开始），GitHub罕见地整体瘫痪了7小时47分。如果你平时用Cursor、Codex、Claude Code这类AI编程工具，把代码托管在GitHub上，那天晚上大概率被波及：代码仓库、Pull Request、Actions、API、Webhooks先后出现异常，连Copilot都受到影响。36氪有做海外项目的开发者说，自己每天几百次代码提交全堵在本地，CI流水线直接卡死。知乎
7小时47分全线瘫痪，有多严重
有多严重？GitHub官方复盘称，高峰时网页及API错误率约20%，归档和原始内容下载的失败率接近50%，企业SSO（SAML、OIDC、SCIM）也全部宕机。知乎
真正放大故障的，是重试风暴
但这次真正值得看的不是“GitHub挂了”，而是官方复盘里那个反常识的细节。起点是个常规基础设施事故：Central US数据中心的负载均衡网络饱和，Istio sidecar达到并发上限，又没被扩容策略正确观察到。真正把故障放大的，是VS Code的一个潜在重试缺陷：客户端不停重试，把Copilot Token服务的请求量从常态的每秒7000～9000次，一路推到了7万～10万次，放大了约10倍。说白了，就是自动化客户端的重试风暴，把一次局部故障踩成了7小时47分的大宕机。知乎
机器提交越来越快，评审带宽跟不上了
这事放在两年前无伤大雅，放在今天就很扎眼。这两年AI编程把代码提交变成了机器行为：Agent自动克隆、推送、开PR、失败重试。Linear刚发布的聚合报告能对上号：在6887个固定付费团队样本里，接入Coding Agent的团队，每周打开的PR从两年前的平均21个涨到65个，翻了三倍多；没接入的团队只从8个涨到10个。知乎但同一份报告也说了句大实话：已有任务的耗时并没有下降，AI的使用更像增加了一层工作，瓶颈正在从“写代码”转移到“评审和合并”。机器提交得越来越快，人的评审带宽开始跟不上了，这次宕机就是这对矛盾第一次集中爆发。
Cursor趁乱上线Origin，但你该做的不是搬家
反应最快的是Cursor。宕机几乎同一时间，Cursor开始向全部付费计划推出Origin早期Beta，先提供代码仓库、PR、代码浏览和GitHub同步，企业管理员可以选择退出。知乎
于是社区立刻分成两派：一派喊“GitHub护城河塌了”，一派说这是趁火打劫。先把边界说清楚，免得被带节奏：Origin目前是早期Beta，同步自GitHub的仓库，推送仍回GitHub，GitHub还是事实来源。知乎在Origin里，代码、PR和Agent被放进同一个环境，开发者可以针对屏幕上打开的文件向AI提问，也可以让Agent修改代码、创建或更新PR、推送代码。36氪Cursor官方把Origin定义成一个git forge。知乎所以对绝大多数从GitHub起步的项目来说，Origin现在更像“叠在GitHub上的一层Agent工作台”，而不是替代品。真正值得观察的不是“GitHub被取代”，而是代码托管开始围着Agent重做：Agent会并发、会重试、会不停开PR，仓库就不能只当文件柜。
现在该做什么：三件低成本灾备动作
那普通AI编程用户现在该干什么？我的建议是：别急着搬家，但补三件低成本的灾备动作。
第一，给重要仓库加个备份远端。Gitee、自建Gitea，或者第二家托管平台都行，`git remote add`一行的事。下次再宕机，你至少还能从镜像克隆、继续干活，不用干等。
第二，依赖GitHub raw/archive下载关键文件的工作流，提前做缓存或镜像。这次宕机里，归档和原始文件下载的失败率接近50%，比网页和API还惨。你的AI工具安装脚本、Skill依赖如果直链GitHub raw，宕机时就是重灾区。
第三，给自己的Agent和自动化脚本加重试退避。这次官方复盘把重试风暴点名了，GitHub列出的整改项里也有“重试退避”。知乎你的CI和Agent对着挂掉的服务死命重试，既是给别人添堵，也烧自己的Token和额度。
团队用户再多看一条：AI编程时代真正的瓶颈不是生成，是评审。PR翻三倍、耗时却没降，说明评审吞吐、重复变更识别、高风险文件的合并规则得跟着Agent一起升级，不然代码堆得越快，债背得越多。
后续值得盯三个信号：Origin从Beta走向全量的节奏，Cursor已经发了Continuity技术博客讲它的托管方案；GitHub整改项的落地情况，sidecar扩容、重试退避、区域故障转移；以及Linear报告里那个悬而未决的问题，PR暴增之后，合并率和上线质量到底怎么样。这三件事任何一件有进展，“代码托管要不要换地方”这个问题的答案都会变。现在下结论，还太早。
