這項由賓夕法尼亞大學（University of Pennsylvania）開展的研究，以預印本形式發布於arXiv平台，編號為arXiv:2501.18916v2，最新版本更新於2026年6月23日。感興趣的讀者可通過該編號在arXiv資料庫中檢索完整論文。
程序員們有一個共同的煩惱：寫出來的代碼能跑，但跑得慢。就像一道菜做出來能吃，但味道和效率都還不夠好。專業的大廚會用多年積累的經驗和技巧，一步步把菜餚打磨到極致。那麼，能不能讓AI也學會這種"精益求精"的本領，把一段普通代碼反覆打磨成高效程序？
這正是這項研究要解決的核心問題。研究團隊發現，現有的大型語言模型（就是ChatGPT這類AI）其實並不擅長優化程序——因為訓練數據中幾乎沒有"程序跑得快慢"這類資訊，AI從來沒學過這個。所以光靠AI直接改代碼，效果非常有限。
為了突破這個瓶頸，研究團隊提出了兩套新方法：一套叫做"檢索增強搜索"（RAS），另一套叫做"原子編輯引導搜索"（AEGIS）。這兩套方法配合使用，讓AI在優化代碼時的平均速度提升幅度達到了人類程序員水平的兩倍多，甚至在某些測試中超越了人類選手的優化成果。
一、問題出在哪裡：AI改代碼為何總差點意思
要理解這項研究的價值，得先搞清楚"程序優化"到底是怎麼回事。假設你寫了一段代碼，功能正確，但運行起來很慢——就像你找到了正確的路，但走的是羊腸小道而不是高速公路。程序優化的任務，就是在不改變代碼功能的前提下，幫它找到那條"高速公路"。
現代編譯器（把人寫的代碼翻譯成機器能執行的語言的工具）會做一些自動優化，但這些優化都是"低層次"的，就像幫你把鞋帶系得更緊，卻沒辦法告訴你換一雙跑鞋。真正高水平的優化，往往需要改變算法本身——比如把一個每次都從頭搜索的笨方法，換成一個能記住中間結果的聰明方法。這種級別的優化，需要深刻理解程序在做什麼。
此前，賓夕法尼亞大學的團隊已經建立了一個名為PIE（Performance Improving Edits，性能提升編輯）的基準測試集，專門用來衡量各種AI方法在C++程序優化上的表現。他們發現，當時效果最好的"黑盒"方法（不調整AI權重、只靠提示詞驅動的方法）叫做"動態代碼檢索"——它的做法是在一個由"慢程序-快程序"配對組成的訓練資料庫中，根據代碼相似度找幾個相關案例，然後把這些案例餵給AI，讓AI學著照葫蘆畫瓢地改寫當前程序。
這個方法已經比什麼都不做強很多，但研究團隊覺得還不夠好。問題在於：僅僅"找代碼長得像的例子"，並不能保證找到的例子真的用了相同的算法思路。兩段代碼可能都用了大量的循環和數組操作，表面上看很像，但一個在解決"最短路徑"問題，另一個在處理"字符串匹配"——優化策略完全不同，找這種"形似神不似"的例子幫不上什麼忙。
此外，原來的方法是"一錘子買賣"——給AI一組例子，讓它一次性生成改好的代碼，不管結果好不好都不再繼續打磨。這就像請一個廚師來改良菜譜，但只讓他嘗一口就提交最終版本，不給他反覆試驗的機會。
二、RAS的核心創意：先描述算法，再按算法找例子
新方法RAS的第一個關鍵改進，是改變了"找相似案例"的方式——從"看代碼長什麼樣"變成"看代碼在做什麼"。
具體做法是這樣的：當AI拿到一段待優化的程序時，先不急著去翻資料庫找類似代碼，而是讓AI先"讀懂"這段程序，用一句自然語言描述它的核心算法。比如，一段代碼可能被描述為"使用帶記憶化的動態規劃，尋找從第一個元素到最後一個元素的最小跳躍代價，代價定義為相鄰元素的絕對差值之和"。
有了這段文字描述之後，再把這段描述轉換成一個數學向量（可以理解為一串數字，代表這段話的語義），然後去資料庫里找語義最相近的案例——也就是那些同樣使用了類似算法思路的"慢程序-快程序"配對。
這種方式的妙處在於，兩段寫法完全不同的程序，只要它們用的是同一種算法，就能被正確地匹配在一起。反過來，兩段看起來很像的程序，如果算法本質不同，也不會被錯誤地匹配。這就像在圖書館找書，與其按封面設計找，不如按內容主題找，找到的書才真正有參考價值。
為了實現這個"先描述後檢索"的過程，研究團隊預先對訓練資料庫里的每一對慢-快程序都生成了自然語言描述，並儲存好對應的語義向量。這樣在實際使用時，只需要給當前待優化程序生成一次描述，就可以快速檢索到最相關的案例，不會產生太大的額外計算開銷。
三、RAS的第二個創意：反覆打磨，而不是一次了事
RAS的第二個改進是引入了"束搜索"（beam search）機制。這個名字聽起來很學術，但背後的道理非常直觀。
回到廚師改良菜譜的比喻：與其讓廚師嘗一口就定稿，不如讓他做出幾個改良版本，挑出其中最好的一個，然後以這個版本為基礎再做新一輪改良，如此往復幾輪，最終得到一道真正經過反覆打磨的菜。
RAS的工作流程正是如此。從原始的"慢程序"出發，第一步：檢索相關案例，讓AI生成若干個優化版本，從中挑出跑得最快且結果正確的那一個。第二步：把上一步選出的最優程序作為新起點，再次檢索相關案例（注意，這次檢索的是基於已經優化了一輪的新程序的描述，所以找到的案例也會更相關），再生成若干個新版本，再挑最優。如此循環，論文中默認進行四輪。
每一輪中，AI只使用一個檢索到的案例（一對慢-快程序）作為參考，而不是像之前的方法那樣把多個案例一股腦全塞進提示詞。這樣做的好處是，每一步的優化方向更清晰、更聚焦，不會讓AI陷入"同時學太多技巧、反而不知所措"的困境。
在整個搜索過程中，有一個重要的細節保證了效率：每一輪檢索時，算法會刻意避免使用之前已經用過的案例，確保每一步都能引入新的優化思路，而不是原地踏步。
四、實驗數據：RAS到底比之前好多少
研究團隊在兩個基準測試集上驗證了RAS的效果。
在C++程序優化方面，使用了PIE基準測試集，包含973個待優化的測試程序。衡量指標是"平均最佳加速比"——也就是經過優化後，程序平均能跑得多快。
使用GPT-4o作為底層AI時，RAS達到了8.03倍的平均加速比，而原來最好的"動態代碼檢索"方法只有4.43倍。使用更新的Qwen3-Coder模型時，RAS達到8.70倍，動態檢索只有4.23倍。使用DeepSeek
3.2時，RAS達到9.18倍，動態檢索為7.03倍。
另外還有一個"優化成功率"指標（% Optimized），衡量有多少比例的程序被成功提速超過10%。RAS在GPT-4o下達到96.92%，在Qwen3-Coder下達到98.56%，在DeepSeek 3.2下達到99.08%，而人類程序員的成功率是98.87%。也就是說，RAS在優化成功率上已經與人類程序員不相上下，甚至在某些模型下小幅超越。
研究團隊還設計了一個"去掉上下文檢索、只保留疊代搜索"的對照實驗（稱為"No Contextual"），結果顯示它的性能明顯低於完整的RAS，介於動態檢索和RAS之間。這說明"基於算法描述的檢索"和"疊代搜索"這兩個創新各自都貢獻了顯著的性能提升，缺一不可。
在Python程序優化方面，研究團隊使用了Mercury基準測試集（包含256個LeetCode題目的Python解法）。核心指標是"Beyond@1"，代表程序在所有提交中的運行時間百分位。使用Qwen2.5-7B-Instruct這個相對較小的模型，原始未優化程序的均值是58.66，而RAS將其提升到87.85，提升幅度超過10個百分點，顯著縮小了小模型與大模型之間的性能差距。
五、AEGIS：像編譯器一樣，把大改動拆成小步驟
RAS雖然效果很好，但它每一步的改動幅度往往很大——就像一個廚師直接把菜譜改得面目全非，你很難搞清楚哪一步改動起了關鍵作用。這對於需要理解和審查優化過程的程序員來說，不夠透明。
受現代編譯器設計思路的啟發，研究團隊提出了AEGIS（原子編輯引導搜索）。現代編譯器做優化時，不是一次性大改，而是經過一系列"編譯器趟次"（compiler passes），每一趟只做一種特定類型的微小改動，比如"消除重複計算"、"把遞歸改成循環"、"優化內存訪問順序"等。AEGIS就是要讓AI也學會這種"小步快跑"的優化方式。
AEGIS的核心是一個"預處理"步驟：在正式優化任何程序之前，先對訓練資料庫里的每一對慢-快程序進行"拆解"。具體過程可以分為三個階段。
第一階段是"分解"：讓AI看一對慢程序和快程序，然後用自然語言描述出這兩者之間的差異，把它們拆解成一個有序的改動列表。比如"第一步：把cin/cout替換成scanf/printf以加快輸入輸出；第二步：把不必要的變量聲明移到循環外面；第三步：把遞歸改成疊代"等。
第二階段是"重建"：按照這個改動列表，從原始慢程序出發，一步一步地應用每個改動，生成一系列中間程序。比如第一步改動之後得到程序1，第二步改動之後得到程序2，以此類推。這樣就把一對慢-快程序變成了一條"程序演化鏈"，鏈上的每一步只有一個微小改動。
第三階段是"泛化"：每一個微小改動都有對應的自然語言描述，但這些描述是針對特定訓練程序的，比如"把這個函數裡的遞歸改成循環"。為了讓AI能把這個改動應用到其他程序上，需要讓AI把描述改寫成更通用的表達，比如"對於使用遞歸且存在重疊子問題的動態規划算法，將其改寫為自底向上的疊代實現，以消除函數調用開銷"。這種更通用的描述就是"原子編輯"。
經過這個預處理步驟，原來的訓練資料庫從"慢-快程序對"變成了"原子編輯+程序示例對"的資料庫，裡面包含了大量細粒度的、可泛化的優化技巧。
在實際優化一個新程序時，AEGIS仍然使用RAS的疊代搜索框架，但每次檢索的不再是整體的慢-快程序對，而是最相關的"原子編輯"。找到相關的原子編輯後，AI被要求把這個具體的優化技巧應用到當前程序上，同時參考資料庫中該原子編輯對應的程序示例。
六、AEGIS的實驗結果：更小的步子，更容易理解的過程
AEGIS在性能上略低於RAS，但仍然顯著優於所有基線方法。使用GPT-4o時，AEGIS達到6.08倍平均加速比；使用Qwen3-Coder時為5.37倍；使用DeepSeek 3.2時為6.48倍。這些數字都遠高於動態代碼檢索的4.43倍/4.23倍/7.03倍，也超過了"無上下文"對照實驗的3.86倍/2.76倍/5.87倍。
研究團隊分析了AEGIS性能略低於RAS的兩個可能原因：一是AI分解生成的中間程序，不能保證每一步都有實質性的性能提升，可能有些"原子編輯"其實沒什麼用；二是同一對原始訓練數據可能產生多個原子編輯，在檢索時這些相關編輯可能被重複選取，降低了搜索過程的多樣性。
但AEGIS真正的優勢體現在"可解釋性"上。研究團隊用"字符級編輯距離"來衡量每一步改動的幅度（編輯距離越小，說明改動越小、越容易理解）。結果顯示，AEGIS的平均編輯距離明顯低於RAS：使用GPT-4o時，AEGIS為213.05，RAS為257.77；使用Qwen3-Coder時，AEGIS為194.05，RAS為259.87；使用DeepSeek 3.2時，AEGIS為263.24，RAS為296.41。
更值得關注的是第一步的改動幅度對比：RAS在第一步往往會做出極大的改動（編輯距離約500-600），之後的步驟改動相對較小；而AEGIS第一步的改動就已經被控制在250-400的範圍內，全程改動更為均勻分散。這對於需要理解和審查優化過程的程序員來說，更加友好。
七、AI改的代碼，準確率有多高
任何代碼優化方法都必須回答一個關鍵問題：改完之後，代碼還是正確的嗎？功能被改壞的"優化"不是優化，而是引入了新bug。
研究團隊對這個問題做了仔細檢驗。在GPT-4o實驗中，他們模擬了"如果只追求速度、不管正確性"的場景，看看AI是否會選擇錯誤的程序。結果是：RAS在全部973個測試案例中，只有5個會選到錯誤程序，準確率99.5%；AEGIS則完全沒有選到錯誤程序，準確率100%。
為了更嚴格地驗證，研究團隊還用了一個叫做CBMC（C語言有界模型檢查器）的專業工具，對DeepSeek 3.2生成的10個程序對進行形式化的等價性驗證——也就是用數學方法證明優化前後的程序在所有可能的輸入下都會產生相同的輸出。結果是10個程序對中有8個被證明完全等價，剩餘2個存在微小差異（一個程序多輸出了幾個換行符），核心邏輯完全正確。
八、失敗案例分析：哪類問題讓AI犯難
研究團隊還仔細分析了哪些程序沒能被成功優化，從中發現了一些規律。
對於AEGIS，"未優化"程序集合中有12.09%涉及二分搜索，而整個測試集中只有4.32%的程序涉及二分搜索——說明AEGIS對二分搜索類程序的優化能力相對薄弱，失敗率比平均水平高出接近三倍。此外，AEGIS未優化集合中有45.05%是動態規劃問題，整體比例為51.59%，這個差距不算特別顯著。
對於RAS，整體失敗率更低（只有3.08%的程序未被成功優化）。但有意思的是，涉及Kruskal算法（一種用於求解最小生成樹的圖論算法）的程序，在全體測試集中只占1.03%，卻在RAS的失敗案例中占到了20%，是個明顯的薄弱點。相比之下，AEGIS在Kruskal算法上的失敗率反而更低一些。
這種分析有很實際的價值：通過識別兩種方法各自的弱點，可以有針對性地在訓練資料庫中補充相關類型的優化案例，從而進一步提升性能。
九、代碼嵌入模型的對比實驗
研究團隊還專門檢驗了"用專門針對代碼訓練的嵌入模型，能不能縮小代碼檢索與上下文檢索的差距"這個問題。他們用Codestral-Embed-2505（一個專為代碼設計的語義向量模型）替換了默認的通用文本嵌入模型，在DeepSeek 3.2的第一輪搜索中進行對比。
結果顯示：RAS（上下文檢索）在第一輪達到8.03倍加速、96.30%優化成功率；代碼嵌入（Codestral）達到6.57倍、88.39%；通用文本嵌入（無上下文）達到5.92倍、87.26%。專用代碼嵌入模型確實比通用文本嵌入略好一些，但與上下文檢索的差距仍然很明顯。
研究團隊解釋了這個現象背後的原因：競賽程序員寫代碼時常常使用相似的變量名和操作模式，導致表面上很像的代碼實際上在解決完全不同的問題，代碼嵌入會被這些表面相似性誤導。而上下文檢索通過算法描述抽象掉了這些表面差異，找到的是真正在算法層面相似的案例，自然效果更好。
十、研究的局限性與未來方向
研究團隊坦誠地討論了兩個主要局限性。第一，RAS和AEGIS都需要對每個程序進行多輪優化-評估循環，計算開銷比一次性生成要大，在實際大規模部署時需要考慮成本。AEGIS還有額外的預處理開銷，需要提前對整個訓練資料庫進行拆解和重建。
第二，這套方法目前主要在相對簡單、獨立的程序（如競賽編程題目的解法）上驗證，對於由多個模組組成的大型工業代碼庫，可能需要先解決"找到哪些代碼片段值得優化"的問題，才能套用這套框架。
儘管如此，研究團隊認為這套方法為將AI應用於實際代碼優化提供了一條可行的路徑。事實上，相關技術已經開始在工業界落地，賓夕法尼亞大學的相關研究人員此前發表的研究中提到了將高層代碼優化應用於倉儲系統性能提升的實踐。
歸根結底，這項研究做了一件很有趣的事：它教會AI"先理解程序在做什麼，再去找相似的優化案例"，同時讓AI養成了"反覆打磨、每次只做一個改動"的好習慣。這兩個改變加在一起，讓AI的代碼優化能力產生了質的飛躍。
對普通人來說，這意味著未來我們使用的各種軟體、APP、在線服務，有可能在不改變功能的前提下跑得更快、耗電更少——因為背後的代碼經過了AI的精心打磨。對程序員來說，這套方法提供了一個有力的輔助工具，尤其是AEGIS的"小步改動"模式，讓程序員能清楚地看到每一步優化在做什麼、為什麼要這樣做，而不是面對一段突然變成另一段的神秘代碼。
當然，正如研究團隊自己指出的，AI優化的結果仍然需要程序員來驗證正確性。這套工具還沒有強大到完全自主運作的程度，更像是一個博學的助手，幫你提出優化建議，最終決定權仍在人的手中。有興趣進一步了解技術細節的讀者，可以在arXiv上通過編號arXiv:2501.18916查閱完整論文。
Q&A
Q1：RAS（檢索增強搜索）和普通的AI代碼優化有什麼區別？
A：普通AI代碼優化通常是"一次性"的，直接讓AI改寫程序。RAS的不同之處有兩點：一是檢索時先讓AI用自然語言描述程序用的算法，再找算法相似的參考案例，而不是找代碼寫法相似的；二是會反覆疊代多輪，每輪選出最優結果再繼續改進，而不是生成一次就結束。這兩個改進使平均加速效果比此前最好的方法高出約兩倍。
Q2：AEGIS生成的原子編輯資料庫是怎麼來的？
A：AEGIS通過三個步驟構建原子編輯資料庫。首先讓AI對訓練集中每對慢-快程序進行差異分解，用自然語言描述出若干個具體的改動步驟。然後按步驟逐一應用這些改動，生成一系列中間程序。最後讓AI把每個改動的描述從"針對特定程序"改寫成"適用於更多程序"的通用表達。這樣訓練集中的每對程序都會產生多個"原子編輯+示例程序對"，匯總形成資料庫。
Q3：RAS優化後的程序準確率怎麼保證？
A：RAS在每一步搜索中只保留通過所有測試用例的程序，不正確的直接排除。實驗中GPT-4o版RAS在973個測試案例上的準確率為99.5%，AEGIS為100%。此外研究團隊還用形式化驗證工具CBMC對10個DeepSeek生成的程序進行了數學等價性證明，8個完全等價，另2個只有輸出格式的微小差異，核心邏輯完全正確。
