背景

這篇文章源於 tldraw 創辦人 Steve Ruiz 的反思，探討在 AI 輔助開發普及的時代，開源專案收到的外部貢獻（Pull Requests, PR）價值是否已降至負值。作者發現，當 AI 讓撰寫程式碼變得極其廉價且低門檻時，維護者審查大量由 AI 生成、缺乏脈絡且品質參差不齊的程式碼，其成本已遠超過自行撰寫的效益。

社群觀點

Hacker News 的討論首先聚焦於「垃圾進，垃圾出」的連鎖反應。許多評論者指出，作者在文章中承認自己使用 AI 將簡短的筆記擴充成看似正式的 GitHub Issue，這種行為本身就是「問題單垃圾化」的源頭。社群成員認為，當專案維護者帶頭產出缺乏深度的 AI 內容時，自然會吸引外部貢獻者同樣使用 AI 快速生成對應的 PR。這種「AI 對抗 AI」的過程，導致雙方都在處理毫無意義的冗餘資訊，甚至有留言直言，作者抱怨外部貢獻品質低落，卻忽略了正是自己的低成本指令誘導了這些無效勞動，缺乏自我覺察。

關於程式碼價值的轉變，社群出現了深刻的辯論。部分觀點認同作者的看法，即當程式碼撰寫變得容易，真正的價值將回歸到對問題的深刻理解、架構設計以及對既有模式的遵循。如果外部貢獻者只是將問題丟給 Claude 或 Cursor 產出解答，而沒有投入時間理解專案的 UI 組件或輔助函式，那麼這些程式碼對專案來說就是一種負債。然而，也有反對者認為，寫程式從來就不是最難的部分，解決問題才是。如果 AI 能協助非專業開發者（如嵌入式工程師或一般用戶）精確地指出問題點，甚至提供初步的修復方向，這依然具備溝通價值。爭議點在於，這種「指尖傳遞」的過程是否應該直接體現為程式碼，還是應該停留在更高品質的討論與回報階段。

此外，討論也延伸到了 GitHub 模式的未來。有資深開發者指出，GitHub Issues 長期以來被誤用為個人待辦清單或社交媒體，導致溝通成本過高。社群中有人提議，或許應該將「討論」與「臭蟲追蹤」嚴格分離，僅允許經過充分驗證的提案進入開發流程。對於 AI 帶來的「垃圾郵件化」現象，甚至有網友建議開發類似 SponsorBlock 的瀏覽器擴充功能，用來標記並過濾那些慣於產出 AI 垃圾內容的貢獻者。

最後，社群對管理層與開發者的角色變遷感到憂慮。如果 AI 真的能讓程式碼撰寫變得完美且廉價，那麼開發者的獨特性將體現在對業務邏輯的掌握與決策權上。但這也意味著，那些僅依賴 AI 產出而缺乏底層理解的新一代開發者，可能永遠無法獲得足以評核 AI 產出好壞的專業能力。這種「過渡期」的斷層，被視為開源生態系乃至整個軟體產業面臨的最大挑戰。

延伸閱讀

在討論中，有網友提到部分知名專案如 Ghostty 與 Hyprland 已開始改變工作流，將 GitHub Discussions 作為第一線的用戶回報區，只有在資訊足夠詳盡且被維護者認可後，才會轉化為正式的 Issue。此外，關於隱私與 noreply 電子郵件的設定，GitHub 官方文件也提供了相關指引，以避免在參與開源貢獻時洩漏個人資訊。