Meta團隊揭秘:AI編程助手如何像老司機帶新手一樣，越做越聰明？

這項研究來自Meta超級智能實驗室，聯合華盛頓大學、紐約大學、卡內基梅隆大學、普林斯頓大學及Google DeepMind的多位研究人員共同完成。論文以預印本形式于2026年4月16日發布在arXiv平臺，編號為arXiv:2604.16529v1，分類為計算機軟件工程領域（cs.SE）。有興趣深入了解的讀者可以通過該編號在arXiv官網查詢完整論文。

**當AI編程助手遇到"老手帶新手"的問題**

先從一個熟悉的場景說起。假設你是一家公司的技術主管，手下有十個程序員同時在解決同一個復雜的系統漏洞。每個人忙活了幾個小時之后，你會怎么做？你大概不會只隨機挑一份交給老板，而是會把所有人的工作記錄翻出來，看看誰的思路最清晰、誰踩了哪些坑、誰快要接近答案了，然后綜合這些信息，要么選出最好的那份，要么讓他們互相借鑒、再來一輪。

這個場景，正是這篇論文試圖解決的核心問題。只不過這里的"程序員"換成了AI，而那個"系統漏洞"換成了GitHub上真實的代碼問題。研究團隊想搞清楚：當一個AI編程助手能多次嘗試解決同一個問題時，怎樣才能讓后來的嘗試真正比前面的更聰明，而不只是換個方式重蹈覆轍？

**一、為什么這個問題比想象的難得多**

過去幾年，AI領域有一個非常流行的做法，叫作"測試時擴展計算"——簡單理解就是，在AI回答問題的時候，不急著只給一個答案，而是讓它多想幾次，然后從中選最好的。這個方法在數學解題、寫短文這類任務上效果很好，因為答案比較短，很容易比較哪個更好。

但AI編程助手干的活可不是這種。當AI幫你修復一個真實的代碼錯誤時，它要做的事情遠不止"寫幾行代碼"。它需要先理解整個代碼倉庫的結構，找到可能出問題的文件，運行命令測試，看到報錯信息再調整，就像一個真正的程序員坐在電腦前工作一樣。這樣的一次完整工作流程，研究團隊稱之為一次"軌跡"（rollout）。

一次軌跡可能包含幾十步甚至七八十步的操作記錄。你可以把它想象成一個程序員的完整工作日志，里面有他查看了哪些文件、執行了哪些命令、看到了什么輸出、又做了什么決定。這樣的日志，內容極其龐雜，讀起來費力，而且充斥著大量重復的終端輸出、死胡同探索這類低價值信息。

正因如此，針對短答案設計的那套"多選一"方法根本用不上來。你沒辦法把兩個長達幾千行的工作日志扔給AI說"幫我比較一下哪個更好"，因為AI自己也會被那堆噪音淹沒，判斷失準。更別說把一個程序員的工作記錄喂給另一個程序員、讓他從中學習"下次該怎么改進"——那得讀多久？

這就是研究團隊發現的核心障礙：**對于AI編程助手來說，測試時多次嘗試的瓶頸不是"嘗試次數不夠多"，而是"怎么把之前的嘗試變成真正有用的信息"**。

**二、解題思路：給每次嘗試寫一份"精華摘要"**

既然問題出在"原始記錄太亂、太長、難以比較和復用"，解決方案就呼之欲出了：給每次嘗試寫一份結構化的精華摘要。

研究團隊讓AI在每次完成一輪工作之后，把那份冗長的工作日志"濃縮提煉"成一份簡潔的結構化文檔。這份文檔會記錄這次嘗試的核心假設是什么、做了哪些關鍵決定、取得了哪些進展、又在哪里卡殼了、失敗的原因可能是什么。所有亂七八糟的終端輸出、重復的文件讀取操作，統統略去不計。

這個做法聽起來簡單，卻是整個研究的基石。有了這份摘要，兩件原本很難的事情就變得可行了：第一，拿多份摘要互相比較，判斷哪次嘗試的質量更高；第二，把高質量的摘要作為"經驗"提供給下一輪嘗試，讓AI在開始新一輪工作之前就能站在前人的肩膀上。

這兩件事，正好對應著研究團隊設計的兩個核心方法，一個叫"遞歸錦標賽投票"，另一個叫"并行蒸餾精煉"。

**三、從混戰到決賽：遞歸錦標賽投票的工作方式**

以足球聯賽做個類比。如果你要從32支球隊里選出冠軍，不會讓所有球隊同時踢一場亂戰，而是先分組，每組選出一個勝者，再讓勝者互相對抗，一輪一輪淘汰下去，最終決出冠軍。這個過程叫"錦標賽制"。

