DeepSWE：讓 coding agent 差距重新被看見的長程工程評測
你一定也遇過這種狀況：在線上排行榜看某個 LLM 的 coding 分數高到嚇人，興沖沖地把它拉進專案幫忙改 bug，結果它連基本目錄結構都摸不透，隨便改了幾個檔案就兩手一攤。這種落差，正是 Datacurve 推出 DeepSWE 想要正面對決的痛點。
DeepSWE 是 Datacurve 在 2026 年 5 月公開的新一代 coding agent 評測。它測的不是單次補程式碼，而是 AI 工具能不能像開發者一樣讀專案、改檔案、跑驗證。以前的排行榜常讓頂尖模型看起來很接近，但實際拿來改專案時，穩定度、探索能力、寫測試的習慣、會不會漏掉需求，差距依然非常大。工程任務不是只補一個函式或改一個 test，而是要讀懂整個 repo、判斷修改範圍、保持既有行為、補驗證，最後交出能跑的 patch。
先把幾個詞說清楚
這篇會遇到幾個 AI 開發工具圈常用的詞，先換成比較接近台灣開發者日常的說法。
| 名詞 | 這篇裡的意思 |
|---|---|
| coding agent | 會自己讀檔、改檔、跑指令、嘗試完成工程任務的 AI 開發代理。 |
| benchmark | 評測題庫。用一批固定任務比較不同模型或工具。 |
| repo / codebase | 程式碼倉庫，也就是一個完整專案，不單單是單一檔案。 |
| prompt | 交給模型的任務描述。DeepSWE 特別在意短描述下，模型能不能自己找上下文。 |
| patch / code diff | 模型最後交出的修改內容，可以理解成一份 code diff。 |
| verifier | 驗證器。負責判斷模型改完後，功能是不是真的符合要求。 |
| harness | 執行框架。它規定模型能用哪些工具、怎麼讀檔、怎麼下指令、怎麼交答案。 |
| trajectory | 執行軌跡。模型完成任務過程中的指令、思考步驟、檔案修改與測試紀錄。 |
| pass rate | 通過率。100 題通過 70 題，就是 70%。 |
DeepSWE 在測什麼
DeepSWE 評測的不是「模型會不會寫出某段已知答案」，而是「模型能不能在一個真實 codebase 裡完成一個新工程任務」。
它的任務設計有四個重點：
- 任務從頭撰寫，不直接取用公開 PR、commit 或既有解法，降低預訓練污染與解答外洩。
- 任務分散在 91 個活躍開源 repo，涵蓋 TypeScript、Go、Python、JavaScript、Rust。
- 任務描述比 SWE-Bench Pro 短，但參考解法平均需要更多程式碼與更多檔案修改。
- 驗證器以可觀察行為為準，不要求模型的寫法長得像參考解法。
圖 2：DeepSWE 更像「把需求交給 coding agent 做完整工程變更」，不是「讓模型猜某個 PR 的修改包」。
這讓 DeepSWE 和傳統從 GitHub issue 或 PR 衍生的評測有明顯差別。許多公開評測會把問題、重現步驟、測試細節、甚至變數與函式名稱都講得很清楚；DeepSWE 則刻意把任務描述寫得更接近人類會丟給 AI 開發代理的工作描述，模型必須自己想辦法摸索結構、撈資料，最後定位出需要修改的檔案。
為什麼它比較接近開發體感
DeepSWE 最值得看的地方不是單純分數，而是任務形狀。
| 指標 | SWE-Bench Verified | SWE-Bench Pro | DeepSWE |
|---|---|---|---|
| 平均任務描述長度 | 1,700 chars | 4,614 chars | 2,158 chars |
| 平均參考解法新增行數 | 10 lines | 120 lines | 668 lines |
| 平均參考解法修改檔案數 | 1 file | 5 files | 7 files |
圖 3：DeepSWE 的任務描述不是最長，但參考解法規模明顯更大。
這組數字說明一件事：DeepSWE 不是靠塞更多任務描述內容來拉高難度，而是把「定位問題」與「完成跨檔案變更」也納入評測。這正是 coding agent 和單次程式碼補全最大的差異。
對日常開發來說，一個好用的模型不只是會改幾行 code，它還要能做這幾件事：
- 從短需求推回整個 codebase 裡的實作位置。
- 分辨要改 API、state、測試、還是只改局部邏輯。
- 在改完後主動跑現有測試或補新的 unit test。
- 不把無關的既有功能弄壞。
- 不用硬猜驗證器，而是做出真的符合行為的改動。
排行榜怎麼看
DeepSWE 的發佈版排行榜把前沿 coding agent 模型拉出明顯差距。官方頁面顯示，GPT-5.5 xhigh 以 70% 位於第一，GPT-5.4 xhigh 為 56%，Claude Opus 4.7 max 為 54%，接著是 Claude Sonnet 4.6 high 的 32%。
圖 4：DeepSWE 讓頂尖模型的通過率拉開，而不是全部擠在相近區間。
| 模型設定 | DeepSWE 通過率 |
|---|---|
| GPT-5.5 xhigh | 70% ± 4% |
| GPT-5.4 xhigh | 56% ± 5% |
| Claude Opus 4.7 max | 54% ± 5% |
| Claude Sonnet 4.6 high | 32% ± 4% |
| Gemini 3.5 Flash medium | 28% ± 4% |
| GPT-5.4 mini xhigh | 24% ± 4% |
| Kimi K2.6 | 24% ± 4% |
| Mimo v2.5 Pro | 19% ± 4% |
| GLM 5.1 | 18% ± 4% |
| Gemini 3.1 Pro | 10% ± 3% |
| DeepSeek v4 Pro | 8% ± 2% |
| Gemini 3 Flash | 5% ± 2% |
這裡要小心解讀：DeepSWE 固定使用 mini-swe-agent 作為共用 harness，讓不同模型在同一套工具與任務描述下比較。這能降低工具外殼差異，但也代表它不是 Cursor、Claude Code 等產品體驗的完整排名。
簡單來說，DeepSWE 的結論比較適合這樣讀：在同一個簡化 harness 中，哪些模型比較能完成長程、跨 codebase、行為導向的程式開發任務？它不應該被解讀成哪個完整 coding IDE 或 CLI 產品一定比較好。
驗證器才是這次最有價值的部分
DeepSWE 對 SWE-Bench Pro 做了一段很值得看的驗證器稽核。Datacurve 抽樣比較 DeepSWE 與 SWE-Bench Pro 的驗證器判斷，讓另一個 LLM 分析器重新閱讀執行軌跡、任務定義、參考解法、驗證器輸出，再判斷 patch 是否真的完成需求。
結果很尖銳：
| 類型 | SWE-Bench Pro | DeepSWE |
|---|---|---|
| False positive，錯誤實作被驗證器接受 | 8.5% | 0.3% |
| False negative，合理解法被驗證器拒絕 | 24.0% | 1.1% |
| 分析器與驗證器整體不一致 | 約 32% | 約 1.4% |
圖 5：Datacurve 認為 DeepSWE 的驗證器更接近真實任務成功，不會過度獎勵或懲罰特定修改形狀。
這裡的重點不是分析器永遠正確，而是驗證器如果失真，會讓排行榜的可信度直接崩掉。如果通過或失敗本身常常判錯，模型排名再精細也只是在量錯東西。
DeepSWE 想避免幾種常見問題：
- 標準答案測試只驗到當時的狹窄路徑，導致假實作或半成品也混過去。
- 測試綁定私有 helper 名稱，導致功能正確但實作寫法不同的 patch 被拒絕。
- 測試資料沒有一起帶入，讓合理解法在環境層出錯。
- 驗證器混入無關測試，導致模型完成需求卻被旁支行為懲罰。
- 評測環境保留完整
.git歷史，模型能從歷史 commit 裡挖出答案。
DeepSWE 的任務不是從既有已合併 commit 改寫而來，容器裡也只提供基準 commit 的淺層 clone，理論上就沒有標準答案 hash 能抄。這個設計讓它更像在測「解新題」，而不是測「找答案」。
強模型會自己驗證
DeepSWE 另一個有趣觀察是測試行為。官方用分析器標記每次實驗裡，coding agent 有沒有跑現有測試、寫新測試、寫臨時重現腳本，或直接擺爛跳過驗證。
結果顯示，越強的模型越常主動補測試。在 DeepSWE 上，Claude Opus 4.7 與 GPT-5.4 在超過 80% 的執行紀錄裡，會用專案原本的測試框架寫新測試。而在限制較多的 SWE-Bench Pro 上，同一批模型寫新測試的比例顯著下降。
| 模型 | SWE-Bench Pro 寫新測試比例 | DeepSWE 寫新測試比例 |
|---|---|---|
| GPT-5.4 | 18% | 85% |
| Claude Opus 4.7 | 28% | 83% |
| Claude Sonnet 4.6 | 12% | 68% |
| GPT-5.5 | 23% | 67% |
| Claude Opus 4.6 | 11% | 66% |
原因不是模型突然變懶，而是任務描述會塑造行為。SWE-Bench Pro 的任務模板會提醒 AI 不要修改測試邏輯或測試檔，模型可能把這解讀成「不要自己補測試」。DeepSWE 沒有這句限制，模型自己寫腳本、補測試的工程習慣就回來了。
這對日常使用 coding agent 很有啟發：如果你希望模型像工程師一樣工作，不要只要求 it 「改好」，也要讓它知道可以設計驗證、可以新增測試、可以用專案原本的測試框架取得信心。
mini-swe-agent 的意義
DeepSWE 所有主要分數都用 mini-swe-agent 跑。這個選擇有兩層含義。
第一，它把工具外殼固定，讓排行榜更像模型能力比較。GPT、Claude、Gemini 等模型都拿同一個 shell 工具與共享任務描述，不吃各家產品自己的編輯工具與隱性提示加成。
第二，它也降低了產品真實感。開發者平常不是用 mini-swe-agent，而是用 Cursor、Claude Code、Gemini CLI 等工具。不同工具有不同編輯方式、上下文策略、任務續接流程、權限設計、測試整合，這些都會影響實際體驗。
官方也做了一個小型試跑，比較 mini-swe-agent 和各模型原生工具。結果 mini-swe-agent 在該切片上沒有明顯劣勢，有些情況還更好。但這個樣本很小，只能說明「共用 harness 不一定嚴重偏袒某模型」，不能推出所有產品場景都如此。
對開發者的實際意義
DeepSWE 值得放進工具選型參考，但不要把它當唯一答案。它最有價值的用法是幫你問出更準的問題。
選模型時，不只看「哪個分數高」，也要看：
- 你的任務是不是長程跨檔案任務。
- 你的 repo 是否需要模型自己探索架構。
- 你的工作流是否允許模型新增測試。
- 你的執行框架是否保護環境，不讓模型讀到不該讀的答案。
- 你的驗證器是否驗證行為，而不是驗證實作形狀。
如果你自己在公司內做 coding agent 評測，DeepSWE 的方法比排行榜數字更值得參考：
- 寫短任務描述，逼 coding agent 自己找上下文。
- 選真實 repo，不只選教科書型任務。
- 驗證器要看公開 API、CLI 輸出、UI 行為、資料狀態，不綁私有 helper。
- 每題保留參考解法，但評分不要要求模型改得跟參考修改一樣。
- 把執行軌跡、patch、logs 留下來，因為錯誤分類比單一分數更有用。
- 固定執行框架後再比較模型，換執行框架時另開一組實驗。
局限也要一起看
DeepSWE 自己列出的限制很誠實：
- 所有模型都透過 mini-swe-agent 跑，隔離 harness 效果，但犧牲了真實產品體驗。
- 題庫只取活躍、至少 500 stars 的開源 repo，不一定代表長尾專案或私有 codebase。
- 任務集中在 TypeScript、Go、Python，Java 與 C++ 還沒覆蓋。
- 它偏長程工程任務，定位 bug 與重構任務還不夠多。
- 任務描述雖然比 SWE-Bench Pro 短，但仍比很多開發者實際丟給 coding agent 的訊息更完整。
這些限制不會削弱 DeepSWE 的價值，反而說明它不是「終局評測」。它更像一個方向：評測應該往更原創、更長程、更行為導向、更能觀察工程習慣的方向走。
來源標示與建議閱讀
本文根據下列公開資料整理，正文為重新撰寫與分析，不直接轉貼原文段落。
尺規的意義不是定義優劣，而是讓人在未知的迷宮裡，看見前行的腳印。
Signals
Visits
--
Waiting for Cloudflare metrics.