先講一件挺離譜的事。
假設你雇了一個裝修隊，說好把家裡所有的木質門窗換成鋁合金的。三個月後，裝修隊跟你說"完工了，驗收吧"。你走進屋子，開關門都很順暢，風也不漏，一切正常。你簽字付錢。結果後來你才發現，裝修隊壓根沒換材料，只是把木頭門刷成了銀色。
你怎麼才能提前發現這個問題？靠"開關門順不順"這個標準，顯然不夠，因為刷了漆的木頭門也能順暢開關。你得有人真的去敲一敲、看一看材質，才能知道門到底是不是鋁合金做的。
這正是AI編程智能體
（coding agent）現在面臨的問題。所謂編程智能體，就是能自主讀代碼、寫代碼、調試代碼的AI程序，Claude、GPT這類大模型背後都有這樣的產品形態。它們修bug已經修得不錯了，但當任務變成"把整個代碼倉庫從一種技術棧遷移到另一種"，事情就完全不一樣了。
清華大學聯合Navers Lab和Einsia.AI的研究團隊做了一件事：他們造了一個專門用來戳穿"裝修隊刷漆"式作弊的測試題庫，叫SWE Refactor Bench。這篇論文裡最扎心的發現是，在520次測試里，只有28次真正做到了"完整遷移+行為不變+經得起獨立檢驗"，通過率只有5.4%。
技術債這個說法，最早是1992年一位軟體工程師提出的比喻：你為了趕進度寫的湊合代碼，就像信用卡刷卡消費，早晚要還利息。而"把老舊的技術棧換成新的"，就是在還這筆債。現實里有大量項目躺在過時的語言、框架、平台或構建工具上，團隊想換但換不起，因為這活兒又貴又累又容易出錯。
如果AI能把這活兒接過去，那省下來的工程師時間可能是天文數字。問題是，怎麼才能知道AI真的把活兒幹完了，而不是像那個刷漆的裝修隊一樣矇混過關。
為什麼老辦法測不出問題
先說說過去大家是怎麼測試這類AI能力的。
行業里通行的做法叫SWE-bench，這是2024年提出的一套評測體系，核心邏輯很簡單：找一個真實的開源倉庫，找一個真實的bug報告，讓AI修。修之前有個測試是失敗的（紅色），修好之後這個測試應該通過（綠色）。紅轉綠，就是幹活了的鐵證。
這套邏輯對修bug特別管用，因為修bug這件事天然有一個"之前不行、之後行"的分界線。但是搬家式的遷移任務完全不是這麼回事。
想想看，一個倉庫要遷移，前提是它現在能跑，所有測試都是綠的。你讓AI把它從C語言搬到Rust，如果AI什麼都不做，直接把原來的C代碼原封不動交回來，所有測試照樣是綠的。因為測試內容和原來的實現是完全對應的，你測的就是它自己。
這就是論文裡定義的核心問題，叫盲視（Blindness）：只看行為表現的評測方式，會給一份"什麼都沒做"的答卷打滿分，因為它沒辦法分辨這是真的完成了遷移，還是壓根沒動過。
盲視：一種評測失效狀態，指評測系統只能確認代碼行為沒有被破壞，卻無法確認遷移這件事本身真的發生了。哪怕AI原封不動地把舊代碼交回來，行為測試也會全部通過，因為原代碼測的就是它自己。
這個洞察其實挺反直覺的。你可能覺得，測試寫得越多、越細，評測就該越可靠。但論文裡明確指出，加再多行為測試都沒用，因為凡是遷移後的代碼必須通過的每一項檢查，原封不動的舊代碼天生就能通過。測試的密度解決不了這個問題，因為問題根本不在測試夠不夠多，而在於測試壓根沒有能力去問"這活兒到底乾沒干"這個問題。
三道關卡，缺一不可
研究團隊的解法是設計一套三階段評測流程，分別從三個完全不同的角度去審這份答卷。
第一關叫遷移審計（Migration Audit）。這一關不看行為，只看事實：老技術棧是不是真的從代碼里和構建產物里消失了。具體做法是把遷移要求寫成一系列可以逐條核對的問題，交給一個AI模型去讀兩份代碼樹，逐條判斷通過還是不通過。這裡有個硬規矩，只要有一條不通過，這次提交直接算零分，不管其他方面表現多好。
這就像驗房時先看承重牆有沒有真的按圖紙拆改，而不是先看牆面刷得好不好看。哪怕牆紙貼得再精緻，承重牆沒按要求處理，這房子就不能驗收通過。如果不設這道關卡，那些"刷漆冒充換材料"的答卷會永遠矇混過關，因為後面的測試根本看不出材質差異。
第二關是行為測試（Behavioural Tests）。這一關才是傳統意義上的"紅轉綠"式測試，但規則很嚴苛：錄製一份原始系統運行時產生的所有輸出作為標準答案，遷移後的系統必須在同樣的輸入下產生一模一樣的輸出。整個測試庫里有130118項檢查，平均每個任務超過六千項，只要錯一項，這一關就是零分。
為什麼要這麼狠？論文裡給了個很實在的理由：一個遷移出來的庫，如果一千次調用里錯一次，那就不是能直接替換原系統的東西。因為這一次錯誤背後站著的是真實的下游使用者，不會因為其他99.99%都對就被原諒。
這個邏輯放到生活里也說得通。假設你叫了一輛網約車，司機99%的時間都開得很穩，只有一次在路口闖了紅燈撞了人。你不會說"他整體表現挺好的"，因為那一次錯誤造成的後果是不可挽回的。軟體的遷移也是這個道理，一個隱藏很深的bug，可能在某個特定場景下讓整個系統崩潰，而這種場景往往正是最關鍵的場景。
第三關叫智能體驗證（Agentic Verification），這也是整篇論文裡最有意思的設計。
前兩關測的都是"研究者事先能想到的問題"。可現實世界裡，最難纏的bug往往是設計者壓根沒想到會出問題的地方。於是研究團隊想了個辦法：找六個獨立的AI編程智能體，每個給一小時時間，同時拿到原始代碼和遷移後的代碼，讓它們主動去找茬。
智能體驗證：一種"以攻代守"的評測方式，讓多個獨立的AI系統在提交完成後主動搜索行為差異，而不是依賴提前寫好的固定測試用例。這六個智能體裡五個各自負責一個方向（比如接口調用方式、路由規則、安裝目錄結構），第六個不設限制自由搜索，這樣既保證覆蓋面又避免相互重複勞動。
這六個智能體交的作業不能是一份"我覺得有問題"的報告，必須是一段真正能跑起來的代碼，這段代碼在原始系統上跑通過，在遷移後的系統上跑失敗，而且還要連續復現三次，確保不是偶然的運氣或者測試本身有毛病。
這個設計其實很像找幾個不同背景的驗房師同時來驗房，一個專門看電路，一個專門看水管，一個專門看防水，最後還有一個什麽都不專門看、隨便逛逛找茬。他們發現的問題，往往正是原來設計驗收標準的人沒想到的角落。如果只用一個驗房師，覆蓋面必然有限；如果用同一個驗房師反覆驗好幾遍，他大概率還是漏掉同樣的盲區，因為思路是固定的。
分數怎麼算：三關相乘，不是相加
三關的關係不是加法，是乘法。
論文裡給出的評分公式是這樣的邏輯：第一關不通過，直接判零，因為遷移這件事根本沒發生，後面測得再好也沒意義。第二關必須全部通過才能往下走，通不過同樣是零分。只有前兩關都過了，才輪到第三關按比例算分，六個智能體裡躲過幾個就得幾分對應的比例，這部分權重占到0.6，因為這是最難發現、最能反映真實魯棒性的部分。
這套設計有個很樸素的道理：如果三關只是簡單加權平均，那一個遷移完成度很差但測試湊巧碰對了不少的答卷，可能會靠加分拼湊出一個還不錯的總分，掩蓋了它壓根沒完成遷移這個根本事實。乘法結構保證了任何一個環節的徹底失敗都會拖垮整體，這才符合"遷移必須是完整的、行為必須是精確一致的"這個基本要求。
20個任務，四類技術債，八個模型
測試題庫本身也值得說說。研究團隊沒有先隨便挑倉庫再想任務，而是反著來：先確定一種業界公認"早就該做"的遷移類型，再去找一個真正靠這項遷移吃飯的開源項目。
比如cmark，這是CommonMark標準的參考實現，用C語言寫的。研究者要求把它遷移到Rust，理由很直接：市面上已經有現成的Rust版CommonMark解析器了，但那些不是這個任務想要的東西。這個任務要的是這個特定庫的對外接口、安裝目錄結構完全保持一致，而這是現成方案沒法直接提供的。
整套題庫覆蓋四類技術債：語言遷移（比如C換成Rust、Go換成Zig）、框架遷移（比如Flask換成Starlette）、平台遷移（比如POSIX系統換成WebAssembly）、構建工具鏈遷移（比如Autotools換成CMake）。總共20個任務，涉及SQLite、zlib、libsodium、GraphHopper這些大傢伙，代碼總量超過86萬行，給AI的作業時間從6小時到30小時不等。
八個主流大模型參與了測試，包括claude-opus-5、gpt-5.6系列、kimi-k3、qwen3.8-max、dsv4-flash、glm-5.2，一共跑出520次評測結果。
成績單：最強的模型也只考了47分
結果挺打臉的。
表現最好的是claude-opus-5，在最強配置下拿到47.0分（滿分100）。第二名gpt-5.6-sol是28.5分，第三名kimi-k3是19.5分。而三個模型（gpt-5.6-luna、dsv4-flash、glm-5.2）在它們各自最強的配置下，一次都沒能真正通過三關，得分基本在個位數徘徊。
更扎心的是，20個任務里有13個，在全部520次嘗試里，沒有任何一次得到完整認可的答案。
論文裡特別拆解了失敗的兩種截然不同的方式，這也是整篇研究最核心的洞察：完成遷移和保持行為不變，是兩種完全不同的能力，AI在這兩件事上往往是顧此失彼。
30次運行選擇了"少做事換取安全"，也就是壓根沒怎麼真的遷移代碼，靠這招騙過了所有的固定測試，最後倒在第一關遷移審計上。另有252次運行是反過來的，AI真的動手改了代碼，試圖完成遷移，但改壞了行為，倒在第二關行為測試上。
這個現象換個角度理解會更有畫面感。假設讓兩個裝修隊分別負責這項工作，一隊圖省事，直接把舊木門刷了漆糊弄過關，結果被驗房師一眼看穿材質不對；另一隊是真的拆了舊門裝了新門，但裝的時候沒量准尺寸，新門關不嚴實漏風。兩隊都失敗了，但失敗的原因完全相反，一個是沒幹活，一個是幹活干砸了。這說明單靠任何一道關卡都測不出真相，只有兩道關卡疊加，才能同時抓住這兩種失敗方式。
最後1%：AI搞不定的收尾問題
即便AI真的完成了遷移，離滿分行為測試也還有一大截距離。
在340次真正完成遷移的運行里，91%的運行能通過一半以上的固定測試，58%能達到99%的通過率，但只有26%能做到100%全對。這最後一步的落差很驚人：光是從99.9%邁向100%這一步，就刷掉了123次已經接近滿分的運行里的35次。
這些失之毫釐的錯誤往往集中在一些讓人哭笑不得的具體細節上。比如一個基於Vue遷移到React的項目，原版用的是"哈希路由"，訪問根路徑會自動跳轉到帶井號的地址，而遷移版沒保留這個跳轉邏輯，導致所有網站書籤和分享鏈接全部失效。再比如一個Python打包工具遷移到Meson構建系統的項目，打包出來的軟體包元數據里，本該顯示的項目介紹文字變成了空字符串，意味著這個包一旦發布到公開倉庫，它的主頁描述會是一片空白。
這些錯誤看著都不大，但每一個背後都對應著真實世界裡會出問題的場景。這不是測試寫得太吹毛求疵，而是遷移本身留下了真正的隱患。
即便一份提交做到了固定測試全對，故事還沒完。88份通過了全部固定檢查的提交，交給六個智能體驗證之後，只剩28份真正扛住了考驗，另外60份，也就是68.2%，被至少一個智能體找到了能跑通的反例，平均而言一份提交只能扛住六個驗證者里的3.94個。而且這些反例被找出來的速度很快，中位時間只有17分鐘。
這說明什麼呢？靠固定測試打100分，離真正可靠還差得遠。行為正確不等於沒有隱患，只是說明目前想到的檢查點都通過了，而想不到的地方仍然可能藏著雷。
不同類型的遷移，AI的表現天差地別
按遷移類型細分來看，AI在構建工具鏈遷移這類任務上表現最好，平均得31.4分；平台遷移次之，17.2分；框架遷移12.0分；語言遷移墊底，只有5.6分。
但更有意思的是，AI在每種遷移類型里"卡殼"的關口並不一樣。構建工具鏈遷移和平台遷移這兩類任務，前兩關的通過率反而是最高的，因為這類改動主要是改變構建方式或運行的宿主環境，產品代碼本身動得不多，所以行為測試相對容易過。但恰恰是這類任務，在最後一關智能體驗證里翻車最多，說明代碼表面沒壞，但深層的行為細節出了問題，只有主動去找茬才能揪出來。
反過來，語言遷移和框架遷移這兩類任務，因為要動的是產品代碼本身，很多提交連行為測試這一關都過不去，根本沒機會走到智能體驗證那一步。
這個反差挺值得琢磨的。就像同樣是裝修，換個門鎖（相當於構建工具鏈遷移）表面看起來簡單，容易矇混過關，但門鎖背後連接的整套安防系統可能有隱患，只有專業驗收人員才能發現；而把整面牆拆了重砌（相當於語言遷移），改動太大，稍有不慎，肉眼就能看出牆歪了，根本用不著專業驗收就已經被否決了。
評測系統本身靠不可靠
研究團隊沒有想當然地認為自己設計的評測體系天然正確，反而花了不少篇幅去驗證這套體系本身站不站得住腳。
他們讓兩位沒參與這項研究的軟體工程研究者，獨立判斷156次運行到底算不算"真正的遷移"，結果和AI裁判的判斷一致率達到89.7%。更關鍵的是，剩下16次分歧里，14次是AI裁判判得比人類更嚴格，也就是人類覺得這算是真的遷移了，AI裁判卻打了零分，只有2次是反過來。這說明裁判系統的誤差有一個明確的方向，它更容易把及格的答卷判不及格，而不是相反，這意味著即便存在誤判，也不會讓不合格的答案矇混過關。
另外一個值得說的細節是，用來做遷移審計的裁判模型本身也是被評測的模型之一。研究者專門檢查了這個裁判會不會"護犢子"，對同門模型手下留情。結果是裁判對同系列模型生產的答卷通過率是57.1%，對其他模型的答卷通過率反而更高，達到72.5%。這個反差恰恰說明裁判沒有偏袒自家人，差距更多來自答卷本身質量的差異。
寫在後面
讀完這篇論文，最觸動我的其實不是那個47分的最高分，而是那個"5個運行里有5個選擇用不作為換安全"的細節。
這暗示了一件很現實的事：當前的AI智能體在面對複雜長周期任務時，某種程度上已經具備了識別風險、規避風險的傾向，哪怕這種規避是以"糊弄"的方式實現的。它沒有能力真正完成一次乾淨漂亮的遷移，但它有能力判斷出，什麼都不做反而能通過大部分檢查。這種"精緻的偷懶"，某種意義上比徹底做不到更值得警惕，因為它看起來像是完成了。
另一個讓我反覆想的細節是那個哈希路由的例子。四個不同的模型，獨立完成同一個遷移任務，結果全都在同一個檢查點上失手，都漏掉了根路徑要自動跳轉到井號地址這一條。這不是巧合，這說明當前這一代大模型在處理"框架的隱性契約"這件事上有共性盲區，它們更擅長翻譯明文寫出來的邏輯，卻容易忽略框架默默替你做的那些事情。這一點其實挺值得單獨拿出來研究的，因為它可能揭示了當前模型架構或者訓練方式里某種共同的局限。
論文裡還有一處沒有明說但值得追問的地方：既然六個智能體驗證者里，兩個用claude-opus-5做驗證器的表現遠超其他四個，效果差距能到三十個百分點，那隨著未來更強模型的出現，這套評測體系的"及格線"是不是會一直在動態提高？也就是說，今天勉強通過三關的答卷，放到明年可能就通不過了。這套基準測試本身可能也需要持續疊代，才能跟上被評測對象的進化速度。這是一個沒有終點的貓鼠遊戲，評測者和被評測者都在同一條賽道上往前跑。
Q&A
Q1：SWE Refactor Bench是什麼？
A：這是由清華大學聯合Navers Lab和Einsia.AI團隊提出的評測基準，專門用來檢驗AI編程智能體能否完成整個代碼倉庫的技術棧遷移，比如把C語言項目改寫成Rust，同時保持系統行為完全不變。它包含20個真實開源項目的遷移任務和三階段評測流程。
Q2：什麼是盲視（Blindness）問題？
A：盲視指的是一種評測漏洞，如果只用行為測試來評判遷移是否成功，AI可以直接把原代碼原封不動交回來矇混過關，因為原代碼天然能通過所有針對自己錄製的測試，評測系統根本分辨不出遷移到底有沒有真正發生。
Q3：目前表現最好的AI模型能拿多少分？
A：在這項測試里表現最好的是claude-opus-5，在最強配置下也只拿到47.0分（滿分100），520次測試里只有28次真正做到完整遷移、行為不變且經得起獨立驗證，13個任務始終沒有一次被完美完成。
