GitHub Copilot 反彈：開發者嬲在話事權，不是大規模離開 GitHub

Copilot 點解成為火藥桶：由補字變成 repo 治理

反彈不是單純關於 AI code completion 有無用，而是 Copilot 被容許在哪些地方行動。

The Register 報道，過去 12 個月 GitHub Community 最受關注的討論，是要求提供方法阻止 Copilot 在 repo 內生成 issues 同 pull requests ^[8]。同一報道亦指，以 upvotes 計，第二受關注的討論是要求修正用戶無法停用 Copilot code reviews 的問題 ^[8]。

這個分別很重要。AI 在你私人 editor 入面建議幾行 code，是一回事；AI 走入 issue queue、pull request 流程同 review 介面，就變成 repo 治理的一部分。對 maintainer 來說，問題不只是 Copilot 寫得好不好，而是 project owner 能否為自己的社群定規矩 ^[8]。

質素投訴令「自動化」不再顯得無害

部分不滿亦來自可靠性疑慮。GitHub Community 有討論帖包含用戶指稱，VS Code 入面的 Copilot 不可靠，並對其 project 造成損害 ^[9]。這類討論不能當成獨立 benchmark，去代表所有用戶或所有 workflow 的 Copilot 表現；但它有助解釋，為何有開發者不再把不想要的 Copilot 活動視為無傷大雅的自動化 ^[9]。

當一個工具既難以避開，又被部分用戶視為不可靠，爭論重點就會由「生產力」轉到「同意權」。

Agent 可靠性已經是營運問題

GitHub 自己的 status page 顯示，agentic workflow 會令風險提高。2026年4月22日 18:49 至 19:32 UTC，Agent HQ Codex agent 的 Copilot Cloud Agent sessions 未能由多個入口正常啟動，包括 issue assignment 同 @copilot comment mentions ^[7]。GitHub 表示，受影響的是 Copilot Cloud Agent 總 jobs 的 0.5%，約 2,000 個 failed jobs；Copilot 以及其他 agent sessions 未受影響 ^[7]。

這不是整個 GitHub 平台全面倒下。但它說明了另一件事：當團隊把真實工作交由 AI agents 處理，Copilot 的可用性就會變成交付計劃的一部分。如果開發者會把 issues assign 給 agents，或者透過 pull request comments 觸發工作，Copilot availability 就不再只是輔助功能，而是 operational dependency ^[7]。GitHub 的 news page 亦承認近期出現 availability incidents，並表示 outages 會影響客戶 ^[10]。

Microsoft 的 AI 路線改變信任方程式

Business Insider 報道，Microsoft 正重組團隊以加強 GitHub，並計劃為 AI coding 同 agents 改造 GitHub；同時 GitHub 面對 Cursor、Claude Code 等 AI coding 對手 ^[14]。由產品策略角度看，這方向不難理解：repos、pull requests、issues、reviews，本來就是 coding assistants 最自然嵌入的地方。

但文化層面就敏感得多。很多開發者視 GitHub 為共享的軟件基礎設施。當 Copilot 功能令人覺得難以避開，maintainers 可能不再把它看成可選的 productivity tool，而是看成 Microsoft 借 GitHub 的中心位置推動自己的 AI 策略 ^[8][14]。

AI Credits 令界線變成預算問題

GitHub 表示 Copilot 正轉向 usage-based billing；由 6月1日起，Copilot 用量會消耗 GitHub AI Credits ^[10]。這不代表每個團隊都一定要付更多錢。但它代表組織需要清楚知道：Copilot 可以在哪些地方運行、誰可以觸發它，以及 AI 用量如何反映到預算上 ^[10]。

對本身已經不滿 Copilot 出現在共享 repo 空間的團隊來說，metered AI usage 會令 GitHub 的方向更不像「可選助手」，而像一層收費式 AI 功能被織入日常開發流程 ^[8][10]。

不要把所有反平台故事都當成 GitHub 出走

近年不少「開發者重新掌控工具」的故事，容易被放入 GitHub 反彈敘事入面，但未必真的關 GitHub 事。David Heinemeier Hansson 的 HEY profile 介紹他是 37signals 的 co-owner 兼 CTO，也是 Ruby on Rails 的 creator ^[26]。他近期的文章談及 37signals 的 cloud exit，包括收到 20 部 Dell R7625 servers，以及希望離開 cloud complexity 的計劃 ^[17][22]。

這些文章講的是 cloud infrastructure，不是已被記錄的 GitHub departure。這個分別要分清：對大型集中式軟件平台的懷疑可能正在增加，但那不等於有證據顯示開發者正大規模離開 GitHub ^[17][22]。

工程團隊現在應該做甚麼

實際回應不是恐慌，而是把 GitHub 同 Copilot 的假設講清楚、寫清楚。

• 盤點 Copilot 入口位。 檢查 Copilot 可以在哪些地方出現或行動：issues、pull requests、code reviews、comments、issue assignment，以及 @copilot workflows ^[7][8]。
• 訂 repo-level policy。 決定哪些 Copilot 功能可用、受限制，或者不准使用；open-source projects 同有 compliance 要求的 repos 尤其要清晰 ^[8]。
• 6月1日前檢查 AI Credits。 Copilot 用量將會消耗 GitHub AI Credits，engineering、platform 同 finance teams 都應該理解用量如何計算 ^[10]。
• 把 AI-agent incidents 納入營運計劃。 如果 delivery 依賴 issue assignment、pull request comments 或 agent sessions，就要把 Copilot availability 視為 operational dependency ^[7]。
• 保留簡單的人手後備流程。 關鍵 repo 仍然需要清楚的人類 owner、文件化 release procedures，以及 automation 失效時的 recovery path。

結論

「開發者正大規模拋棄 GitHub」這個講法，未有足夠證據支持。更有力的結論是：GitHub 正面對信任問題。Copilot 正進入共享開發流程；Microsoft 據報正圍繞 AI coding 同 agents 重組 GitHub；當 agents 開始做真實工作，可靠性事故的後果更大；而 usage-based AI billing 亦即將到來 ^{[7][8][10][14]}。

GitHub 仍然重要。真正未解的問題是：當它變成一個更進取的 AI 平台，開發者會要求拿回幾多控制權？