2026 年 4 月底，微軟 VS Code 團隊合併了一個看似平凡的 PR，卻在開發者社群引發了一場不小的風暴。這個 PR 只改了一行程式碼——把一個設定的預設值從 "off" 改成 "all"。但這個設定叫做 git.addAICoAuthor，它的作用是：自動在你每一次 commit 中加上 Co-authored-by: Copilot <copilot@github.com> 的署名。

想像一個場景：你花了一整個下午寫了一段複雜的演算法，過程中 Copilot 只幫你補上了幾個括號和一行註解。但你按下 git commit 之後，Git 紀錄上卻出現了「Copilot 也是共同作者」的紀錄。這個改動，讓許多開發者開始認真思考一個問題——AI 到底應該被當作工具，還是共同作者？

發生了什麼事：一個預設值引發的連鎖反應

事情的起源是 VS Code GitHub 上的一個 Pull Request #310226，由微軟工程師 cwebster-99 提出。PR 的描述非常簡潔：

「This PR changes the Git extension’s git.addAICoAuthor setting so that AI co-author trailers are enabled by default.」

具體來說，改動只涉及 extensions/git/package.json 這一行：

"default": "off"  →  "default": "all"

這個設定早在 2025 年就存在於 VS Code 中，原本預設關閉，使用者可以手動開啟。當偵測到 commit 內容包含 AI 生成的程式碼時，VS Code 會自動在 commit message 尾部追加 Co-authored-by: Copilot <copilot@github.com>。

微軟將這個功能定位為「自動標記 AI 貢獻」，用意是讓開發者明確記錄哪些程式碼是 AI 輔助完成的。從專案管理的角度來看，這個出發點或許是好的——AI 生成程式碼的透明度確實是開發社群關注的議題。

但問題在於「預設開啟」這件事。對許多開發者來說，這代表微軟在沒有告知的情況下，替他們做了選擇。

開發者的兩大擔憂

在 HackerNews 的討論中，開發者的反彈主要集中在兩個層面。

第一是 隱私與紀錄的完整性。很多開發者不希望自己的 commit history 被「Copilot 共同作者」的標籤佔滿。這不是因為他們不喜歡 Copilot，而是因為並非每一次使用 Copilot 都是「有意義的共同創作」。有時 Copilot 只是完成了 auto-complete——補上變數名稱、關閉括號、或是自動完成一行 getter。這些動作在傳統編輯器中也會由 IntelliSense 完成，只是 Copilot 更聰明一些。把這些等同於「共同作者」顯然太過頭了。

第二是 對開源專案的潛在影響。對開源維護者來說，這個改動可能帶來更實際的困擾。Git 的 commit 紀錄不僅是版本控制工具，也是法律文件——它記錄了誰貢獻了什麼程式碼。如果每個 commit 都自動加上 AI 署名，那麼專案的貢獻者清單將被 AI 名義稀釋，這對實際的人類貢獻者是否公平？

更進一步說，有些開源專案使用 Signed-off-by 和 Co-authored-by 來管理貢獻者授權（DCO）。如果 AI 被列為共同作者，這個機制的價值就會被模糊化——AI 無法提供法律授權，但它的名字卻出現在了授權鏈中。

Copilot 的「貢獻」到底該如何計算？

這個問題的核心在於：AI 的輔助程度要達到多少，才算「共同作者」？

目前 VS Code 的判斷機制相當寬鬆——只要 Copilot 有提供過建議（即使開發者沒有採納），相關的檔案變更就可能被標記為 AI 相關。在實際使用中，這代表：

對於一個專業開發者來說，這就像你的同事只是經過你的螢幕看了一眼，就被列為論文的共同作者一樣荒謬。

Git 社群過去對於 commit 署名有一個不成文的默契：Co-authored-by 應該用於「實際參與了程式碼創作」的人（或團隊）。Copilot 的參與模式更接近於「智慧型輸入法」而不是「共同開發者」。

微軟的立場：透明度的雙面刃

