這項由北京航空航天大學(xué)軟件學(xué)院何樂涵、陳澤仁、高翔、張哲、盛祿等研究人員，以及上海人工智能實驗室邵靜共同完成的研究發(fā)表于2025年6月的arXiv預(yù)印本平臺（論文編號：arXiv:2506.18315v1）。感興趣的讀者可以通過該編號在arXiv官網(wǎng)查閱完整論文。

當(dāng)下的人工智能已經(jīng)能夠根據(jù)我們的需求自動生成代碼，就像一個永不疲倦的程序員助手。GitHub Copilot這樣的工具已經(jīng)走進(jìn)了千家萬戶的開發(fā)環(huán)境。然而，這些AI生成的代碼就像一道看起來美味但可能有毒的菜肴——表面上語法正確，運(yùn)行起來卻可能漏洞百出。

傳統(tǒng)的解決方案就像給廚師配備一個品嘗員：通過測試用例來檢驗代碼是否正確。這種被稱為"測試驅(qū)動開發(fā)"的方法確實有效，但存在一個致命缺陷——如果測試用例本身就有問題呢？這就好比品嘗員的味覺出了問題，明明菜里放錯了鹽卻說味道剛好。更糟糕的是，很多時候我們根本沒有足夠的高質(zhì)量測試用例，就像讓品嘗員在沒有標(biāo)準(zhǔn)答案的情況下判斷菜品好壞。

北航團(tuán)隊發(fā)現(xiàn)了一個更聰明的解決方案。與其讓AI去猜測具體的輸入輸出應(yīng)該是什么樣子，不如讓它理解程序應(yīng)該遵循的基本規(guī)律。這就像不去記憶每道菜的具體味道，而是掌握烹飪的基本原理：炒菜不能糊、湯不能咸得發(fā)苦、甜品不能是酸的。

研究團(tuán)隊把這種方法稱為"屬性生成求解器"（Property-Generated Solver，簡稱PGS）。這個系統(tǒng)就像配備了兩個專業(yè)人員的廚房：一個是負(fù)責(zé)做菜的廚師（生成器），另一個是負(fù)責(zé)制定和檢查烹飪標(biāo)準(zhǔn)的質(zhì)檢員（測試器）。質(zhì)檢員不需要知道每道菜的具體味道應(yīng)該是什么，只需要確?；镜呐腼冊瓌t得到遵守。

一、傳統(tǒng)方法的根本缺陷：自欺欺人的惡性循環(huán)

為了理解這項研究的價值，我們需要先看看現(xiàn)有方法存在什么問題。設(shè)想你要讓AI為你寫一個數(shù)學(xué)函數(shù)，比如計算一個數(shù)字的質(zhì)因數(shù)分解。傳統(tǒng)的方法是給AI提供一些例子：12應(yīng)該分解為[2,2,3]，15應(yīng)該分解為[3,5]。然后讓AI根據(jù)這些例子學(xué)會寫代碼。

但問題來了：如果AI對這個數(shù)學(xué)概念的理解本身就有偏差怎么辦？比如它誤以為質(zhì)因數(shù)分解只需要找到能整除的質(zhì)數(shù)，而忽略了重復(fù)因子的重要性。在這種情況下，它可能會給出12的分解結(jié)果為[2,3]，漏掉了一個2。

更糟糕的是，當(dāng)我們要求這個有偏見的AI自己生成測試用例時，它很可能會生成同樣錯誤的測試：認(rèn)為12分解為[2,3]是對的。這樣一來，錯誤的代碼通過了錯誤的測試，整個系統(tǒng)陷入了"自欺欺人"的惡性循環(huán)。

傳統(tǒng)測試方法還面臨另一個挑戰(zhàn)：預(yù)測正確答案往往比生成代碼本身還要困難?？紤]一個復(fù)雜的圖著色問題——給地圖上的每個區(qū)域涂色，確保相鄰區(qū)域顏色不同。要為每種可能的地圖配置都預(yù)測出正確的著色方案，這比編寫解決這個問題的代碼還要復(fù)雜。

