AI寫代碼寫嗨了，開源社區先扛不住

出品 | 網易智能

作者 | 小爪

編輯 | 王鳳枝

AI編程工具最早讓人興奮的地方，是它能寫代碼。

現在真正麻煩的地方，也是它能寫代碼。

當一個工具只是幫你補全幾行函數，風險還留在用戶自己的電腦里。寫錯了，用戶改；跑不通，用戶調；不該提交，用戶自己攔下來。

但AI編程工具正在越過這個邊界。它們不只補全代碼，還能接任務、讀倉庫、跑測試、生成pull request。代碼不再只是生成給用戶看，而是進入開源項目、公司倉庫和維護者的審核隊列。

問題也因此變了。過去我們問的是：AI能不能寫出代碼？現在更該問的是：它寫出來的東西，誰來審？

《金融時報》近期長文把這個矛盾放到開源社區里看：生成代碼的成本被AI降低了，但審核代碼、理解代碼、拒絕低質量貢獻的成本，并沒有一起消失。它只是被轉移到了維護者那一側。

當AI編程工具把創建和提交變得更便宜，真正被放大的是代碼進入別人工作流之后的審核成本。

被堵住的不是代碼庫，是維護者

《金融時報》從cURL寫起。

cURL是互聯網里那種幾乎所有人都在用、但幾乎沒人意識到自己在用的軟件。項目維護者估計，libcurl已經被安裝超過200億次。它是現代數字生活的底層零件，卻不是由一家巨型公司維護。cURL最核心的維護者，是瑞典開發者丹尼爾·斯滕伯格（Daniel Stenberg）。

AI編程工具給這類維護者帶來的新麻煩，是大量看似有用、實際需要人類仔細排查的提交和報告。

根據斯滕伯格1月26日發布的博客，cURL的漏洞懸賞自2019年啟動以來，累計確認87個漏洞，支付超過10萬美元獎勵；但從2024年下半年開始，AI垃圾報告逐漸拖垮這個機制，2025年明顯惡化，真實漏洞確認率跌到5% 以下。cURL最終決定在1月31日停止漏洞懸賞。

維護者真正抵觸的，不是新工具本身，而是提交變得太便宜了。

過去，一個人要給cURL這樣的項目提交漏洞報告或代碼修改，至少要理解一點上下文?，F在，一個人可以把問題丟給模型，讓它生成報告、建議補丁，甚至組織成看起來很專業的文本。提交者的成本變低了，維護者的成本卻沒有同步下降。

即使是完全由AI生成的報告，維護者要打開它、讀懂它、復現它，再決定它是不是一個真實問題。

貢獻變便宜以后，信號也在失效

開源貢獻過去不只是"交付一段代碼"，也是一種信任建立過程。

你修了一個bug，寫了一個功能，補了一段文檔，項目維護者接受了，你就成了貢獻者。這個貢獻可能給你帶來聲譽、簡歷亮點、同伴認可，甚至工作機會。維護者花時間反饋，也是在培養未來的協作者。

但AI編程工具正在讓這套激勵變形。

tldraw創始人史蒂夫·魯伊茲（Steve Ruiz）今年1月宣布，tldraw將自動關閉外部貢獻者的PR。原因很直接：項目面對大量低質量、AI生成的代碼，需要維護者花時間審核。他在博客里問了一個很刺耳的問題：如果寫代碼已經是容易的部分，為什么還要別人來寫？

AI輔助本身并不會讓貢獻失去價值。一個真正理解項目的人，用AI生成測試、整理上下文、加速實現，仍然可能提交高質量改動。魯伊茲自己也說，他和團隊會使用AI寫代碼。

麻煩在于，當提交門檻被降到接近零，維護者更難區分：對方是來協作的，還是只是把"垃圾"丟進審核隊列。

開源貢獻原本是一種關系。AI把其中一部分變成了低成本輸出。真正受傷的不是某一行代碼，而是維護者判斷"這個人值不值得繼續溝通"的信號。

這種變化不只發生在代碼提交里，也發生在公共知識系統里?！督鹑跁r報》提到，ChatGPT出現前，Stack Overflow每月還有超過10萬個問題；最近一個月已經不到1500個，回答率也從過去約80% 降到一半左右。

以前開發者遇到問題，會搜索、提問、解釋自己卡在哪里，然后等別人回答。那些問答后來變成公共知識，下一批人搜索時還能看到上下文、爭論、替代方案和踩坑記錄。現在，越來越多問題被丟進私有聊天框。用戶拿到了答案，平臺拿到了互動數據，但公共知識庫沒有同步增長。

開源維護者面對的是輸入端的堵塞：低質量提交變多；Stack Overflow面對的是輸出端的萎縮：公共問答變少。 一個是審核負擔上升，一個是公共知識積累下降，但背后都是同一件事：AI把過去發生在公共社區里的互動，轉移到了私人模型對話或維護者隊列里。

