AI太會寫代碼，人類已經(jīng)審不過來了

凌晨三點，某金融科技公司的代碼倉庫依舊在更新。

工程師沒有通宵加班，是AI還在庫庫干活。

自從團隊全面接入AI編程工具后，這家公司的月均代碼產(chǎn)量，從過去的2.5萬行飆升到25萬行。短短幾個月，倉庫里積壓了超過100萬行尚未完成審查的代碼。《紐約時報》把這一現(xiàn)象稱為“代碼大爆炸”（The Big Bang of Code）：生成的速度，已經(jīng)遠遠超過人類消化的能力。

5分鐘生成1000行代碼，40分鐘才能勉強審?fù)辍?/p>

寫代碼第一次變成了最輕松的部分。真正的卡點變成了理解與審核。

行業(yè)當(dāng)然也在試圖補上這個缺口。以Anthropic的Opus4.8，以及更高一檔但受限開放的Mythos/Fable系列為代表，已經(jīng)不滿足于把代碼寫得更快，而開始強化代碼理解、跨文件推理和審查能力：追蹤變量流向、識別潛在漏洞、給出帶上下文的修改建議。它們正在被賦予新角，從程序員的助手，到審查員的助手。

但這并沒有讓問題消失。AI負責(zé)生成，AI也開始參與審查；代碼產(chǎn)能繼續(xù)膨脹，理解和責(zé)任卻沒有同步跟上。

當(dāng)Claude Code、Cursor等工具把“對話框”變成主戰(zhàn)場，工程師越來越像“提示詞調(diào)度員”，而不再只是傳統(tǒng)意義上的程序員。代碼洪流席卷而來，但誰來為質(zhì)量負責(zé)？誰來為漏洞負責(zé)？誰來真正理解這套系統(tǒng)的結(jié)構(gòu)？

更尖銳的問題是：人類審查，究竟是AI時代低效的瓶頸，還是最后一道不能撤掉的防線？

01

代碼洪流：為什么AI會生產(chǎn)這么多代碼？

AI產(chǎn)出代碼的速度為何遠超人類審核的能力上限？這并非單一原因所致。

AI擅長生成新代碼，卻不擅長復(fù)用舊代碼。

代碼分析公司GitClear在2023年的一項研究發(fā)現(xiàn)，隨著GitHub Copilot、Cursor等AI編程工具的流行，代碼重復(fù)率（即“克隆代碼”）已從2020年的約3.3%攀升至7.1%。報告指出，AI更傾向于“新增代碼塊”，而不是建議刪除、重構(gòu)或移動既有代碼。

當(dāng)開發(fā)者要求實現(xiàn)一個功能組件時，AI可能會在項目的不同角落，生成五個看似大同小異的文件，而非建議開發(fā)者復(fù)用或重構(gòu)已有的一個。

AI像一個永遠只會往房間里添家具的助手——沙發(fā)壞了？再給你來一個新的。墻面過時了？再刷一層。至于空間是否擁擠，它不負責(zé)。

更關(guān)鍵的是，開發(fā)者行為也隨之異化。

理解一個已有組件，平均需要5分鐘；讓AI生成一個功能類似的新組件，只需10秒。

成本差距擺在那里。

于是越來越多開發(fā)者選擇“重新生成”，而不是“復(fù)用理解”，快速產(chǎn)出模塊，但減少架構(gòu)思考。

當(dāng)理解成本高于生成成本，代碼就開始無節(jié)制繁殖。

然而，速度的提升往往以犧牲設(shè)計的嚴(yán)謹(jǐn)性、架構(gòu)的清晰度為代價，為未來的維護埋下隱患。

同時，AI工具正在重塑編程的界面。以Claude Code和Cursor的“智能體模式”為例，Agent模式下，編譯器窗口幾乎被弱化，過去，開發(fā)者在IDE里寫代碼、調(diào)試、重構(gòu)；現(xiàn)在，更多時間在和模型“聊天”。

復(fù)雜Excel報表？過去查文檔兩小時。現(xiàn)在一句話需求，十幾秒生成完整腳本。

然而，便利的另一面是“大腦過濾”的失效。開發(fā)者不再需要深入思考細節(jié)，AI為了確保邏輯的“完備性”，常常會添加大量防御性代碼、邊界檢查，甚至過度工程化的抽象層，導(dǎo)致生成的代碼雖能運行，卻冗長、復(fù)雜，猶如一篇過度解釋的說明書，極大增加了閱讀與審查的成本。

更極端的，是組織層面的推動。

Meta等科技公司內(nèi)部曾興起名為“tokenmaxxing”的競賽，鼓勵工程師比拼誰能用最少的提示詞，驅(qū)動AI生成最多行代碼。代碼行數(shù)（Lines of Code,LOC）這一陳舊且飽受詬病的指標(biāo)，在AI時代被意外地重新賦予“核心KPI”的意味。