第三個問題是現(xiàn)有測試往往只關(guān)注代碼覆蓋率——確保代碼的每一行都被執(zhí)行到——而不關(guān)心邏輯的正確性。這就像檢查一道菜時只確保每種調(diào)料都用到了，而不管最終味道是否正確。

二、屬性測試：從具體例子到抽象原則

北航團(tuán)隊的解決方案借鑒了一個在軟件工程中相對小眾但威力巨大的概念：屬性測試（Property-Based Testing）。這種方法的核心思想是，與其關(guān)注具體的輸入輸出對應(yīng)關(guān)系，不如關(guān)注程序應(yīng)該滿足的高層次屬性或不變量。

繼續(xù)用質(zhì)因數(shù)分解的例子來說明。與其測試"12分解為[2,2,3]"這樣的具體對應(yīng)關(guān)系，屬性測試會關(guān)注這樣的規(guī)律："分解結(jié)果中所有數(shù)字的乘積必須等于原始數(shù)字"以及"分解結(jié)果必須按照非遞減順序排列"。這些屬性相對容易定義和驗證，而且不需要我們預(yù)先知道每個輸入的正確答案。

這種方法的優(yōu)勢顯而易見。對于圖著色問題，我們不需要為每張地圖都找出正確的著色方案，只需要驗證"相鄰區(qū)域的顏色不相同"這個簡單屬性。對于排序算法，我們不需要預(yù)測每個數(shù)組排序后的具體結(jié)果，只需要確保"結(jié)果是非遞減序列"且"包含原數(shù)組的所有元素"。

屬性測試還有一個重要特點：它能夠自動生成大量多樣化的測試輸入。不像傳統(tǒng)方法需要人工設(shè)計測試用例，屬性測試系統(tǒng)可以根據(jù)問題的約束條件自動產(chǎn)生各種邊界情況和特殊場景，大大提高了錯誤發(fā)現(xiàn)的概率。

三、雙智能體協(xié)作：生成器與測試器的完美配合

PGS系統(tǒng)的核心是兩個AI智能體的巧妙配合。這就像一個高效的軟件開發(fā)團(tuán)隊：一個專注于編碼實現(xiàn)，另一個專注于質(zhì)量保證。

生成器（Generator）是團(tuán)隊中的"程序員"。它根據(jù)問題描述生成初始代碼，然后根據(jù)測試反饋不斷改進(jìn)。與傳統(tǒng)的單一AI不同，這個生成器專門優(yōu)化了代碼生成和迭代改進(jìn)的能力。當(dāng)它收到來自測試器的反饋時，能夠精確定位問題所在并進(jìn)行針對性修復(fù)。

測試器（Tester）則是團(tuán)隊中的"質(zhì)量工程師"。它的工作流程包含幾個關(guān)鍵步驟。首先，它分析問題描述，識別出程序應(yīng)該滿足的高層次屬性。比如對于一個排序函數(shù)，測試器會識別出"輸出必須是有序的"、"輸出必須包含輸入的所有元素"等屬性。

接下來，測試器將這些抽象屬性轉(zhuǎn)換為可執(zhí)行的檢查代碼。這些檢查代碼就像自動化的質(zhì)檢流程，能夠?qū)θ魏谓o定的輸入輸出對進(jìn)行驗證。測試器還會設(shè)計驗證機(jī)制，確保這些屬性檢查本身是正確的——通過已知的正確案例驗證檢查代碼不會誤報，通過已知的錯誤案例驗證檢查代碼能夠成功發(fā)現(xiàn)問題。

測試器的另一個重要任務(wù)是生成多樣化的測試輸入。它不是隨機(jī)生成數(shù)據(jù)，而是根據(jù)問題的特性和約束條件，系統(tǒng)性地創(chuàng)造各種測試場景：常見情況、邊界條件、極端情況等。這確保了測試的全面性和有效性。

