VS Code 悄悄把你的功勞分給 Copilot？Git 提交中的 AI 共同作者爭議

想像你在開一個 PR，程式碼是自己一行一行寫的，debug 時也沒問過 Copilot，結果打開 Git log 一看——每筆 commit 後面都多了「Co-authored-by: Copilot」。你愣了一下，心想：我什麼時候同意過？

這不是科幻情節。就在上週，微軟 VS Code 團隊提交了一個 PR（#310226），要把 git.addAICoAuthor 設定從預設「關閉」改為「全部開啟」。意思是：只要你用了 VS Code，Git 就會自動在 commit 訊息尾巴加上「Co-authored-by: Copilot」——不管你實際上用了多少 Copilot。這個改動在 HackerNews 上炸了鍋，獲得超過 1300 分、700 多則討論，開發社群的反應從困惑到憤怒都有。

這場風暴是怎麼開始的？

PR 內容：看起來很小的改動

這份 PR 的作者是微軟工程師 cwebster-99，改動內容其實很簡單：把 VS Code Git 擴充套件中的 git.addAICoAuthor 設定值，從預設 "off" 改成 "all"。

根據 PR 描述，這個設定的目的是「當 AI 生成的程式碼貢獻被偵測到時，自動在 commit 中加入 Co-authored-by 標記」。改動本身只涉及一行設定檔的預設值變更，但在開發者社群中掀起了遠超預期的波瀾。

問題在哪裡？

爭議的核心在於：VS Code 怎麼判斷哪些程式碼是 Copilot 貢獻的？

如果開發者使用 Copilot 的自動補完功能寫了一些程式碼，那麼在 commit 中標註 Copilot 的共同作者身份或許合理。但現實中，Copilot 的運作方式遠比「我有用／我沒用」複雜：

1. 補完與修改的模糊界線：Copilot 可能會補完一行簡單的註解或樣板程式碼，這些內容在傳統的工作流程中不會有人認為需要標註「共同作者」。但系統的偵測機制可能會把它認定為 AI 貢獻。

2. 隱形觸發：許多開發者報告，即使在設定中關閉了 Copilot，某些 VS Code 版本的 UI 元素或背景程序仍可能被系統判定為「使用了 AI 輔助功能」。

3. 連鎖效應：一旦啟用了 "all" 預設值，任何被系統認為有 AI 參與的 commit 都會自動加入共同作者標記，開發者甚至不會在 commit 時被明確提示。

社群反應：從困惑到強烈反對

HackerNews 討論串中，開發者的反應大致可以分成幾個陣營。

「這根本是標籤詐欺」

最強烈的反對聲浪來自那些認為「Co-authored-by 標籤應該有意義」的開發者。在 Git 的慣例中，Co-authored-by 表示另一個真人開發者對這段程式碼有實際貢獻——可能是共同開發、code review 後的修改、或是 pair programming 的成果。把這個標籤套用到 AI 身上，某種程度上稀釋了它的意義。

一位 HN 使用者寫道：「如果每次我開 VS Code 寫 hello world 都被標成 Co-authored-by: Copilot，那這個欄位就變成了一個笑話。」

「AI 做了什麼，就該被標註」

另一群人則認為，如果 Copilot 確實貢獻了程式碼，標註它是合理的。問題在於「確實貢獻」的定義不明確——Copilot 的補完功能是以逐字元的方式運作，不像真人開發者會提出設計方案、討論架構、debug 數小時。

「這是個治理問題，不是技術問題」

比較中立的觀點認為，這個爭議真正的問題不在於「要不要標註 AI」，而在於預設值應該是選擇加入（opt-in）還是選擇退出（opt-out）。把預設值設為 "all" 意味著微軟替所有 VS Code 使用者做了決定，而在這個敏感議題上，很多人認為應該反過來——讓使用者自己選擇要不要啟用。

微軟的立場：透明度還是免責聲明？

從 PR 的上下文來看，微軟這次改動的動機可能有兩層。

其一是透明度：隨著 AI 輔助編碼越來越普遍，開源專案和企業團隊可能會想知道哪些程式碼來自 AI。自動標註可以提供這層透明度，幫助維護者理解專案的貢獻結構。

其二是法律與合規考量：這才是最關鍵的部分。如果某段由 Copilot 生成的程式碼日後引發了版權爭議（Copilot 的訓練資料本身就充滿了版權問題），微軟可以主張「我們已經標註了這是 AI 生成的，責任在使用者」。換句話說，這個功能更像是微軟的免責聲明，而不是對開發者的尊重。

這種解讀讓很多開發者感到不舒服。如果一個平台在未經你明確同意的情況下，自動在你的作品上蓋章表示「這部分是 AI 寫的」，而你對這個標籤沒有控制權——這聽起來確實不太對勁。

更深層的問題：AI 輔助的邊界在哪裡？

這場爭議其實反映了一個更大的命題：在 AI 輔助開發的時代，什麼算是「你的程式碼」？

光譜化的程度

現代開發者使用 AI 的方式是一個光譜：

• 極端 A：完全不使用任何 AI 輔助，每一個字元都手打
• 層次 1：使用自動補完（Tab 補完變數名稱、括號配對、常見片語）
• 層次 2：使用 Copilot 等工具生成程式碼片段，然後手動修改
• 層次 3：用 Cursor 或 Claude Code 生成整個函式，僅做小幅調整
• 層次 4：讓 AI Agent 自主完成整個任務（如「建立一個 Express API 路由」）
• 極端 B：完全讓 AI 寫程式，自己只負責驗證

