“AI 不要只做簡單的程式碼生成，還要做複雜的軟體工程。”

作者丨馬曉寧

編輯丨陳彩嫻

2025年不僅是智慧體爆發元年，也是AI軟體工程的元年。以AI驅動的自動化軟體工程正加速重構開發正規化。

今天崑崙萬維官宣，開原始碼智慧體Skywork-SWE-32B今日全球上線，以“小引數”重寫倉庫級修復規則。

這是開源生態對抗閉源巨頭的關鍵一役——Skywork-SWE-32B讓企業用消費級顯示卡部署AI工程師成為現實。

模型在SWE-bench-Verified上（OpenHands程式碼輔助框架）將修復準確率拉昇至47.0%，一舉超越了現有引數規模在32B以下的開源模型，直逼Claude v3.7（56.0%）的閉源神話。

掙脫了閉源的枷鎖，AI正從“工具”升級為“協作者”，軟體工程才能真正迎來智慧體驅動的正規化轉移。

現在，開發者可在Hugging Face領取這份“開源工程師”了。

技術報告：https://huggingface.co/Skywork/Skywork-SWE-32B/resolve/main/assets/Report.pdf

部落格：https://quixotic-sting-239.notion.site/eb17f379610040ceb54da5d5d24065bd

模型權重：https://huggingface.co/Skywork/Skywork-SWE-32B

SWE任務：對智慧體模型的終極試煉

經常寫程式碼的人都知道，軟體工程（Software Engineering, SWE）任務，可以說是難度遠超一般的程式碼生成任務。將大型語言模型驅動的智慧體投入真實的軟體工程任務，絕非簡單的“寫程式碼”指令所能涵蓋。

即使是人類工程師，處理陌生專案時首次修復正確率也不到70%。

現在，將一個SWE任務交給智慧體模型，簡直像是要求一個“AI工程師”在極短的時間內，快速融入一個新團隊接手一個龐大且不熟悉的遺留系統，準確理解一個模糊的Bug報告，找到根本原因，設計出符合團隊規範且不會破壞任何其他功能的修復方案，並一次性提交正確的程式碼變更。

這樣的“AI工程師”可真不好找。

超越傳統程式碼生成的能力要求

和傳統的程式碼生成相比，SWE的要求可謂是高得離譜。任何一個環節的薄弱，都可能導致智慧體在複雜工程現實面前束手無策。

以上下文範圍問題為例吧。程式碼生成關注語法和區域性邏輯，就像只看見一棵樹；而軟體工程需要理解整片森林的生態系統。

說到修改某個函式時，普通生成器只看函式本身，工程師卻要考慮十處呼叫點和三年前留下的TODO註釋。非技術層面更關鍵，那些從未寫在程式碼裡的團隊規範要不要遵守？沒有寫在文件裡的效能底線，要不要了解？

這些可不是什麼虛無縹緲的東西，做個“最佳化排序演算法”吧，程式碼生成給出快排實現就結束；而SWE要考慮：為什麼前任用氣泡排序（歷史）？會不會破壞報表模組的呼叫（依賴）？是否符合記憶體限制（約束）？

看似只是一個簡單的需求，實際上已經給智慧體上了無數道枷鎖，對模型的能力要求也是高了不止一個level。

你以為這就完了嗎？

在SWE的開發中，每個決策都涉及多維度的取捨，需求、環境和工具鏈都在發生持續的變化，任何修改都會產生漣漪效應，智慧體與開發者或者工程師進行多輪、深入、澄清性對話，最好還是能主動提問以消除需求歧義。

現在知道，崑崙萬維想要做倉庫級程式碼修復能力的模型，有多不容易了吧。

現有SWE資料集的三大致命缺陷

這是對智慧體模型的工程實踐水平與系統性思維能力的全面考驗，想要訓練出足夠優秀的模型，困難究竟卡在哪裡了呢？

在大量的從業者看來，SWE模型訓練最大的bug，還是出在資料集上。宣稱能驅動智慧體執行軟體工程任務的大模型，其能力基石在於訓練資料。

儘管已有不少工作聚焦於SWE任務並收集了相關的資料集，但當前的主流資料集仍存在三大核心問題，嚴重阻礙了該領域的進一步發展。它們如同沉重的鎖鏈，將模型的潛力死死禁錮在實驗室的牢籠中，使其難以突破理論演示的邊界，邁向真實的工程戰場。

第一大問題，缺乏可執行環境與驗證機制。

已有開源資料（如 SWE-bench-extra、SWE-Fixer）通常缺乏環境或單元測試來驗證資料正確性，導致生成的修復難以驗證。