研究團隊設計的"遞歸錦標賽投票"（RTV）就是這個思路。假設AI對同一個編程問題做了16次獨立嘗試，那就先把16份摘要兩兩配對，讓AI作為"裁判"讀這兩份摘要，判斷哪次嘗試更有可能是正確解法。每對摘要的比較不是只判斷一次，而是重復判斷8次，然后按少數服從多數的原則選出勝者，這樣可以減少單次判斷的偶然誤差。第一輪比較結束后，16次嘗試變成8次勝者，然后再兩兩對比，8變4，4變2，2變1，最終選出整個群體里質量最高的那次嘗試。

為什么要用兩兩對比，而不是直接把所有摘要一次性扔給AI說"選最好的"？研究團隊做了一個很有意思的實驗，專門比較不同"組大小"的效果。結果發現，兩兩對比（每組2份摘要）的效果明顯優于4選1、8選1、16選1。道理其實不難理解：當你同時比較的候選項越多，信息量越大，裁判反而越容易因為信息過載而判斷失準；而兩兩對比，任務簡單明確，判斷質量自然更高。

與此同時，實驗還發現投票次數越多，最終結果越穩定——從只投一次票到投16次票，效果持續提升，但在8次投票之后提升幅度開始放緩，因此最終方案選定每組比較投8次票。

這個方法單獨使用時效果已經相當可觀：對于SWE-Bench Verified這個測試平臺（里面都是GitHub上真實的代碼問題），Claude-4.5-Sonnet的平均解題率從67.4%提升到了73.6%；對于另一個叫Terminal-Bench v2.0的測試平臺（專門測試在命令行環境中解決復雜任務的能力），同一個模型的得分從40.6%跳升到了54.6%。僅靠"選得更準"這一件事，提升就如此顯著。

**四、站在前人肩膀上：并行蒸餾精煉的運作邏輯**

光"選得準"還不夠。研究團隊更野心勃勃的想法是：能不能讓后來的AI不只是在前人的成果里挑一個，而是真正從前人的經驗中學到東西，下一次做得比任何一次前人都要好？

這個過程，研究團隊借用了一個已有方法的框架，并加以改造，稱之為"并行蒸餾精煉"（PDR）。

具體來說，第一輪先讓AI做16次獨立嘗試，每次嘗試結束后都生成一份精華摘要。接下來，用上一節介紹的錦標賽方法從中選出質量最高的4份摘要，作為"經驗材料"。然后，開始第二輪嘗試，同樣是16次，但這次每次嘗試在開始之前，AI會先讀那4份精華摘要，了解前人發現了什么、踩了哪些坑、最有希望的方向是哪里，然后在全新的、干凈的環境中開始工作。

有一個細節值得特別注意：第二輪每次嘗試都是在"新環境"里開始的，不是在第一輪留下的半成品代碼上繼續。這就好像一個程序員讀完了同事的工作筆記，然后自己從頭開始做，而不是接著同事寫了一半的代碼繼續寫。為什么要這樣做？因為第一輪留下的半成品代碼可能方向就錯了，或者已經把某些東西改壞了，如果繼續在上面修改，可能越改越亂。從頭開始，反而更干凈。

為了搞清楚"讀幾份前人摘要最合適"，研究團隊專門比較了三種做法：只讀自己上一次的摘要，隨機選4份摘要來讀，以及用錦標賽方法選出最好的4份來讀。結果非常清晰：讀多份摘要遠比只讀自己的那份要好。以Gemini-3.1-Pro為例，只讀自己一份時，第二輪平均解題率從72.7%只提升到了73.8%，提升微乎其微；換成隨機選4份來讀，提升到76.9%；再用錦標賽篩選出最好的4份來讀，則達到了79.3%。

這個結果揭示了一個很有意思的道理：**精華摘要的質量，直接決定了下一輪AI能學到多少東西**。研究團隊進一步做了一個更細致的分析，把所有任務按照"提供的4份參考摘要里有幾份是來自成功解題的嘗試"來分組，然后看每組里第二輪的平均解題率。結果極為規律：參考摘要里沒有一份成功案例時，第二輪解題率趨近于零；有1份時約為33%；有2份時約55%；有3份時約85%；全部4份都是成功案例時，第二輪解題率高達99%以上。

這說明成功的經驗本身就是最好的老師。如果你讀的全是失敗記錄，哪怕寫得再詳細，也很難做出突破；但只要能看到一些成功的案例，再復雜的問題都有希望被復現和超越。

**五、把兩個方法合而為一：完整的工作流程**

兩個方法各有所長：錦標賽投票擅長在一群候選方案里"選得準"，蒸餾精煉擅長讓AI"做得更好"。把它們結合起來，就形成了研究團隊的完整方案。

