小編精選 - 技術文章翻譯 · 04月27日

為什麼 GitHub Copilot 要收集你的資料，也是 AI 訂閱以前便宜的原因

============================================

你知道什麼是資料標註嗎？這是一篇科普內容。

相信大家都收到通知，從 4 月 24 日起，Copilot Free、Pro 和 Pro+ 使用者的互動資料：包括你輸入的程式碼、模型的輸出、游標周圍的程式碼上下文、你寫的註解和文件、檔名、儲存庫結構、導覽模式，預設都會被用來訓練 GitHub 的 AI 模型。

重點是，雖然資料不會分享給第三方 AI 提供商，但會分享給 GitHub 關聯公司（也就是微軟）。這其實也可以看出，AI 時代資料的重要性，特別是持續更新中的資料的重要性。

而在大家討論這個行為的時候，不少人也提出類似疑問：
“GitHub 上不是已經有最大的開源程式碼嗎？為什麼還不夠？為什麼還非要使用者資料？而且為什麼 GitHub 似乎連自己的模型也沒做好？”

這個問題其實沒有那麼直觀，因為對 AI 來說，單純只有「結果」是不夠的，真正有價值的資料，往往還需要帶著上下文、過程、回饋和結果的完整鏈路資料。

你需要了解，什麼是值錢的資料，也就能了解，程式碼的資料標註是什麼。

GitHub 有很多開源專案，這些程式碼很重要，而且非常重要。如果沒有這些公開程式碼，程式大模型不可能有現在這個水準，比如 Cursor 在 Composer 2 報告裡也提到過：

程式碼是大模型訓練裡最重要的一類資料來源，但 Cursor 也強調過，真正面向「軟體工程」 Agent 的模型訓練，不能只停留在靜態程式碼上，而要盡量貼近真實使用者任務、程式碼庫、工具呼叫和真實執行環境。

換句話說，開源程式碼能告訴模型「軟體長什麼樣」，但只有使用者的互動資料，才能告訴模型「軟體是怎麼一步一步被寫出來、怎麼被修改、驗證，再被接受或否決」。在鏈路層面，單純的結果資料是不夠的。

可以用一個最簡單的例子來類比，比如現在你看到一道選擇題，最後答案是 C，但你不知道題目是什麼，也不知道為什麼是 C，更不知道 A、B、D 為什麼不對，那這個「C」對你有多大幫助？

只有答案的幫助很有限，因為你下次遇到類似問題時，依然不知道該怎麼判斷；甚至就算把原題再擺到你面前，AI 也不一定能認得出來。因為真正有價值的資料，通常至少應該包含這幾個部分：

題目是什麼
解題過程是什麼
有沒有不同解法
最後答案是什麼
這個答案最後有沒有被驗證通過

寫程式也是一樣，一個公開 repo 裡最終呈現出來的往往是「最後版本的程式碼」，它像是考試的最終答卷，但中間缺了很多關鍵資訊：

使用者最開始想解決什麼問題
這個問題是怎麼描述的
模型第一次給了什麼方案
哪一步寫錯了
使用者改了哪裡
哪個方案被接受，哪個被拒絕
為什麼這個 patch 被保留，另一個被刪掉
這個改動最後有沒有通過測試
使用者究竟是要「能跑」，還是要「可維護」，還是要「符合專案風格」

這些資訊，恰恰才是把模型從「會補全程式碼」進化到「會解決真實問題」的關鍵，也是資料標註的關鍵。GitHub 這次的協議更新，其實也講得很直白：

他們希望取得的，不只是輸入輸出本身，還包括程式碼上下文、游標附近的環境、註解和文件、檔名、儲存庫結構、導覽模式，以及使用者對建議的回饋，因為他們看到了「使用微軟內部真實互動資料」後帶來的效能提升，並認為真實世界互動資料有助於模型更好理解開發流程。

所以對平台來說，重要的不只是程式碼資料的多少，他們想拿到的是「人在真實開發過程中，如何與 AI 協作」的過程資料。

這其實也是 Cursor 最值錢的部分。這次 SpaceX 給 Cursor 的估值和合作，不是因為它現在的產品形態有什麼特別；現在的 Cursor 3 形態和 Codex app、Claude Code Desktop、Trae solo 沒什麼區別，支撐它 600 億估值的，更多是它的這些使用者和資料，而這些資料也可以幫助 xAI 進一步提升：

其實 Cursor 也意識到 IDE 場景已經保不住了，所以 Cursor 3 才會轉換成新的形態，同時開始力推自己的大模型。

所以「資料」不只是程式碼，它在鏈路上可以分為四種場景：

靜態結果資料，也就是 GitHub 的程式碼、issue、文件等，它解決的是「知識」和「分佈」的問題：
- 常見 API 怎麼寫
- 專案結構通常怎麼組織
- 某類功能最終長什麼樣
- 常見編碼風格和模式是什麼
指令／回應資料，比如使用者提一個需求，然後模型給出一段程式碼或解釋，它能把「問題」和「回答」連起來
多軌跡資料，在「指令／回應資料」基礎上增加了行動軌跡，比如搜尋、開啟、閱讀、修改、執行、報錯、修復、執行、測試、成功、patch，它是模型在複雜任務裡的行動軌跡。因為真正強的程式 Agent，訓練核心不只是「程式碼語料」，而是「任務—環境—動作—回饋—結果」這樣的閉環
偏好／回饋資料，比如使用者接受了哪個建議、修改了哪個建議、直接拒絕了哪個建議。這類資料的價值在於讓模型學會什麼叫「對」、什麼叫「更好」、什麼叫「更像真實開發者會接受的結果」

