從 Zig 禁 LLM 貢獻政策談開源社群的 Reviewer ROI 與 Contributor 培養
今天看到 Simon Willison 寫 Zig 語言那篇關於禁止 AI 貢獻的文章，第一反應是「哇這也太硬了吧」，但仔細想想，背後的邏輯其實蠻值得聊的。
簡單講 Zig 的立場：所有 issue、PR、comment 都禁止使用 LLM 生成。不是「品質不好才禁」，是「就算品質好也禁」。他們的核心理由不是程式碼品質，而是——審 PR 的目的從來不只是收程式碼，而是在培養可信任的長期貢獻者。
這個觀點讓我想了蠻久的。因為在學術圈，我們其實一直在做類似的事。
Reviewer 的時間是最稀缺的資源
先講一個數字好了。我之前幫一個 NLP 相關的 open source project 做 review，一個 PR 平均花我 45 分鐘到 2 小時不等。如果是新 contributor 的第一個 PR，通常要花更久，因為你要看他的 code style、思考模式、對 codebase 的理解程度，然後寫很多 comment 解釋「為什麼我們這邊要這樣做」。
這個時間投資的 ROI 在哪裡？不在那個 PR 本身。而是在：這個人下次交的 PR 會更好、更快被 merge，三個月後他可能可以自己 review 別人的 code，半年後他可能變成 maintainer。
用一個比喻來說好了：reviewer 花的時間像是存定存，每一次 review 都是在對一個特定的人做投資。如果今天那個 PR 其實不是那個人寫的——比如是 LLM 寫的，然後他只是 copy-paste 過來——那我的投資對象就消失了。我花了 2 小時去 review 一個 PR，寫了 15 則 comment 解釋我們的 design principle，結果那個 contributor 下次還是一樣用 LLM 生成然後 copy-paste。我的時間完全浪費了。
Contributor Poker：你在看的是人，不是程式碼
Zig 的文件裡用了一個概念我覺得很有意思，就是 review 其實是一種「contributor poker」——你在透過 PR 的品質和互動來判斷這個人是不是值得信任。
我自己的經驗也是這樣。在實驗室帶學弟妹，我不會只看他們 paper 寫得好不好。我在看的是：他對自己做的東西真的理解嗎？他能不能在 meeting 上被問到的時候說出「這邊我不確定，但我覺得可能是因為 X」而不是「呃… 那個… ChatGPT 跟我說…」？
開源社群也一樣。一個 contributor 交了 5 個 PR，每次 review 的互動你都可以看出：
- 他的第 3 個 PR 比第 1 個好多少？（學習曲線）
- 他對你的 review comment 是照做還是有自己的想法？（獨立思考）
- 他有沒有開始主動提出 edge case？（深度理解）
如果中間參雜了 LLM 生成的 code，這些信號就全部失真了。你不知道他進步了還是 LLM 進步了。你不知道他對你的 feedback 有吸收還是只是下次換了一個更好的 prompt。
但這裡有一個反論我一直在想
我自己寫論文也會用 LLM 幫忙 brainstorm、改 wording、甚至 debug 一些 code。那我的指導教授在看我的 paper 的時候，他有辦法判斷我到底懂不懂嗎？
老實說，大部分時候他可以。因為學術圈有 oral defense、有 meeting 上的討論、有 reviewer rebuttal。這些環節你沒辦法靠 LLM。但開源社群呢？一個 GitHub PR 的互動其實非常 async，而且通常不會有面對面的環節。所以 reviewer 只能靠 PR 本身的品質和 comment 互動來 build trust。
如果這個唯一的信號管道被 LLM 污染了，trust 就建立不起來。
數字上的 trade-off
我自己粗估過一個小型 open source project 的情況：
- 活躍 reviewer：2-3 人
- 每人每週能 review 的 PR 數量：5-8 個
- 新 contributor 的第一個 PR 被 merge 的比例：大約 30-40%（很多人第一個 PR 被 review 後就消失了）
- 第一個 PR 被 merge 的人，後續持續貢獻超過 6 個月的比例：大約 15-20%
也就是說，100 個新 contributor 進來，最後留下來成為可信任的長期貢獻者的，大概就 5-8 個人。reviewer 花的時間有 80% 以上是「沉沒成本」——投資在了後來消失的人身上。
如果再加上 LLM 生成的 PR，假設有 30% 的新 PR 是 LLM 貢獻，那 reviewer
的有效 ROI 又被稀釋了。原本你花 100 小時的 review 時間，最後培養出 5 個可信任的 contributor。現在同樣 100 小時，可能只培養出 3-4 個，因為有些時間被花在了「永遠不會成長的假 contributor」身上。
我的看法：不是非黑即白
我不覺得所有 project 都該學 Zig 一刀切。原因很簡單——不同 project 的 reviewer 瓶頸不一樣。
像 Zig 這種底層語言、核心開發者很少、trust 極度重要的 project，禁止 LLM 貢獻是合理的。因為他們的 bottleneck 就是 reviewer 時間，而且他們真的在 play the long game——寧可 contributor 少但每個都可信任。
但像一些「接受 drive-by contribution」的大型 project，比如 documentation fix、typo correction，禁 LLM 可能就殺傷過大了。這類 PR 本來就不期望對方變成長期 contributor。
不過話說回來，我在想一件事：如果未來大部分 PR 都是 AI-assisted 的，那 reviewer 的角色是不是要根本性地改變？也許未來的 review 不再是「透過 PR 來認識人」，而是需要其他管道來 build contributor trust。就像學術圈有 oral defense 一樣，也許開源社群也需要某種同步的互動機制。
不知道有沒有人在做類似的事情？比如要求 contributor 做 pair programming session 或者 live code review 之類的。這聽起來很重，但如果 async 管道的信號越來越不可信，也許某種程度的同步互動是必要的。
反正博士念到第 N 年，對「花了很多時間投資一個人結果他跑了」這件事，我是有很深的體悟的（嘆
作者：十年大博士