第二大問題，高質量訓練資料稀缺。

儘管某些資料集規模較大（如 SWE-Dev、SWE-Gym），但缺乏經過嚴格驗證的訓練樣本，公開可用的高質量資料極為有限，導致開源模型在 SWE 任務上落後於閉源模型。

第三大問題：資料規模法則適用性不明確。

相較於自然語言領域中的任務，SWE任務現有的公開訓練資料體量較小，尚無法有效驗證資料擴充套件是否能帶來模型能力的持續增長。

唯有跨越這資料鴻溝，智慧體才有望從“程式碼補全工具”蛻變為值得信賴的“工程夥伴”。

誰能想到，這個眾多國內外公司都無法取得突破的問題，竟然就被崑崙萬維這家國內的AI公司給實現了呢？

Skywork-SWE-32B的破局之道

為什麼是崑崙萬維？可能不少人會有這樣的疑問。

崑崙萬維作為中國AI開源領域的先行者，自2022年底釋出並開源“崑崙天工”AIGC全系列演算法模型以來，持續深耕AGI，既有著技術突破，又有全面前瞻的生態佈局。

2023年崑崙萬維就開源了130億引數模型Skywork-13B系列，配套釋出當時最大的中文資料集Skypile-150B（600GB），2024年開源全球首個支援單臺RTX 4090伺服器推理的千億MoE稀疏模Skywork-MoE，推理成本降低3倍，效能接近70B稠密模型。前段時間中國大陸首個對標OpenAI deep research的天工超級智慧體，也是崑崙萬維推出的agent產品。

既有技術能力，又有工程思維，能夠做出來倉庫級程式碼修復能力的智慧體模型，也是順理成章了。

為了Skywork-SWE-32B，崑崙萬維團隊構建了一套自動化、結構化、可復現的SWE資料收集與驗證流程，共分為3個階段、9個步驟，最終構建出超1萬條高質量任務例項、8千條多輪互動的軌跡，為模型訓練提供堅實基礎。

構建萬級可驗證閉環資料集

資料構建流程圖

圖中顯示，三個階段分別為，A.資料採集與預篩選、B.基於執行的驗證機制、C.智慧體軌跡生成，每個階段又有主要的三個步驟。

資料採集與預篩選階段，先透過 GitHub API 抓取超過 15 萬個開源倉庫的元資訊，處理後最終獲得 8,472 個有效倉庫的元資訊，再透過收集與任務初篩構建出初始的146,568個任務樣本，最後安裝驗證保留23,389個任務樣本。

資料構建過程中各個階段資料樣本量變化圖

基於執行的驗證機制階段， 統一命令生成，Docker環境構建，最後進行單元測試驗證。

最後一個智慧體軌跡生成階段，首先要對每個任務執行最多100輪互動，完成智慧體軌跡生成，Patch級驗證，最終累計收集8,209條高質量、長上下文、多輪互動的驗證透過軌跡，構建訓練樣本庫。

Skywork-SWE資料集的GitHub倉庫詞雲圖

這樣構建的Skywork-SWE資料集，在任務數量與程式碼覆蓋廣度上遠超現有同類資料集（如SWE-Gym Lite與SWE-bench Verified），不僅涵蓋如 Pydantic、SQLGlot、DVC 等主流開源GitHub專案，還包含大量中小型倉庫，為大模型提供了豐富、多樣且貼近實際的軟體工程任務樣本，持續推動智慧體模型的能力演進。

系統性驗證軟體工程Scaling Law的機會

基於Skywork-SWE資料集的高質量智慧體軌跡，選用目前最具自主性的開源OpenHands框架，崑崙萬維團隊訓練了Skywork-SWE-32B模型。看這款模型的引數和得分，真給開源界整了個大活兒。

Skywork-SWE-32B基於開源OpenHands Agent框架，實現了38.0% pass@1的準確率，在32B規模的開原始碼智慧體中達到了當前最優水平。

這說明什麼？同尺寸模型裡最能打，沒有之一！

更為關鍵的是，實驗結果進一步表明：Scaling Law在SWE任務上也成了。

以前我們說，跟語言任務不一樣，SWE任務現有的公開訓練資料體量較小，尚無法有效驗證資料擴充套件是否能帶來模型能力的持續增長。

但是現在，這個論點被崑崙萬維證實了。

只要訓練資料規模能夠持續擴充套件，模型效能就能持續提升，在軟體工程任務中，這句話一樣有效，一樣有用。