Meta首席技術(shù)官安德魯·博斯沃思（Andrew Bosworth）在一份內(nèi)部備忘錄中曾樂觀地寫道：“過去需要數(shù)百名工程師的項目，現(xiàn)在幾十人就能完成。過去需要數(shù)月的工作，現(xiàn)在幾天就能搞定。”這種預(yù)期催生了“人不如AI”的焦慮，也驅(qū)使團隊追求代碼產(chǎn)出的“數(shù)字繁榮”，而非內(nèi)在質(zhì)量。其結(jié)果，便是海量未經(jīng)充分思考、設(shè)計的代碼被快速提交，涌向本已脆弱的審查通道。

AI生成的代碼，在“正確性”與“優(yōu)雅性”之間存在巨大鴻溝。為了滿足一個復(fù)雜需求，AI可能會生成多層嵌套的回調(diào)函數(shù)，或使用晦澀難懂的庫特性。

不同開發(fā)者或同一開發(fā)者在不同時間，由于提示詞的細微差別，生成的代碼風(fēng)格、結(jié)構(gòu)可能迥異。這種不一致性，讓后續(xù)的代碼審查如同閱讀一本多人合著且沒有統(tǒng)一文風(fēng)的文集，理解成本陡增。

更根本的挑戰(zhàn)在于，AI并不真正理解業(yè)務(wù)的上下文、系統(tǒng)的長期演進目標(biāo)和技術(shù)債的代價。它生成的是一段“在當(dāng)下看似正確”的代碼片段，而非“在整體系統(tǒng)中可維護、可演進”的代碼。

02

審查不過來，會發(fā)生什么？

代碼產(chǎn)量的激增，并未帶來預(yù)期中的效率飛躍，反而觸發(fā)了連鎖的負面反應(yīng)，將開發(fā)者拖入更深的疲憊與技術(shù)債泥潭。

我們是在用更快的機器，制造更慢的流程嗎？

AI幾分鐘生成上千行代碼，人工審查卻需要數(shù)十分鐘甚至更久。

安全公司Snyk在2023年的一份報告中指出，AI生成的代碼中，約有25%含有已確認(rèn)的安全漏洞，這一比例顯著高于人類編寫的平均水準(zhǔn)。

其結(jié)果是一種詭異的角色倒置。越來越多開發(fā)者坦言，現(xiàn)在他們花在審查、調(diào)試、修改AI代碼上的時間，已經(jīng)超過了以往自己動手編寫的時間。

審查海量AI代碼，是一項高強度、高密度的腦力勞動。開發(fā)者需要持續(xù)判斷：這段代碼的邏輯是否周全？是否有隱藏的錯誤？是否與系統(tǒng)其他部分存在沖突？是否引入了安全風(fēng)險？

《麻省理工科技評論》等媒體指出，持續(xù)的、高強度的AI代碼審查，正導(dǎo)致全球范圍內(nèi)的開發(fā)者出現(xiàn)普遍的職業(yè)倦怠、認(rèn)知疲勞和心理壓力。他們的大腦長期處于“防御性”的審查模式，而非“創(chuàng)造性”的構(gòu)建模式，創(chuàng)新熱情與工作滿意度受到侵蝕。

未經(jīng)充分審查的代碼一旦進入代碼庫，便成為未來的“技術(shù)債”。AI生成的代碼，由于其冗余、高耦合和低可讀性的傾向，往往本身就是高利息的“債務(wù)”。這些代碼的積累，使得系統(tǒng)架構(gòu)日益腐化，短期可運行，長期難維護。技術(shù)債開始滾雪球，形成“代碼越多，質(zhì)量越差，修改越難，新代碼越多”的惡性循環(huán)。最終，整個系統(tǒng)可能變得無人能夠完全理解，每一次改動都如履薄冰。

AI代碼的浪潮也猛烈沖擊著開源世界的協(xié)作倫理。

許多知名開源項目維護者不堪其擾。

2023年，cURL創(chuàng)始人丹尼爾·斯坦伯格（Daniel Stenberg）因無力處理如潮水般用AI生成的、質(zhì)量低劣的漏洞報告和補丁，最終關(guān)閉了運行六年的漏洞賞金計劃。

另一款開源工具Ghostty的創(chuàng)建者米切爾·哈西莫夫（Mitchell Hashimoto）則直接明令禁止所有由AI生成的貢獻，并推出了基于信任的“擔(dān)保人”制度。開源的核心——開放的協(xié)作與智慧共享，正因AI的無差別、低質(zhì)量貢獻而面臨嚴(yán)峻挑戰(zhàn)。

03

答案也在AI嗎？