《金融時報》提到的預印本論文《氛圍編程正在殺死開源》（Vibe Coding Kills Open Source）也在討論類似風險。它把問題放進一個經濟模型里看：如果AI智能體成為開源包的主要消費者，而人類用戶不再閱讀文檔、報告漏洞或參與討論，維護者過去獲得聲譽、反饋和機會的機制會被削弱。

產品能力越像貢獻者，產品責任越像貢獻者

這種變化先體現在產品能力上：AI編程工具開始接手更長、更完整的編程任務。

GitHub去年介紹Copilot編程智能體時，用戶已經可以把issue分配給Copilot，讓它在后臺運行、推送提交，并創建draft pull request（草稿拉取請求）。Anthropic的Claude Code也在向長任務推進。Anthropic研究頁稱，GitHub項目中出現編程智能體活動的比例，自2025年末以來已經翻倍；Claude Code用戶每周平均使用約20小時。

OpenAI對Codex的描述同樣如此。OpenAI 6月25日發布的文章稱，智能體把知識工作的單位從單次互動，變成可以委托的長任務。到2026年5月，抽樣個人用戶中，80.6% 至少發起過一次估計超過30分鐘人工工作量的Codex請求，25.6% 發起過超過八小時的請求。

當一個工具只是幫用戶寫幾行代碼，用戶可以自己決定要不要用、要不要提交。但如果工具自己接issue、自己改倉庫、自己把結果送進GitHub PR、Jira工單、Slack工作流和團隊審核流程，它的輸出就會占用別人的時間。

一個pull request不是點開看一眼就完事。維護者要判斷需求是否合理、是否符合項目方向；要看代碼有沒有破壞兼容性；要跑測試；要復現問題；要解釋為什么不能合并。

AI生成的低質量代碼還常常不是一眼假的。它可能語法正確，也可能通過局部測試，甚至變量名和注釋都很像樣。但它未必理解項目長期維護里的那些舊賬：有些API不能隨便改，有些路徑要兼容舊版本，有些看似簡單的修復會影響其他平臺。

寫代碼的成本降了，判斷這些代碼該不該進入項目的成本沒有跟著降。

問題不在AI，而在成本轉嫁

下一階段，AI編程工具應該比拼的，不只是寫得快，而是誰能減少審核成本。

一個好的AI編程工具，不應該只是生成更多代碼，而應該讓別人更容易判斷這些代碼能不能用。 它要清楚說明改了什么、為什么改、影響范圍在哪里；要自動跑相關測試，而不是只貼一段"應該能工作"的說明；要把不確定的地方標出來；要讓維護者能快速回滾、快速定位、快速拒絕。

GitHub在Copilot編程智能體的官方介紹里強調，智能體的PR需要人工批準后才能運行CI/CD工作流，也強調現有分支保護規則仍會生效。平臺已經開始給自動提交代碼加護欄，但開源社區面對的情況更復雜。CI只能告訴你一部分"會不會壞"，不能告訴你"該不該合并"。

維護者也應該被放進產品設計里。工具廠商要處理提交前責任：AI工具要不要先讀取CONTRIBUTING文件、issue模板、測試說明和維護者偏好？平臺要給維護者更強的過濾權：能不能標記AI生成貢獻、限制新賬號批量提交、要求提交者附上測試證據，甚至給項目提供一鍵關閉或限流AI PR的設置？

弱工具生成的垃圾很容易被識別，強工具生成的半成品才最消耗人。

AI編程工具不會因為開源維護者抱怨就停下來。GitHub、Anthropic、OpenAI都在把編程智能體往更長任務、更自動化、更接近真實工作流的方向推。這條路大概率不會回頭。開發者也確實會繼續用這些工具，因為它們能節省時間，能處理重復任務，也能讓非專業開發者完成過去做不了的技術工作。

問題不是AI該不該寫代碼，而是它寫完之后，誰承擔后果。

如果一個工具讓用戶五分鐘生成一個PR，卻讓維護者花三十分鐘判斷為什么它不該合并，那更像成本轉移，而不是生產力提升。如果一個工具能生成代碼，也能解釋變更、補齊測試、尊重項目規則、減少審核負擔，它才更接近真正的協作者。

生成變得便宜以后，審核就會變貴。

《金融時報》文章最后回到"維護"。斯滕伯格說，對任何項目來說，第一次寫代碼從來不是問題；真正的挑戰，是長期維護、長期修bug。如果你不理解代碼，就只能繼續依賴AI去修后面所有問題。

這句話可以當作今天AI編程工具的警告。AI最擅長放大創建。 它讓更多人能寫代碼、提需求、造應用、生成PR。但軟件世界真正難的，往往不是創建，而是維護：理解舊代碼，修復邊緣問題，守住兼容性，拒絕不該合并的改動，在幾年后還能知道當初為什么這么寫。

AI編程工具真正要跨過的門檻，不是寫出更多代碼，而是寫出別人愿意審核、敢于合并、以后還能維護的代碼。