當(dāng)生成器產(chǎn)生的代碼被測試時，測試器會收集所有的執(zhí)行結(jié)果，包括成功的案例和失敗的案例。對于失敗的案例，測試器不是簡單地報告"測試失敗"，而是會進(jìn)行深入分析，找出最具代表性、最簡潔的失敗案例，并提供詳細(xì)的錯誤描述和改進(jìn)建議。

四、智能反饋策略：簡單問題帶來深刻洞察

在軟件調(diào)試中有一個重要原則：最簡單的能復(fù)現(xiàn)問題的輸入往往最有助于定位和解決問題。北航團(tuán)隊在PGS中實現(xiàn)了這一原則，開發(fā)了一套智能的反饋選擇策略。

傳統(tǒng)的軟件測試往往追求高代碼覆蓋率，認(rèn)為測試應(yīng)該觸及代碼的每一個分支和路徑。但研究團(tuán)隊發(fā)現(xiàn)，對于AI代碼生成來說，這種策略可能適得其反。復(fù)雜的測試用例雖然能夠觸及更多代碼路徑，但也可能讓AI"迷失在細(xì)節(jié)中"，難以識別問題的核心所在。

相比之下，簡單的測試用例更容易讓AI理解問題的本質(zhì)。比如，如果一個排序算法在處理包含重復(fù)元素的數(shù)組時出現(xiàn)問題，那么用[2,1,2]這樣的簡單例子比用包含幾十個元素的復(fù)雜數(shù)組更容易讓AI理解錯誤的根源。

PGS采用了類似于"增量調(diào)試"的策略：在所有導(dǎo)致屬性違反的測試用例中，優(yōu)先選擇輸入最短、執(zhí)行時間最快的案例作為反饋。這種策略有多重好處。首先，簡單的輸入更容易讓AI跟蹤執(zhí)行流程，理解錯誤發(fā)生的具體位置。其次，簡單的案例往往能夠暴露算法的根本性缺陷，而不是邊界條件的特殊處理問題。最后，處理簡單案例的計算成本更低，提高了整個迭代過程的效率。

研究團(tuán)隊通過實驗驗證了這一策略的有效性。在LiveCodeBench測試集上，使用最短輸入長度的反饋策略比使用最長輸入長度的策略在成功率上高出3個百分點，同時減少了12%的計算開銷。

五、實驗驗證：全面超越現(xiàn)有方法

為了驗證PGS的有效性，研究團(tuán)隊進(jìn)行了大規(guī)模的對比實驗。他們選擇了三個具有代表性的代碼生成基準(zhǔn)測試集：HumanEval（包含164個手寫Python編程問題）、MBPP（約500個眾包的入門級Python問題）和LiveCodeBench（880個來自實際編程競賽的挑戰(zhàn)性問題）。

實驗中使用了三個不同能力級別的大語言模型：DeepSeek-Coder-V2（專門優(yōu)化的開源代碼生成模型）、Qwen2.5-Coder（在編程任務(wù)上表現(xiàn)出色的通用模型）和DeepSeek-R1-Distilled-32B（具有長鏈?zhǔn)酵评砟芰Φ母咝阅苣Ｐ停?/p>

PGS與多種現(xiàn)有方法進(jìn)行了對比，包括直接提示、鏈?zhǔn)剿季S推理、Code-T（使用自動生成測試的方法）、Self-Edit（自我修正方法）、Reflexion（基于反思的迭代改進(jìn)）等多種先進(jìn)技術(shù)。

實驗結(jié)果顯示了PGS的顯著優(yōu)勢。在pass@1指標(biāo)（一次生成成功的比例）上，PGS相比傳統(tǒng)測試驅(qū)動開發(fā)方法取得了23.1%到37.3%的相對提升。特別值得注意的是，在最具挑戰(zhàn)性的LiveCodeBench測試集上，PGS在困難問題（Hard級別）上的表現(xiàn)尤為突出，成功率達(dá)到40.7%，遠(yuǎn)超直接提示方法的28.1%。

