2024年，JetBrains內部測試顯示：讓AI代理（AI Agent，自主執(zhí)行任務的智能程序）遷移代碼，技術通過率100%，但架構評審通過率不到40%。問題不在AI寫不出能跑的代碼，而在于它讀不懂"這里不該這么寫"的潛臺詞。

AI代理的盲區(qū)：把"最常見"當成"最正確"

當你讓AI代理寫代碼，它的標準操作是翻遍代碼庫找例子?？吹侥硞€模式出現100次，它就默認這是團隊認可的寫法。這種策略在小型項目里勉強能用，放到存活15年以上的老代碼庫里就是災難。

JetBrains TeamCity技術負責人Pavel Sher打了個比方：「代理看到100個舊實現，會以為這是標準。但它分不清哪些是團隊想保留的，哪些是還沒來得及刪的技術債?！?/p>

TeamCity的代碼庫始于2006年。團隊一直在用新API替換舊數據庫接口，但遷移進度參差不齊。有些模塊已經完成現代化，有些還卡在2015年的實現方式。AI代理掃描全局時，舊代碼的數量優(yōu)勢直接扭曲了它的判斷。

一次具體實驗暴露了這個問題。團隊要求代理將幾個類從舊數據庫API遷移到新API。新接口的設計哲學完全不同：舊API是命令式、逐行處理；新API是聲明式、批量操作。這不是改幾個方法名能解決的，需要重新設計數據流和錯誤處理策略。

代理交出的初稿讓測試全綠，代碼能跑。但Pavel Sher在評審時發(fā)現了致命傷：API調用確實換成了新的，但周圍的錯誤處理、數據結構、控制流全是舊設計。相當于給馬車裝了電動車馬達——動力源換了，整體架構還是19世紀的。

第一個補?。河?已審核案例"替代"全局掃描"

團隊調整了策略。不再讓AI自己翻代碼庫找規(guī)律，而是人工挑選已經通過評審的遷移案例，明確告訴代理："Class A是這么遷的，Class B照這個來。"

效果立竿見影。代理的輸出從"技術正確但架構混亂"變成了"與團隊現有實踐一致"。Pavel Sher注意到，代理開始復用新API推薦的設計模式，而不是被周圍舊代碼帶偏。

這個改動背后的邏輯很樸素：代碼庫里的頻率分布不等于團隊的真實意圖。人工篩選的案例雖然數量少，但代表了"我們認可的做法"，比100個未經甄別的舊實現更有指導價值。

JetBrains沒有公布具體數字，但內部反饋稱這一調整讓"概念一致性"問題的出現頻率下降了約60%。

更深的問題：隱性知識怎么編碼

案例驅動的方法解決了眼前的問題，但Pavel Sher清楚這不夠徹底。TeamCity的代碼評審中，大量判斷依賴無法寫成文檔的隱性知識。

他舉了個例子：某個模塊的錯誤處理風格看起來過時，但團隊暫時不想動，因為上游依賴即將被替換，現在重構是浪費精力。這種"暫時容忍"的決策，代碼庫里沒有任何標記，AI代理不可能自己推斷出來。

「有些規(guī)則我們寫了文檔，有些只存在于老成員的腦子里，」Pavel Sher說，「代理需要一種方式接觸到后者，否則永遠會在錯誤的時間做正確的事。」

JetBrains的實驗還在繼續(xù)。他們正在測試讓代理主動詢問不確定的決策，而不是默認選擇最頻繁的選項。另一個方向是讓代理對比"最近修改的代碼"和"很久沒動的代碼"，用時間維度輔助判斷哪些模式代表當前方向。

這些探索指向同一個核心：AI代理的"上下文窗口"（Context Window，模型能同時處理的文本長度）在物理上越來越寬，但"有效上下文"——真正理解項目演進脈絡的能力——仍然需要人工搭建橋梁。

2024年底，TeamCity團隊將部分實驗成果整合進了JetBrains AI Assistant的代碼生成功能。用戶反饋中最常見的一條是：代理現在"少問蠢問題了"——它不再執(zhí)著于復用明顯過時的工具類，而是能識別出哪些代碼是團隊近期主動引入的新模式。

Pavel Sher最近評審的一個PR里，代理主動避開了某個被標記為"待廢棄"的緩存接口，盡管該接口在代碼庫里仍有200多處調用。這個判斷沒有寫在任何文檔里，是從三個月內的提交記錄中推斷出來的。

「它終于開始看日期了，」Pavel Sher在內部備注里寫，「下一步是讓它理解為什么那個接口被標記廢棄——這部分代碼庫里可沒有?！?/p>