【CSDN 编者按】AI 技术的快速发展，让越来越多的企业和开发者开始尝试将 AI 工具应用于软件开发中，期望能够提升开发效率、减轻开发负担。Devin，作为一款自发布便备受瞩目的自动化 AI 开发工具，宣称能够像人类工程师一样独立完成从代码编写到调试、部署等一系列任务。为了验证这个说法，本文作者经过一个月的实际测试，分享了他们的亲身体验和深刻感想。

2024 年 3 月，一家新的 AI 公司突然崭露头角，凭借强大的融资支持，吸引了业界的广泛关注：它完成了由 Founders Fund 领投的 2100 万美元 A 轮融资，同时得到了行业领袖们的支持，包括 Collison 兄弟、Elad Gil 以及科技界的其他杰出人物。这家公司背后的团队成员更是令人惊叹：他们都是国际奥林匹克信息学竞赛（IOI）金牌得主——这些人解决的编程问题大多数人都难以理解。他们推出的产品名为 Devin，声称将是一位完全自主的软件工程师，能够像人类同事一样与你对话，完成从学习新技术、调试成熟代码库到部署完整应用，甚至训练 AI 模型等各类任务。

Devin 的早期演示让人印象深刻：一段视频展示了 Devin 在完全没有人工干预的情况下，独立完成了一项 Upwork 悬赏任务，安装并运行一个 PyTorch 项目。据该公司声称，Devin 在 SWE-bench 基准测试中可以解决 13.86% 的真实 GitHub 问题——比之前的系统性能高出约三倍。最初，只有一小部分用户能够体验这一技术，许多人在 Twitter 上激动地分享，称其将彻底改变软件开发的方式。

作为 Answer.AI 团队的一员，我们一直在实验 AI 开发者工具，而 Devin 给我们带来了一种不同的感觉。如果它能兑现其承诺的一半，那么它确实有可能改变我们的工作方式。然而，尽管 Twitter 上充满了激动人心的评论，但我们发现实际使用它的详细报道却寥寥无几。于是，我们决定亲自测试 Devin，用一系列真实任务来考验它。这篇文章便是我们对 Devin 的深入探索——对 2024 年最受关注的 AI 产品进行一次彻底的检验。

（AI 生成图片）

Devin 是什么？

Devin 的独特之处在于其基础设施。不同于一般的 AI 助手，Devin 通过 Slack 平台操作，并且能够自建计算环境。当你与 Devin 进行对话时，实际上是在与一个拥有完整计算环境的 AI 交流——这个环境包括了网页浏览器、代码编辑器和命令行界面。Devin 能够安装依赖项、查阅文档，甚至预览它自己创建的 Web 应用。以下是启动任务让 Devin 工作的一种方法：

（通过 Slack 启动 Devin 任务的方式）

整个体验设计上让人感觉像是在与同事交流。你描述想要完成的工作，Devin 就开始行动。通过 Slack，你可以观察它解决问题的过程，必要时向你请求凭证，并在任务完成后分享链接。而背后，它正在一个 Docker 容器中运行，使其能够在隔离环境下安全地进行实验，同时保护你的系统不受影响。此外，Devin 还提供了一个 Web 界面，允许你访问其工作环境，实时观看它与 IDE、网页浏览器等工具的交互。以下是Web界面的截图：

（Devin 的 Web 界面）

初步成功

我们交给 Devin 的第一个任务简单但真实：将 Notion 数据库中的数据导入 Google Sheets。Devin 以惊人的能力完成了这一任务：它找到了 Notion API 文档，理解了所需内容，并指导我一步步设置 Google Cloud Console 中的必要凭证。不同于单纯提供 API 指令，它一步步引导我完成每个菜单的操作和按钮的点击，省去了通常繁琐的文档查找过程。整个过程持续了大约一个小时，其中只有几分钟的人工干预。最终，Devin 分享了一个链接，指向一个格式完美的 Google Sheets 文档，成功完成了数据的导入。