在修復(fù)成功率（RSR）指標(biāo)上，PGS同樣表現(xiàn)優(yōu)異。這個指標(biāo)衡量的是將初始錯誤代碼修正為正確代碼的能力。PGS在HumanEval和MBPP上平均比代表性的測試驅(qū)動開發(fā)方法高出約15.7個百分點，展現(xiàn)了其強(qiáng)大的迭代改進(jìn)能力。

六、深入分析：為什么屬性測試如此有效

實驗數(shù)據(jù)揭示了PGS成功背后的深層原因。首先，研究團(tuán)隊發(fā)現(xiàn)，對于大語言模型來說，生成正確的屬性檢查代碼比直接生成完整的解決方案要容易得多。在LiveCodeBench的難題中，直接生成正確代碼的成功率只有1.1%，但生成有效屬性檢查的成功率高達(dá)48.9%。

這個現(xiàn)象背后有其合理性。定義"程序應(yīng)該滿足什么條件"往往比"程序應(yīng)該如何實現(xiàn)"更加直觀。比如，描述"排序后的數(shù)組應(yīng)該是有序的"比實現(xiàn)"快速排序算法的具體步驟"要簡單得多。

其次，屬性測試能夠?qū)㈦[藏的邏輯錯誤轉(zhuǎn)化為明顯的運(yùn)行時錯誤。在沒有屬性檢查的情況下，25.3%的錯誤代碼會產(chǎn)生"錯誤答案"——代碼運(yùn)行正常但結(jié)果不正確，這類錯誤最難調(diào)試。而引入屬性測試后，這個比例降低到10.5%，同時"運(yùn)行時錯誤"（包括屬性違反）的比例從4.6%增加到11.8%。雖然總錯誤數(shù)量增加了，但錯誤變得更容易識別和修復(fù)。

第三，屬性測試提供了更豐富的語義信息。傳統(tǒng)的測試失敗通常只告訴我們"期望輸出X，實際輸出Y"，而屬性違反會告訴我們"違反了乘積相等性"或"違反了有序性"，這種高層次的錯誤信息更有助于AI理解問題的本質(zhì)并進(jìn)行針對性修復(fù)。

七、跨模型表現(xiàn)：通用性驗證

PGS的另一個重要優(yōu)勢是其跨模型的穩(wěn)定表現(xiàn)。無論是在能力相對較弱的DeepSeek-Coder-V2上，還是在性能強(qiáng)大的DeepSeek-R1-Distilled-32B上，PGS都展現(xiàn)出了一致的改進(jìn)效果。這說明PGS的核心思想——將代碼生成與驗證解耦，通過屬性測試提供高質(zhì)量反饋——是一個通用的、不依賴特定模型架構(gòu)的改進(jìn)策略。

特別值得關(guān)注的是PGS在不同難度任務(wù)上的表現(xiàn)差異。在簡單任務(wù)上，由于大多數(shù)現(xiàn)有方法已經(jīng)能夠取得較好效果，PGS的改進(jìn)幅度相對溫和。但在中等和困難任務(wù)上，PGS的優(yōu)勢愈發(fā)明顯。這符合直覺：當(dāng)問題變得復(fù)雜時，高質(zhì)量的測試和反饋機(jī)制變得更加重要。

研究還發(fā)現(xiàn)了一個有趣的現(xiàn)象：隨著任務(wù)難度增加，"通過了可見測試但最終失敗"的情況越來越多。在簡單任務(wù)中，這個比例是62.4%對65.9%（通過隱藏測試對通過可見測試），而在困難任務(wù)中變成了1.1%對18.1%。這個巨大的差距說明了傳統(tǒng)測試方法在復(fù)雜問題上的局限性，也解釋了為什么PGS在困難任務(wù)上的相對優(yōu)勢更為顯著。

八、技術(shù)細(xì)節(jié)：讓屬性測試真正可行

雖然屬性測試的理念很優(yōu)雅，但要讓它在實際的AI代碼生成中發(fā)揮作用，還需要解決許多技術(shù)細(xì)節(jié)。

首先是屬性質(zhì)量的保證。并非所有AI生成的屬性都是有用的，有些可能過于寬泛（比如"輸出不能為空"），有些可能存在邏輯錯誤。PGS設(shè)計了一套驗證機(jī)制：每個屬性都必須通過已知正確案例的測試（確保不會誤報），同時在已知錯誤案例上失敗（確保具有發(fā)現(xiàn)錯誤的能力）。

其次是輸入生成的多樣性。屬性測試的威力很大程度上依賴于能夠生成多樣化、有代表性的測試輸入。PGS不是簡單地隨機(jī)生成數(shù)據(jù)，而是根據(jù)問題的約束條件和特性，系統(tǒng)性地創(chuàng)造不同類型的測試場景。對于排序問題，它會生成空數(shù)組、單元素數(shù)組、已排序數(shù)組、逆序數(shù)組、包含重復(fù)元素的數(shù)組等各種情況。

第三是反饋的精確性。當(dāng)屬性違反發(fā)生時，系統(tǒng)需要提供足夠詳細(xì)但不過于復(fù)雜的錯誤信息。PGS會識別違反的具體屬性，提供導(dǎo)致違反的輸入和輸出，并用自然語言描述問題的本質(zhì)。比如，不是簡單地說"測試失敗"，而是說"對于輸入12，期望分解結(jié)果的乘積為12，但實際乘積為6"。

最后是迭代控制。PGS需要在"快速收斂"和"充分探索"之間找到平衡。系統(tǒng)設(shè)置了最大迭代次數(shù)限制（通常為5次），確保在合理時間內(nèi)完成生成過程。同時，它也會動態(tài)調(diào)整屬性的數(shù)量和復(fù)雜度，避免過度復(fù)雜的驗證邏輯影響效率。

九、實際應(yīng)用潛力與局限性

PGS的成功為AI輔助編程開辟了新的可能性。在實際軟件開發(fā)中，程序員經(jīng)常面臨這樣的情況：知道程序應(yīng)該滿足什么條件，但不確定具體如何實現(xiàn)。PGS提供了一種新的交互模式：開發(fā)者可以描述程序的功能需求和約束條件，讓AI基于這些高層次的規(guī)格自動生成并驗證代碼。

這種方法在某些領(lǐng)域特別有價值。在算法競賽中，問題通常有明確的輸入輸出格式和約束條件，但具體的解決策略需要創(chuàng)造性思維。PGS可以幫助參賽者快速驗證算法思路的正確性。在教育領(lǐng)域，學(xué)生可以通過描述程序應(yīng)該滿足的性質(zhì)來驗證自己的代碼實現(xiàn)，獲得更有針對性的學(xué)習(xí)反饋。

然而，PGS也存在一些局限性。首先，它依賴于能夠清晰描述程序?qū)傩缘哪芰Ατ谝恍┥婕皬?fù)雜業(yè)務(wù)邏輯或用戶體驗的應(yīng)用，很難用簡單的屬性來完全描述程序的正確性。其次，當(dāng)前的實現(xiàn)主要針對算法性問題，對于涉及用戶界面、數(shù)據(jù)庫操作、網(wǎng)絡(luò)通信等的復(fù)雜軟件系統(tǒng)，還需要進(jìn)一步的擴(kuò)展和適應(yīng)。

