有個(gè)數(shù)據(jù)挺有意思：用AI寫代碼的人，平均花在返工上的時(shí)間比手寫多40%。這不是我編的，是GitClear去年拉取1.5億行代碼后算出來(lái)的。我看完覺(jué)得他們矯情，直到自己栽了跟頭。

「 obvious 」是個(gè)危險(xiǎn)的詞

項(xiàng)目開(kāi)始那天，我對(duì)著屏幕敲下第一行提示詞。需求很明確——一個(gè)內(nèi)部工具，對(duì)接三個(gè)API，做數(shù)據(jù)清洗和可視化。以前這種活兒，我得先寫PRD，拆任務(wù)，畫架構(gòu)圖，再吭哧吭哧編碼。

這次不一樣。我把需求丟給AI，讓它生成用戶故事和驗(yàn)收標(biāo)準(zhǔn)；把標(biāo)準(zhǔn)丟回去，讓它出技術(shù)方案；再把方案丟回去，讓它寫代碼。我只需要盯著架構(gòu)設(shè)計(jì)和集成點(diǎn)，代碼審查只看編譯錯(cuò)誤和「明顯的邏輯問(wèn)題」。

AI的速度是真實(shí)的。第一天結(jié)束，倉(cāng)庫(kù)里有了完整的腳手架和CRUD接口。第三天，前端頁(yè)面能跑通主流程。第二周，功能清單打勾過(guò)半。Git提交記錄像瀑布一樣往下滾，綠得發(fā)亮。

「這邏輯 obvious 啊，」我跟同事說(shuō)，「AI處理確定性任務(wù)，人類抓不確定性，分工明確?！?/p>

當(dāng)時(shí)我沒(méi)意識(shí)到，「obvious」這個(gè)詞本身就是個(gè)陷阱。

第18天的裂縫

問(wèn)題是從一個(gè)邊緣case開(kāi)始的。某個(gè)API返回的數(shù)據(jù)格式偶爾會(huì)變，AI寫的解析代碼沒(méi)做防御，直接拋異常。我讓AI修，它加了個(gè)try-catch，把異常吞掉，返回空對(duì)象。下游模塊拿到空對(duì)象，繼續(xù)跑，把臟數(shù)據(jù)寫進(jìn)數(shù)據(jù)庫(kù)。

我發(fā)現(xiàn)了，罵了句臟話，讓AI重寫。它加了一層校驗(yàn)，但校驗(yàn)邏輯和另一個(gè)模塊的判斷條件沖突。修復(fù)A，B炸；修復(fù)B，C炸。我開(kāi)始在三個(gè)文件之間打地鼠，每個(gè)補(bǔ)丁都是AI生成的，每個(gè)補(bǔ)丁都帶來(lái)新的副作用。

更麻煩的是代碼本身。AI寫的函數(shù)平均長(zhǎng)度是我手寫的2.3倍（我后來(lái)統(tǒng)計(jì)的），變量命名跟著訓(xùn)練數(shù)據(jù)的分布走，時(shí)而是駝峰，時(shí)而是下劃線，時(shí)而突然出現(xiàn)一個(gè)「temp_data_final_v2」。注釋？有，但都是「This function handles the data」這種正確的廢話。

我試圖重構(gòu)，但看不懂調(diào)用鏈。AI在生成代碼時(shí)做了大量隱式假設(shè)——這個(gè)全局變量會(huì)被初始化、那個(gè)配置項(xiàng)一定存在、網(wǎng)絡(luò)請(qǐng)求永遠(yuǎn)不會(huì)超時(shí)——這些假設(shè)散落在47個(gè)文件里，沒(méi)有文檔，沒(méi)有測(cè)試覆蓋。

第18天晚上，我盯著覆蓋率報(bào)告：核心模塊38%，邊緣模塊0%。但所有功能「看起來(lái)」都正常。

第23天的決定

