用得越多、失業越快？GitHub 大改 Copilot 規則：默認拿個人代碼訓練 AI，還搬出 Anthropic 擋槍！

整理 | 褚杏娟

當地時間 3 月 26 日，GitHub 宣布，自 4 月 24 日起，除非用戶主動選擇退出，Copilot Free、Pro 和 Pro+ 用戶與 Copilot 的交互數據將被用于訓練和改進其 AI 模型。此次調整不適用于 Copilot Business 和 Copilot Enterprise 用戶。此外，免費獲得 Copilot Pro 權限的學生和教師不受此次更新影響。

GitHub 強調用戶仍然保有選擇權。對于不希望參與訓練的個人用戶，可以在設置中的 “Privacy（隱私）”選項里手動退出。GitHub 強調會提前 30 天通知用戶，并允許隨時退出。不過，值得注意的是，Free、Pro 和 Pro+ 個人用戶被默認納入了訓練范圍，需要自行設置退出。

被吐槽很難找到的退出設置

被拿去訓練模型的數據

根據 GitHub 的說明，可被用于模型訓練的數據包括：

• 用戶接受或修改后的輸出內容

• 用戶發送給 GitHub Copilot 的輸入內容，包括展示給模型的代碼片段

• 用戶光標位置周圍的代碼上下文

• 用戶編寫的注釋和文檔

• 文件名、代碼倉庫結構以及導航模式

• 用戶與 Copilot 功能的交互，包括 Chat 和行內建議

不過，GitHub 也劃出了一些不會被納入本次項目的數據范圍：

• 來自 Copilot Business、Copilot Enterprise 或企業擁有的代碼倉庫的交互數據

• 在 Copilot 設置中選擇退出模型訓練的用戶的交互數據

• 靜態存儲的 issue、discussion 或私有倉庫內容。

官方特意使用了“靜態存儲”這個說法，是因為當用戶主動使用 Copilot 時，Copilot 確實會處理來自私有倉庫的代碼。這些交互數據是運行服務所必需的，并且除非選擇退出，否則它們可能會被用于模型訓練。

GitHub 明確表示，Business 和 Enterprise 客戶的數據不會用于模型訓練，原因是現有合同明確禁止這樣做；如果某個 GitHub 賬戶屬于付費組織，或者是付費組織的外部協作者，該賬戶的交互數據也會被排除在訓練之外。對此，GitHub 的解釋是，這是合同義務所決定的，并稱自己對保護訓練數據“很有信心”。

GitHub 對這項調整的解釋是，Copilot 的使用量正在快速增長，模型需要更多“真實世界數據”來覆蓋越來越多的編碼場景。

GitHub 稱，過去一年，其已經開始利用微軟員工的交互數據訓練模型，這一做法帶來了明顯改進，包括多種編程語言中的建議采納率提升，“這證明了真實世界的交互數據確實能夠提升模型在更廣泛、更多樣的使用場景中的表現。”

GitHub 強調，AI 輔助開發的未來賴于開發者提供的真實世界交互數據，因此除了微軟員工數據之外，公司也將開始使用 GitHub 員工的交互數據來訓練模型。”

數據共享方面，用于訓練的數據可能會被 GitHub 和微軟內部負責 AI 模型開發的人員訪問，也可能交由簽有合同限制的服務提供商代為處理，但不會賣給第三方，也不會提供給第三方模型廠商用于訓練他們自己的模型。

GitHub：微軟、Anthropic 和 JetBrains 也這樣

GitHub 提到微軟、Anthropic 和 JetBrains 也在采取類似措施，以說明自己并不是孤例。與此同時，GitHub 直接回應了一個尖銳問題：如果真實用戶代碼對模型這么重要，這是否意味著 GitHub 的競爭優勢更多來自現有用戶基礎，而不是更好的研究？

對此，GitHub 的回答是，“目前已有 2600 萬開發者 在使用 Copilot，這提供了極為豐富的使用場景和需求，因此公司希望通過用戶自愿貢獻的交互數據，讓 Copilot 更好地覆蓋多樣化編碼任務。”

除此之外，GitHub 還面臨一個信任層面的老問題。GitHub 專門回應了外界對 Copilot Chat 暴露私有代碼的擔憂。GitHub 的說法是，外界提到的案例涉及第三方收集“曾短暫公開后又轉為私有”的代碼，不屬于 GitHub 主動暴露數據的范疇；對于此次新計劃收集的數據，公司會通過訪問控制、審計日志和自動化過濾來保護，包括過濾 API key、密碼、token 和個人身份信息。

GitHub 的回應，顯然沒有開發者買單。

有用戶直言：“我真的非常討厭這種做法。”

首先，它一上來就給出了具有誤導性的“退出”操作說明。 如果我進入賬戶設置，再點 Copilot，實際上什么都不會發生，只是那個列表項展開而已。我根本沒法像郵件里寫的那樣，在那里“選擇是否允許將你的數據用于 AI 模型訓練”。

其次，真正可以退出的設置項，文字表述和郵件里的說明也對不上。 所以他們就是在故意把人繞暈，賭很多用戶根本找不到這個設置。更離譜的是，它還被放在設置頁面最底部。

第三，我也不清楚，如果我的倉庫里加了協作者，而他們沒有選擇退出，那我的代碼會不會也被拿去用？ 總之，這次政策調整爛透了。也許是時候看看別的 Git 平臺了。我對 GitHub 也算有些經驗，確實該試試別家了。這件事反而成了一個催化劑。

貪婪是沒有盡頭的。

而且這種事情本來就不該默認開啟。 賬戶應該默認是退出狀態，只有在你自己愿意的情況下，才主動打開。

除了退出設置的坑，還有用戶陷入賬戶界定的迷茫中：

我有一個大約 20 人的組織。我們并沒有在組織層級啟用 Copilot；但當我進入 Security Code Quality 時，我卻能使用 Copilot 來生成修復建議。而且正因為它沒有被正式啟用，所以那里也沒有“退出”的選項。 所以我現在想知道，這個功能到底是來自我個人賬號的 Copilot 免費版（因為它并沒有在組織層面啟用），還是說其實存在一個我沒看到的、某種“隱藏的”組織級 Copilot 免費版。我只想弄清楚，我是不是需要去推動所有能訪問這個組織的人都退出這次更新。

“這是我做過最快的退出操作。”“我正在認真考慮因為這件事關閉我的 GitHub 賬號。”“如果有其他替代方案請告訴我，我實在受夠了這種把消費者當成產品對待的做法。”這類聲音充斥整個社區。

https://github.blog/news-insights/company-news/updates-to-github-copilot-interaction-data-usage-policy/

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

OpenClaw 出圈，“養蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發 / 運維流程并形成穩定收益。

針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。