如何吸引 AI 機器人參與你的開源專案

背景

這篇文章源於一位維護數十個開源專案的開發者，在觀察到其他小型專案頻繁收到 AI 自動生成的拉取請求（PR）後，反思自己的專案為何乏人問津。作者與 Claude 協作撰寫了一篇充滿諷刺意味的指南，建議開發者透過撰寫模糊的議題描述、移除測試與型別標註、甚至將龐大的 node_modules 目錄提交至版本控制系統，來刻意製造「混亂」，藉此吸引 AI 代理人前來進行無意義的修補與貢獻。

社群觀點

這篇帶有強烈反諷色彩的文章在 Hacker News 引發了熱烈討論，讀者對於文章中「層層遞進」的幽默感反應不一。許多留言者坦言，起初閱讀前幾項建議，如撰寫模糊議題或增加待辦清單時，還以為是某種新興的開發策略，直到讀到「禁用分支保護」與「移除測試」時才驚覺這是一篇諷刺文學。這種從正經轉向荒誕的寫作手法，讓不少開發者在笑聲中感受到當前 AI 貢獻氾濫對開源生態造成的荒謬現狀。

針對文章中提到的極端做法，社群展開了關於技術細節的延伸辯論。例如，針對「提交 node_modules」這一點，有開發者認真討論起軟體供應鏈的安全性。雖然在諷刺語境下這被視為吸引 AI 的誘餌，但部分留言者指出，某些專案確實會為了確保建置的封閉性與穩定性而選擇將依賴項納入版本控制，儘管這會犧牲安全性更新的便利性。這種將諷刺與現實技術決策交織的討論，反映出開發者對於專案維護成本與自動化工具之間的複雜情緒。

此外，社群中也出現了對於「AI 貢獻動機」的深層反思。有觀點認為，單純調整專案結構可能不足以吸引 AI，因為目前的 AI 代理人並非主動在尋找這類技術指標，而是受到背後開發商的行銷策略或特定流量入口所引導。更有讀者提議，這類吸引 AI 亂入的行為應該被視為一種社群標籤，甚至像是一種「詛咒」在 GitHub 上流傳。儘管文章內容由 AI 協作完成，但社群普遍認為其精準捕捉到了當前開源維護者面臨的困境：AI 雖然提高了參與數量，卻往往帶來了更多需要人工審核的無效噪音。

最後，部分讀者對這類「以毒攻毒」的實驗抱持觀望態度，好奇若真的照做，是否真能引發如文章所述的「AI 互修循環」——即一個機器人修補了錯誤，引來另一個機器人修正其型別，最後形成一套自我維持的自動化貢獻鏈。這種對未來開發模式的戲謔想像，也反映了開發者對於 AI 介入開源領域後，人類角色逐漸邊緣化的集體焦慮。