谷歌50%代碼靠AI寫(xiě)，交付速度反而跌了

AI工具幫谷歌寫(xiě)了50%的代碼，微軟也有30%。這個(gè)數(shù)字放在三年前，足夠讓CTO們集體高潮。但一個(gè)反常識(shí)的事實(shí)是： shovelware（粗制應(yīng)用）沒(méi)有爆發(fā)，反而在減少。更扎心的是，越來(lái)越多工程師覺(jué)得AI在拖慢他們。

Stack Overflow去年調(diào)研了3萬(wàn)多名開(kāi)發(fā)者，45%的人把"調(diào)試更耗時(shí)"列為AI帶來(lái)的最大痛點(diǎn)。不是AI寫(xiě)得慢，是工程師讀不懂AI寫(xiě)的代碼。就像你讓實(shí)習(xí)生一夜趕出80頁(yè)P(yáng)PT，第二天匯報(bào)時(shí)你根本接不住話(huà)。

代碼膨脹：AI的"數(shù)字肥胖癥"

PlayerZero團(tuán)隊(duì)追蹤了一個(gè)典型現(xiàn)象：某團(tuán)隊(duì)用AI輔助后，代碼提交頻率飆升300%，但生產(chǎn)事故響應(yīng)時(shí)間從平均2小時(shí)拉長(zhǎng)到6小時(shí)。問(wèn)題不是出在AI生成環(huán)節(jié)，是出在后邊的消化環(huán)節(jié)。

工程師Spencer在內(nèi)部復(fù)盤(pán)會(huì)上打了個(gè)比方：「以前我們像手藝人，工具是錘子和鑿子；現(xiàn)在像指揮交響樂(lè)團(tuán)，但樂(lè)譜是AI即興寫(xiě)的，你還得實(shí)時(shí)判斷哪個(gè)音符會(huì)走調(diào)。」

數(shù)據(jù)印證了這個(gè)困境。GitClear分析過(guò)1.5億行代碼變更記錄，發(fā)現(xiàn)AI輔助代碼的"代碼流失率"（上線(xiàn)后6個(gè)月內(nèi)被重寫(xiě)或刪除的比例）比人工代碼高出37%。換句話(huà)說(shuō)，AI在批量生產(chǎn)技術(shù)債，而技術(shù)債的利息是復(fù)利計(jì)算的。

調(diào)試地獄：不熟悉的地形最耗體力

傳統(tǒng)開(kāi)發(fā)中，調(diào)試約占30%工時(shí)。AI時(shí)代這個(gè)比例被打破了——不是降低，是結(jié)構(gòu)性地轉(zhuǎn)移了。以前是"我寫(xiě)我修"，現(xiàn)在是"我猜我修"。

一位在微軟Azure團(tuán)隊(duì)工作的工程師描述過(guò)典型場(chǎng)景：凌晨2點(diǎn)，告警響起。他點(diǎn)開(kāi)代碼，發(fā)現(xiàn)核心邏輯是三個(gè)月前Copilot生成的，自己只做過(guò)表面審查。「就像走進(jìn)別人家廚房找鹽，你知道肯定有，但每個(gè)抽屜都得翻一遍。」

Stack Overflow的調(diào)查里還有個(gè)細(xì)節(jié)被忽視了：62%的開(kāi)發(fā)者承認(rèn)，他們會(huì)因?yàn)?代碼不是自己寫(xiě)的"而傾向于整體重寫(xiě)，而非局部修復(fù)。這種心理成本沒(méi)有被任何效率計(jì)算器收錄。

工具鏈的"最后一公里"陷阱

AI編碼工具的商業(yè)模式有個(gè)先天缺陷：它們按"生成token數(shù)"或"使用時(shí)長(zhǎng)"收費(fèi)，天然鼓勵(lì)多寫(xiě)、快寫(xiě)。但軟件工程的真實(shí)成本從來(lái)不在"寫(xiě)"，在"維護(hù)"。

PlayerZero的觀察更尖銳：當(dāng)前AI工具解決的是"打字速度"，不是"思考速度"。當(dāng)工程師把認(rèn)知負(fù)荷從"設(shè)計(jì)"轉(zhuǎn)移到"審查"，整體系統(tǒng)風(fēng)險(xiǎn)在上升——因?yàn)閷彶楸仍O(shè)計(jì)更容易走過(guò)場(chǎng)。

谷歌內(nèi)部有個(gè)未公開(kāi)的指標(biāo)叫"代碼理解深度"，用AI輔助的模塊得分平均比人工模塊低22個(gè)百分點(diǎn)。這個(gè)數(shù)字沒(méi)有出現(xiàn)在任何財(cái)報(bào)里，但出現(xiàn)在無(wú)數(shù)次延期評(píng)審會(huì)的PPT腳注中。

組織層面的"代謝綜合征"

更隱蔽的問(wèn)題在團(tuán)隊(duì)層面。當(dāng)AI成為默認(rèn)選項(xiàng)，"代碼所有權(quán)"這個(gè)概念正在瓦解。

Netflix工程師曾分享過(guò)一個(gè)案例：兩個(gè)團(tuán)隊(duì)合并后，發(fā)現(xiàn)核心服務(wù)里有40%的代碼找不到明確負(fù)責(zé)人——不是沒(méi)寫(xiě)名字，是寫(xiě)名字的人自己也認(rèn)不出那是自己"審批"過(guò)的AI產(chǎn)出。「就像檔案館著火，你沖進(jìn)去救文件，發(fā)現(xiàn)每份都蓋著章，但沒(méi)人知道章是誰(shuí)刻的。」

這種模糊性直接推高了協(xié)作成本。原本5分鐘能確認(rèn)的改動(dòng)，現(xiàn)在需要跨3個(gè)時(shí)區(qū)拉會(huì)對(duì)齊。AI省下的打字時(shí)間，加倍償還給了組織溝通。

PlayerZero的結(jié)論是克制的：AI編碼工具的價(jià)值不在"更快交付功能"，在"降低特定類(lèi)型任務(wù)的門(mén)檻"。把兩者混為一談，是過(guò)去三年行業(yè)最大的集體幻覺(jué)。

他們給出的建議也反直覺(jué)——不是少用AI，是更刻意地保留"人工痕跡"：強(qiáng)制要求工程師手寫(xiě)核心邏輯的偽代碼，再讓AI填充；建立"代碼口述歷史"機(jī)制，每個(gè)模塊必須附3分鐘講解視頻；把代碼審查從"批作業(yè)"改成"結(jié)對(duì)考古"。

這些做法都在承認(rèn)一件事：軟件工程的瓶頸從來(lái)不是打字速度，是人對(duì)系統(tǒng)的理解深度。AI可以幫你跳過(guò)打字，但跳不過(guò)理解。

那位Stack Overflow的受訪(fǎng)者最后說(shuō)了句被調(diào)研報(bào)告埋在第47頁(yè)的話(huà)：「我現(xiàn)在寫(xiě)代碼的時(shí)間確實(shí)少了，但做夢(mèng)都在想那些我沒(méi)寫(xiě)過(guò)的代碼會(huì)不會(huì)在凌晨3點(diǎn)崩掉。」

當(dāng)50%的代碼來(lái)自AI，你的焦慮是減半了，還是翻倍了？