去年TeamCity團隊做了個實驗：讓AI把舊數(shù)據(jù)庫API遷移到新版本。代碼能跑，測試全過，資深工程師Pavel Sher卻直接打回——新API套著舊架構(gòu)，像給電動車裝了個蒸汽機的殼子。

這不是個例。AI寫代碼的能力已經(jīng)夠用了，真正卡脖子的是"代碼品味"。

頻率≠正確：AI的"從眾陷阱"

AI agent（智能體）的工作原理聽起來很合理：掃描代碼庫，找到重復(fù)100次的模式，照著寫。問題是，那100次重復(fù)的可能正是團隊想淘汰的 legacy code（遺留代碼）。

Pavel Sher打了個比方：agent看到滿地的舊鞋印，以為那是路，其實大家只是在繞開前面的坑。

TeamCity作為2005年誕生的老牌CI/CD工具，代碼庫里埋著近20年的技術(shù)債。實驗里那個遷移任務(wù)，新API和舊API不是簡單替換關(guān)系，需要重新設(shè)計數(shù)據(jù)流、錯誤處理、邊界情況處理。AI交上來的作業(yè)，API調(diào)用是新了，周圍的骨架全是老的——它把"保持一致"執(zhí)行得太徹底了。

核心矛盾在于：AI能判斷"能不能跑"，但判斷不了"該不該這么寫"。

第一個補丁：用"先例"替代"頻率"

團隊的第一個改進很樸素。不再讓AI自己翻代碼庫找規(guī)律，而是直接喂給它已經(jīng)通過評審的遷移案例。

指令變成："Class A是這么遷的，Class B照做。"

效果立竿見影。AI開始模仿被認可的做法，而不是被重復(fù)的做法。Pavel注意到，agent生成的代碼結(jié)構(gòu)開始貼近團隊真正想要的方向，legacy patterns（遺留模式）的殘留明顯減少。

但這個方案有天花板。先例再多，也覆蓋不了所有場景。遇到?jīng)]見過的邊界情況，AI還是會退回到"看周圍怎么寫"的安全模式。

團隊需要讓AI理解的不是"怎么做"，而是"為什么這么做"。

第二個補?。喊?設(shè)計意圖"寫進上下文

突破口來自一次復(fù)盤。Pavel在評審時發(fā)現(xiàn)，自己判斷代碼好壞的依據(jù)，很大程度上是"這個項目之前做過什么決定"。

那些決定很少寫在文檔里。它們散落在過去的pull request討論、代碼評審注釋、架構(gòu)決策記錄（ADR）里。新人靠耳濡目染慢慢吸收，AI沒這個條件。

團隊開始實驗：把這些分散的設(shè)計意圖整理成結(jié)構(gòu)化上下文，隨任務(wù)一起喂給AI。

具體做法分三層。第一層是顯式規(guī)則——命名規(guī)范、API白名單、禁止使用的模式，直接寫進系統(tǒng)提示。第二層是遷移先例，像之前那樣打包成案例庫。第三層最關(guān)鍵：提煉"我們?yōu)槭裁催x這個方案"的簡要說明，讓AI理解約束背后的邏輯。

舉個例子。舊API的錯誤處理是返回null，新API改為拋異常。AI如果只模仿先例，會在新場景下機械復(fù)制；但如果同時告訴它"我們正從靜默失敗轉(zhuǎn)向快速失敗，方便調(diào)試"，agent遇到未覆蓋的情況時，能做出方向一致的判斷。

Pavel的觀察是：AI開始表現(xiàn)出類似"代碼嗅覺"的東西——說不清為什么，但知道這里該改。

還沒解決的：誰來維護"意圖"？

這套方法在TeamCity的實驗里跑通了，但團隊很清楚代價。設(shè)計意圖的整理是人工活，需要熟悉項目歷史的人持續(xù)投入。 precedents（先例庫）會膨脹，需要定期清理過時的。規(guī)則寫多了，AI可能變得過于保守，錯過合理的創(chuàng)新。

更深層的問題是：當(dāng)AI開始依賴這些上下文，代碼庫本身的"自解釋性"會不會變差？新人不再通過讀代碼學(xué)規(guī)矩，而是直接問AI，那些未成文的團隊智慧會不會斷層？

JetBrains沒有給出標(biāo)準(zhǔn)答案。他們開源了實驗框架，把問題拋給了更廣泛的開發(fā)者社區(qū)。

一個有趣的細節(jié)是，Pavel現(xiàn)在評審AI生成的代碼時，會特意檢查agent有沒有"過度學(xué)習(xí)"某個先例——就像老師看學(xué)生是不是在死記硬背。最近一次，他發(fā)現(xiàn)一個agent在三個不同場景下用了同一套異常處理模式，其中兩個合適，一個明顯過度設(shè)計。他在評審注釋里寫："這里不需要這么重，參考#2847的討論。"

那條注釋會被收錄進下一個版本的上下文。AI的"品味"就是這樣，一行一行地，從人的判斷里長出來。