虽然 Devin 生成的代码略显冗长，但确实有效。这也让我们看到了未来的曙光——一个能够处理“胶水代码”任务的 AI，解放了开发者大量的时间。Johno 也成功地使用 Devin 创建了一个行星追踪器，用于反驳关于木星和土星历史位置的说法。特别令人印象深刻的是，他是完全通过手机完成的这个任务，Devin 负责了所有环境设置和代码编写等繁重工作。

扩大我们的测试范围

在初步成功的基础上，我们开始深入探索 Devin 的异步能力。我们设想让 Devin 在会议期间编写文档，或在我们专注于设计工作时调试问题。但随着测试规模的扩大，问题逐渐显现。那些看似简单的任务，Devin 常常需要数天而非数小时来完成，有时会陷入技术死胡同，或者给出过于复杂、无法使用的解决方案。

更令人担忧的是，Devin 倾向于推进实际上不可能完成的任务。例如，在被要求将多个应用程序部署到单一的 Railway 环境中时（Railway 并不支持此功能），Devin 并没有识别出这一限制，而是花费了一整天尝试各种方法，甚至虚构了一些并不存在的功能。

最令人沮丧的并不是失败本身——毕竟所有工具都有其局限性——而是我们花了大量时间试图挽救这些失败的尝试。

深入探究问题所在

在这个问题上，我们感到有些困惑。我们看到 Devin 在处理 API 集成和构建功能应用时表现得非常出色，但它却在一些看似简单的任务上却遇到了困难。难道是运气不好？还是我们使用的方式不对？

在一个月的时间里，我们系统地记录了 Devin 在以下几类任务中的测试表现：

● 从头创建新项目

● 执行研究任务

● 分析和修改现有项目

结果让我们有些沮丧：在 20 个任务中，Devin 失败了 14 次，成功 3 次（包括最初的两次），还有 3 次无法确定成败。更为关键的是，我们无法找到任何规律来预测哪些任务会成功。那些看似与我们早期成功类似的任务，往往以意想不到的方式失败。以下是我们在每个类别中的经历总结：

（1）从头创建新项目

这个类别本应是 Devin 的强项。毕竟，其公司的演示视频展示了它独立完成 Upwork 悬赏任务的能力，而我们自己早期的成功案例也表明它能够从头创建新项目。然而，现实情况要复杂得多。

例如，当我们尝试与一个名为 Braintrust 的 LLM 可观测性平台集成时，任务非常明确：生成合成数据并上传。然而，Devin 给出的解决方案可以说是一团乱麻——过多的抽象层使得简单操作变得不必要的复杂。最终，我们放弃了对 Devin 的尝试，转而使用 Cursor 逐步构建集成，结果发现这种方法要高效得多。同样，当我们要求 Devin 为我们的 AI 笔记工具与 Spiral.computer 进行集成时，一名团队成员把 Devin 生成的代码形容为：“杂乱无章，代码读起来比我从头开始写的还要混乱”。尽管 Devin 可以访问两者的文档，但它似乎还是喜欢把每个环节都做得过于复杂。

最能说明 Devin 这方面问题的，应该是网络爬虫。我们要求 Devin 访问 Google Scholar 链接并抓取某位作者最新的 25 篇论文——对于像 Playwright 这样的工具来说，这项任务简直轻而易举，而 Devin 还具备浏览网页和编写代码的能力，按理说应该更容易实现。然而，Devin 却陷入了一个无限循环，不停地尝试解析 HTML，无法摆脱自己的混乱状态。

（2）研究任务

如果 Devin 在处理具体的编码任务时遇到困难，那么它在研究性工作中的表现是否会更好呢？很遗憾，结果顶多是参差不齐。虽然它能够处理一些基本的文档查阅（比如我们早期的 Notion/Google Sheets 集成），但更复杂的研究任务对它来说仍然是一个挑战。

例如，当我们要求 Devin 研究带有准确时间戳的转录总结——这是我们面临的一个具体技术难题时，但它只是简单复述了与主题相关的边缘信息，并没有真正深入核心问题。它没有尝试探索可能的解决方案或识别关键的技术难点，而是提供了与根本问题无关的通用代码示例。即便在 Devin 看似有所进展时，结果往往也不像表面上看起来那么好。比如，当我们要求它创建一个简单的 DaisyUI 主题示例时，Devin 生成了一个看似可行的解决方案。然而，仔细检查后我们发现，这个主题实际上毫无作用——我们看到的颜色依然是默认主题的颜色，而非我们的自定义设置。

