背景

這篇文章介紹了一款針對 GitHub 開發的瀏覽器擴充功能，旨在解決 Pull Request（PR）中 AI 生成程式碼的歸屬問題。隨著 Copilot 或 Cursor 等工具普及，人類與 AI 的協作變得極度交織，傳統的 Git Blame 難以區分哪些行數是由機器生成、哪些是由人類撰寫。該工具透過 Git Notes 儲存元數據，在不污染提交歷史的前提下，讓團隊在審查 PR 時能清楚看見 AI 的貢獻比例與具體內容。

社群觀點

針對這項工具的必要性，Hacker News 社群展開了激烈的辯論。反對者認為，最簡單的解決方案是為 AI 配置獨立的帳號或電子郵件，直接利用現有的 Git 工具鏈進行追蹤，而不需要額外的插件。然而，開發者 rbbydotdev 回應指出，現代 AI 協作往往是行間的即時補全或局部重構，若要為此頻繁切換提交者身分，會產生大量瑣碎且具干擾性的提交紀錄，尤其在進行 Squashed Commit 後，這些細微的歸屬資訊將徹底消失。因此，在行級別（per-line basis）進行標記，才能真正反映出人類與機器交織的開發實況。

關於「透明度」的討論是另一個焦點。支持者認為，AI 產出的程式碼往往具有「看似合理但邏輯謬誤」的特性，這種高品質的表象容易讓審查者掉以輕心。透過標註 AI 貢獻，可以提醒審查者對特定區塊進行更深度的檢查，防止「AI 垃圾」積少成多導致系統崩潰。部分留言者更直言，提交未經審查的 AI 程式碼是對團隊的不尊重，開發者應主動提供提示詞（Prompt）或 AI 的思考邏輯作為上下文，而非僅僅丟出結果。

然而，另一派觀點則對此持懷疑態度，認為這類工具可能演變成一種「意識形態的棍棒」。反對者主張，程式碼的最終所有權與責任應始終歸屬於提交的人類開發者，無論該程式碼是 AI 生成、參考 StackOverflow 還是由猴子敲出來的，重點應放在程式碼是否正確解決問題，而非其來源。他們擔心這種標註會引發針對 AI 使用者的偏見或不必要的挑剔，甚至認為在 Git 歷史中塞入這些資訊純屬噪音。

此外，社群也觸及了技術實作與未來趨勢的討論。有人建議將這類資訊放入 Commit Message 的 Trailer 區段（如 Co-authored-by），使其成為版本庫歷史的一部分，而非依賴外部插件。也有人指出，隨著 AI 生成速度遠超人類審查能力，這種「不對稱性」才是真正的危機。儘管有人懷疑這類工具的實用價值，但開發者強調，這是一場關於透明度的實驗，旨在幫助團隊在風險承受度與開發效率之間取得平衡，而非為了推卸責任。

延伸閱讀

在討論中，參與者提到了幾款具有類似功能或相關理念的工具與專案：

• Aider / CECLI：被提及具備類似的 AI 貢獻追蹤功能。
• GitLens：部分使用者提到其版本中也曾嘗試過類似的歸屬顯示功能。
• Sandal：由社群成員分享的相關工具，可用於處理類似的開發流程。
• Refined GitHub with AI PR：本討論的核心專案，可在 GitHub 上找到其原始碼。