對軟體的罪行：分析 GitHub 的基礎設施衰退

現代軟體開發的生態幾乎與 GitHub 同義。對許多開發者而言，GitHub 個人檔案是職業合法性的先決條件。然而，在全球最受歡迎的程式碼託管平台光鮮介面之下，正隱藏著日益嚴重的基礎設施衰退。當一項服務成為全球軟體生產的中樞神經系統時，其可靠性與效能不再僅是「使用者體驗」的問題——它們成為系統性風險。

近期的停機與效能下降常被視為「代理式開發工作流程」的成長痛。但仔細觀察顯示，GitHub 目前的狀態並非成長的意外，而是有意將炫目的 AI 功能置於基礎工程卓越之上所導致的優先順序結果。

AI 優先悖論

Microsoft 與 GitHub 積極將「AI 代理」與 Copilot 推入平台的每個角落。在典型的倉庫首頁，使用者會看到多個 AI 按鈕，常常在螢幕的同一象限出現四個。此舉不僅是使用者體驗的選擇，更是資源的消耗。

GitHub 把近期的可用性問題歸因於代理式工作流程的快速加速。然而，這種「負載」是其自身策略的直接結果。透過補貼這些工具以推動採用，GitHub 實際上為自己的基礎設施資助了一場分散式阻斷服務（DDoS）攻擊。

雖然 Microsoft 宣稱「先可用性，再容量，最後新功能」，資料卻顯示相反。檢視 GitHub 在 30 天內的公開變更日誌，可見其優先順序的明顯落差：

  • Copilot 提及次數: 59
  • Agent 提及次數: 8
  • Performance 提及次數: 0
  • Reliability 提及次數: 0

量化臃腫：比較實驗

為了了解技術衰退的程度，我們進行了一項實驗，將 GitHub 與 GitLab 以及 Codeberg（Forgejo）的前端資源使用情況進行比較。目標是使用受限的「Fast 3G」連線模擬真實環境，測量在三個服務上渲染最小且相同倉庫的成本。

記憶體與堆積使用量

即使在沒有任何活躍處理的穩定狀態下，RAM 消耗仍令人驚訝。PlayStation 2 僅以 32 MiB 的總 RAM 渲染 3D 圖形，而現代程式碼託管的網頁前端僅為顯示文字就消耗遠超此數。

服務 穩定狀態堆積使用量
Codeberg ~14 MiB
GitLab ~68 MiB
GitHub ~69 MiB

載入實際內容時，浪費會進一步升高。對高活躍頁面（如 Rust 語言的 Pull Request）進行堆積快照時，顯示出超過 148 MiB 的峰值——比原始 iPhone 的記憶體還多——僅為渲染一個連結清單。

網路負載與程式碼量

使用自訂分析工具（anhar），對空白倉庫的網路請求進行剖析。結果顯示傳送至客戶端的程式碼量存在巨大的差異。

  • GitHub: 載入約 300 個檔案，總計約 550,000 行程式碼與資料。作為對照，這比原始 DOOM（35k 行）或整個 MS-DOS 4.0 作業系統（332k 行）所需的程式碼還要多。
  • GitLab: 拉取約 7 MiB，分佈於 70 個檔案（約 10,000 行）。
  • Codeberg: 拉取約 1 MiB，分佈於 11 個檔案（約 1,100 行）。

GitHub 依賴 Webpack 進行分塊，導致交付系統碎片化，需要數百個獨立的 HTTP 請求，增加大量開銷，使「可互動時間」降至不可接受的程度。在某些測試中，空白頁面在受限連線下完整載入需超過 21 秒。

基礎設施的「Enshittification」

有一種常見理論稱為「enshittification」，即產品先服務使用者，接著是企業客戶，最終只為其股東服務。但 GitHub 的衰退感覺不同。這種臃腫不僅傷害使用者，也傷害 Microsoft。他們需負擔頻寬成本與維護這個破爛程式碼庫所需的工程時數。

這不僅是技術債務，更是職業誠信的失敗。當平台的前端如此低效時，會引發關鍵問題：若「餐廳」（前端）已被如此忽視，那「廚房」（後端與資料庫架構）又會是什麼樣子？

社群觀點與替代方案

開發者社群的回應呈兩極分化。有些使用者仍感滿意，認為 GitHub 的規模足以說明部分低效是合理的。另一些則看到危機徵兆，正遷移至更精簡的替代方案。

「我把那隻小狗放到我的 tailnet 上，安裝了 Gitea，從此所有專案都只用它。我感到自由。」 — @jodacola

其他人警告說真正的「鎖定」不是程式碼，而是社會資本——GitHub 的星標。如 @ashishb 所指出，星標是衡量專案重要性的貨幣，而出售假星標的服務則進一步腐蝕了軟體品質的訊號。

成績摘要

服務 成績 判斷
Codeberg C+ 基礎有潛力，但缺乏壓縮與最小化。
GitLab D+ 受過多未使用的 JS/CSS 以及垃圾回收不佳所困擾。
GitHub F 滑稽地過度臃腫；將 AI 提示置於基本效能之上。

結論

軟體的本意是為使用者解決問題。當我們用來構建全球軟體的工具本身成為浪費與無能的典範時，這不僅是劣質產品，更是對媒介的罪行。產業目前對 AI 驅動「代理」的執著正形成腐蝕的回饋迴路，AI 生成的程式碼與 AI 驅動的負載正削弱承載它們的平台。未來的方向必須回歸基礎：效率、可靠性，以及對使用者資源的尊重。

Sources