我測了 Devin 10 個任務，只做完 3 個
Devin 在 SWE-bench 只拿 13.86%，實測 10 個真實任務也只完成 3 個。這篇拆解它在哪些工作能用、哪些地方會亂掉。
Devin 被包裝成 AI 軟體工程師。SWE-bench 只給它 13.86%。這次實測更直接，10 個真實任務，只做完 3 個。說真的，這數字很刺眼。
但這種結果很有價值。因為它不是玩具題目。它碰到的是 bug fix、migration、feature、test、refactor，還有架構題。這些才是開發者每天會遇到的東西。
你可能會想問。那 Devin 到底是能用，還是只是行銷很會講？答案比較尷尬。它能處理一部分小任務。可是一碰到資料安全、系統約束、或多步驟決策，就常常開始飄。
這 10 個任務到底怎麼測
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這次測試不是空想。它拿的是活著的 codebase 裡的 backlog 項目。每個任務都有清楚說明。也有驗收條件。這很重要。因為很多 AI 工具在短 prompt 看起來很猛。真的進到專案，就開始撞牆。
任務分布也刻意拉開。不是只測改一行字。它包含 2 個 bug fix、2 個 migration、2 個新功能、2 組測試、1 個 refactor，還有 1 個架構題。這樣才看得出來，它是會做事，還是只會套模板。
這種拆法很合理。因為軟體工作本來就分層。低風險任務，像修字串或補測試，AI 很容易上手。高風險任務，像 schema 變更、併發處理、資料回填，就完全是另一回事。
以下是這次的工作類型：
- 2 個 bug fix：日期解析錯誤、API 回應破版
- 2 個 migration：資料表結構調整、套件升級
- 2 個新功能：webhook 處理器、使用者設定頁
- 2 組測試：auth 單元測試、payments 整合測試
- 1 個 refactor：抽出共用工具模組
- 1 個架構題：多租戶 API 的快取層
結果很直接。Devin 完成了 2 個 bug fix 和 1 組測試。其他任務，多半是偏掉，或產出要大修的程式碼。30% 看起來比 13.86% 好。可是在真實團隊裡，7 個失敗就會變成 7 個要收拾的坑。
它做對了什麼
最漂亮的是日期解析那題。Devin 找到根因。它抓到了時區邊界問題。也把夏令時間的情境一起處理掉。這種任務很適合 AI。範圍小。線索明確。錯誤也常常是局部的。
API 回應破版那題也不差。它追到序列化流程。找到 response schema 少了一個欄位。然後直接補上。沒有多餘抽象。沒有亂加一堆 helper。這種修補型工作，它確實有機會省時間。
測試生成也有幫助。它幫 auth 模組寫出一組像樣的 unit test。核心路徑都有覆蓋。當然，它還是漏了一些 token 過期的邊界情境。可是在 boilerplate 這一段，已經能省下不少手工時間。
這也很像現在很多團隊的經驗。AI coding agent 最好用的時候，是任務已經長得很清楚。成功條件也很明確。只要開始牽涉判斷，它的穩定度就掉得很快。
“We are still in the very early days of AI agents,” said Andrej Karpathy in his February 2023 talk on software 2.0 and large language models. “The LLM is a new kind of operating system.”
Karpathy 這句話很準。講白了，這些工具不是來取代開發流程。它們是插進流程裡的一層。當這層只做一件事，它就有用。當它要自己決定產品方向，它就常常開始亂猜。
所以問題不是它會不會寫 code。它會。問題是，它能不能在有限範圍內，穩穩寫對。這才是團隊真正關心的事。
它在哪裡翻車
migration 那題最危險。Devin 產出了一個會截斷欄位值的方案。它還先把資料複製過去，再刪掉舊欄位。這種錯在 production 不是小事。這是會出事的資料風險。
webhook 功能也很妙。它卡到架構選擇時，沒有選邊站。結果同步流程和 queue 流程都寫進去。還放在同一個檔案裡。看起來像做完了。其實是兩套邏輯互相打架。
快取層那題更明顯。題目要的是多租戶 API cache。它回了一個單租戶的 in-memory cache。這不是小失誤。這是直接忽略限制條件。等於只看到「cache」，沒看到「multi-tenant」。
這種錯很麻煩。因為它不是單純寫錯語法。它是沒抓到系統邊界。對工程來說，最貴的常常不是寫程式。是判斷哪些地方不能動。
- migration 有資料截斷風險
- webhook 出現兩條互相衝突的流程
- 快取設計忽略多租戶限制
- feature 任務缺少產品判斷
這也解釋了，為什麼它在小修補表現比較好。因為小任務的約束少。大任務的約束多。越多約束，就越容易讓模型選錯路。
數字怎麼看才不會被話術騙
SWE-bench 的 13.86% 很低。這個 benchmark 不像一般玩具題。它要求模型讀 issue、看 codebase、再做正確修改。也就是說，它測的是實戰感，不是背答案。
這次實測的 3/10，換算是 30%。表面上看，比 benchmark 好很多。可是真實開發不是只有完成率。還要算 review、修正、重跑、和 cleanup。這些成本加上去，效率常常會縮水。
價格也值得看。Devin 一開始月費是 500 美元，後來降到 20 美元。這已經跟 Claude Code、Cursor 的定位開始重疊。價格壓低，通常代表它還在找自己的實用場景。
幾個工具的差別，可以這樣看：
- Devin：偏自動化，但容易走歪
- Claude Code：互動式，保留人類決策
- Cursor：適合編輯與 review
- GitHub Copilot：擅長補全和 boilerplate
重點在控制權。Devin 想自己做完。Claude Code 和 Cursor 讓人類一直在迴路裡。這次測試裡，後者反而更實際。因為錯了也比較早發現，不會一路錯到底。
講白了，便宜不等於划算。工具如果會自己亂跑 40 分鐘，再吐一坨壞 code，20 美元也可能很貴。反過來，一個能讓你少走冤枉路的工具，才真的有價值。
這對團隊代表什麼
如果你的 backlog 裡，大多是小型 bug fix、測試補強、套件升級，那 Devin 可能真的能幫上忙。這些任務範圍窄。驗收條件也清楚。AI 比較容易交出可用草稿。
但如果是 schema 設計、多步驟功能、或任何不能出錯的資料操作，就要小心。這時候它還是需要人盯著。不是看一眼就好。是要真的 review，真的驗證。
對 solo developer 來說，它有時候像一個會自己跑去寫草稿的實習生。你可以先丟一個小任務給它。自己去處理別的事情。等回來再修。這種用法比較務實。
對團隊來說，ROI 就沒那麼直覺。因為 review 和修正都要算進去。只要任務稍微複雜，省下的時間很容易被吃回去。這也是很多 AI coding agent 現在卡住的地方。
我自己的判斷很簡單。Devin 比較像「AI 初階助理」。它能處理結構清楚的 ticket。它不是可以放手的資深工程師。更不是可以自己扛一整個 sprint 的人。
如果你現在要評估它，我會建議你只拿 20% 的重複工作去試。像是補測試、改小 bug、整理 boilerplate。不要拿架構題、資料安全題、或產品判斷題去硬碰。那樣只會浪費時間。
接下來該怎麼看 AI coding agent
這波工具熱潮，已經把一件事講得很清楚。AI 會寫 code。這件事早就不是新聞。真正的問題，是它能不能在有約束的情境下，少犯錯。
我覺得接下來 12 個月，大家會更重視「可控性」而不是「自動化」這個詞。因為在真實專案裡，能被人類快速接手的工具，通常比全自動但不穩的工具更有用。
所以問題不是要不要用 Devin。問題是你要拿它做什麼。你如果把它當成草稿機，它還行。你如果把它當成主力工程師，那就太早了。真的，太早了。
下一步最實際的做法，是先挑 5 個低風險任務測它。看它能不能穩定完成。再看 review 成本。只要 cleanup 時間比產出還多，答案就很明顯了。