整個流程分四步走。第一步，對同一個編程問題做16次獨立嘗試，并為每次嘗試生成精華摘要。第二步，用錦標賽投票從16份摘要里選出質量最高的4份，作為"精選經驗庫"。第三步，基于這4份精選摘要，開展16次新的嘗試——每次嘗試都先讀這4份摘要，然后在新環境里從頭工作。第四步，對第二輪的16次嘗試再做一次錦標賽投票，從中選出最終答案。

這個流程在"開發"與"探索"之間維持了一個微妙的平衡。一方面，用錦標賽把4份最好的摘要選出來，是在"聚焦"——把注意力集中在最有希望的方向上；另一方面，第二輪仍然做16次獨立嘗試而不是只做1次，是在"保持多樣性"——不同的嘗試可能從4份摘要里汲取不同的靈感，探索出風格各異的解題路徑，再通過最后一輪錦標賽選出最終答案。

**六、實驗結果：數字背后的真實意義**

研究團隊在兩個測試平臺上，用五個不同的頂尖AI模型進行了全面測試，測試對象包括Claude-4.5-Opus、Gemini-3.1-Pro、Claude-4.5-Sonnet、Gemini-3-Flash和GPT-5-0825，測試平臺是SWE-Bench Verified（500道真實GitHub代碼問題）和Terminal-Bench v2.0（88道復雜命令行任務）。

結果在所有模型上都呈現了一致的提升趨勢。以Claude-4.5-Opus為例，在SWE-Bench Verified上，單次嘗試的解題率是70.9%，經過完整方法處理后達到77.6%，提升了約6.7個百分點；在Terminal-Bench v2.0上，從47.0%提升到59.1%，提升超過12個百分點。Gemini-3.1-Pro在兩個平臺上分別從72.3%提升到76.6%，從52.5%提升到64.8%。

不同模型在Terminal-Bench v2.0上的提升幅度普遍大于SWE-Bench Verified，這與兩個測試平臺的任務特性有關：Terminal-Bench v2.0的任務難度更大、解題路徑差異也更大，因此多輪嘗試和經驗積累帶來的收益也更顯著。

有一個數據特別值得關注：研究團隊發現，第二輪16次嘗試平均所需的操作步數，只有第一輪的大約一半。以Claude-4.5-Opus為例，在SWE-Bench Verified上第一輪平均41步，第二輪降到了14步；在Terminal-Bench v2.0上從24步降到了12步。這說明AI在讀完前人的精華摘要之后，對整個代碼庫的結構、問題所在的位置、最有可能奏效的解法都有了更清晰的認識，不需要再做那些"摸黑探路"式的操作，而是能更直接地走向答案。效率幾乎翻倍，而成功率也同步提升，這是一個雙贏的結果。

**七、那些原本無解的題，也被做出來了**

有一組特別有意思的發現，研究團隊稱之為"新解法發現"。這指的是：某個AI模型在第一輪16次獨立嘗試里，所有嘗試都失敗了；但在第二輪——也就是讀完前人失敗摘要之后的第二輪嘗試里——成功解決了這個問題。

在Terminal-Bench v2.0上，這樣的情況共出現了13個任務。以Claude-4.5-Opus為例，它在第一輪完全解不了"gpt2-codegolf"這道題（要求用不超過5000字節的C語言代碼實現GPT-2語言模型的文字生成），但在第二輪讀完了前四次失敗嘗試的摘要之后，成功寫出了一個3467字節、能正確運行的C程序。

更極端的是"large-scale-text-editing"這道題：在研究測試的五個模型里，第一輪沒有任何一個模型能成功完成這個任務；但Gemini-3.1-Pro在第二輪讀了自己四次失敗嘗試的摘要之后，成功解決了它。這意味著，通過讓AI從自身失敗中"提煉經驗"，可以解鎖原本超出其能力范圍的任務。

這背后的機制研究團隊也做了定性分析。以"sparql-university"任務為例，第一輪四次嘗試都失敗了，但其中有一次發現了關鍵規律：歐盟國家的條件和學生人數超過10人的條件不需要同時滿足同一個系，是兩個獨立條件。第二輪的AI讀了這個摘要之后，直接把這個關鍵發現寫進了自己的解題策略里，最終成功解決了問題。

**八、精華摘要究竟好在哪里：與原始記錄的對比**

研究團隊不只是提出了這個方法，還專門驗證了一個核心假設：到底是精華摘要更好，還是直接用原始工作日志也差不多？

