重點摘要
微軟把「AI 採用率 KPI」悄悄寫進了你的 commit,影響 GitHub 上四百萬筆歷史記錄
VS Code 1.118 預設對所有 commit 插入 Copilot 歸因標籤,即使使用者明確停用 AI 功能仍無法阻止,引發版控誠信疑慮。
標籤寫入 git commit trailer,不顯示於提交前編輯畫面;企業合規「AI 內容低於 30%」門檻可能因假歸因在數據層面直接失效。
此事件已成「預設值即政治」的標誌性案例,暴露廠商 KPI 需求與開發者版控信任之間的結構性張力。
前情提要
事件始末:VS Code 如何在未使用 Copilot 時仍插入歸因
2026 年 4 月 16 日,微軟開發者 cwebster-99 提交 PR #310226,將 VS Code 設定 git.addAICoAuthor 的 schema 預設值從 "off" 靜默改為 "all",由 dmitrivMS 合併進主線。此變更直到 4 月 28 日 Issue #313064 出現大量使用者回報後,才引起外界廣泛關注。
問題的技術根源在於兩處設定不一致:package.json 中的 schema 宣告預設為 "all",但 repository.ts 執行期的 fallback 仍殘留 "off",導致實際行為難以預期。更嚴重的是,即使使用者在 UI 明確啟用 disableAIFeatures: true,歸因標籤仍會被寫入 git commit trailer。
Trailer 不顯示在一般的提交訊息編輯畫面中,開發者在按下送出前毫無察覺機會。VS Code 1.118 於 4 月 29 日正式發布後,此行為迅速觸及大量使用者,GitHub 上隨之出現約四百萬筆帶有 Co-authored-by: Copilot <copilot@github.com> 尾行的 commit,其中絕大多數並未實際使用過 Copilot 的任何建議。
企業 KPI 驅動下的「被迫採用」現象
HN 用戶 bg24 在討論串中直言:自己曾身處完全相同的情境——管理層要求看到 AI 採用率的 KPI,而插入 commit 歸因,恰好是最容易被量化與計算的那個數字。這番話在科技社群引發強烈共鳴。
名詞解釋
KPI(關鍵績效指標):企業用來衡量目標達成程度的可量化指標。在此情境中,「Copilot 歸因出現在 commit 中的次數」被當作「AI 工具採用率」的代理指標,但這一替代測量方式本身存在根本性缺陷。
bg24 同時指出,「病毒傳播性」是另一個誘因:當一個功能能讓 Copilot 標記出現在越來越多的 commit 中,這份可見度本身就能製造採用率快速增長的假象。Alex Yumashev 在 X 上直言:「微軟就因為我裝了 Copilot 擴充套件,把廣告塞進了我的 commit。」
從更宏觀的角度看,這起事件暴露了一種結構性問題:當工具供應商的商業指標需求與開發者的實際體驗之間存在落差,廠商有動機選擇對自身 KPI 最有利的預設值,而非對使用者最透明的選項。
開發者信任與版本控制誠信的底線
Git 的 commit 歷史在許多組織中具有法律與審計意義——它是記錄「誰做了什麼、何時做的」的不可篡改帳本。在未實際使用 AI 輔助的情況下,強制附加 AI 歸因標籤,不僅是資訊不準確,更可能影響程式碼所有權的判定。
美國版權局在 Thaler v. Perlmutter 案中再次確認非人類實體不具版權保護資格。部分企業已訂出「AI 生成內容不超過單一檔案 30%」的合規門檻,以規避著作權爭議。然而,若 Copilot 歸因在未真正使用的情況下自動寫入,合規審計工具將無法分辨「形式歸因」與「實質使用」,這道防線在數據層面直接失效。
Issue #313064 中的回報者寫道:「我沒有用 Copilot 編輯原始碼或 commit 訊息,但這行字就這樣出現了——是在沒有我同意的情況下。」這句話觸及了版本控制作為信任基礎設施的核心:若使用者無法相信自己的 commit 記錄反映真實狀態,整個協作生態的信任前提就會動搖。
Microsoft 的回應與開源社群的反撲
2026 年 5 月 2 日,dmitrivMS 正式回應,承認兩個根本問題:停用 AI 功能時不應啟用歸因;未由 AI 實際修改的變更不應加上歸屬標籤。他承諾在版本 1.119 中修復,並將預設值回歸 "off"。
在此之前,PR #312880 已於五天前提交,將預設值從 "all" 降為 "chatAndAgent",作為過渡緩解措施。然而社群並不買帳:Issue #313064 的 PR 累積了超過 353 個反對票,仍未被鎖定討論。p-e-w 的評論直接點出了問題核心:「有些錯誤實在太過嚴重,讓人不得不懷疑背後的意圖——即使後來得到了糾正。」
開源社群的反應則更為激進:部分開發者已轉向 VSCodium(VS Code 的去遙測分支),或改用純命令列的 git 工作流,以規避任何形式的隱性注入。這場事件已成為開發者社群討論「預設值即政治」的標誌性案例。
多元觀點
正方立場
支持 Copilot 歸因的一方認為,AI 工具的使用透明度本身是有價值的。
隨著越來越多開發者在日常工作中使用 AI 輔助,自動記錄 AI 參與程度有助於團隊了解技術棧的實際構成,也為企業提供真實的 AI 採用率數據,而非依賴開發者自主填報。
從長期看,建立 AI 歸因標準可以形成產業規範,讓程式碼審計和合規工作更具可追溯性。支持者認為問題不在於「要不要記錄」,而在於「如何取得知情同意」——修復實作 bug 後,此功能方向仍有其合理性。
反方立場
反對方的核心論點是:沒有真實使用就沒有歸因的正當性。
Git commit history 是一份法律文件等級的記錄,在未獲使用者同意的情況下寫入虛假歸因,是對版本控制誠信的根本性破壞。更值得警惕的是,即使明確停用 AI 功能 (disableAIFeatures: true) ,標籤仍被插入——這說明此行為並非疏忽,而是刻意設計。
bg24 的坦白揭示了背後的商業邏輯:插入歸因最終服務的是微軟的 KPI,而非開發者的利益。用誤導性數據建立的採用率指標,對企業決策者和監管機構都是一種欺騙,且可能使企業合規的「AI 內容比例門檻」在審計層面完全失去意義。
中立/務實觀點
務實的立場認為,AI 歸因作為功能本身並無原罪,問題完全出在實作選擇上。
若 git.addAICoAuthor 預設為 "off",使用者主動開啟後才觸發歸因,整個爭議根本不會發生。Trailer 格式的不可見性、與停用 AI 設定的衝突、schema 與 runtime 的不一致——這三個實作問題疊加,才造成如此大規模的信任損傷。
從產品設計角度,此事件是「透明度優先原則」被商業指標壓制的典型案例,也提醒開發者工具的每一個預設值都需要經過倫理審查,而不只是技術審查。「預設值即政治」這句話,在此案例中得到了最直白的佐證。
實務影響
對開發者的影響
每位使用 VS Code 1.117.0 至 1.118.x 版本的開發者,都應立即在設定中搜尋 git.addAICoAuthor 並手動設為 "off",同時使用 git log --grep='Co-authored-by: Copilot' 掃描既有 commit,確認是否有需要向團隊說明的意外歸因記錄。
對於使用純命令列 git 的開發者,此問題原則上不影響。部分開發者已轉向 VSCodium(去遙測版 VS Code)作為替代方案,但應注意 VSCodium 並非完全等同,部分擴充套件相容性需個別確認。
對團隊/組織的影響
企業工程團隊應盡快在共用的 .vscode/settings.json 中鎖定 "git.addAICoAuthor": "off",防止個別開發者的預設值差異造成 commit 記錄不一致。
對於已訂定「AI 生成內容比例門檻」的企業,應重新評估現有 commit 歷史中的歸因資料是否可信,並在合規審計前先完成說明或清理。法務團隊亦應留意 Thaler v. Perlmutter 案對非人類著作權認定的最新解釋,確認歸因記錄與實際 AI 使用的對應關係。
短期行動建議
- 立即:更新 VS Code 到 1.119(發布後),或手動將
git.addAICoAuthor設為"off" - 本週:通知團隊成員此問題,統一
.vscode/settings.json設定 - 本月:審查 CI 流程,確認 commit 驗證規則能偵測非預期的 Copilot trailer 格式
社會面向
產業結構變化
此事件凸顯了 AI 工具廠商與開發者工具生態之間的權力不對稱:微軟既是 VS Code 的開發者,也是 GitHub Copilot 的銷售方,兩個角色的利益衝突在預設值設計上直接體現。
從更廣泛的趨勢看,「AI 採用率 KPI」正在成為企業技術管理的標配指標,但如何真實量化 AI 工具的使用深度,目前業界並無共識。這次事件將加速討論更嚴謹的 AI 使用追蹤標準,以及誰有權定義「採用」的邊界。
倫理邊界
爭議的倫理核心是:在未取得使用者同意的情況下,修改具有法律意義的記錄是否構成誤導?
Git commit 不只是技術記錄,它在開源授權、企業合規、學術誠信等場景中都承擔著「作者聲明」的角色。自動插入非真實貢獻者的歸因,挑戰的是版本控制系統作為信任基礎設施的根本預設,也迫使業界正視「AI 作者資格」這個尚未有定論的法律問題。
長期趨勢預測
短期內,主要 IDE 和工具廠商將面臨更嚴格的社群審查,任何涉及 commit、程式碼所有權或 AI 使用記錄的預設值變更都需要更高的透明度和明確的使用者授權流程。
中長期,隨著 AI 生成內容在軟體開發中的比例持續上升,「程式碼作者歸因」的定義本身可能需要法律層面的重新框架。這次事件只是序章——開發者工具廠商、法律界與開源社群的三方博弈才剛剛開始。
唱反調
若開發者確實頻繁使用 Copilot 但從未主動記錄,默認歸因可以填補透明度的空白——有助於團隊和企業了解 AI 工具在生產代碼中的實際滲透率,形成更誠實的技術棧揭露。
此次事件的根本問題是實作 bug(schema 與 runtime 設定不一致),而非預設值設計方向本身有誤;修復 bug 後,選擇性開啟的 AI 歸因功能對願意使用 AI 的團隊仍有實際追蹤價值。
社群風向
我曾身處這種情境。主要驅動力是管理層要求看到 AI 採用率的 KPI,而這偏偏是最容易實作的那個數字。病毒傳播性也是一個面向——實作團隊現在應該知道,大多數人不欣賞把 Copilot 插入 commit 訊息,他們的工作是把這個訊息傳達給管理層。
我欣賞你承認這是個錯誤,但正如你自己對他人錯誤的判斷,有些錯誤實在太過嚴重,讓人不得不懷疑背後的意圖——即使後來得到了糾正。在我見過的任何環境中,「默認對每個 commit 加上錯誤歸因而不通知使用者」都會在審查階段被直接拒絕。
如果你覺得 GPL 已經夠麻煩的了,你應該看看 VSCode 現在在搞什麼。
又一個立刻關掉 VS Code 的理由。「我終於知道為什麼我的 commit 突然變成 co-authored by copilot——明明我根本沒在那個 commit 用 copilot,完全不懂這有什麼意義。」我已經改回純命令列 git 了。
HN 永恆的老調:所有糟糕的技術演進都是管理層的錯,工程師是無可指摘的技術純粹主義者。
炒作指數
行動建議
立即在 VS Code 設定中搜尋 git.addAICoAuthor,手動設為 "off";並用 git log --grep='Co-authored-by: Copilot' 掃描既有 commit,確認是否有需向團隊說明的意外歸因。
在團隊共用的 .vscode/settings.json 中鎖定 "git.addAICoAuthor": "off",防止個別開發者的預設值差異造成 commit 記錄不一致,並加入 CI 規則偵測非預期的 Copilot trailer。
追蹤 VS Code 1.119 發布進度與 Issue #313064 的社群後續;關注企業合規政策如何因應 commit 歸因自動化帶來的著作權認定邊界問題。