AI Engineer onepage/ DeepSWE
James Shi, Datacurve · 17:34
這支影片在講：要測 coding agent，先讓它無法背答案
DeepSWE 不從既有 pull request 抓題，而是讓真正在維護開源專案的工程師從零寫出任務；再用隔離環境與程式驗證器，檢查模型交出的可觀察行為。
Published: 2026-07-26Video ID: Yk87oUPVaxU
01 / 問題
PR 題庫可能已被模型看過
從公開歷史修復案例抽題很方便，但也會讓評測混入訓練資料，分數難以分辨是推理能力還是記憶。
02 / 反轉
真實感不等於可信
任務要由熟悉 repo 的維護者撰寫、保留長程脈絡，並把「不要擴大需求」也納入失敗型態。
03 / 解法
以程式驗證行為
不要相信模型說它完成了；在隔離環境中執行 verifier，讓可觀察輸出決定是否真的過關。
Watch for this
影片最值得抓的四個訊號
Task set
113
由工程師從零撰寫、不是從既有 PR 擷取的軟體工程任務。
Task shape
Long-horizon
每題都來自真實開源 repo，需要跨檔案與脈絡的工作，不是單一步驟補洞。
Failure mode
Over-scope
模型悄悄做了題目沒要求的事，也是一種可被評分的失敗。
Judge
Program
用可執行 verifier 檢查 observable behavior，降低自我回報與 reward hacking 的空間。
Core story
DeepSWE 對 benchmark 設計的三個要求
要求 1
把 contamination 當成第一級風險
若題目是公開 PR 的重播，模型可能在訓練時見過答案。DeepSWE 改由實際維護者從零編寫任務，讓分數更接近模型當下的工程推理與執行能力。
要求 2
任務要保留真實 repo 的摩擦
每一題在真實開源專案與隔離環境中運行。重點不只是改出一段 code，而是理解高層 prompt、既有行為、相依關係與完成邊界。
要求 3
評分應盯住行為，而非說詞
程式化 verifier 驗證外部可見結果，並盡量設計成不容易被投機取巧。這讓「沒有驗證自己工作」與「擅自擴張範圍」都能浮出來。
Decision map
題目、環境、驗證器要一起設計
任務來源：由 maintainer 撰寫作者了解 repo 的隱性約束，較能把真實工作中的高階需求與完成條件寫進題目。
執行環境：可隔離、可重現同一個任務要能重跑，才能把模型差異與環境雜訊分開，也便於追查不穩定結果。
完成判準：觀察輸出以 tests 與程序驗證行為，不把「模型宣稱完成」或表面合理的 diff 當成證據。
失敗分類：連 over-scoping 都算工程代理不該因做得更多就加分；功能、範圍與驗收合約都需要被明確約束。
Chapters
影片章節
0:00DeepSWE benchmark 導言
1:03113 個原創、抗污染任務
2:08好 benchmark 的條件
3:51排行榜與模型差距
5:18失敗型態：over-scoping
7:16模型會驗證自己的工作嗎？
8:45核心貢獻者撰題
10:15寫出真實的高階 prompt
11:45程式驗證器與可觀察行為
13:43限制與未來方向
15:25Reward hacking 與防作弊設計
Use this checklist
對自己的 coding agent eval，先做這四件事
為題目做 contamination 審計標記題目是否來自公開 issue、PR 或常見教學資料；把未公開或新撰任務放進核心評測集。
把成功定義成可觀察的行為讓 CI、API contract、UI 狀態或資料庫結果驗收，不以 diff 大小、模型自評或人工印象取代。
把範圍漂移列為顯性失敗建立不可碰的檔案、行為與非目標清單；agent 修對 bug 卻引入未授權重構，不能算成功。
量測「會不會自己驗證」除了 pass rate，也記錄 agent 是否跑過正確的測試、是否根據結果修正，以及驗證步驟的成本。
Source video