研究團(tuán)隊也坦誠地討論了一些技術(shù)挑戰(zhàn)。屬性的生成質(zhì)量仍然依賴于大語言模型的理解能力，當(dāng)面對全新的問題域時，可能會生成不夠準(zhǔn)確或不夠全面的屬性。此外，當(dāng)前的實現(xiàn)主要關(guān)注功能正確性，對于性能、安全性、可維護(hù)性等其他軟件質(zhì)量屬性的支持還有待加強(qiáng)。

十、未來展望：走向更智能的編程助手

這項研究為AI輔助編程的未來發(fā)展指明了一個重要方向：從"模仿人類代碼"走向"理解程序本質(zhì)"。傳統(tǒng)的代碼生成模型主要通過學(xué)習(xí)大量人類編寫的代碼來獲得生成能力，本質(zhì)上是一種模式匹配和組合。而PGS展示了另一種可能性：讓AI理解程序應(yīng)該滿足的抽象性質(zhì)，基于這些理解來生成和驗證代碼。

這種方法的潛在影響是深遠(yuǎn)的。它可能會改變我們與編程工具交互的方式：不再是告訴計算機(jī)"如何做"，而是告訴它"要達(dá)到什么目標(biāo)"。這種聲明式的編程范式可能會顯著降低編程的門檻，讓更多人能夠參與到軟件開發(fā)中來。