從微軟的角度來看，這個改動有其邏輯。隨著 AI 生成程式碼在企業專案中的比例越來越高，法規遵循和智慧財產權管理的壓力也越來越大。GitHub 在 2025 年就開始要求一些企業客戶明確標記 AI 生成內容，以便進行合規稽核。將這個功能預設開啟，可以確保無論開發者有沒有主動開啟，企業都能獲得完整的 AI 使用紀錄。

但問題在於，微軟的解決方案是一種「一刀切」的做法。它沒有區分「AI 輔助修改一個字元」和「AI 生成整個函式的程式碼」，而是把所有使用 Copilot 的情境都標為「共同作者」。

更有開發者指出，這個機制的觸發條件並不透明——開發者無法準確知道什麼時候會觸發「AI detected」的條件，也無法在 commit 前預覽是否會被加上署名。這就像在簽合約時才發現對方已經在條款裡加了一行你沒注意到的小字。

開發者的應對方式

如果你不希望自己的 commit 被自動加上 Copilot 署名，目前有幾種處理方式：

方法一：直接關閉設定（最簡單）
在 VS Code 的 settings.json 中加入：

"git.addAICoAuthor": "off"

這會完全停用 AI 共同作者功能，無論 Copilot 是否參與都一樣。

方法二：選擇性啟用
如果你希望在某些專案中啟用這個功能，可以在工作區設定（.vscode/settings.json）中控制：

"git.addAICoAuthor": "all"  // 永遠啟用
"git.addAICoAuthor": "detected"  // 僅在偵測到 AI 貢獻時啟用

方法三：使用 Git hooks 過濾
更進階的開發者可以撰寫一個 pre-commit hook，自動移除 Co-authored-by: Copilot 行。在 .git/hooks/pre-commit 中加入：

#!/bin/sh
git diff --cached --name-only | while read file; do
    sed -i '/^Co-authored-by: Copilot <copilot@github.com>$/d' "$file"
done

方法四：社群反饋
截至 2026 年 5 月，這個 PR 已經被合併到 VS Code 的主分支。如果你反對這個預設行為，可以到 該 PR 的討論頁面 表達意見，或追蹤 VS Code 的 issue tracker 看後續是否會加入選擇性選項。

這不只是 VS Code 的問題

VS Code 這個案例其實反映了整個開發工具產業當前面臨的共同挑戰：AI 整合的程度越深，使用者的控制權就越容易被侵蝕。

我們已經見證過類似的情況：GitHub Copilot 在 2024 年開始強制安裝依賴、JetBrains AI Assistant 在更新後自動開啟了程式碼分析功能、Cursor 引入了無法關閉的上下文收集機制。每一次都是「為了提供更好的體驗」，但每一次也都讓開發者對自己的開發環境失去了部分掌控。

這不是一個簡單的是非題。AI 輔助開發確實需要某種程度的透明度和標記機制，但這種機制應該由開發者主動選擇啟用，而不是被工具預設強制執行。

從另一個角度來看，這個事件也暴露了另一個更根本的問題：我們還沒有一套公認的「AI 共同作者」標準。什麼程度的 AI 參與算「貢獻」？AI 的貢獻該如何量化？AI 如果被列為共同作者，它的法律地位是什麼？這些問題不僅影響 VS Code 的設定預設值，也關乎整個開源社群的運作規範。

你會關掉它嗎？

截至今天，VS Code 的這個 PR 已經合併，預設開啟的版本預計會隨下一次更新推送給所有使用者。對大多數開發者來說，你可能根本不會注意到這個改變——除非你養成了習慣，每次 git log 時都會檢查 commit 的詳細內容。

但如果你在意這件事，現在就可以決定：要在幾秒鐘內把設定關掉，還是接受這個「AI 共同作者」的新常態？無論如何，至少先知道你的工具替你做了這個選擇。

未來，當你在深夜提交那一個修復了三天 bug 的 commit，卻看到 Co-authored-by: Copilot 出現在你名字下方時，你會記得你曾經有過這個選擇。

這不僅僅是一個關於預設值的爭論，而是一個關於開發者自主權的問題——在你的開發流程中，誰能有最後決定權？