在層次 1 和層次 2 之間，貢獻的歸屬就開始模糊。自動補完一個 for 迴圈的結構體算不算 Copilot 的貢獻？如果算，那 VS Code 內建的 snippet（程式碼片段）功能要不要也算貢獻？

客觀標準的困難

目前沒有任何技術能精確區分「開發者自己寫的程式碼」與「AI 輔助產生的程式碼」。Copilot 的運作機制是根據上下文推測下一個 token，而不是記錄「哪些 token 是使用者從建議中選擇的」。這意味著任何「自動偵測 AI 貢獻」的機制，都只能是近似值，甚至可能誤判。

對開發社群的實際影響

開源專案的治理

對於開源專案維護者來說，這個改動帶來了實際的管理難題。如果每個來自 VS Code 使用者的 PR 都帶有「Co-authored-by: Copilot」標記，維護者要如何看待這些貢獻？

有些專案可能不介意，甚至歡迎 AI 輔助貢獻。但有些專案（特別是那些對貢獻品質有嚴格要求的專案）可能不希望在 Git history 中出現大量 AI 共同作者標記。更麻煩的是，如果這個標記會觸發某些專案的 CLA（貢獻者授權協議）檢查或自動化流程，可能導致 PR 合併流程出錯。

企業環境的合規問題

在企業環境中，這個標記可能引發更嚴重的問題。很多企業對 AI 生成程式碼的使用有明確規範——例如，「AI 生成的程式碼必須經過人工審查才能進入正式程式碼庫」。如果 VS Code 自動標註的結果與企業政策衝突，可能會導致合規團隊介入。

更細微的問題是：如果一個 commit 被標註為「Co-authored-by: Copilot」，而該公司的政策禁止將任何 AI 生成程式碼部署到生產環境，那這個 commit 是否會被自動擋在 CI/CD 流程之外？

開發者的應對策略

如果你不希望 VS Code 自動在你的 commit 中加入 AI 共同作者標記，以下是實際的應對方法：

立即行動：關閉功能

在你的 VS Code 設定檔（settings.json）中加入以下設定：

"git.addAICoAuthor": "off"

這會把 AI 共同作者功能完全關閉，即使系統偵測到 AI 貢獻也不會加入標記。

如果你希望保留這個功能但只在特定情況下啟用，可以改成：

"git.addAICoAuthor": "detected"

這個設定只會在系統明確偵測到大量 AI 貢獻時才加入標記，而不是無差別地全部標註。

中長期策略：注意你的工具預設值

這次事件提醒了我們一個重要的教訓：永遠不要信任工具的預設值。VS Code 的 git.addAICoAuthor 只是冰山一角。以下是檢查你開發環境中類似設定的建議清單：

1. VS Code 使用者設定：定期檢查 settings.json，特別是以 git.、editor.、ai. 開頭的設定
2. Git 全域設定：執行 git config --global --list 檢查是否有你沒印象的全域設定
3. 擴充套件權限：檢查已安裝擴充套件的權限設定，特別是那些有 AI 功能的
4. IDE 遙測設定：檢查你的 IDE 是否正在傳送使用資料（telemetry data）到雲端

進階技巧：commit hook 檢查

如果你想要更嚴謹的控制，可以透過 Git hook 來自動檢查 commit 訊息中是否有 AI 共同作者標記，並在你不同意的情況下阻止 commit。以下是一個簡單的 pre-commit hook 範例：

#!/bin/bash
# .git/hooks/prepare-commit-msg

COMMIT_MSG_FILE=$1

if grep -q "Co-authored-by: Copilot" "$COMMIT_MSG_FILE"; then
  echo "⚠️  警告：這個 commit 包含 AI 共同作者標記。"
  echo "   如果你不同意，請移除這行後重新 commit。"
  echo "   你也可以在 VS Code 設定中關閉此功能："
  echo "   \"git.addAICoAuthor\": \"off\""
fi

這件事為什麼重要？

你可能會想：「不就是一行 commit 標記嗎，有這麼嚴重？」

是的，因為它觸及了一個更根本的問題：AI 時代的創作歸屬權。

當你使用 AI 輔助寫程式時，功勞歸誰？如果 AI 幫你生了 80% 的程式碼，你是「作者」還是「編輯」？如果 AI 只幫你補了一個分號，它算是「共同作者」嗎？

這些問題沒有標準答案，因為它們涉及的不只是技術，還有倫理、法律和社會慣例。而在這些討論還沒有共識之前，硬體平台（VS Code）擅自預設「是 AI 的功勞」——這對開發者來說，無論從哪個角度看都不太對勁。

更深一層來看，這個事件也反映了一個正在發生的權力轉移：從「開發者決定如何標註自己的程式碼」到「平台替你決定」。寫程式這件事，本來是最個人、最有創造力的活動之一，但隨著 AI 工具滲透進每一個環節，開發者對自己作品的掌控權正在被悄悄侵蝕。

這次的 Copilot 共同作者風波表面上只是一個設定值，但它背後的故事——關於誰有權定義「貢獻」、誰該被標誌為「作者」、平台應該在多大程度上替使用者做決定——這些問題，會隨著 AI 開發工具的普及而變得越來越重要。

就像站在岸邊看著海浪一波波打過來，知道無法阻止它，只能學會如何與它共存。問題是，我們要在什麼時候、用什麼方式、決定哪些是我們可以接受的共處方式。