（3）分析与修改现有代码

Devin在处理现有代码库时的表现尤其令人担忧。这类任务需要理解上下文并保持与既定模式的一致性——这是 AI 软件工程师应该具备的核心能力。

我们尝试让 Devin 处理 nbdev 项目时，遇到了一些令人震惊的问题。当我们要求它将一个 Python 项目迁移到 nbdev 时，Devin 连基本的 nbdev 设置都无法理解，尽管我们提供了详尽的文档供其参考。更让人费解的是，它在处理 notebook 时的方式——它没有直接编辑 notebook，而是创建 Python 脚本来修改 notebook，导致本应简单的任务变得过于复杂。虽然 Devin 偶尔也提供了一些有用的意见或想法，但它生成的实际代码始终存在各种问题。

在安全审查方面，情况也类似。当我们要求 Devin 对一个不到 700 行代码的 GitHub 仓库进行安全漏洞评估时，它反应过度，标记了大量误报，还虚构了根本不存在的问题。这类分析本可以通过单一且垂直的 LLM 调用来完成，而不是 Devin 采用的这种复杂方式。

此外，调试任务中也存在类似问题。当我们调查为什么 SSH 密钥转发在设置脚本中无法正常工作时，Devin 过分关注脚本本身，从未考虑问题可能存在于其他地方。这种“狭窄的视野”意味着它无法帮助我们找到实际的根本原因。同样，当我们要求它在用户输入和数据库值之间进行冲突检查时，一位团队成员花了几个小时试图搞明白提供 Devin 的方案，最终还是决定自己编写该功能，耗时仅约 90 分钟。

团队反思

经过一个月的密集测试，我们团队聚集在一起，并总结了我们对 Devin 的使用经验。以下的几句话可能最能表达我们的感受：

Johno Whitaker：“Devin 能完成的任务通常都很小且定义明确，但这种任务还不如我自己做，反而更快；对于那些我认为可能会节省时间的大型任务，它往往又会失败。所以，目前没有什么真正的应用场景让我想用它。”

Isaac Flath：“最初我对 Devin 接近成功的状态很兴奋，因为我觉得只需稍作调整即可。但随着需要更改的地方越来越多，我对它越来越失望，最终发现自己不如从头开始，一步步完成。”

Hamel Husain：“尽管我们提供了大量的文档和示例，但 Devin 依旧难以使用AnswerAI内部工具，而这些工具对我们来说又至关重要，所以我们都不太爱用它。相比之下，Cursor 等工具就没有这个问题，我们可以逐步引导其向正确的方向发展。”

与 Devin 不同，我们发现由开发者主导工作流程的工具（如 Cursor），可以避免我们在 Devin 中遇到的大部分问题。

结论

与 Devin 合作的过程，展示了自主 AI 开发所追求的理想状态。用户体验是精致的——通过 Slack 聊天、异步观察它工作、看到它设置环境并处理依赖关系。当它运行良好时，确实令人印象深刻。

然而，问题在于——它很少能成功。在我们尝试的 20 项任务中，有 14 次失败，3 次结果不确定，仅有 3 次成功。更令人担忧的是，我们无法预测哪些任务会成功。即使是类似于我们早期成功的任务，也会以复杂且耗时的方式失败。于是，最初看似有前景的自动化功能，反而变成了一种负担——Devin 会在不可能的解决方案上花费数天时间，而不是及时识别出根本性障碍。

这反映了我们在 AI 工具中反复观察到的一种模式：社交媒体上的热议和公司估值与实际应用价值几乎没有关系。我们发现，最可靠的信息大多来自于用户详细的使用故事和实际产品的交付。就目前而言，我们更倾向于使用那些由我们主导开发过程的工具，同时在需要时获得 AI 的帮助即可。

原文：https://www.answer.ai/posts/2025-01-08-devin.html