你有沒有想過一個問題：如果一家公司同時要做十個不同的網站項目，最後會變成什麼樣子？
大概率是這樣的：每個網站都有自己的聯繫表單，每個表單都要檢查郵箱格式對不對，每個團隊都各自寫了一遍這個檢查邏輯。十個項目，十份幾乎一樣又不完全一樣的代碼。哪天老闆說郵箱驗證規則要改，十個項目就要改十遍，改漏一個都算你沒做完。
這不是段子，這是軟體行業幾十年來一直存在的真實痛點。現在這個痛點被放大了，因為寫代碼的不再只是人類程序員，還有大量的AI編程智能體在批量生產代碼。KAIST的研究團隊盯上了這個問題，寫了一篇論文，專門討論當AI要連續生成一堆相關軟體項目時，應該怎麼避免代碼越寫越亂。
**AI寫代碼寫多了，也會"發福"**
先說一個背景知識。
現在的AI編程智能體已經能獨立生成不算簡單的完整應用了，從頭到尾寫出一個能跑起來的網站或工具，這在幾年前是不可想像的。但真實的軟體開發場景里，幾乎沒有人只做一個孤立的項目。企業通常維護的是一整套相關應用的組合，它們共享業務邏輯、界面風格、操作習慣，只是各自獨立部署。
問題就出在這裡。如果讓AI一個一個項目地做，每個項目都是從零開始理解需求、從零開始寫代碼，那麼共享的那部分邏輯就會被重複實現無數次。更麻煩的是，已經有研究（SlopCodeBench
）發現，AI智能體在長時間維護代碼的過程中會產生"slop"，也就是代碼依然能跑，功能依然正確，但會變得越來越囉嗦、越來越繞、結構越來越亂。這個現象有點像人變胖，功能沒壞，但整體狀態在變差。
如果是N個AI智能體分別獨立維護N個項目，這個"發福"過程會被放大N倍，因為每個智能體都在各自的軌道上重新發明輪子，各自積累自己的冗餘代碼，彼此之間的差異也會越來越大。
研究團隊把這個場景定義成一個新問題，叫做**Super Library Agent問題**，簡稱SLA。
超級庫智能體問題：當一個AI智能體需要按順序生成N個相關的應用程式時，它不僅要完成每個應用本身，還要同時維護一個跨應用共享的"超級庫"，把可復用的代碼組件放進去，供後續應用調用。
這個設定聽起來簡單，實現起來卻處處是坑。
**樸素方案為什麼會失敗**
研究團隊先搭了一個最樸素的方案，作為對照組。這個方案的邏輯很直白：一個編碼智能體先生成新應用的代碼，然後另一個庫維護智能體掃描已有的所有代碼，把重複出現的部分提取到共享庫里，同時把老代碼改成調用新庫的形式。
聽起來很合理對不對？但實際跑起來，這套樸素方案暴露出兩個致命問題。
第一個問題是提取召回率低。
功能上完全等價的兩段代碼，寫法可能天差地別。一個開發者可能用try-catch包一層再讀寫localStorage，另一個開發者可能封裝成一個獨立函數再調用，表面上看完全不像同一個東西。如果庫維護智能體只靠表面相似度或者代碼文本匹配去找可復用的部分，很多真正該合併的代碼就會被漏掉。
這就好比你讓一個新來的倉庫管理員去清點貨架，只憑包裝盒長得像不像來判斷是不是同一種商品。結果同一款零食，因為換了一批新包裝，就被當成了兩種完全不同的商品分別上架。倉庫越來越大，重複的貨架也越堆越多，管理員卻渾然不覺，因為他根本沒有意識到自己漏掉了什麼。如果不換個判斷標準，貨架的冗餘只會越滾越大。
第二個問題是遷移的正確性沒法保證。
這個問題更隱蔽。把一段本地代碼提取到共享庫里，絕不只是把代碼剪切粘貼那麼簡單。原來調用這段代碼的地方需要改成導入庫的寫法，依賴這段代碼的其他函數也要跟著調整，有時候連周邊的接口設計都要聯動修改。一個不夠細緻的遷移智能體，很可能只把明面上能看到的那部分代碼換掉了，卻漏掉了背後一連串的連鎖調用關係，結果留下一堆調用不到的死代碼，或者乾脆引用報錯。
**候選引導式提取：先猜再驗證**
針對第一個問題，研究團隊設計了一套叫做**索引式候選提取**的機制。
核心思路是：不要直接比較代碼文本長得像不像，而是先讓AI把每一段代碼翻譯成一句自然語言摘要，再拿這些摘要去做匹配。
代碼分塊*：研究團隊用一種叫做AST（抽象語法樹）的技術，把每個代碼文件切分成函數、類、模組這樣有語義邊界的小塊。切好之後，用一個輕量級的AI模型給每一小塊寫一句不超過160個字符的英文摘要，說明這段代碼是幹什麼的。
這個轉換的意義在於，兩段寫法完全不同但功能一樣的代碼，翻譯成自然語言之後，摘要往往會長得很像。比如一個"用useState加try-catch讀寫localStorage"的寫法，和另一個"直接調用getItem和setItem"的寫法，翻譯成人話都是"從本地儲存讀取並持久化數據"。這時候一個專門的候選選擇智能體，就可以拿著這些摘要去跨應用比對，找出哪些模式在兩個以上的應用里反覆出現。
這就好比一個精通十幾種方言的翻譯，不管你說的是四川話還是廣東話，只要意思是"我想喝一杯熱水"，他都能聽出來這是同一個需求。而如果換成一個只會按發音死記硬背的助理，四川話的"要杯熱水"和廣東話的"要杯熱水"發音完全不同，他可能壓根反應不過來這是同一件事，然後就把這兩個需求當成兩回事分別處理，重複勞動就這麼產生了。
論文裡還提到一個細節，叫做**預提取代碼庫整合**。
在真正跨應用做提取之前，先對每個新生成的應用內部做一次"自我整理"，把同一個應用里重複或者高度相似的本地實現先合併成一個模組。這一步的意義在於，如果不先做這個內部整理，直接跨應用去找共享模式，那個負責跨應用提取的智能體會因為看不到應用內部已經有的重複，而漏掉本該被識別出來的抽象機會。實驗數據也驗證了這一點：去掉這一步之後，冗餘度（Verbosity）從0.0994漲到0.1264，結構侵蝕度（Erosion）從0.0987漲到0.1263，代碼行數也明顯變多。
**上下文感知遷移：不止替換，還要順藤摸瓜**
針對第二個問題，也就是遷移容易出錯的問題，研究團隊提出了**上下文感知依賴遷移**這套機制，裡面有兩個關鍵設計。
第一個是**提取軌跡**。
每次庫維護智能體新增或更新一個共享庫里的組件，都會同時生成一份結構化的記錄文檔，寫清楚這個組件是從哪些應用的哪些代碼塊提取出來的、為什麼這個模式可以被泛化、以及原來的代碼應該怎麼替換成新的庫調用方式。這份記錄會交給負責遷移的智能體，讓它不用重新猜測兩者的對應關係，直接照著說明書操作。
第二個是**調用圖條件約束**。
對於每一個待遷移的候選項，系統會自動分析代碼的調用關係，把這段代碼的調用者和被調用者列出來，一起打包提供給遷移智能體，提示它需要聯動修改的範圍有哪些。
這兩個設計合起來，效果類似於裝修房子時，工頭不光告訴工人"把這堵牆拆了"，還附上一張標註了水管走向和電線位置的圖紙。如果沒有這張圖紙，工人可能真的只是把牆拆了，但牆裡埋的水管和電線該怎麼接、接到哪裡，全靠工人自己現場猜。猜對了沒事，猜錯了輕則漏水，重則短路。論文的消融實驗顯示，去掉調用圖條件約束之後，準確率從77.21%掉到74.48%，冗餘度和結構侵蝕度雙雙上升，說明去掉這個約束之後，遷移智能體確實會留下更多沒清理乾淨的死代碼。
**實驗結果：數字說話**
研究團隊在兩個基準測試上驗證了這套完整方案，一個叫WebGen-Bench，專門測試網站生成能力，另一個叫PaperBench，專門測試能否復現AI科研論文裡的實驗代碼。
在WebGen-Bench上，完整方案（論文裡稱為SLA-FULL）相比零樣本基線（每個項目獨立生成，互不復用）取得了這樣的結果：
代碼總行數下降9.0%，token總量下降6.7%，冗餘度下降38.0%，同時功能準確率還提升了1.5%，視覺外觀評分基本持平。
在PaperBench上，代碼行數下降5.0%，token量下降7.4%，結構侵蝕度下降10.4%，功能得分反而提升了2.6%。
這裡有一個很值得說的對比。有一個後處理式的對照方法叫做Librarian，它的做法是等所有項目都寫完了之後，再統一做一次庫重構。它確實在MDL（一種衡量代碼資訊熵的指標，數值越低說明代碼越規整）這個指標上做到了最優，但它的結構侵蝕度反而比零樣本基線還要高。這說明單純為了壓縮代碼體積而做的後處理重構，可能會把複雜度都堆到幾個共享組件里，代碼總量看著小了，但局部反而更臃腫難懂了。這也側面證明了論文強調的觀點：庫的構建應該是在線的、跟著開發進度同步進行的過程，而不是完事之後再補救。
**維護階段的真正考驗**
光看初次構建的效果還不夠，真正的考驗在後續維護。
研究團隊設計了一個後續實驗：先讓各個方法把八個項目按順序都跑完，然後統一下發一個跨應用的政策更新，比如"所有聯繫表單必須校驗郵箱格式包含@和句號"這樣的通用規則，看看不同方法要改多少代碼才能滿足這個新要求。
結果非常直觀。零樣本方案因為每個項目完全獨立，需要在每一個用到郵箱校驗的項目里各自加一遍校驗邏輯，總共改動了936行代碼。而完整方案因為已經把郵箱校驗的邏輯沉澱進了共享庫里，只需要在庫里改一次，絕大多數應用甚至一行代碼都不用動，總改動量只有256行，減少了超過70%。
這個對比像極了你家小區突然通知所有單元都要統一更換門禁卡系統。如果每棟樓的物業各自為政，那就得挨個樓棟分別採購、分別施工、分別培訓住戶，十棟樓干十遍。但如果小區本來就有一套統一的門禁管理平台，物業只需要在後台改一次配置，所有樓棟自動同步生效。這裡的差別不是誰更聰明，而是有沒有提前把"共同的東西"抽出來放在一個大家都認的地方。
除了改動量變小，研究團隊也檢驗了改動之後原來的功能有沒有被破壞，結果顯示完整方案在保持原有功能、滿足新需求、維持視覺質量這幾項上，表現都跟其他方法處在同一水平線，沒有出現"為了省事而犧牲質量"的情況。
**庫里到底裝了什麼樣的東西**
論文還做了一個挺細緻的分析，看共享庫里沉澱下來的組件到底是些什麼類型。
研究團隊把高復用組件（被八個應用里至少四個引用的組件）分成三類：基礎界面元件（比如按鈕、頁腳這類通用控制項）、行為型鉤子工具（比如處理本地儲存、搜索過濾這類邏輯封裝）、以及頁面級或業務級模式（比如聯繫表單、卡片網格這類組合型組件）。
結果顯示，除了那個後處理式的Librarian方法之外，其他方法提取出來的基礎界面元件數量差不多，但完整方案在行為型工具和頁面級模式這兩類上明顯更豐富。舉個例子，樸素方案提取出來的往往是Header、Footer這種最基礎的組件，而完整方案能進一步提取出useFilteredList（過濾列表邏輯）、FeatureCardGrid（功能卡片網格）這類更高階的抽象。
這說明基於自然語言摘要的提取方式，確實拓寬了庫的語義覆蓋範圍，而不只是把淺層的、顯而易見的重複找出來。
論文還統計了庫組件的復用廣度分布。完整方案平均能沉澱出13.3個導出組件，其中被6到8個應用共同引用的高頻組件平均有4.8個，相比之下樸素方案只有2.0到2.7個。這意味著完整方案不是簡單地把復用密度堆高在少數幾個組件上，而是真的構建出了一個規模更大、被更多應用真實用到的共享庫。
**一個額外的發現：成熟的庫能讓新項目寫得更好**
論文最後還做了一個挺有意思的補充實驗，檢驗一個已經積累了一定規模的共享庫，能不能反過來幫助生成全新的應用。
研究團隊讓一個普通的編碼智能體去生成八個內容展示類應用，一組不給它任何共享庫，另一組給它之前實驗裡已經沉澱好的完整版共享庫，其他條件全部一致。
結果顯示，有庫可用的那一組，界面測試準確率從80.95%提升到84.35%，外觀評分也略有提升，同時應用本地的代碼量明顯減少，即使把庫本身的代碼也算進去，總代碼行數依然下降了約11%。
這個現象其實挺符合直覺：一個新手廚師如果廚房裡已經備好了高湯、醬料這些半成品，做菜的時候就能省去很多重複勞動，把精力放在真正體現這道菜特色的部分上，做出來的菜反而可能更精細。反過來，如果什麼都要從頭熬製，時間和精力都被基礎工序占掉了，成品質量未必能保證。
**論文也坦誠的局限**
研究團隊在論文裡很坦率地承認了兩個局限。
第一個是目前還沒有專門為這類問題設計的原生基準測試。現有的WebGen-Bench和PaperBench都不是為長周期庫演化設計的，研究團隊是把單任務基準改造成了順序任務序列來湊合用的。這意味著被維護的應用本身就是基準測試產物，沒有真實用戶、沒有提交歷史，補丁量的減少能不能在真實項目里復現，其實還沒有被驗證過。
第二個局限是維護過程的度量方式。目前的可維護性評估主要靠代碼行數、重複度、冗餘度這些代理指標，這些指標能反映一部分信號，但沒法完全衡量一個代碼庫是不是真的更容易被人理解、修改、擴展。真正的可維護性需要通過反覆的實際變更才能被檢驗，而論文目前只測了一輪維護。
Q&A
Q1：Super Library Agent問題解決的核心痛點是什麼？
A：當AI智能體需要連續生成多個相關的應用程式時，如果各自獨立開發，會導致相同的業務邏輯在每個項目里重複實現，而且長時間維護還會讓代碼變得越來越冗餘混亂。Super Library Agent的思路是讓智能體在生成新應用的同時維護一個共享庫，把跨應用復用的組件沉澱進去，從而減少重複、提高整體可維護性。
Q2：索引式候選提取和普通的代碼相似度匹配有什麼區別？
A：普通匹配靠比較代碼文本或結構相似度，容易漏掉寫法不同但功能相同的代碼。索引式候選提取先把每段代碼翻譯成自然語言摘要，再基於摘要做跨應用匹配，這樣即使兩段代碼寫法完全不同，只要功能描述相似就能被識別為可復用候選，大幅提高了提取召回率。
Q3：這套方法在實際測試中效果如何？
A：在WebGen-Bench測試中，完整方案相比獨立生成的基線，代碼行數減少9%，token量減少6.7%，冗餘度減少38%，同時功能準確率還提升了1.5%。在後續的維護測試中，需要改動的代碼量比獨立生成方式減少超過70%。
