初創公司使用 AI “碼農” Devin 一個月的體驗原創精華

發布于 2025-2-14 10:22

瀏覽

0收藏

編者按： Devin 真的能像人類軟件工程師那樣工作嗎？作為 2024 年備受矚目的 AI Agent 產品，它的實際表現如何？
我們今天為大家帶來的文章中，作者通過一個月的實際使用體驗，發現 Devin 在處理簡單、明確的編程任務時表現不錯，但距離達到初級軟件工程師的水平還有很長的路要走。
文章詳細介紹了 Devin 的使用體驗，包括其出色的上手流程設計、與 GitHub 的便捷集成，以及實時代碼審查功能。在處理范圍狹窄、定義明確的代碼修改時，特別是前端組件相關的任務，Devin 表現相當出色。然而，當面對需要跨組件協作的全棧任務時，即使是對初級工程師來說較為簡單的工作，Devin 也往往難以勝任。從成本效益來看，對于那些它能夠完成的小型任務（通常花費 2-10 美元），Devin 確實能為團隊節省寶貴的時間；但在處理較復雜任務時，其成功率和性價比都令人失望。

本文系原作者觀點，Baihai IDP 僅編譯轉載。

作者 | Vikram Sreekanti and Joseph E. Gonzalez

編譯 | 岳揚

我們總是對新的人工智能產品充滿好奇，卻苦于沒有時間去親自體驗。在最近的假期里，我們終于抓住機會，使用了 Congition 公司推出的 Devin[1]，這款產品在 2024 年可是備受矚目。

如果你一直未曾關注過這方面的事情，那么可能還不知道，Devin 在去年三月份[2]發布的一款軟件工程 AI Agent 曾引起了不小的轟動。在相關演示視頻中，這款 Agent 能夠跨多個代碼文件，完成一項相當復雜的編程任務。我們原本對這個 AI Agent 的普適性持保留態度，但 Cognition 在去年十二月[3]將 Devin 正式對外開放，于是我們決定在假期中好好體驗一番 Devin。

初創公司使用 AI “碼農” Devin 一個月的體驗-AI.x社區

圖片來源：DALL-E 3。AI 軟件工程師的潛力無疑是巨大的，但（提前預警！）我們還有很長的路要走。

在我們詳細介紹對該產品的使用體驗之前，我們想先聲明，本文的任何負面觀點，都不是為了貶低 Devin（或任何其他產品）。我們對所有致力于 AI 產品開發的人抱有極高的敬意 —— 技術的快速更迭和市場的不確定性已經讓我們面臨了足夠多的挑戰。我們分享這些反饋意見，既是為了更好地開發 RunLLM[4]，同時也希望我們的觀點能對他人有所啟發。如果我們有哪里說錯了，歡迎指正！

上個星期，我們看到了 Answer AI 發布的一篇關于 Devin 的博客文章[5]。我們尚未詳讀全文，但值得一提的是，他們的結論與我們的看法頗有幾分相似。

01 引言

Devin 是一款相當謙遜、有自知之明的工具。它對自己的定位是，在得到明確指導的情況下，能夠像一名初級軟件工程師那樣完成任務。根據相關經驗，它大約能獨立工作 3 小時，之后才需要考慮是否會出現偏差。這種預期管理既清晰明確又非常實用，與我們此前關于 AI 工作流程[6]與人類工作交接[7]的論述不謀而合。

Cognition 公司的 CEO Scott Wu 在采訪中透露了他們團隊使用 Devin 的思路[8]，頗為引人入勝：正確的使用方法是在每天早上給 Devin 分配任務，然后讓它在你忙于其他工作的時候自行運行。幾小時后，你再回來查看它的工作進度，并提供必要的指導。到了一天工作結束時，Devin 應當能夠完成你所布置的任務。這種合作模式，與你在團隊中與初級工程師的合作非常相似。

02 Devin 的使用體驗和上手流程

Devin 的使用體驗和上手流程設計得相當出色。你只需將 Devin 連接到你的 GitHub 代碼庫。Devin 會分析你的代碼庫，了解其中的主要組件，以及編譯步驟、代碼風格、最佳實踐等。對于我們這樣的初創公司來說，這些內容可能不算豐富，但 Devin 仍能自動推理出構建流程的基本要素。

完成初步分析后，Devin 會展示其分析結果，并邀請你根據每個源代碼目錄的需要，添加額外的安裝或配置步驟。為了檢查這些配置是否正確，它會嘗試執行所有的安裝和配置步驟。

為 Devin 指派新任務非常直接。目前它尚未與 Linear 或 Jira 這類任務管理系統集成，僅提供了一個簡單的文本框，供你輸入希望 Devin 完成的任務描述。（你也可以在 Slack 的摘錄對話串（Thread）中標記（tag）任務，但我們發現這種做法并不太實用。）

初創公司使用 AI “碼農” Devin 一個月的體驗-AI.x社區

圖片來源：Cognition 的 Devin。使用 Devin 的聊天界面是最快捷的指派新任務方式。

當你分配給 Devin 一個新任務時，它首先會通過審查代碼庫來制定行動方案，并確定它認為應該進行的代碼修改，從而制定行動計劃。你可以實時在 web app 中觀察它審查文件的過程和所做的代碼修改（這一功能相當酷炫），一旦完成，它就會運行代碼檢查和代碼測試（如果有的話），解決遇到的問題，并創建一個 PR（pull request）。你可以在 PR 中留下評論，指導 Devin 進行代碼修改或修復 bugs。

簡而言之：Devin 的使用體驗既直觀又易于與工程團隊的工作流程融合。

03 Devin 的強項