當(dāng)問題由AI制造，行業(yè)自然會問：能否再用AI解決？

我們把這個問題分別拋給一位字節(jié)的高級數(shù)據(jù)運營、一位滴滴的工程師專家和一位美國初創(chuàng)企業(yè)的軟件工程師，他們都表示，工作中已經(jīng)大量使用AI寫代碼，且認(rèn)為未來AI寫代碼+AI審查是一個確定的趨勢。

他們表示，目前人工檢查AI代碼會遇到一些難點，比如代碼量大，人工需要讀懂邏輯和寫法，會消耗大量的時間；在安全性上有風(fēng)險，可能泄露數(shù)據(jù)結(jié)構(gòu)；有時會存在邏輯一致性的問題，需要手動修改。

領(lǐng)先的科技公司正在積極布局。

2025年12月，明星AI編程工具Cursor收購了代碼審查機器人初創(chuàng)公司Graphite，旨在幫助工程師優(yōu)先處理最敏感、風(fēng)險最高的代碼審查請求。

在中國，大廠也已在實踐。比如阿里巴巴的“通義靈碼”AI編程助手已深入數(shù)萬開發(fā)者的日常，官方數(shù)據(jù)顯示，每天有超過一半的有效代碼評審意見已由AI自動產(chǎn)生。在人工評審量小幅下降的背景下，總體有效評審量（含AI意見）實現(xiàn)了同比翻倍。阿里甚至聯(lián)合高校開源了業(yè)界首個多語言、具備存儲庫上下文感知的CodeReview Benchmark，試圖為AI代碼評審設(shè)立行業(yè)標(biāo)準(zhǔn)。

初創(chuàng)公司也看到了其中的巨大機遇。像Qodo這樣的公司，專注于打造“AI代碼生成->風(fēng)險發(fā)現(xiàn)->自動審查->治理修復(fù)”的全流程平臺，并因此獲得了巨額融資，預(yù)示著代碼質(zhì)量管理市場即將迎來爆發(fā)。

在所有嘗試中，最引人注目也最富爭議的，是Anthropic的Project Glasswing。這個項目最早圍繞Claude Mythos Preview展開，集結(jié)了AWS、蘋果、谷歌、微軟、思科、Linux基金會等科技與開源生態(tài)里的關(guān)鍵玩家，后來又?jǐn)U大到約150個新機構(gòu)，覆蓋電力、水務(wù)、醫(yī)療、通信、硬件等關(guān)鍵基礎(chǔ)設(shè)施領(lǐng)域。

它的目標(biāo)不只是讓AI找漏洞、修漏洞，更是提前演練一個問題：當(dāng)強大的AI模型足以大規(guī)模發(fā)現(xiàn)軟件缺陷時，網(wǎng)絡(luò)安全行業(yè)該如何驗證、披露、修補這些突然涌來的漏洞。

Mythos Preview的能力已經(jīng)足夠讓行業(yè)緊張。Anthropic稱，Project Glasswing啟動后的幾周里，它和大約50個合作伙伴用Mythos Preview發(fā)現(xiàn)了超過1萬個高危或嚴(yán)重級別的軟件漏洞。Mozilla的案例更直觀：Firefox團隊把Claude Mythos Preview接入安全排查流程后，在Firefox150版本中修復(fù)了271個由這輪評估發(fā)現(xiàn)的漏洞，其中不少是過去需要頂級安全研究員長時間推理才能發(fā)現(xiàn)的問題。

但問題也隨之反過來了。Anthropic最初沒有把Mythos Preview向普通用戶開放，理由是它的網(wǎng)絡(luò)安全能力太強，可能被濫用。

6月，Anthropic試圖用兩條線推進：一邊推出受防護的Fable5，面向更廣泛用戶；一邊推出限制更少的Mythos5，繼續(xù)給少數(shù)安全團隊使用。但幾天后，美國政府以國家安全和出口管制為由要求暫停外國人訪問Fable5和Mythos5，Anthropic隨即關(guān)閉了所有客戶對這兩個模型的訪問。

這讓Mythos成了一個非常典型的AI時代矛盾：它可能是修補軟件漏洞的利器，也可能被用來更快地發(fā)現(xiàn)和利用漏洞。

AI既是矛，也是盾。最有可能緩解AI代碼安全問題的工具，本身也可能成為新的安全風(fēng)險源。

那么，人類審查，是AI時代的軟件瓶頸嗎？

也許是。但它也是當(dāng)下的最后一道防線。

AI提高生產(chǎn)力，本應(yīng)讓人類擺脫重復(fù)勞動。然而在當(dāng)前階段，它卻也增加著工作量，而非減少。是AI跑得過快，還是人類不夠快？這也許是一個需要讓時間來回答的問題。