以下是評測結果，我整理總結了一下分享給大家。

Devin 主要基于 Slack 工作流：

Devin 主要通過 Slack 交互，而非 IDE 集成。用戶在 Slack 中標記 @devin 并提出請求，例如更新代碼、修復 bug 等。Devin 的界面包括遠程服務器、瀏覽器、VS Code 編輯界面和計劃器，用戶可以逐步查看 Devin 的操作和進度。

Devin 的實際測試：

Steve首先測試了一個可以在消費級硬件上運行的小型圖像生成模型。由于他不懂 Python 也不知道如何操作，便請求 Devin 幫他運行。Devin 成功克隆了代碼庫，啟動程序，并生成了想要的貓咪圖片。隨后，Steve又要求它生成四張狗狗乘坐熱氣球的圖片，雖然生成的圖像質量略顯驚悚 (這當然不是 Devin 的錯，而是模型本身的問題)，但 Devin 的確完成了任務。

接著，Steve嘗試讓 Devin 為這個圖像生成模型添加一個基于 Web 的 UI 界面，以便輸入提示詞并查看生成的圖像。Devin 開始工作并發送更新，過程中它會記錄筆記并存儲在 notes.txt 文件中，以便在后續步驟中引用和使用，這似乎是一種總結重要信息并跨步驟傳遞的有效方法。Devin 有時還會創建“知識條目”，即一些可能在后續子令牌運行中用到的有用信息片段，并將其存儲和查找，模擬團隊內部的知識積累。

總的來說，Devin 表現出色。它能夠創建計劃、編寫代碼、查找和修復代碼中的 bug，甚至進行端到端測試以驗證功能。它還能響應用戶反饋并嘗試解決問題。任何你在 Slack 中的回復，Devin 都會嘗試回復。例如，它能夠識別部署問題并持續調試，雖然最終未能解決問題，但其努力嘗試的過程值得肯定。

Devin 的一些問題：

工作流程不理想： Devin 的工作流程并非個人偏好。提交請求后等待 15 分鐘才能收到 PR，然后在 PR 上來回溝通。個人更喜歡在本地 IDE 中進行所有操作，實時查看更新，并在本地提交和調試，而無需跳轉到遠程服務器和其他不熟悉的工具，以及忍受漫長的等待和延遲。

可靠性有待提高： Devin 的理念是讓異步代理同事處理任務，并并行執行多項操作，最終向你提供結果。但這只有在 Devin 足夠可靠的情況下才是一個高效的工作流程。讓 AI 自己去執行任務，除非你非常確信它能夠可靠地完成。否則，寧愿使用自己的 IDE 來完成。

其他 bug： 在測試過程中，Devin 還出現了一些其他問題，例如無法正確生成拉取請求、添加不必要的代碼、無法響應反饋等，雖然這些問題并非無法解決，但也影響了使用體驗。

與 Cursor 的比較

與 Devin 相比，Cursor 代理的優勢在于無需手動添加文件到上下文，它會自動掃描代碼庫并添加相關文件。在同樣的任務中，Cursor 代理能夠快速準確地完成代碼修改，并且能夠實時控制和查看更新，無需等待和跳轉到其他工具。這種實時交互和掌控感讓你對 Cursor 代理更有信心。

在 GraphQL 后端功能的測試中，Cursor 代理也取得了與 Devin 類似的結果，成功添加了 Comments Resolver 并將其集成到 API 中。此外，Cursor 代理在運行命令前會進行確認，更加謹慎，這對于在本地機器上運行的工具來說是一個重要的優勢。

總結：

雖然 Devin 在 AI 編碼領域展現出一定的潛力，但它不太可能像 Cursor 那樣迅速普及。這不僅僅是因為 500 美元的月費，更重要的是 Cursor 代理更容易上手，其增量式方法也更符合個人的工作習慣。Devin 試圖一步到位，并以代理驅動開發的新方式為噱頭籌集資金（據說devin已經估值20億美金了），但這并不是理想中的工作流程。也許當大型語言模型更加完善，代理更加可靠時，Devin 的價值才能真正體現出來。但個人更看好 Cursor 的增量式方法，而不是 Devin 的全面改革式方法

盡管如此，仍然很高興看到 AI 編碼領域出現新的競爭者，這將推動 Cursor 進一步發展。期待看到 Devin 的未來發展。