Red Squares 那张红格子图很刺眼。

它把 GitHub 故障记录压成一块块红色方格，像一张开发者版的晴雨表：红一点，CI 卡住；再红一点，PR 合不了；红到一片，发布窗口就要改。

现在问题又往前走了一步。一篇题为《GitHub and the Crime Against Software》的长文在开发者圈流传，作者 Efron Licht 批评 GitHub 近来的故障、页面臃肿、Pull Request 和评论页卡顿，还把矛头指向 Copilot、Agent 等 AI 工作流入口。

Red Squares 只能告诉你：GitHub 最近不太稳。

这篇长文补上的信息是：不稳背后可能不只是运维问题，还牵涉平台怎么定义可用性、怎么分配产品优先级、怎么把 AI 增长压力塞进原本的代码协作流程里。

这事到底发生了什么

几个点压缩看：

  • 故障体感变强.开发者用 Red Squares 这类工具追踪 GitHub 故障，说明稳定性已经从偶发抱怨变成日常感知。
  • 争议扩大到状态页.Efron Licht 对照 GitHub 官方状态页、Online Services SLA 和第三方状态记录，认为官方可用性展示与用户体感存在落差。
  • AI 工作流成了新靶心.GitHub 官方提到 agentic development workflows 带来仓库创建、PR、API、自动化和大仓库负载增长。批评者认为，GitHub 一边推 Copilot 和 Agent，一边让开发者承受更重的平台负载。
  • 前端性能被拉出来拷问.原文批评 GitHub 的 PR、评论、Actions 日志等页面变重，浏览器内存占用高，部分场景下 Safari、Firefox 体验也不稳定。
  • 替代品被重新讨论.GitLab、Codeberg 被拿来对照。它们不是无成本退路，但至少提醒开发者：GitHub 不是自然法则，只是当前事实标准。

这里要把证据强度分清。

第三方状态页和用户体感能说明波动明显，不能直接证明 GitHub 真实宕机率。SLA 是否违约，要看服务范围、统计周期、排除项和补偿条款。页面性能测试也受仓库样本、浏览器、插件、网络环境影响，不能当作全行业基准。

但这些限制不等于批评无效。

开发者抱怨的核心从来不是“某个页面慢了三秒”。真正让人不安的是：GitHub 已经是开源协作、企业代码托管、CI/CD、安全扫描、Webhook、API 自动化的底座。底座晃一下，上面的流程都会跟着晃。

谁会被影响：不是所有用户，是重度依赖者

普通用户偶尔打开仓库看代码，最多觉得网页变慢。

真正被打到的是两类人。

一类是开源维护者。Issue、PR、Release、Actions、Packages、Security Advisory，全绑在 GitHub 上。平台慢，维护节奏就慢；状态页说没事，用户那边却跑不动，维护者还要解释。

另一类是企业研发团队。很多公司的发布流水线已经长在 GitHub Actions、API、Webhook 和权限系统上。GitHub 不只是一个网站，而是研发组织的交通枢纽。

交通枢纽的问题，从来不只是某趟车晚点。

晚点如果可预期，团队还能排班。怕的是信号系统说一路绿灯，车站里已经挤满人。官方状态页、SLA、第三方监测之间的口径差异，真正伤的是信任。

AI 入口不是原罪，优先级才是

我不反对 GitHub 做 Copilot，也不反对 agentic workflow。

代码托管平台天然适合接 AI。它知道仓库结构，知道 PR 上下文，知道 issue 历史，也知道 CI 结果。AI 如果能帮开发者少切窗口、少翻日志、少写重复说明，这是正经价值。

问题在于，开发者打开 GitHub 的第一任务通常很朴素：看 diff，审 PR，查 issue，跑 CI，合并代码。

如果这些核心动作变慢，而页面上 Copilot、Agent 入口越来越显眼，用户很自然会得出一个判断：平台在优化销售漏斗，不是在优化工作流。

这句话刺耳，但很难绕开。

GitHub 当然可以说负载来自大仓库、Actions 并发、供应链扫描、API 自动化、通知系统和搜索索引。都对。现代代码托管早就不是一个 Git remote 加网页壳。

可 GitHub 也不能把 AI 工作流只算成增长故事，不算成基础设施成本。

“天下熙熙，皆为利来。”放在这里并不玄。Copilot 是收入，Agent 是叙事，AI 工作流是增长曲线；页面性能、状态页透明度、Actions 稳定性，都是成本中心。公司内部资源怎么排，用户在网页上能闻到味道。

味道不对，信任就掉。

GitLab 和 Codeberg 是退路，但不是逃生门

拿 GitLab、Codeberg 对照 GitHub，有意义，但别把迁移说得太轻。

GitLab 的优势是 DevOps 套件完整，CI/CD、权限、代码审查、安全能力更集中，自托管能力也成熟。代价同样清楚：部署、维护、升级、权限治理都更重。

Codeberg 基于 Forgejo，气质更轻，社区治理色彩更强，适合重视开放基础设施的小项目。问题也现实：生态、企业集成、第三方服务数量，比 GitHub 少一截。

所以对多数团队来说，正确动作不是“明天搬家”。

更实际的是降低单点依赖：

  • 重要仓库同步镜像到 GitLab、Codeberg 或自托管平台；
  • 发布产物不要只挂在 GitHub Release；
  • 文档、包分发、容器镜像保留备用路径；
  • CI 关键路径评估是否全压在 GitHub Actions；
  • Webhook、API rate limit、状态页告警要有外部监测；
  • 企业内部要知道.GitHub 挂了，谁能拍板切流程。

这不是唱衰 GitHub。

恰恰因为 GitHub 太重要，才不能把它当成永远不会出问题的空气。

真正该盯的不是下一次红格子

红格子还会出现。大型平台没有零故障。

接下来更该看四个变量。

一是状态页透明度。用户体感和官方口径长期不一致，会比一次故障更伤人。

二是前端性能预算。PR、评论、Actions 日志这些核心页面不能越来越像广告后台。开发者不是来逛商场的。

三是 AI 入口克制。Copilot 能帮忙，就放在需要它的地方；别把每个页面都改成增长入口。

四是 Actions 和 API 稳定性。网页慢还可以忍，自动化断流会直接影响发布、测试、安全扫描和外部集成。

历史上很多基础设施平台都经历过同一段路：先靠简单可靠赢得信任，再靠生态扩张变得沉重，最后在增长、治理和用户耐心之间拉扯。铁路、电力、云服务、代码托管都一样，只是换了外壳。

GitHub 还没到崩坏那一步。

但它已经到了一个必须重新证明自己的阶段：AI 可以长，页面不能肿；功能可以多，核心路径不能抖；状态页可以有口径，不能让重度用户觉得自己被糊弄。

红格子画的是故障。

真正该怕的是，开发者看着红格子越来越多，心里开始默默设计离开的路线。