AI寫代碼寫嗨了，開源社區(qū)先扛不住

出品 | 網(wǎng)易智能

作者 | 小爪

編輯 | 王鳳枝

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

現(xiàn)在真正麻煩的地方，也是它能寫代碼。

當(dāng)一個(gè)工具只是幫你補(bǔ)全幾行函數(shù)，風(fēng)險(xiǎn)還留在用戶自己的電腦里。寫錯(cuò)了，用戶改；跑不通，用戶調(diào)；不該提交，用戶自己攔下來。

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

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

《金融時(shí)報(bào)》近期長文把這個(gè)矛盾放到開源社區(qū)里看：生成代碼的成本被AI降低了，但審核代碼、理解代碼、拒絕低質(zhì)量貢獻(xiàn)的成本，并沒有一起消失。它只是被轉(zhuǎn)移到了維護(hù)者那一側(cè)。

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

被堵住的不是代碼庫，是維護(hù)者

《金融時(shí)報(bào)》從cURL寫起。

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

AI編程工具給這類維護(hù)者帶來的新麻煩，是大量看似有用、實(shí)際需要人類仔細(xì)排查的提交和報(bào)告。

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

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

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

即使是完全由AI生成的報(bào)告，維護(hù)者要打開它、讀懂它、復(fù)現(xiàn)它，再決定它是不是一個(gè)真實(shí)問題。

貢獻(xiàn)變便宜以后，信號也在失效

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

你修了一個(gè)bug，寫了一個(gè)功能，補(bǔ)了一段文檔，項(xiàng)目維護(hù)者接受了，你就成了貢獻(xiàn)者。這個(gè)貢獻(xiàn)可能給你帶來聲譽(yù)、簡歷亮點(diǎn)、同伴認(rèn)可，甚至工作機(jī)會。維護(hù)者花時(shí)間反饋，也是在培養(yǎng)未來的協(xié)作者。

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

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

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

麻煩在于，當(dāng)提交門檻被降到接近零，維護(hù)者更難區(qū)分：對方是來協(xié)作的，還是只是把"垃圾"丟進(jìn)審核隊(duì)列。

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

這種變化不只發(fā)生在代碼提交里，也發(fā)生在公共知識系統(tǒng)里?！督鹑跁r(shí)報(bào)》提到，ChatGPT出現(xiàn)前，Stack Overflow每月還有超過10萬個(gè)問題；最近一個(gè)月已經(jīng)不到1500個(gè)，回答率也從過去約80% 降到一半左右。

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

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

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

產(chǎn)品能力越像貢獻(xiàn)者，產(chǎn)品責(zé)任越像貢獻(xiàn)者

這種變化先體現(xiàn)在產(chǎn)品能力上：AI編程工具開始接手更長、更完整的編程任務(wù)。

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

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

當(dāng)一個(gè)工具只是幫用戶寫幾行代碼，用戶可以自己決定要不要用、要不要提交。但如果工具自己接issue、自己改倉庫、自己把結(jié)果送進(jìn)GitHub PR、Jira工單、Slack工作流和團(tuán)隊(duì)審核流程，它的輸出就會占用別人的時(shí)間。

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

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

寫代碼的成本降了，判斷這些代碼該不該進(jìn)入項(xiàng)目的成本沒有跟著降。

問題不在AI，而在成本轉(zhuǎn)嫁

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

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

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

維護(hù)者也應(yīng)該被放進(jìn)產(chǎn)品設(shè)計(jì)里。工具廠商要處理提交前責(zé)任：AI工具要不要先讀取CONTRIBUTING文件、issue模板、測試說明和維護(hù)者偏好？平臺要給維護(hù)者更強(qiáng)的過濾權(quán)：能不能標(biāo)記AI生成貢獻(xiàn)、限制新賬號批量提交、要求提交者附上測試證據(jù)，甚至給項(xiàng)目提供一鍵關(guān)閉或限流AI PR的設(shè)置？

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

AI編程工具不會因?yàn)殚_源維護(hù)者抱怨就停下來。GitHub、Anthropic、OpenAI都在把編程智能體往更長任務(wù)、更自動化、更接近真實(shí)工作流的方向推。這條路大概率不會回頭。開發(fā)者也確實(shí)會繼續(xù)用這些工具，因?yàn)樗鼈兡芄?jié)省時(shí)間，能處理重復(fù)任務(wù)，也能讓非專業(yè)開發(fā)者完成過去做不了的技術(shù)工作。

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

如果一個(gè)工具讓用戶五分鐘生成一個(gè)PR，卻讓維護(hù)者花三十分鐘判斷為什么它不該合并，那更像成本轉(zhuǎn)移，而不是生產(chǎn)力提升。如果一個(gè)工具能生成代碼，也能解釋變更、補(bǔ)齊測試、尊重項(xiàng)目規(guī)則、減少審核負(fù)擔(dān)，它才更接近真正的協(xié)作者。

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

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

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

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