AI編程進入下半場！新基準不測補丁，拷問真正的工程能力

新智元報道

【新智元導讀】AI寫代碼已從補丁階段進入全流程工程評估，SWE Atlas 首次系統(tǒng)評測代碼理解、測試編寫與重構(gòu)等核心能力。結(jié)果顯示，盡管GPT-5.4等模型能完成基礎功能，但在代碼健康、邊界覆蓋和跨文件協(xié)調(diào)上仍有明顯不足。

當全世界都在用SWE-Bench類基準為編程智能體封神時，Scale AI拋出了一顆深水炸彈：SWE Atlas。

在這套由資深工程師手寫的284道考題里，前沿模型集體掉檔，Pass@1 最高僅43.49%，做三次能全對的比例驟降30~50%。

更扎心的是，模型們寫代碼修bug的能力一騎絕塵，但在代碼理解、測試編寫、重構(gòu)這些專業(yè)工程師真正在做的事情上，幾乎全員翻車。論文戳穿了一個殘酷真相：當前最強的AI編程智能體，是優(yōu)秀的補丁工，卻仍然是糟糕的工程師。

過去兩年，AI寫代碼的敘事被反復刷新，OpenHands、Agentless、SWE-Bench、SWE-Bench Pro、TerminalBench……每一次榜單更新，都伴隨著新一輪AI替代程序員的喧囂。

但你有沒有想過一個問題：所有這些基準，幾乎都在做同一件事，修bug和加feature。

而真實世界里的軟件工程，遠遠不止這兩件事。一位工程師真正的日常，是閱讀陌生代碼庫、為新功能寫測試、對歷史代碼做重構(gòu)、回答隊友的架構(gòu)問題、debug一個只在生產(chǎn)環(huán)境復現(xiàn)的運行時異常……這些上游和下游的能力，幾乎被所有主流benchmark集體無視。

Scale AI團隊近期發(fā)布的SWE Atlas正是要把這塊評測盲區(qū)補上。

論文鏈接：https://arxiv.org/pdf/2605.08366v1

修bug不等于會工程

論文一開篇就給出了一個犀利的判斷：

把軟件工程等同于功能修復，會制造一個關鍵盲區(qū)。專業(yè)的軟件工程，是維護代碼健康、防止未來回歸、理解復雜架構(gòu)，而這些能力在現(xiàn)有基準中幾乎都沒有被有效評估。

研究團隊進一步指出，過度專注于功能解決，會讓 Agent 被訓練成excellent patchers（優(yōu)秀的補丁工），卻是poor engineers（糟糕的工程師），能修 bug 能加功能，但寫不出可維護的代碼、留不住一個倉庫的長期健康。

為此，SWE Atlas 選擇了三個被嚴重低估、卻在職業(yè)開發(fā)中無處不在的工作流：

• Codebase Q&A（代碼庫問答，124題）：上游能力，深度理解陌生代碼庫，回答架構(gòu)、運行時行為、安全相關的問題；

• Test Writing（測試編寫，90題）：下游能力，為指定行為撰寫生產(chǎn)級測試，覆蓋單元測試、集成測試和端到端驗收測試；

• Refactoring（代碼重構(gòu)，70題）：橫向能力，在不改變可觀測行為的前提下重組代碼，處理重復、遷移、模塊化等問題。

全部284道任務，由資深工程師手寫，取材自18個活躍維護的開源倉庫。

圖 1：SWE Atlas一覽。左：三大工作流及子類目的任務分布（共 284 題）；右：三個工作流的真實任務樣例。

不止跑測試

量化工程素養(yǎng)

SWE Atlas 與以往基準最關鍵的差異，在評估方式上。

傳統(tǒng)基準用 test suite 跑通與否來判定 Pass/Fail，本質(zhì)上只是衡量能不能用。而 SWE Atlas 引入了rubric-based LLM-as-a-Judge，讓 LLM 按照專家編寫的結(jié)構(gòu)化打分表，對答案的工程嚴謹度逐項打分。

每道題平均有多少條打分項？答案讓人咋舌：

• Codebase Q&A 平均 10.5 條 rubric

• Test Writing 平均 17.1 條 rubric

• Refactoring 平均 17.4 條 rubric + 平均 18 條測試