Devin 最擅長的是進行范圍狹窄、定義明確的代碼修改，這些代碼修改僅涉及單個組件和少數代碼文件。我們最初讓它完成的任務包括：優化餅圖的顯示格式，修正 API 在返回數據時遇到的邊界問題，以及在創建新數據源時設定默認的更新計劃。這些任務如果由人工來完成，每個大約需要一個小時的時間來研究、實施和測試。而有了 Devin，只需花費一兩分鐘來描述任務，并在將其完成的工作合并前用五分鐘來檢驗。

初創公司使用 AI “碼農” Devin 一個月的體驗-AI.x社區

圖片來源：Cognition 公司的 Devin。通過一個實時儀表板，我們可以看到 Devin 在 shell、代碼編輯器等環境中的操作過程。

盡管它有時會在通用最佳實踐與特定代碼庫的特定規則之間猶豫，但它很快就能根據你的指導做出反應 —— 隨著時間的推移，它會建立一個針對特定代碼庫的知識庫，我們可以對其進行檢查和編輯修改。例如，Devin 最初嘗試安裝并導入了 @tanstack/react-query 庫，但這個庫并不適用于 RunLLM 的代碼庫。當我們指出應參考其他文件的實現方式時，它立刻進行了自我糾正。

根據我們的經驗（我們不確定這是否是普遍現象），Devin 在處理前端代碼時似乎表現得比處理后端代碼更為出色。例如，它能夠輕松處理相當復雜的 Redux stores 來優化狀態管理，然而卻在使用 Python 的 FastAPI 框架時遇到了困難 —— 即便面對的是相當基礎的功能實現。

簡而言之：Devin 在前端代碼庫中修復小 bugs 或進行細微的優化時，能夠有效節省時間。

04 Devin 的局限

在完成了一些基礎任務后，我們決定交給 Devin 一個更具挑戰性的全棧任務，我們認為這個任務適合初級工程師去完成。這項任務需要添加一個新的（且獨立的）數據庫表，創建一個新的 API 接口，并將該接口集成到前端交互中。每處單獨的改動并不復雜，但需要將各個部分整合在一起。正常情況下，工程師可能需要幾個小時就能搞定。

然而，事情并沒有按預期進行。在最初的任務描述中，我們明確指出沒有現成的數據庫表來記錄所需信息。Devin 找到了一個功能類似的舊 API 接口，并試圖在此基礎上進行調整，但它似乎誤以為舊接口的存在意味著數據庫中已有相應的信息。盡管我們反復多次提示，它仍然無法在數據庫的 schema 中添加新表。

在前端部分，Devin 將新按鈕添加到了一個僅在特定條件下才會顯示的位置。我們多次要求它讓按鈕在所有情況下都顯示，但同樣，盡管反復提示，它還是無法實現這一需求。

在嘗試了多種不同的提示詞來解決上述問題后，我們決定自己接管這部分工作，看看能否基于 Devin 的工作“半成品”將這個 PR 調整到可用的狀態。但仔細檢查后發現，Devin 添加的用于前端與新增 API 接口連接的代碼大多不可用 —— 它忽略了我們之前教給它的最佳實踐，處理 API 響應的代碼也是一團糟。此時，我們決定從頭開始實現這一功能，因為這樣比修復 Devin 編寫的代碼要容易得多。

有趣的是，我們還發現 Devin 很容易陷入一種死循環，它試圖解決代碼檢查器發現的問題，卻又在之前所做的代碼更改之間來回打轉。在這個循環過程中，它似乎并沒有優先考慮用戶對 PR 中需要改進之處的反饋。

我們并不清楚是什么原因導致 Devin 出現這種混亂。每個組件的任務應該都相當簡單，因此我們推測，跨多個組件的協同工作可能是最讓 Devin 困擾的部分。它似乎無法將自身的規劃或我們提供的反饋獨立應用于特定組件。

簡而言之：一個我們期望初級工程師能在一天內完成的全棧任務，對 Devin 來說卻是一個難以逾越的挑戰。如果這是一個新招聘的工程師，我們可能不會考慮將其留在團隊中。

05 成本效益分析

在 Devin 能夠順利完成任務的情況下，其經濟效益是顯而易見的。 目前，500 美元可以購買 250 個 ACU（ Devin 的工作量計算單位），而 Devin 完成那些小型任務通常只需要 1-5 個ACU（即 2-10 美元）。如果花幾美元就能修復小 bugs，并且每次至少節省一個小時的工作時間，這樣的交易無疑是劃算的 —— 無論何時，我們都會選擇這樣做。但問題在于，適合 Devin 處理的任務范圍非常有限，這些任務既需要工程師切換工作焦點，又要在 Devin 的能力范圍內完成。

當 Devin 無法完成任務時，其經濟效益就開始值得懷疑了。 我們嘗試的三個較大任務平均消耗了大約 20 個ACU，其中有兩個任務并沒有給出可用結果。雖然 40 美元對于完成這些任務來說非常便宜，但根據我們有限的樣本來看，這些任務消耗的 ACU 數量與任務難度并不成正比 —— 它們并不比那些成功的小任務難上 5 到 10 倍。更重要的是，這些任務常常失敗，導致我們花費的 40 美元打了水漂。

如果 RunLLM 是一家每月有 50 個以上明確界定的小錯誤需要 Devin 修復的大公司，情況可能有所不同。但事實上，我們已經讓 Devin 嘗試了大部分它能夠成功的任務。

簡而言之：對于那些 Devin 能夠完成的任務，為之支付費用是絕對沒有問題的。但當 Devin 無法完成任務時，你會因為資金浪費而感到失望。