GitHub Copilot 被爆在 PR 偷塞「提示/廣告」:Hidden HTML 爭議、11K PR 受影響與平台信任問題
事件摘要
GitHub Copilot 近期爆出一波爭議:有開發者發現,當 Copilot 協助編輯 Pull Request 描述時,會插入隱藏的 HTML 註解與「提示內容」,其中部分文字被認為帶有推廣 Copilot 與 Raycast 等工具的意味。
這件事之所以引發強烈反彈,不只是因為內容本身,而是因為它出現在 PR 描述 這種開發者高度信任的工作區,而且還透過 hidden HTML 註解包起來。
已知較可靠的事實
根據 Windows Central、Neowin、The Register、TechSpot 等報導:
- 爭議核心字串包含:
START COPILOT CODING AGENT TIPS - Copilot 生成的 PR 內容中,確實出現了隱藏 HTML 註解與提示文案
- 被插入的內容會提到:
- GitHub Copilot 本身
- Raycast
- Jira / Slack / Teams 等整合工作流
- GitHub 後續已把這個功能 / 行為停用或撤回
數字查證:不是 150 萬,較可信的是 1.1 萬左右
Threads 貼文提到「高達 150 萬個案例」,這個數字目前看起來偏誇大。
主流科技媒體比較一致的說法是:
- 搜尋相關字串後,可找到 超過 11,000 個 PR 受到影響
所以比較穩妥的寫法應該是:
至少上萬筆 PR 受影響,而不是直接下結論說 150 萬。
這也是這件事值得注意的地方: 問題真實存在,但社群轉述時有放大數字的傾向。
為什麼工程師會這麼反感
1. PR 是高信任區域
Pull Request 描述不是一般聊天框,而是工程協作流程的一部分。任何自動插入、尤其是看起來像作者本人寫的內容,都會直接影響信任。
2. Hidden HTML 本身就是敏感手法
更諷刺的是,GitHub 官方文件本來就提醒過:
PR 中的 hidden HTML comment 是 prompt injection 的已知媒介。
結果這次爭議內容偏偏也是用 hidden HTML 註解包裝,讓社群覺得踩線非常明顯。
3. 「提示」和「廣告」之間的界線太模糊
如果內容只是產品教學提示,也許還能討論;但一旦牽涉到第三方工具(如 Raycast)與推廣性語句,很多開發者就會把它解讀成:
AI 助手正在開發流程裡偷偷做分發與置入。
這件事真正暴露的問題
這次爭議最值得記下來的,不只是 Copilot 有沒有塞廣告,而是:
1. AI 寫作權限正在滲進正式工作流
從 email、文件、issue,到現在 PR,AI 不再只是輔助聊天,而是在替你產出正式協作文本。這類場景一旦被插入商業訊息,信任成本比一般推薦位高很多。
2. 平台劣化(Enshittification)正在進入 AI 工具層
當工具一開始靠體驗吸引用戶,之後再慢慢把流量、注意力與內容位置商品化,這就是典型的平台劣化劇本。
3. 開發者對「工作區純度」極度敏感
工程師可以接受 sponsor 區塊、marketplace、banner,但很難接受 PR 內文、commit、diff 說明這種核心工作界面被偷偷動手腳。
與隱私條款更新的疊加效應
Threads 文還提到 GitHub 將從 2026/4/24 起,預設把 Copilot 互動內容用於模型訓練,需使用者主動 opt-out。這個方向與近年的 AI 產品策略一致,但若與「PR 偷塞提示」事件放在一起看,會讓開發者更容易產生兩種感受:
- 平台正在變得更侵入
- 使用者需要更主動保護自己的內容與工作流程
也就是說,真正讓人不安的不是單一事件,而是:
產品提示、內容利用、模型訓練、工作流程滲透,開始同時發生。
結論
這起事件不一定足以證明 GitHub Copilot 已經變成「廣告軟體」,但它很清楚地踩到了開發者的信任紅線。
比較準確的結論應該是:
- 事件為真:Copilot 的確在部分 PR 內插入 hidden HTML 與提示內容
- 數字需保守:目前較可信的是 11K+ PR,不是 150 萬
- 影響很大:因為它發生在最不該被污染的工程協作界面
- 長期風險更值得看:平台是否會持續把 AI 助手變成分發、導流與資料回收入口
如果未來類似做法再往 commit message、issue template、code review comment 擴張,反彈只會更大。