這些rubric涵蓋的是真正的代碼評審視角：測試是否覆蓋了邊界條件？重構(gòu)后是否清除了舊定義？文檔是否同步更新？是否引入了反模式？是否破壞了接口？這些問題，傳統(tǒng) Pass/Fail 測試根本看不見。

更進一步，所有任務都經(jīng)過獨立專家三審，3 位專家中至少 2 位認為有效，rubric 才會保留。整套數(shù)據(jù)集、評測腳本、judge prompt 已全部開源。

GPT-5.4摘冠

但全員剛剛及格

研究團隊把當前最強的前沿模型與頂級開源模型一同送上考場，分別在廠商自家 scaffold（Codex CLI、Claude Code、Gemini CLI）和極簡 mini-SWE-Agent兩套環(huán)境下運行，跑 3 次取平均。

表 1：SWE Atlas 各模型綜合通過率。Pass@1 為單次平均通過率，Pass3 為三次試驗全部通過的比例（一致性指標）。

幾個非常扎眼的結(jié)論：

1. 第一檔：GPT-5.4 與 Opus 4.7 幾乎并駕齊驅(qū)。

在 native scaffold 下，GPT-5.4（Codex）以43.49%的 Pass@1 拿下第一，Opus 4.7（Claude Code）以41.89%緊隨其后，兩者在統(tǒng)計意義上幾乎打平。

2. 開源模型仍有顯著差距。

在 mini-SWE-Agent 這套裸跑環(huán)境下，開源最佳 GLM 5 拿到 24.03%，而前沿模型最高（Opus 4.7）能跑到 38.94%，15 個點的鴻溝依然清晰。Kimi K2.5、Minimax M2.5 落在 15–19% 區(qū)間。

3. 真正震撼的，是Pass3。

三次都通過的比例，相對單次成績普遍下滑 30~50%。GPT-5.4 的 Pass3 僅 29.2%，Opus 4.6 跌到 22.9%，開源模型大多在個位數(shù)。換句話說，當前 SOTA 模型在做這些任務時，運氣成分依然很大，多跑一次就可能不會做了。

功能對了，為什么分數(shù)還是不高？

論文最有意思的部分，是揭示了功能正確和工程合格之間那道巨大的鴻溝。

圖 2：工程質(zhì)量明顯落后于功能正確性。上：所有模型通過功能檢查（變異測試 / 回歸測試）的比例都高于通過 rubric 的比例；下：rubric 類目細分，Test Comprehensiveness、Code Maintainability、Artifact Cleanup 是前沿與開源拉開差距的關鍵。

在Test Writing任務上，模型們寫出的測試套件，通過變異測試（Mutation Test）的比例普遍高于通過rubric的比例，差距在10–15個點。也就是說，模型能寫出看起來能跑、能抓bug的測試，但嚴謹度上仍有明顯缺陷。

而Refactoring任務的差距更夸張：

如果只看回歸測試是否通過，每個模型的得分都能高達 60–80%，看上去都很能打。但一旦拉上 rubric 打分，分數(shù)立刻被腰斬，這正是當前飽和型基準的盲點。

翻譯過來就是：模型能在保持行為不變這件事上蒙混過關，但真正完成重構(gòu)的結(jié)構(gòu)性工作（如清理舊定義、提取模塊、修正反模式）大多沒做到位。前沿模型與開源模型的差距，正好集中在Code Maintainability（代碼可維護性）和Artifact Cleanup（舊產(chǎn)物清理）兩項上。

Codebase Q&A：高分模型，都在跑代碼

圖 3：Codebase Q&A 任務的失敗模式。左：解決率與代碼執(zhí)行次數(shù) / 答案長度的關系，會跑代碼的模型更能贏；右：四類失敗模式的分布，不同廠商模型各有各的病灶。

團隊發(fā)現(xiàn)了一個非常有意思的相關性：在 Codebase Q&A 任務上得分最高的模型，往往擁有最高的平均代碼執(zhí)行次數(shù)。

人工審查這些代碼調(diào)用后他們發(fā)現(xiàn)，最強模型不是在靜態(tài)看代碼，而是在真正把應用跑起來、發(fā)請求、做運行時分析。這種實驗型行為模式，跟一個資深工程師 debug 時的直覺驚人地相似。

