AI Newsway

LLM修復程式碼時弄壞可用程式碼的次數,是真正修好次數的十倍

arXiv新報告測量了盲目迭代修復,並找到一個能關掉破壞行為的引導向量——連同所有真正的修復一起關掉

|5分鐘閱讀0
Source code under review: the study measured what happens when a language model is handed working code and asked to fix it anyway.
Source code under review: the study measured what happens when a language model is handed working code and asked to fix it anyway.

把語言模型放到一段本來能正常執行的程式碼上,它會以相當的頻率把程式碼弄壞。arXiv上的一份新報告為這種直覺補上了算術:在某一組配置下,自動修復迴圈破壞正確程式的比例約為26%,而真正修好有缺陷程式的比例只有約2.3%——比例超過十比一,方向還是錯的。

要點速覽

  • 以競賽程式設計提交程式碼為測試物件,LLM修復迴圈破壞可用程式碼的比率為0.261,修復缺陷程式碼的比率僅為0.023。
  • 放任其反覆迭代,模型會陷入偽修復迴圈,把同一處改動反覆加入又撤銷,且搜尋替換式編輯比整檔案重寫更容易迴圈。
  • 探測發現了一個能預測編輯傾向的內部方向,到第19層附近幾乎可以完全區分;抑制該方向後破壞性迴圈徹底停止,但所有真正的修復也隨之消失。

這項測量做了什麼

這篇由Xietao Wang-Lin、Anton Isopoussu和Louis Mahon撰寫的論文If It's Not Buggy, Don't Fix It,考察的是作者所稱的盲目迭代用法:把程式交給模型,接受返回的任何改動,然後重複。這恰好描述了越來越多團隊把修復機器人接入程式碼評審的方式。

測試平臺是CodeContests+:20道題目,每題40份C++提交,每題平均23個測試用例,分別在Google的Gemini 2.5 Flash-Lite和阿里巴巴的Qwen2.5-7B-Instruct上執行。在貪心解碼加搜尋替換編輯的條件下,Gemini的修復率為0.023 ± 0.002,破壞率為0.261 ± 0.032;另一組配置下破壞率達到0.293 ± 0.011。作者的結論直白:破壞率可能顯著高於修復率。

這些數字旁邊需要放上兩條限定。受測模型是小而快的型號,而非前沿系統;競賽程式設計提交也不同於擁有自有測試套件、評審關卡和CI的生產程式碼庫。這項基準測試衡量的是一個沒有停止條件、沒有人類介入的迴圈——這正是論文的著眼點,但它與衡量一條儀表完備的修復流水線並不是一回事。

停不下來的迴圈

更令人不安的發現是,讓流程一直跑下去會發生什麼。模型往往不會收斂到一個穩定版本,而是進入論文所稱的偽修復迴圈:同一處改動被引入、移除、再引入,程式在通過與失敗之間來回擺動。搜尋替換程式碼塊產生的這類迴圈,無論數量還是長度都明顯多於整檔案編輯。

這在運營層面很關鍵,因為陷入迴圈的代理看上去很忙:它生成差異、報告活動、消耗token。如果迴圈裡沒有接入測試預言機,它的輸出中沒有任何訊號表明它是在原地打轉而不是在推進。

一個代表"這看起來有問題"的內部方向

論文真正有意思的地方在機制分析部分。作者通過探測模型的啟用值構造出一個追蹤編輯傾向的引導向量,其區分度從淺層的AUC 0.7至0.8,上升到第19層附近接近1.0。這意味著模型內部攜帶著一種"有缺陷程式碼"的表徵,而這種表徵正被完全沒問題的程式錯誤觸發——相當於在網路中找到了確切地址的幻覺

在γ = -0.5上沿反方向引導,破壞性迴圈完全停止,所有正確提交都被保留。同時,它也一處都沒修好。與其說這是一個可部署的旋鈕,不如說它乾淨地證明了:在這些模型中,編輯的意願與修復的能力是糾纏在一起的——你無法只調低誤報而保住真正的命中。

這對執行修復機器人的團隊意味著什麼

務實的解讀不是自動修復沒用,而是停止條件本身才是產品。缺少可靠預言機來判斷"這裡沒什麼可修的"的修復工具,會把大部分編輯花在根本不需要改動的程式碼上,而上面的算術表明這些編輯是淨負值。

