11 月 5 日上傳到 arXiv 的預印本〈Accepted but Wrong〉(Chen 等四位作者)量了一件開發者很常踩的事:語言或函式庫升級後,請 LLM 修舊程式,修完能跑、也通過「一般輸入」的測試,結果卻是錯的。在作者設計的受控環境裡,只靠一般輸入的測試放行了 41.0% 的錯誤修補;多加一筆由發行說明(release note)寫出的邊界輸入,降到 6.5%。
讀到的程度:我只讀到 arXiv 摘要頁,經網頁摘要工具轉述,沒有讀 30 頁全文;下面的數字全部來自這一頁,沒有獨立複測。該文是未經同儕審查的預印本,單一來源,而且作者說產出物只在要求時提供。另外,我是從 11 月 7 日的一份 AI 彙整電子報得知這篇的存在,再回頭讀原頁。
📖 學
一、研究的對象:「無聲失敗」
遷移(migration)出錯常見兩種:一種直接報錯,容易抓到;另一種是這篇關心的「無聲失敗」,也就是程式照跑、回傳值卻不對。例子類型是某個函式在新版本改了預設行為,舊版輸出與新版規格在一般輸入上剛好一樣,只有碰到特殊輸入才分叉。這時用一般輸入寫的測試會誤放行。
二、實驗規模與設計
依摘要頁:預先註冊(preregistered)的研究,共 73 個任務,涵蓋 CPython、Node.js、SQLite 三個專案中 60 項有文件記載的變更。每個候選修補都在真實的執行環境上,對照「不公開給模型的規格」去驗證。擴大後的候選程式碼選單共 1491 個片段,其中有 233 個「困難干擾項」,也就是在一般輸入上與舊行為輸出相同的錯誤程式。
要特別注意的限制:摘要頁明說「沒有執行任何模型寫的程式碼」。候選來自一份由作者撰寫的有限選單,所以這些百分比衡量的是「測試設計能擋掉多少選單中的錯誤」,不是 LLM 在實際專案中的失敗率。
三、主要結果
| 放行條件 | 錯誤修補被放行的比例 |
|---|---|
| 一般輸入的全部斷言 | 0.410 |
| 加一筆由發行說明寫成的邊界輸入 | 0.065 |
| 同上,在 15 個未見過的群集上 | 0.061 |
| 由盲測的 GPT-5.6-luna 撰寫三筆輸入 | 0.070 |
另外,邊界輸入由人寫與由前沿模型寫都是 0.058,都通過預先註冊的檢定;但有兩個本地模型當作撰寫者時沒有通過。換句話說,「讓模型自己出邊界測資」並非每個模型都行。
四、仍然漏網的部分
加入困難干擾項後,仍有 0.168 與 0.153 的「困難錯誤程式」通過(摘要頁對這兩個數字分屬哪兩種設定沒有交代,我不另做推測)。所以邊界輸入不是萬靈丹:錯誤只要刻意貼近舊行為,仍然能溜過去。
五、自測與審計
摘要提到,在四個模型家族中,邊界輸入讓三個開放權重家族每次嘗試的錯誤放行率都下降(例子:0.233 降到 0.057),而模型自己寫的測試幫助較小。另有一輪盲測的 AI 審計把 34 份規格標為「比需求更嚴」,但拿掉這些有爭議的檢查後,0 個判定改變,表示結論對這項爭議不敏感。不過摘要也承認,類別標籤的爭議仍未解決。
六、這能與不能說明什麼
能說明:在這種有限設定下,測試輸入的「選法」比測試的「數量」更關鍵,一筆對準變更內容的輸入勝過許多一般輸入。不能說明:現實專案中 LLM 修補有 41% 是錯的,或某個模型比另一個差,因為沒有執行模型產生的程式。
🧠 記
- 一般輸入測試放行 41.0% 的錯誤修補;加一筆發行說明衍生的邊界輸入降到 6.5%。
- 規模:73 任務、60 項變更、CPython/Node.js/SQLite;預先註冊。
- 仍有 0.168、0.153 的困難錯誤程式通過,邊界輸入不是萬靈丹。
- 限制:沒有執行模型寫的程式碼;預印本;我只讀到摘要頁。
✍️ 實踐
- 挑一個你最近升級過的依賴,讀它的 changelog,找出一項「行為改變」,寫一個只有新舊版會不同的輸入,把它加進測試。
- 做一個小實驗:請你常用的模型針對同一項變更,分別寫「三筆一般輸入」與「一筆你看過 changelog 後指定的邊界輸入」,比較哪一組能分辨舊新行為。
- 之後審 LLM 的遷移修補時,先問「這組測試有沒有任何輸入會讓舊行為與新規格分岔」,沒有就不算驗證過。
🔗 延伸學習
- arXiv:2611.08269 Accepted but Wrong:主要來源,只讀摘要頁。
- Sam on AI:AI Brief, November 7, 2026:當日彙整,用來確認這篇的存在。
💬 問 AI
我讀到 arXiv 2611.08269〈Accepted but Wrong〉:73 個遷移任務、60 項 CPython/Node.js/SQLite 變更,一般輸入測試放行 41.0% 的錯誤修補,加一筆由發行說明寫成的邊界輸入後降到 6.5%,但沒有執行模型寫的程式碼。請你:
1. 分開列出「摘要明確說的」「你能查證的」「你自己的推論」。
2. 說明為什麼「測試輸入的選法」比「數量」重要,並舉一個 Python 或 Node.js 版本升級造成行為改變的真實例子(不確定就說不確定)。
3. 幫我針對我手上這個依賴的 changelog 設計一筆邊界輸入。
4. 不要編造數字或引文。