結論非常明確：精華摘要在每一種場景下都優于原始日志。在錦標賽投票階段，用摘要做比較的最終解題率始終高于直接比較原始日志的方案，而且這個優勢在越到后期的比較輪次中越明顯——因為越到最后，剩下的候選方案差異越細微，需要對細節更敏感的比較，這時候原始日志里充斥的噪音就成了巨大的干擾，而摘要則能精準呈現差異所在。

這個發現支持了研究團隊的核心論點：**對AI編程助手來說，測試時擴展計算的關鍵問題不是"計算量"，而是"信息表示"**。同樣的計算預算，用什么形式來表示和傳遞經驗，決定了最終能得到多大的收益。

**九、錦標賽裁判本身的準確性**

研究團隊還做了一件事：衡量AI在擔任"裁判"時的判斷準確率。具體方法是，從所有包含"有成功嘗試和有失敗嘗試"的對比組里，統計AI實際選中了成功那一方的比例。

結果顯示，在Terminal-Bench v2.0上的判斷準確率普遍高于SWE-Bench Verified。研究團隊分析認為，這是因為SWE-Bench的任務要求判斷代碼改動的細微差異和被隱藏的測試案例，而Terminal-Bench的任務在命令行輸出里有更直接可見的成功/失敗證據，裁判更容易判斷。

總體來說，各模型的裁判準確率大約在60%到85%之間。這個數字說明AI裁判雖然有效，但并非完美——仍然存在改進空間。研究團隊也指出，未來可以專門針對"做好組間比較決策"這件事對AI進行專項訓練，或者引入專門的裁判模型，都可能進一步提升效果。值得一提的是，Gemini-3.1-Pro在擔任裁判時的準確率相對偏低，這導致它在最后一輪錦標賽投票中的提升幅度比其他模型小（第二輪平均解題率76.2%，最終選出的答案解題率76.6%，提升僅0.4個百分點）。

**十、這項研究打開了一扇新的大門**

歸根結底，這篇論文想說的事情其實可以用一句話概括：對于AI編程助手來說，讓它"嘗試更多次"是有價值的，但價值的大小完全取決于你怎么利用那些嘗試留下的信息。原始的工作日志太亂、太長、太難復用；但經過提煉的精華摘要，則可以成為非常有效的"經驗傳承"載體——既能用來更準確地選出好方案，又能用來幫助下一輪嘗試站在更高的起點上。

研究團隊也直言，這套方法目前還有明顯的局限性。精華摘要里保存的是"對之前嘗試的文字描述"，而不是那些嘗試中真正產生的代碼產物、測試腳本或調試工具。研究團隊提出了一個有趣的未來方向：能不能讓AI不只是在新環境里從頭開始工作，而是真正繼承前一輪嘗試中產生的那些有價值的中間產物，比如寫好了一半的補丁、創建的測試用例、編寫的調試工具？如果能做到這一點，"從前人的經驗中學習"就不只是讀一讀筆記，而是真正接過前人手中的工具、站在前人挖好的坑邊繼續往下挖了。

Q&A

Q1：SWE-Bench Verified和Terminal-Bench v2.0是什么，有什么區別？

A：這是評測AI編程助手能力的兩個測試平臺。SWE-Bench Verified收錄了GitHub上真實的代碼缺陷修復任務，共500道，考察AI能否像真實程序員一樣定位并修復代碼庫中的問題。Terminal-Bench v2.0則收錄了88道復雜的命令行任務，更側重于考察AI在真實終端環境中處理系統級任務的能力，任務難度普遍更高、解題路徑變化也更大，因此在這個平臺上經過多輪改進帶來的提升幅度也更顯著。

Q2：遞歸錦標賽投票為什么要用兩兩對比，直接一次全部比較不行嗎？

A：研究團隊專門測試過"每組比較幾份摘要"對效果的影響。結論是候選項越少，比較質量越高。當所有摘要一次性扔進來比較時，AI裁判面臨的信息量過大，容易判斷失準；而每次只比較兩份，任務簡單明確，裁判準確率更高。多輪兩兩淘汰的總體效果，明顯優于一次性大比較。此外，每次比較還重復投票8次取多數，進一步降低了單次判斷的偶然誤差，讓最終選出的結果更可靠。

Q3：并行蒸餾精煉為什么不讓AI直接在第一輪的代碼基礎上繼續改，而要從頭開始？

A：因為第一輪留下的半成品代碼本身可能就有問題——解題方向可能錯了，或者已經把某些部分改壞了。在錯誤的代碼基礎上繼續修改，很可能越改越亂。從頭開始，讓AI在讀完前人精華摘要之后，把對問題的理解和最有希望的解法方向帶入全新的工作環境，反而能更干凈、更高效地找到正確答案。實驗結果也支持這個判斷：第二輪從頭開始的嘗試平均只需要第一輪一半左右的操作步數。