來深入解析一下「真實世界程式設計基準測試 SWE-bench」。
簡單來說，SWE-bench 是一個專門用來評估大型語言模型（LLM）解決真實世界軟體工程問題能力的黃金標準。它跳脫了傳統上讓 AI 解答單一、封閉的程式挑戰（例如「寫一個排序函數」），而是直接將 AI 丟入一個模擬真實軟體工程師工作的情境中。
這個基準測試由普林斯頓大學的 NLP 團隊於 2024 年底首次推出，因其高難度和貼近現實的評估方式，迅速成為衡量頂尖 AI 模型程式設計能力的權威指標。SWE-bench 如何運作？
其評估流程非常貼近一位軟體工程師修復 Bug 的日常：
- 分派任務 (Issue)： AI 模型會收到一個從真實世界開源專案（例如 Django、matplotlib 等知名 Python 專案）的 GitHub 上複製下來的 Bug 報告（Issue）。這個報告由真人撰寫，可能包含問題描述、重現步驟，但有時也可能模糊不清或缺少關鍵資訊。
- 提供程式碼庫 (Codebase)： AI 模型會被給予整個專案的完整程式碼庫存取權限。這意味著它需要像人類工程師一樣，在成千上萬行的程式碼中進行導航、閱讀和理解。
- 解決問題並提交補丁 (Patch)： AI 的目標是分析問題、找出程式碼中的錯誤，並生成一個補丁檔案（Patch File）。這個檔案記錄了需要對原始碼進行的具體修改，以修復該 Bug。
- 自動化測試驗證 (Evaluation)： 系統會自動將 AI 生成的補丁應用到原始程式碼庫中，然後執行該專案原有的自動化測試套件。評估標準極為嚴格：
- FAIL_TO_PASS: 原本會導致失敗的測試，在應用補丁後必須通過。
- PASS_TO_PASS: 原本就能通過的測試，在應用補丁後不能被破壞，以確保修復沒有引入新的問題。
只有當 AI 生成的補丁能夠成功通過所有相關測試，才算作一次「成功的解決」。最終得分以成功解決的問題百分比來呈現。
SWE-bench 為何如此重要且困難？
它之所以被稱為「真實世界」基準，是因為它反映了軟體開發的真正複雜性，這與簡單的程式測驗有天壤之別：
- 專案級別的複雜度： 問題的解決方案往往需要跨越多個檔案和模組，要求 AI 具備對整個大型程式碼庫的結構性理解能力。
- 模糊的任務定義： Bug 報告是為人類溝通而寫的，AI 必須從自然語言描述中準確理解開發者的意圖。
- 上下文依賴性強： 修復一個 Bug 需要理解變數如何傳遞、類別如何繼承、模組之間如何互動，這是孤立的程式測驗無法模擬的。
- 對精確性的極高要求： 任何微小的語法錯誤、邏輯疏漏或對現有功能的破壞都會導致任務失敗。
最新發展與模型表現
SWE-bench 已成為各大 AI 公司展示其模型實力的重要舞台。隨著模型的進化，這個基準本身也在更新，例如推出了經過人工篩選和改進的 SWE-bench Verified 版本，以更準確地評估模型能力。
- Claude Opus 4.1： 正如您在先前的問題中提到的，Anthropic 的最新模型在此基準測試上取得了創紀錄的 74.5% 的解決率，這是一個非常驚人的成績，也凸顯了其在程式碼重構和修復方面的重大進步。
- 其他頂尖模型： 像 OpenAI 的 GPT 系列、Google 的 Gemini 以及其他專門的程式設計 AI（如 Devin）也都在這個基準上進行了測試，但目前 Claude 4.1 處於領先地位。
總結來說，SWE-bench 不再只是測試 AI 能否「寫程式」，而是在測試 AI 能否成為一名合格的「軟體工程師」。它推動著 AI 技術從單純的程式碼生成，邁向能夠理解複雜系統、自主解決工程問題的更高層次。一個模型在 SWE-bench 上的高分，直接意味著它在輔助甚至自動化軟體開發方面具有更強的實用價值。
針對「如何進行 SWE-bench 測試」這個問題，這是一個純粹的技術性操作，主要面向開發者和研究人員。一般使用者無法像使用 ChatGPT 或 Claude 網頁版那樣直接「玩」這個測試。
以下是為技術人員準備的、相對簡化的步驟指南。整個過程的核心是在一個受控的環境中，讓 AI 模型嘗試修復一個真實的程式碼問題。
核心概念：為何需要 Docker？
在開始之前，必須理解環境隔離的重要性。SWE-bench 中的每一個問題都來自不同的開源專案（如 Django 3.2, matplotlib 3.5 等）。這些專案依賴特定版本的 Python 和函式庫。為了確保 AI 生成的修補程式能在與原始 Bug 完全相同的環境下被測試，SWE-bench 使用 Docker 來為每個問題創建一個獨立、乾淨且版本正確的運行環境。不使用 Docker 將極難重現評測結果。
技術實作步驟指南
步驟一：前置準備 (Prerequisites)
您需要一個適合開發的環境，通常是 Linux 或 macOS（或 Windows 上的 WSL2）。
- 安裝 Git： 用於從 GitHub 下載程式碼。
- 安裝 Docker： 這是整個流程的基石，用於創建隔離的測試環境。請確保 Docker 服務已啟動。
- 安裝 Python： 建議使用 Python 3.9 或更高版本。
- 取得 API 金鑰 (API Keys)： 如果您要測試的是像 GPT-4o 或 Claude Opus 這類商業模型，您需要前往 OpenAI 或 Anthropic 的官方網站申請 API 金鑰。
步驟二：安裝與設定 SWE-bench
- 從 GitHub 克隆官方儲存庫：
git clone https://github.com/princeton-nlp/SWE-bench.git
cd SWE-bench - 安裝 SWE-bench 函式庫：
pip install -e .
(-e表示可編輯模式安裝，方便您查看或修改原始碼)。 - 設定 API 金鑰為環境變數： 在您的終端機中，設定您的金鑰。這能讓 SWE-bench 腳本安全地呼叫模型 API。
- 測試 OpenAI 模型:Bashexport OPENAI_API_KEY="sk-..."
- 測試 Anthropic 模型:Bashexport ANTHROPIC_API_KEY="sk-ant-..."
步驟三：運行評估腳本
SWE-bench 的核心是一個名為 run.py 的腳本。您可以透過指令行參數來控制要測試哪個模型、解決哪個問題。
一個完整的測試指令範例：
假設我們要使用 Anthropic 的 claude-3-opus-20240229 模型，去嘗試解決 django 專案中的 django-11099 這個 Bug。
Bash
python run.py \ --model_name_or_path "anthropic/claude-3-opus-20240229" \ --instance_filter "django__django-11099" \ --testbed "./testbed" \ --log_dir "./output_logs"
指令參數詳解：
--model_name_or_path: 指定您要評測的 AI 模型。SWE-bench 已內建支援多種主流模型，如gpt-4o,gpt-4-turbo,claude-3-opus-20240229等。--instance_filter: 指定要測試的問題 ID。SWE-bench 的完整測試集包含數千個問題，直接跑完會非常耗時且昂貴。通常會先用單一問題來測試流程是否正常。django__django-11099就是一個標準的問題 ID。--testbed: 指定一個資料夾，SWE-bench 會在這裡下載 Django 專案的原始碼。--log_dir: 指定存放結果的資料夾。所有模型的思考過程、生成的程式碼、最終的評測結果都會保存在這裡。
步驟四：解讀結果
執行完畢後，進入您指定的 log 資料夾（此例中為 ./output_logs）。您會找到以模型和問題 ID 命名的子資料夾，裡面包含：
- *.log 檔案： 記錄了 AI 模型與系統互動的完整過程，包括它收到的指示、它的思考步驟以及最終生成的程式碼。
- *.patch 檔案： AI 模型生成的最終修補程式。
- eval.json 檔案： 最重要的結果檔案，裡面會用 JSON 格式記錄這次測試的結果，例如
{"resolved": true}或{"resolved": false}，明確告知您這個 Bug 是否被成功修復。
總結與建議
- 從小處著手： 務必先用
--instance_filter指定單一問題來測試您的環境設定是否正確。 - 成本考量： 運行完整的 SWE-bench 測試集會進行數千次 API 呼叫，費用可能相當高昂。請先確認您的 API 預算。
- 測試本地模型： 若要測試本地運行的開源模型（如 Llama 3），流程會更複雜，通常需要額外設定一個與 OpenAI API 格式相容的本地伺服器。這屬於進階用法，建議詳閱官方文件。
總之，進行 SWE-bench 測試是一個嚴謹的學術/工程評估流程，旨在以最接近現實的方式衡量 AI 的程式設計能力。您可以透過其 GitHub 官方儲存庫 獲得最詳盡、最即時的資訊。
