「你這 27 天講的都是 PHPUnit & Pest Test Explorer 這一個專案的故事,AI 輔助維護這件事,對整個 open source 生態來說,到底是好事還是壞事?」
這是一個值得認真回答的問題。過去 27 天,我們一直站在單一專案、單一維護者的角度看 AI 能幫上什麼忙——issue triage、PR review、依賴升級、除錯。但如果把鏡頭拉遠,看的是成千上萬個像 PHPUnit & Pest Test Explorer 這樣、由少數人甚至單一個人維護的專案,AI 的介入會怎麼改變整個生態的樣貌?今天想誠實地把好處跟隱憂都攤開來講,不只挑好聽的講。
PHPUnit & Pest Test Explorer 這類專案的維護模式很典型——一個或少數幾個人,利用業餘時間回覆 issue、review PR、修 bug、發版。這種維護模式最大的風險不是技術債,是維護者的時間跟精力有限,一旦維護者忙碌或失去動力,專案就會停滯,即使程式碼本身還健康。
AI 能幫上忙的地方,正好是壓縮維護者花在機械性工作上的時間:先幫忙分類 issue(Day 03)、先產出一份審查清單讓 review 更有效率(Day 05)、先處理依賴升級這種例行公事(Day 13)。這些工作單獨看都不困難,但加總起來是維護者精力的主要消耗源。如果 AI 能把這部分時間省下來,維護者就有更多餘裕投入真正需要人判斷的事——技術方向、社群關係、長期規劃。 這對單人維護的專案來說,可能是「這個專案還撐得下去」跟「這個專案慢慢沒人維護」之間的差別。
但反過來看,AI 也讓「產生一個看起來像模像樣的 PR」的門檻降低了。這件事對維護者不見得是好消息。
過去,一個外部貢獻者要提交 PR,通常代表他真的花了時間讀程式碼、理解專案慣例、寫測試。 這個門檻本身有篩選作用——願意跨過這個門檻的人,通常對這個專案有一定程度的投入。但當 AI 可以快速產生「語法正確、結構完整」的程式碼改動時,這個天然的篩選機制被削弱了:一個對專案毫無理解、只是把 issue 描述丟給 AI 產生一段程式碼就送出 PR 的貢獻者,跟一個真正認真研究過的貢獻者,在 PR 列表上可能長得差不多。
用一組對照來看這個轉變:
過去的篩選機制:
「這個 PR 有沒有花時間做」這個判斷,
可以從貢獻者投入的時間跟精力側面推測
→ 願意花時間的人,通常對專案有基本理解
現在面對的情況:
PR 表面上的完整度,
不再能可靠地反映貢獻者對專案的理解程度
→ 維護者要花更多力氣,才能分辨「認真的貢獻」
跟「丟給 AI 隨便產生的貢獻」
這個轉變的實際後果是:維護者的篩選成本,從「要不要接受這個功能」轉移到「這個 PR 背後有沒有人真的理解自己在改什麼」。 Day 06 提過的審查清單能幫忙檢查程式碼本身有沒有問題,但沒辦法回答「這個貢獻者理不理解專案脈絡」這個更根本的問題——而後者往往才是決定一次協作能不能順利進行下去的關鍵。
要澄清一件事:這裡講的隱憂,不是說 AI 輔助產生的貢獻品質天生比較差。Day 08、Day 09、Day 15 這幾篇裡用到的真實案例,很多都展示了 AI 輔助能產出高品質的改動。問題不在 AI 產出的品質,而在「產出門檻降低」這件事本身,讓維護者原本可以依賴的一個間接訊號(花了多少心力)變得不可靠。
這也解釋了為什麼 Day 23 講的「不評判貢獻者能力」這條原則格外重要——當表面訊號不可靠時,更容易誘使人用其他方式(例如猜測貢獻者是不是用 AI)來下判斷,而這種猜測本身就帶著偏見,不是一個可靠的評估標準。
如果你自己維護(或參與貢獻)一個 open source 專案,回想最近收到的幾個 PR:你判斷「這個貢獻值不值得認真 review」的依據是什麼?如果那個依據建立在「這個 PR 看起來花了多少心力」上,這個依據在 AI 輔助貢獻越來越普遍的情況下,還可靠嗎?
明天要把這 28 天累積下來的觀察,收斂成一份誠實的邊界清單:這套做法解決了什麼,又有哪些維護者的決定,不管 AI 再怎麼進步,都不該交出去。