反之，失敗的模式可以拆成四類：信息缺失、答案錯誤、無運行時證據(jù)、跑偏目標。GPT 系列模型主要敗在信息不完整（Missing Info），做了實驗但沒覆蓋完所有 rubric 子問題；Claude 系列則主要敗在缺乏運行時證據(jù)（46%），明明是運行時問題，卻選擇只讀靜態(tài)代碼。

Test Writing：測試寫得多 ≠ 測試寫得好

圖 4：Test Writing 任務下，模型在 Manifest / Mutation / Rubric 三類檢查上的成功率，以及測試數(shù)量與質(zhì)量的關系。

另一個反直覺的發(fā)現(xiàn)來自 Test Writing：

寫得越多，不一定寫得越好。論文觀察到一個清晰的模式：較弱的模型傾向于堆數(shù)量，但這些測試大多只驗證函數(shù)應該做什么，幾乎從不測函數(shù)不應該做什么、什么應該保持不變，以及那些會暴露細微行為偏差的邊界場景。

結(jié)果就是：測試套件看起來很豐滿，但變異測試一打就漏，一個 mutant 改了代碼，測試照樣全綠。

研究團隊指出，越強的模型反而寫得越少、越精準，每個測試都瞄準一個具體的回歸點。這才是專業(yè)測試工程師該有的寫法。

Refactoring：跨文件重構(gòu)，前沿模型也會漏掉調(diào)用點

圖 5：重構(gòu)任務的能力隨改動規(guī)模衰減。左：按 gold patch 的代碼行數(shù)分桶，所有模型在改動量增大時全線崩潰；右：file-edit recall 上前沿模型覆蓋更多文件，但仍會漏掉關鍵調(diào)用點。

SWE Atlas 中的重構(gòu)任務，gold patch 改動從 35 行到 2073 行不等。結(jié)果如圖 5 所示：所有模型的解決率，都隨著改動規(guī)模增大而顯著下降。

更精細的分析揭示，前沿模型確實能覆蓋更高比例的需要修改的文件，但即便是最強的 Opus 4.7，也會在跨文件的調(diào)用點（call sites）上漏掉一部分。換句話說，它們看到了主要的修改入口，卻沒能把改動一致地傳播到整個調(diào)用圖。

這意味著：當一次重構(gòu)需要在多個文件之間做協(xié)調(diào)一致的改動時，當前最強模型仍然是不可靠的。

補丁工與工程師

還差一個SWE Atlas

SWE Atlas 給出的結(jié)論并不絕望，前沿模型在這套更嚴苛的考試上能拿到 40% 以上的分數(shù)，本身已經(jīng)是驚人的能力躍遷。

但它也清晰地告訴我們：能修 bug 和是工程師，是兩件不同的事。

當前的最優(yōu)模型已經(jīng)學會探索代碼庫、跑通應用做運行時分析、覆蓋多文件的修改，這些已經(jīng)遠超 18 個月前的狀態(tài)。但在邊界條件覆蓋、可維護性把控、跨文件協(xié)調(diào)修改、舊代碼的清理這些專業(yè)工程的軟實力上，AI 仍有相當長的路要走。

Scale AI的這項工作，本質(zhì)上是給整個行業(yè)重新校準了一把尺子。別再只盯著SWE-Bench的issue resolution跑分了，真正的軟件工程，遠比修bug復雜得多。

值得一提的是，第三方評測機構(gòu)Artificial Analysis近期推出的 Coding Agent Index 已經(jīng)把SWE-Atlas-QnA與 SWE-Bench-Pro-Hard-AA、Terminal-Bench v2一同納入，作為完整AI編程棧的三大評測之一。即便是當前榜首組合 Cursor CLI + Claude Opus 4.7，綜合 pass@1 也僅有61分，整個榜單的頂尖系統(tǒng)均聚集在40~60分區(qū)間，無一突破70 分，這從外部視角再次印證了SWE Atlas評測的嚴苛度。

而下一代的編程智能體如果想真正接管工程師的工作，得先在 SWE Atlas 上拿到一個像樣的分數(shù)。

參考資料：

https://arxiv.org/pdf/2605.08366v1

編輯：LRST