崩潰發(fā)生在演示前三天。測(cè)試環(huán)境的數(shù)據(jù)量突然增大，一個(gè)AI寫的批量處理腳本把內(nèi)存吃光了。我查日志，發(fā)現(xiàn)它把整個(gè)數(shù)據(jù)集拉進(jìn)內(nèi)存做排序，而不是用流式處理。這個(gè)模式在代碼里重復(fù)出現(xiàn)了11次，都是AI從同一個(gè)訓(xùn)練樣本里學(xué)來(lái)的「最佳實(shí)踐」。

我試圖優(yōu)化，但每個(gè)改動(dòng)都牽扯出新的依賴。某個(gè)「工具函數(shù)」被17個(gè)地方調(diào)用，修改簽名意味著連鎖反應(yīng)。我開(kāi)始懷疑：這些代碼真的是我「審查」過(guò)的嗎？還是我只是看了diff，點(diǎn)了approve，因?yàn)椤缚雌饋?lái)沒(méi)問(wèn)題」？

第23天，我做了一個(gè)決定：刪掉主干代碼，重寫。

不是全部——基礎(chǔ)設(shè)施、配置、部分UI組件還能留。但核心業(yè)務(wù)邏輯，那8000多行AI生成的TypeScript，我一行一行用手敲替代。速度很慢，第三天只寫了400行。但每一行我都知道為什么存在，每一個(gè)分支我都想過(guò)邊界條件。

重寫過(guò)程中，我發(fā)現(xiàn)AI之前「解決」過(guò)三次的那個(gè)API格式問(wèn)題，根本原因是合同沒(méi)對(duì)齊。甲方文檔寫的是v2版本，實(shí)際部署的是v2.1，字段名差了一個(gè)下劃線。AI每次都在癥狀層打補(bǔ)丁，從沒(méi)問(wèn)過(guò)「為什么這個(gè)字段有時(shí)存在有時(shí)不存在」。

它不會(huì)問(wèn)。問(wèn)問(wèn)題是我的工作。

重新理解「杠桿」

項(xiàng)目最終上線了，比原計(jì)劃晚兩周。我復(fù)盤時(shí)算了筆賬：AI幫我省了大約60%的初始編碼時(shí)間，但花在調(diào)試、重構(gòu)、返工上的時(shí)間多了340%。凈收益是負(fù)的。

但我沒(méi)扔掉AI工具。相反，我現(xiàn)在用它更頻繁了——只是場(chǎng)景變了。

寫正則表達(dá)式？扔給AI，它比我會(huì)背語(yǔ)法。生成測(cè)試數(shù)據(jù)？AI能造出我想不到的邊界case。學(xué)習(xí)陌生庫(kù)？AI的示例代碼比官方文檔快十倍。

但架構(gòu)設(shè)計(jì)、狀態(tài)管理、錯(cuò)誤處理策略、那些「如果失敗了怎么辦」的問(wèn)題——這些我親手寫。不是信不過(guò)AI，是因?yàn)檫@些決策的代價(jià)不在當(dāng)下，而在六個(gè)月后的某個(gè)凌晨三點(diǎn)。

有個(gè)類比我后來(lái)常用：AI是GPS導(dǎo)航。市區(qū)通勤，完全信任它，省時(shí)省力。但你要是去荒野徒步，最好自己帶地圖。GPS不會(huì)告訴你哪座橋年久失修，哪條路被山洪沖斷——它只會(huì)在你開(kāi)進(jìn)河里之后，平靜地說(shuō)「正在重新計(jì)算路線」。

我那三周寫的代碼，就是一路「重新計(jì)算」出來(lái)的。每個(gè)補(bǔ)丁都是一次「前方掉頭」，最終把我?guī)нM(jìn)了一片沼澤。

現(xiàn)在我的IDE里還裝著那個(gè)AI插件，快捷鍵沒(méi)改。但每當(dāng)我按下那組鍵，會(huì)先停半秒，問(wèn)自己：這段代碼如果明年出問(wèn)題，我能在酒醒后看懂嗎？

答案如果是否定的，我就自己動(dòng)手。

你最近一次用AI生成的代碼，現(xiàn)在還能不看注釋說(shuō)出它的核心假設(shè)嗎？