先擋入口
我看到那篇 OSS maintainer 抱怨 AI PR 的文章，第一個反應不是「AI 又毀了開源」，而是很像我平常看 queue 爆掉。
說穿了就是，AI 把「送進來」變便宜，但沒有把「判斷值不值得 merge」變便宜。
這件事很多人會吵成價值觀問題。有人說 typo PR 也是修正，既然 patch 是對的，為什麼要拒絕。也有人說 contributor 是為了 CV 履歷刷綠格，所以 maintainer 不應該鼓勵。兩邊都沒有完全錯，但如果站在 infra 角度，真正要管的是 admission control。
Review 不是免費資源
我以前幫一個內部平台看 CI queue，有一陣子大家開始把所有小修都拆成獨立 PR。每個 PR 本身都很小，改 README、改註解、調一個 lint。單看都合理，但一天 30 個 PR 就很煩。
假設每個 PR 只花 10 分鐘：
30 PR/day * 10 min = 300 min/day
300 min = 5 hours
這還只是看 diff，不包含拉 branch、跑測試、問作者為什麼這樣改、處理 review 後的 follow-up。實務上最貴的不是 CI minutes，是 maintainer 的注意力切換。CI 爆掉可以加 runner，maintainer 腦袋爆掉不能水平擴充。
AI 產生的 drive-by PR 問題就在這裡。它把入口流量變成接近零成本。以前要刷 10 個 repo 的 typo PR，至少要自己找、自己改、自己寫說明。現在 prompt 一下就可以大量掃。入口便宜之後，下游如果沒有 backpressure，queue 一定爆。
我會先寫規則，不會先猜人心
我不太喜歡靠「感覺這個人是不是誠懇」做判斷。那很難一致，也很難跟團隊交代。比較能落地的是把規則寫成 contribution guide，然後讓 maintainer 有理由關掉低價值流量。
像這種：
ai_assisted_pr:
allowed: true
requirements:
- author_can_explain_change
- includes_runtime_or_test_impact
- not_mass_drive_by_across_unrelated_repos
close_fast_if:
- typo_only_without_issue_context
- generated_security_report_low_severity
- no_response_after_review_question
這不是反 AI。這是把 PR 當 production traffic 管。
API gateway 會做 rate limit，因為你知道後端資源有限。開源 repo 也一樣。good first issue、拼字修正、安全回報，本來是入口，現在都可能變成 spam vector。沒有 gate 的話，maintainer 其實是在替別人的履歷付 review 成本。
信任問題最後會變成操作問題
最麻煩的是，AI PR 不是全部都爛。有些是真的有用。有些 contributor 也是真的靠 AI 學會進入專案。你不能簡單說「AI 產生就關掉」，那會誤傷真正想貢獻的人。
所以我會看責任歸屬，而不是看工具。
作者能不能回答：為什麼改這裡？有沒有測？如果壞了怎麼 rollback？跟現有 TODO、issue、roadmap 有什麼關係？
答不出來，就算 patch 是對的，我也不會急著 merge。因為 merge 的不是 diff，是後面的維護成本。
很多工程團隊在 code review 都有類似規則，只是以前沒有講得這麼明。AI 讓這件事浮出來而已。以前一個人亂開 PR 的成本高，所以規則可以鬆。現在成本降到接近 0，規則就要變硬。
對小專案尤其痛
大公司可以用 bot triage，可以有 security team，可以把 CVE 流程拆給不同人。小型 OSS project 沒有這些。可能就兩三個 maintainer，晚上下班後看 issue。
對他們來說，三個正確但沒意義的 typo PR，不是「小小改善」。那是三次 context switch。
差十倍的地方在這裡：
有 gate：30 秒看規則，close
沒 gate：10 分鐘看 diff，想措辭，跑 CI，回留言
乘上一個月，差距就很明顯。
我覺得接下來
成熟的 repo 會多一層 AI contribution policy。不是禁止使用 AI，而是要求人站在 PR 後面。可以用 agent 找 bug，可以用 LLM 寫 patch，但送出來的人要能負責。
開源本來就是信任網路。AI 沒有消滅信任，只是把假信號的產量拉高了。維護者要做的不是人工辨識誰真誰假，而是把入口設計到低信任流量自然進不來。
實務上，先擋入口，比在 review queue 裡面慢慢燒掉自己有用。
作者：CtrlC