SWE-bench跑到94%了，AI寫程式碼真的靠譜了嗎？

2025年底，幾家頂級AI實驗室相繼宣布其模型在SWE-bench Verified上的得分突破90%，部分系統甚至聲稱達到了94%以上。這些數字在AI圈引發了不小的震動。SWE-bench是目前最被廣泛認可的AI程式設計能力評測基準，用於衡量AI系統在真實GitHub Issues上的自動修復能力。94%的通過率，聽起來已經接近人類工程師的水準了。

但AI寫的程式碼，真的靠譜了嗎？

這個問題值得認真拆解，因為評測數字和生產環境之間的距離，往往比人們想像的要大得多。

SWE-bench是什麼，它在測什麼

SWE-bench由普林斯頓大學和卡內基美隆大學的研究團隊於2023年推出。它從GitHub上12個頂級開源Python程式碼庫（包括Django、Flask、NumPy、Pandas、Scikit-learn等）中收集了2294個真實的bug修復任務。

每個任務的形式是：給定一個GitHub Issue描述和程式碼庫，讓AI系統產生一個可以通過原始測試套件的補丁。評測結果用「通過率」衡量——即AI成功產生了能讓相關測試通過的補丁的比例。

SWE-bench Verified是其升級版本，經過人工篩選確保測試案例本身品質可靠，目前是業界最主流的基準之一。

94%意味著什麼

當我們說某個系統在SWE-bench上達到94%，意思是：給定一個真實的GitHub Issue和程式碼庫，該系統有94%的概率能產生一個可以讓測試通過的補丁。這個數字確實令人印象深刻。幾年前，最好的系統也只能達到10-20%。進步是真實的、顯著的。

但這個數字本身有幾個重要的語境需要理解。

數字背後的局限性

局限一：任務選擇的偏差

SWE-bench中的任務雖然來自真實的GitHub Issues，但不是隨機採樣的。能夠進入基準測試的Issue，往往是那些有清晰復現步驟、有完整測試案例、修復範圍相對明確的bug。

真實的工程工作中，很大一部分時間花在另一類問題上：需求模糊甚至相互矛盾的功能開發、沒有測試覆蓋的歷史遺留程式碼、需要理解業務邏輯才能判斷正確性的修改、跨系統跨服務的整合問題，以及沒有明確「通過/失敗」標準的效能最佳化。

SWE-bench不覆蓋這些類型的任務。所以94%的通過率，是在一個相對「有利」的任務分佈上取得的。

局限二：測試通過 ≠ 程式碼正確

這是最關鍵的一點。SWE-bench的評測標準是：產生的補丁是否能讓原始測試套件通過。但測試套件本身是不完整的——它測試的是已知行為，而不是所有正確行為。

AI可以通過一個測試，同時引入新的bug（只是新bug沒有對應的測試）、用一種脆弱的方式「修復」了表面症狀而不是根本原因，或降低了程式碼的可維護性。

在一項對SWE-bench解決方案的獨立分析中，研究者發現大約20-30%的「通過」補丁存在至少一個非測試覆蓋的問題。測試通過是必要條件，但不是充分條件。

局限三：程式碼庫規模和複雜性的限制

SWE-bench中的任務，通常涉及的上下文視窗在幾千到幾萬token之間。但真實的生產程式碼庫動輒數百萬行程式碼，複雜的依賴關係，需要理解大量跨檔案的邏輯才能安全地修改某一處。

當前的AI系統在面對超大型程式碼庫時，理解和推理能力下降是系統性的。在SWE-bench上的高分，並不能直接外推到面對一個幾百萬行程式碼的遺留系統時的表現。

AI程式碼在實際使用中表現如何

生產力提升是真實的。GitHub Copilot的使用者調查顯示，使用AI輔助程式設計的開發者平均任務完成速度提升約55%。這不是SWE-bench的數字，這是真實工作中的回饋。

錯誤引入率也在上升。多項研究表明，使用AI產生程式碼的開發者在引入安全漏洞方面的概率比不使用的開發者更高——尤其當開發者沒有足夠仔細地審查AI產生的程式碼時。

程式碼審查成本沒有消失。AI產生的程式碼仍然需要認真審查。有工程師反映，審查AI產生的程式碼有時比自己寫還要花時間——因為AI產生的程式碼看起來「像真的」，容易讓人降低警惕，而其中隱藏的問題可能很微妙。

什麼場景下AI程式碼是可靠的

儘管有上述局限，AI程式設計輔助在特定場景下的可靠性已經相當高：

樣板程式碼產生：CRUD操作、資料轉換、設定檔案、測試樁程式碼
已知模式的實作：常見演算法、標準函式庫用法、框架慣例
文件和注釋產生：解釋已有程式碼的功能
簡單bug修復：型別錯誤、語法問題、簡單的邏輯錯誤
程式碼重構：在明確約束下的提取函式、重命名、結構調整

什麼場景下需要謹慎

安全敏感程式碼：身份驗證、授權、加密、輸入驗證
並發和執行緒安全：AI在這個領域的錯誤率顯著更高
高度領域特定的邏輯：需要深度業務知識的程式碼
介面契約的設計：API設計、資料模型設計
效能關鍵路徑：需要精確理解系統瓶頸的最佳化

結論：94%是真實的進步，但不是終點

SWE-bench上的94%，代表了AI程式設計能力的真實、顯著進步。把這個數字說成「沒意義」是不誠實的。

但把它解讀為「AI寫程式碼已經可以無需審查直接佈署」，同樣是不準確的。

更準確的表述是：AI程式設計工具已經成為合格的程式設計助手，在特定類型的任務上可以大幅提升效率；但在需要深度推理、安全保證、系統級理解的場景下，人類監督仍然是不可省略的環節。

工程實踐上，合理的做法是：把AI當成一個能力很強但需要認真審查的初級工程師，而不是一個可以無條件信任的資深架構師。