而實際上，「過程資料」一直都比「最終結果」更貴，因為「過程資料」更接近「可學習的推理鏈路」：

模型需要看到任務是如何被拆解、決策、試錯、修正並最終完成。

例如一個真實的程式問題，模型並不是簡單產出一段最終程式碼，而是需要學會：

先理解需求
判斷應該改哪個檔案
發現可能影響哪些依賴
知道先查哪裡
知道什麼時候該讀測試
知道什麼時候應該執行命令驗證
發現錯誤後如何回滾或修正
在多個解法之間做取捨

這類東西，只看「最後 commit 長什麼樣」是學不出來的，至少學不完整。例如 OpenAI 在關於 chain-of-thought monitorability 和 reasoning model monitoring 的研究裡就反覆強調過：

推理模型的自然語言思考過程、行動鏈路與中間軌跡，往往就攜帶了各種關鍵資訊；而如果只看最終結果，很多行為就會變得無法監控，所以過程資訊反而能更有效暴露模型真實意圖。

所以，這也是為什麼會有那麼多「資料標註」和「資料清洗」的業務存在，因為現實世界的資料，絕大多數都不是天然可訓練的狀態，例如：

雜訊非常多，真實開發中有大量無效互動，比如試探性提問、情緒化輸入、拼寫錯誤，或是模型其實寫對了但使用者自己沒看懂
鏈路不完整，比如使用者問了，模型也回答了，但是使用者最後沒有後續操作
不同層級的資料要重新歸類，比如這段程式碼，是面對 Bug 修復還是 API 重構，是安全修復還是效能優化，如果不做清洗和歸類，這些資料會混在一起，模型學到的東西就會變得很雜
樣本需要重新整理，需要「把原始互動洗成可訓練資料」，這很好理解，資料只有洗成全鏈路的結構化模式，才能被模型直接使用

這也是為什麼現在很多頂級程式產品，它們的壁壘已經不只是底層模型，而是資料閉環。比如 Cursor 在 Composer 2，雖然基於 Kimi 基座，但是因為有了更多豐富完整資料，所以它可以對 Agent 進行更多針對性優化，能做到從「會寫程式」升級到「更懂真實的軟體工程工作流程」：

一個模型能不能在特定場景裡變強，很大程度上取決於有沒有足夠好的領域鏈路資料去做後訓練。

所以，AI 時代真正有價值的不是孤立的程式碼，而是帶上下文、帶過程、帶回饋、帶結果的完整資料鏈路，而 GitHub 其實也一直有在做自己的模型。

GitHub 目前也有 Raptor Mini 模型，目前的說法是基於 GPT-5 mini 深度微調的輕量級模型，所以想要調好這個模型，讓 Raptor Mini 比 GPT-5 mini 更好用，也需要這樣的鏈路資料。

最後有一點，資料不是一直等價值錢，而是非常依賴時間窗口。

資料不是一直值錢的，而是在特定時候才是最值錢的。比如 Claude Opus 4.6 剛發布那會兒，如果能及時收集到大量相關資料，那就是最值錢的資料。尤其是在大模型快速迭代的時代，資料的價值有明顯的「時間溢價」。

例如，新一代強模型剛發布的時候，比如某個新的推理模型、程式模型或者 Agent 模型上線的那段時間，如果你能第一時間收集到大量真實使用者互動資料，那這些資料的價值會遠遠高於平時。

原因很簡單，因為模型剛發布時，一般會有幾個特徵：

能力剛提升，但還沒有被充分對齊
行為還不穩定
在真實場景中會暴露大量邊界情況
使用者會嘗試各種新玩法
提示詞、工具用法、工作流程都在快速演化

這個時候通常是模型表現最好的時候，因為模型廠需要真實資料；而後續因為成本和資料滿足了之後，就會開始慢慢拉閘，離譜的時候可能還不到巔峰期的 60%。

另外，模型剛出來的時候，產生的資料資訊密度是最高的；而等到模型成熟之後，再收集同樣類型的資料，價值就會低很多。當模型穩定後，這些資料對模型來說，價值就會低很多。

因為模型成熟之後，使用者行為會趨於穩定，大家會逐漸形成固定用法；這時候產生的資料雖然更多，但資訊增量更小，所以資料並不是一直值錢。

所以雖然一直說中轉平台會賣使用者資料，但使用者資料的時效性和洗資料等成本，一般來說普通中轉平台的量級和有效期都不夠。最多就是可能存在一些資訊洩露，除非中轉平台使用者量很大，並且具備及時更新和完善的洗資料流程，至少也是 OpenRouter 的級別，這時候的使用者資料才有價值體現。

當然，實際上這也是風險點，你不能保證你丟給 AI 的東西就是隱私的。比如最近就出現了類似問題，莫名其妙一個使用者的履歷資訊出現在了另一個使用者的對話，被 AI 幻覺吐了出來，也不知道是 Agent 的 session 混亂還是模型意識問題，反正資料只要上去了，就存在隱私風險，你不能 100% 要求平台沒 bug。