這也為已在落地工具中顯現的架構趨勢增加了分量。在草稿與工作區之間安插獨立評審者的"評審再修訂"模式——包括GitHub新近預覽的編排層中跨模型家族的批評環節,本站在Project HydraFusion的報道中介紹過——存在的意義正是打斷這篇論文所測量的盲目迴圈。當破壞以一個數量級壓過修復時,限定迭代次數、不給評審者配工具、以及失效安全的補丁應用,就不再只是保守的設計偏好。

後續觀察

這些比例在真實程式碼庫上對前沿模型是否同樣成立,是顯而易見的後續問題,本文並未給出答案。但報告確實確立了一點:這種失敗模式是結構性的,而非偶發。編輯傾向被內部表徵出來,它會在健康程式碼上啟用,而迭代會放大它而不是稀釋它。任何構建完全自主修復系統的人,都應當圍繞這一事實來設計,而不是等著下一代模型讓問題自行消失。

常見問題

這項研究測試了哪些模型?

Gemini 2.5 Flash-Lite和Qwen2.5-7B-Instruct。兩者都是小型、低成本模型而非前沿系統,因此報告中的比率不應被當作最大規模程式設計模型的表現來解讀。

這是否意味著AI程式碼評審工具會讓程式碼變差?

僅憑這項研究還不能這麼說。它衡量的是沒有停止條件、也沒有人工評審的盲目迭代,屬於最壞情況而非典型部署方式。修復工具被允許自主執行的程度越高,這一結果的相關性就越強。

能不能乾脆關掉誤報的缺陷檢測?

沒那麼幹淨利落。作者找到了一個能消除破壞性編輯迴圈的引導向量,但施加之後,所有成功的修復也一併消失了——這說明同一內部表徵同時驅動著兩種行為。

對這篇文章有什麼感想?

SJ
載入中...

相關文章

GitHub的HydraFusion不再挑模型,而是搭一條工作流
Developer Tools

GitHub的HydraFusion不再挑模型,而是搭一條工作流

GitHub的Project HydraFusion為每個Copilot程式設計請求組裝多模型執行計劃,以單模型的簡潔為代價,換來大幅更低的成本。

Seung Jung5 天前
AI智慧體向RubyGems傾瀉2000多個包,新使用者註冊被關閉四天
Developer Tools

AI智慧體向RubyGems傾瀉2000多個包,新使用者註冊被關閉四天

一份取證報告還原了5月的GemStuffer行動:AI智慧體推送兩千多個gem,迫使RubyGems凍結新使用者註冊四天。

Seung Jung6 天前
OpenAI向開發者開放全雙工語音模型,每分鐘5美分
Developer Tools

OpenAI向開發者開放全雙工語音模型,每分鐘5美分

OpenAI的全雙工語音模型GPT-Live-1已通過API開放,每分鐘0.05美元,在Tau3基準上取得86.2%,遠高於前代的45.7%。

Seung Jung7 天前
Cognition SWE-2逼近前沿僅差一分,成本低64%
Developer Tools

Cognition SWE-2逼近前沿僅差一分,成本低64%

Cognition稱SWE-2在FrontierCode 1.1 Main上得分50.0%,僅落後Fable 5.1一分,成本卻低64%,基座是一款中國開源模型。

Seung Jung7 天前
Perplexity讓數百個代理寫資料庫,部署權限仍握在人手上
Developer Tools

Perplexity讓數百個代理寫資料庫,部署權限仍握在人手上

Perplexity以CobbleDB取代DynamoDB。這套4萬行的Rust儲存系統由兩名工程師與數百個無權部署的代理,在兩個月內打造完成。

Seung Jung昨天
Meta 透過 MCP 把 WhatsApp Business 設定交給 Claude 與 Codex
Developer Tools

Meta 透過 MCP 把 WhatsApp Business 設定交給 Claude 與 Codex

Meta 將 WhatsApp Business 帳號設定開放給 AI 程式撰寫代理,新推出的 WhatsApp Business Tools MCP 伺服器讓 Claude Code 與 Codex 從註冊電話號碼一路處理到範本與 Webhook 設定。

Seung Jung前天