去年秋天，JetBrains TeamCity團(tuán)隊讓AI遷移一段數(shù)據(jù)庫API代碼。任務(wù)完成，測試通過，技術(shù)負(fù)責(zé)人Pavel Sher卻當(dāng)場打回——新API套著舊架構(gòu)，像給電動車裝蒸汽機活塞。

這不是個例。他們跑了47次對照實驗，發(fā)現(xiàn)AI代理有個致命習(xí)慣：看到代碼庫里出現(xiàn)100次的模式，就默認(rèn)這是"正確答案"。老項目的遺留代碼越多，AI抄作業(yè)抄得越歡。

AI的"從眾心理"：頻率=正確？

讓AI寫代碼的標(biāo)準(zhǔn)流程很簡單：掃描代碼庫，找相似場景，模仿現(xiàn)有模式。這套機制在小型項目里運轉(zhuǎn)良好，但遇到十年以上的老代碼庫就翻車。

TeamCity的實驗暴露了一個反直覺現(xiàn)象。AI代理會把"最常見"和"最推薦"劃等號——它看到舊錯誤處理邏輯出現(xiàn)上百次，就會在新代碼里原樣復(fù)刻，哪怕團(tuán)隊三年前就開始逐步替換這套方案。

Pavel Sher在內(nèi)部復(fù)盤時打了個比方：「這就像實習(xí)生第一天進(jìn)公司，發(fā)現(xiàn)所有人都在用某種笨拙的方式填報銷單。他不會去問有沒有更好的辦法，只會想'看來這就是這里的規(guī)矩'?！?/p>

問題的根源在于上下文缺失。人類工程師能分辨"這是歷史債務(wù)"和"這是現(xiàn)行標(biāo)準(zhǔn)"，AI只能統(tǒng)計出現(xiàn)頻次。當(dāng)舊模式在代碼量上占絕對優(yōu)勢時，AI的"學(xué)習(xí)"就變成了"繼承遺產(chǎn)"。

第一次修復(fù)：給AI看"優(yōu)秀作業(yè)"

TeamCity團(tuán)隊的第一個解法很樸素：不讓他只盯著現(xiàn)有代碼，而是提供已經(jīng)通過評審的遷移案例。

指令從"參考周圍代碼"變成"參考Class A的遷移方式，把同樣邏輯應(yīng)用到Class B"。這個微調(diào)讓輸出質(zhì)量顯著提升——AI開始模仿"被認(rèn)可的正確答案"，而非"出現(xiàn)頻率最高的答案"。

但局限很快暴露。這種方法依賴人工提前準(zhǔn)備足夠多的"樣板遷移"，且只適用于團(tuán)隊已經(jīng)做過類似工作的場景。遇到全新類型的重構(gòu)任務(wù)，AI又會回到老路。

更深層的問題是：AI仍然不理解"為什么"要這樣改。它只是在做模式匹配，而非真正的設(shè)計決策。

第二次迭代：讓AI先問"該不該"

團(tuán)隊引入了第二層機制——在生成代碼前，先讓AI評估當(dāng)前上下文中的設(shè)計選擇。

具體做法是：把代碼庫按模塊標(biāo)注狀態(tài)（"推薦做法"/"遺留代碼待重構(gòu)"/"過渡方案"），讓AI在動手前先判斷"我看到的這個模式，屬于哪一類"。

這個步驟把AI從"被動模仿者"變成了"有判斷能力的協(xié)作者"。實驗數(shù)據(jù)顯示，引入上下文評估后，需要人工返工的代碼比例從34%降到12%。

Pavel Sher在JetBrains技術(shù)博客中寫道：「我們不是在教AI寫代碼，是在教它像資深工程師一樣'看全景'。新手盯語法，老手看意圖。」

還沒解決的：AI的"設(shè)計嗅覺"

兩次改進(jìn)后，TeamCity的AI代理已經(jīng)能處理大部分結(jié)構(gòu)化遷移任務(wù)。但團(tuán)隊清楚，有些能力仍然無法自動化。

比如判斷"這個抽象層級是否合適"，或者"這個命名是否符合團(tuán)隊長期演進(jìn)方向"。這些決策依賴對項目歷史的理解，對業(yè)務(wù)域的感知，甚至對同事工作風(fēng)格的熟悉——恰恰是Pavel Sher這類資深工程師的核心價值。

JetBrains沒有公布具體時間表，但內(nèi)部路線圖顯示，下一階段的探索方向是"可解釋的設(shè)計決策"：讓AI不僅能輸出代碼，還能說明"為什么選擇這種結(jié)構(gòu)而非另一種"。

如果這一步走通，代碼評審的形態(tài)可能會變——人類審核的重點從"檢查對錯"轉(zhuǎn)向"評估設(shè)計取舍是否合理"。

TeamCity團(tuán)隊最后放出了一個細(xì)節(jié)：在47次實驗中，AI表現(xiàn)最差的一次，是讓它處理一個混合了三種不同設(shè)計風(fēng)格的模塊。那個模塊的代碼注釋里寫著"TODO: 統(tǒng)一重構(gòu)"，已經(jīng)掛了四年。

AI忠實地繼承了這份混亂——就像它看到的所有前輩那樣。