從技術(shù)發(fā)展的角度看，PGS也為形式化方法在AI時代的復(fù)興提供了新的可能性。形式化方法一直是計算機(jī)科學(xué)中確保程序正確性的重要工具，但由于其復(fù)雜性，在實際開發(fā)中的應(yīng)用有限。PGS展示了如何將形式化思想與現(xiàn)代AI技術(shù)結(jié)合，創(chuàng)造出既強(qiáng)大又易用的工具。

研究團(tuán)隊已經(jīng)開源了PGS的實現(xiàn)代碼，這為后續(xù)研究和應(yīng)用提供了良好的基礎(chǔ)?？梢灶A(yù)期，未來會有更多研究者在此基礎(chǔ)上進(jìn)行擴(kuò)展，將PGS的思想應(yīng)用到更廣泛的編程任務(wù)中，或者開發(fā)出更加智能的屬性生成和驗證機(jī)制。

說到底，這項研究最重要的貢獻(xiàn)不是具體的技術(shù)實現(xiàn)，而是思維方式的轉(zhuǎn)變。它提醒我們，在追求AI生成代碼的表面正確性時，不要忘記程序背后的邏輯本質(zhì)。通過將注意力從"生成什么代碼"轉(zhuǎn)向"滿足什么性質(zhì)"，我們可能找到了一條通往更可靠、更智能的AI編程助手的道路。這種方法不僅在當(dāng)前顯示出了明顯的技術(shù)優(yōu)勢，更重要的是為未來的研究開辟了新的可能性，讓我們對AI輔助編程的前景更加充滿信心。

Q&A

Q1：屬性測試跟傳統(tǒng)的單元測試有什么區(qū)別？ A：傳統(tǒng)單元測試需要預(yù)先設(shè)定具體的輸入輸出對（如輸入12，期望輸出[2,2,3]），而屬性測試關(guān)注的是程序應(yīng)該滿足的通用規(guī)律（如"所有因子的乘積等于原數(shù)"）。屬性測試不需要預(yù)知具體答案，只需要驗證程序是否遵循基本原則，這樣更容易發(fā)現(xiàn)深層邏輯錯誤。

Q2：為什么說傳統(tǒng)AI代碼測試會出現(xiàn)"自欺欺人"的問題？ A：當(dāng)AI對問題理解有偏差時，它生成的代碼和測試用例可能包含相同的錯誤邏輯。比如AI誤解了質(zhì)因數(shù)分解的概念，既會生成錯誤的代碼，也會生成錯誤的測試案例，導(dǎo)致錯誤代碼通過錯誤測試，形成惡性循環(huán)而無法發(fā)現(xiàn)真正問題。

Q3：PGS框架的兩個智能體是如何分工合作的？ A：生成器專門負(fù)責(zé)編寫和改進(jìn)代碼，就像程序員；測試器負(fù)責(zé)制定驗證標(biāo)準(zhǔn)、生成測試數(shù)據(jù)和提供反饋，就像質(zhì)量工程師。測試器會根據(jù)問題描述自動識別程序應(yīng)該滿足的屬性，然后系統(tǒng)性地驗證生成器的代碼是否符合這些要求，形成高效的迭代改進(jìn)循環(huán)。