GitHub 仍是軟體開發世界的核心基礎設施之一。《Business Insider》稱它是領先的軟體開發平台，Microsoft 於 2018 年收購 GitHub [14]。因此，這波爭議不宜簡化成「GitHub 要完了」。更準確的說法是：GitHub 的信任存款正在被消耗。
過去，Copilot 多半被理解為編輯器裡的 AI 程式碼補完工具；你要用就開，不想用就關。但現在爭議的焦點已經移到儲存庫工作流：issue、pull request（PR）、code review、留言、agent 觸發等場景。這些地方不只是個人工具，而是專案協作與治理的現場。對維護者來說，問題不是「AI 會不會寫程式」，而是「誰有權決定它能不能在我的專案裡動作」[7][
8]。
現有證據顯示的是怒氣，不是已證實的出走潮
目前公開報導較能支持「開發者很不滿」這件事，而不是「GitHub 正被大規模拋棄」。
科技媒體《The Register》報導，所謂「無法避開的 AI」功能，讓部分開發者開始考慮其他程式碼託管選項；尤其是維護者希望能阻擋或停用 Copilot 在儲存庫內的行為 [8]。Slashdot 轉述同一波爭議時，也提到一項說法：GitHub 從 Microsoft 旗下相對獨立的子公司，轉入 Microsoft 的 CoreAI 團隊後，似乎讓部分開源社群成員從抱怨 Copilot，轉向更積極地離開 GitHub [
1]。
這些都是警訊，但還不是「大規模逃離」的證明。現有資料沒有提供遷移總量、企業客戶流失數據，也沒有足夠的儲存庫層級證據顯示 GitHub 的地位已實質崩塌。比較穩妥的結論是：隨著 Microsoft 把 AI 更深地嵌入 GitHub，開發者正在重新評估自己願意把多少未受限制的信任交給這個平台 [8][
14]。
Copilot 為何成為引爆點？
這波反彈不是單純反對 AI 補完，也不是否認 AI 工具可能提高效率。真正敏感的是 Copilot 被允許出現與行動的位置。
《The Register》報導，在過去 12 個月，GitHub Community 最受關注的討論，是要求提供方法，阻止 Copilot 在儲存庫中產生 issue 與 pull request [8]。同篇報導也指出，以 upvote 衡量，第二受關注的討論是一則 bug report，要求修正使用者無法停用 Copilot code review 的問題 [
8]。
這個差別很重要。AI 在個人編輯器裡建議一段程式碼，和 AI 出現在 issue queue、PR 流程與 review 介面，是兩種完全不同的權力關係。後者等於進入了專案的公共空間。對維護者而言，核心問題不只是 Copilot 產出的品質，而是專案擁有者能不能為自己的社群設定規則 [8]。
品質抱怨讓「不請自來」的自動化更難被接受
部分不滿也來自使用者對可靠性的質疑。GitHub Community 有討論串指稱，VS Code 裡的 Copilot 不可靠，甚至對專案造成損害 [9]。這類討論不能當成 Copilot 在所有使用者、所有工作流中的客觀品質基準；但它能說明，為什麼一些開發者不再把不想要的 Copilot 行為視為無傷大雅的自動化 [
9]。
當一個工具既難以迴避，又被部分使用者認為不穩定時，爭論就會從「能不能提升生產力」轉向「使用者是否同意」。
AI agent 的可靠性，已經變成營運問題
GitHub 自己的狀態頁也顯示，agentic workflow 會把風險放大。GitHub Status 記錄，2026 年 4 月 22 日 18:49 至 19:32（UTC，協調世界時），Agent HQ Codex agent 的 Copilot Cloud Agent session 無法從 issue assignment 與 @copilot 留言提及等入口啟動 [7]。GitHub 表示，受影響的是 Copilot Cloud Agent 總工作量的 0.5%，約 2,000 個失敗工作；Copilot 以及其他 agent session 未受影響 [
7]。
這不是整個 GitHub 平台崩潰。但它說明了一件事：一旦團隊把實際工作交給 AI agent，AI 的可用性就會進入交付規劃。若開發者會把 issue 指派給 agent，或透過 PR 留言觸發工作，Copilot 的穩定度就不再只是「工具體驗」，而是專案流程的相依條件 [7]。GitHub 的 news 頁面也承認近期曾發生可用性事件，並表示停機會影響客戶 [
10]。
Microsoft 的 AI 路線，改變了信任公式
《Business Insider》報導，Microsoft 正在重整團隊以強化 GitHub，並讓 GitHub 朝 AI coding 與 agent 方向改造；GitHub 也面對 Cursor、Claude Code 等 AI coding 競爭者 [14]。從產品策略來看，這個方向並不難理解：repository、PR、issue、review 本來就是程式開發流程中最自然的 AI 助手入口。
但在文化上，這件事更敏感。許多開發者把 GitHub 視為共享的軟體基礎設施，而不只是 Microsoft 的一款產品。當 Copilot 功能讓人感到難以避開，維護者可能就不會把它看成「可選的生產力工具」，而會理解成 Microsoft 正利用 GitHub 的核心位置，推動自己的 AI 策略 [8][
14]。
AI Credits 讓邊界問題也變成預算問題
GitHub 表示 Copilot 將轉向依使用量計費，且自 6 月 1 日起，Copilot 使用量會消耗 GitHub AI Credits [10]。這不代表每個團隊都一定會付更多錢；但它確實意味著組織需要弄清楚 Copilot 能在哪些地方執行、誰能觸發、以及 AI 使用量如何對應到預算 [
10]。
對於已經不滿 Copilot 進入共享儲存庫空間的團隊來說，計量式 AI 使用可能讓 GitHub 的方向更不像「可選助手」，而像是被縫進開發流程裡的一層可計費自動化 [8][
10]。
不是每個反平台故事，都是 GitHub 出走證據
更廣泛的「開發者想降低平台依賴」敘事，常被一起放進 GitHub 反彈裡，但兩者不一定相同。David Heinemeier Hansson 的 HEY 個人頁介紹他是 37signals 共同所有人與 CTO，也是 Ruby on Rails 的創造者 [26]。他近期的文章談的是 37signals 的 cloud exit：包括 20 台 Dell R7625 伺服器到貨，以及想擺脫雲端複雜度的計畫 [
17][
22]。
這些文章談的是雲端基礎設施，不是有文件支持的 GitHub 離開案例。這個區別很重要：對大型集中式軟體平台的懷疑可能正在升高，但這不等於開發者正在大規模離開 GitHub [17][
22]。
工程團隊現在該做什麼？
實務上的回應不該是恐慌，而是把 GitHub 與 Copilot 的假設明文化。
- 盤點 Copilot 的入口。 檢查 Copilot 可能出現或行動的位置，包括 issue、PR、code review、留言、issue assignment，以及
@copilot工作流 [7][
8]。
- 制定儲存庫層級政策。 決定哪些 Copilot 功能可用、哪些受限、哪些禁止；開源專案與合規敏感的儲存庫尤其需要清楚規則 [
8]。
- 在 6 月 1 日前檢查 AI Credits。 Copilot 使用量將消耗 GitHub AI Credits，工程、平台與財務團隊都應理解使用量如何計算 [
10]。
- 把 AI agent 事件納入營運規劃。 如果交付流程依賴 issue assignment、PR 留言或 agent session，就應把 Copilot 可用性視為一項營運相依 [
7]。
- 保留簡單的人工作業備援。 關鍵儲存庫仍應有明確的人類負責人、文件化的發布流程，以及自動化失效時的復原路徑。
結論：GitHub 仍重要，但開發者會要求更多控制權
「開發者正在大規模拋棄 GitHub」這個說法，目前沒有足夠證據支持。更強而有力的結論是：GitHub 正面臨信任問題。Copilot 正進入共享開發流程，Microsoft 據報正在圍繞 AI coding 與 agent 重整 GitHub；當 agent 開始承接真實工作，可靠性事件的後果更大；而依使用量計費的 AI Credits 也即將成為開發流程的一部分 [7][
8][
10][
14]。
GitHub 仍然重要。真正的開放問題是：當它變成一個更積極的 AI 平台時，開發者會要求多少控制權才願意繼續信任它。
