Answer.AI 实测 Devin：20 项任务仅 3 次成功，自主编程能力存疑

2024 年 3 月，一家新的人工智能公司横空出世，背后有着令人瞩目的支持：由 Founders Fund 领投的 2100 万美元 A 轮融资，并获得了包括 Collison 兄弟、Elad Gil 以及其他科技界名人在内的行业领袖的支持。背后的团队是谁？IOI 金牌得主——那种能解决我们大多数人甚至无法理解的编程问题的人。他们的产品 Devin 承诺成为一个完全自主的软件工程师，可以像人类同事一样与你聊天，能够完成从学习新技术、调试成熟代码库到部署完整应用甚至训练 AI 模型的一切工作。

早期的演示令人信服。一段视频展示了 Devin 独立完成一个 Upwork 悬赏任务，在无人干预的情况下安装并运行一个 PyTorch 项目。¹ 该公司声称，在 SWE-bench 基准测试中，Devin 能够端到端地解决 13.86% 的真实世界 GitHub 问题——比之前的系统好约 3 倍。最初只有少数精选用户可以使用它，引发了大量关于这将如何彻底改变软件开发的激动推文。

作为 Answer.AI 的一个经常试验 AI 开发者工具的团队，Devin 让我们感觉有些不同。如果它能兑现哪怕一半的承诺，就可能改变我们的工作方式。但尽管 Twitter 上充满热情，我们却找不到多少关于人们实际使用它的详细记录。因此我们决定对它进行全面测试，用各种真实世界的任务来检验它。这就是我们的故事——一次对 2024 年最受炒作的 AI 产品之一进行的彻底、真实世界的尝试。

什么是 Devin？

Devin 的独特之处在于其基础设施。与典型的 AI 助手不同，Devin 通过 Slack 运行，并启动自己的计算环境。当你与 Devin 聊天时，你是在与一个可以访问完整计算环境的 AI 交谈——包括网络浏览器、代码编辑器和 shell。它可以安装依赖项、阅读文档，甚至预览它创建的 Web 应用程序。下面是一个为 Devin 启动任务的截图：

这种体验被设计得像与同事聊天一样。你描述你想要什么，Devin 就开始工作。通过 Slack，你可以看着它思考问题、在需要时请求凭据，并分享已完成工作的链接。在幕后，它运行在 Docker 容器中，这为它提供了安全实验所需的隔离，同时保护你的系统。Devin 还提供了一个 Web 界面，你也可以通过它访问其环境，并实时观看它使用 IDE、Web 浏览器等工具工作。以下是 Web 界面的截图：

早期成功

我们的第一个任务简单但真实：把数据从 Notion 数据库拉取到 Google Sheets。Devin 以令人惊讶的能力完成了这项任务。它导航到 Notion API 文档，理解了所需内容，并引导我在 Google Cloud Console 中设置必要的凭据。它不只是抛出 API 说明，而是带我逐步完成每个菜单和按钮点击——省去了通常繁琐的文档查找工作。整个过程大约花了一小时（但其中只有几分钟需要人工交互）。最后，Devin 分享了一个链接，指向一个格式完美的 Google Sheet，里面包含我们的数据。

它生成的代码有点冗长，但能正常工作。这感觉像是瞥见了未来——一个能够处理那些消耗开发者大量时间的“胶水代码”任务的 AI。Johno 也有类似的成功经历，他用 Devin 创建了一个行星追踪器，用来驳斥关于木星和土星历史位置的错误说法。尤其令人印象深刻的是，他完全通过手机完成了这一切，而 Devin 承担了设置环境和编写代码的所有繁重工作。

扩大测试规模

基于早期的成功，我们开始倚重 Devin 的异步能力。我们设想让 Devin 在我们开会时编写文档，或者在我们专注于设计工作时调试问题。但随着测试规模扩大，裂痕开始出现。看似简单的任务往往要花几天而不是几小时，Devin 会陷入技术死胡同，或者产出过于复杂、无法使用的解决方案。

更令人担忧的是，Devin 倾向于在实际上不可能的任务上继续推进。当被要求将多个应用部署到单个 Railway 部署中（Railway 并不支持这一点）时，Devin 没有识别出这一限制，而是花了一天多时间尝试各种方法，并幻觉出并不存在的功能。

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

深入探究问题所在

在旅程的这一阶段，我们感到困惑。我们见过 Devin 胜任地处理 API 集成并构建可用的应用程序，但它却在看似更简单的任务上挣扎。这只是运气不好吗？是我们用错了吗？

在一个月的时间里，我们系统地记录了在这些类别中的尝试：

从零开始创建新项目
执行研究任务
分析并修改现有项目

结果令人清醒。在 20 个任务中，我们有 14 个失败、3 个成功（包括我们最初的 2 个）和 3 个无定论的结果。更能说明问题的是，我们无法辨别出任何模式来预测哪些任务会成功。看似与我们早期成功相似的任务，会以意想不到的方式失败。我们在下面的附录中提供了关于这些任务的更多细节。以下是我们在每个类别中经历的总结：

1. 从零开始创建新项目

这个类别本应是 Devin 的强项。毕竟，该公司的演示视频显示它自主完成了一个 Upwork 悬赏任务，而我们自己早期的成功也表明它可以处理全新开发。现实证明要更复杂。

以我们尝试集成一个名为 Braintrust 的 LLM 可观测性平台为例。任务很明确：生成合成数据并上传。Devin 并没有给出一个聚焦的解决方案，而是产出了只能被形容为代码汤的东西——层层抽象让简单操作变得不必要地复杂。我们最终放弃了 Devin 的尝试，改用 Cursor 一步步构建集成，事实证明效率高得多。同样，当被要求在我们的 AI 笔记记录器和 Spiral.computer 之间创建集成时，Devin 生成了一位团队成员所说的“意大利面条式代码，读起来比我从头写还要混乱得多”。尽管可以访问两个系统的文档，Devin 似乎把集成的每个方面都过度复杂化了。

也许最能说明问题的是我们尝试网页抓取。我们让 Devin 跟随 Google Scholar 链接，抓取某位作者最近的 25 篇论文——有了 Playwright 这类工具，这本该是直截了当的任务。考虑到 Devin 具备浏览网页和编写代码的能力，这尤其应该可以实现。然而，它却陷入了试图解析 HTML 的无限循环，无法从自身的混乱中脱身。

2. 研究任务

如果 Devin 在具体编码任务上吃力，也许它在研究导向的工作上会表现更好？这里的结果充其量只能说是喜忧参半。虽然它能处理基本的文档查询（正如我们在早期的 Notion/Google Sheets 集成中看到的），但更复杂的研究任务被证明颇具挑战。

当我们让 Devin 研究带准确时间戳的转录摘要——这是我们当时面临的一个具体技术挑战——它只是复述了一些勉强相关的信息，而没有真正触及核心问题。它没有探索潜在解决方案或识别关键技术挑战，而是提供了泛泛的代码示例，并未解决根本问题。即使 Devin 看起来在取得进展，结果也往往并非表面那样。例如，当被要求创建一个最小的 DaisyUI 主题作为示例时，它产出的东西看起来像是可用的解决方案。然而，仔细检查后，我们发现该主题实际上什么都没做——我们看到的颜色来自默认主题，而非我们的自定义。

3. 分析和修改现有代码

也许 Devin 最令人担忧的失败出现在处理现有代码库时。这些任务需要理解上下文并与既有模式保持一致——这些技能本应是 AI 软件工程师的核心能力。

我们让 Devin 处理 nbdev 项目的尝试尤其能说明问题。当被要求将一个 Python 项目迁移到 nbdev 时，尽管我们提供了全面的文档访问权限，Devin 连基本的 nbdev 设置都无法掌握。更令人费解的是它操作笔记本的方式——它没有直接编辑笔记本，而是创建 Python 脚本来修改它们，给简单任务增添了不必要的复杂性。虽然它偶尔会提供有用的笔记或想法，但它实际产出的代码始终问题重重。

安全审查也显示出类似的问题。当我们让 Devin 评估一个 GitHub 仓库（代码不到 700 行）的安全漏洞时，它做得过了头，标记了大量误报，并幻觉出并不存在的问题。这类分析或许更适合由一次专注的 LLM 调用来处理，而不是 Devin 更复杂的方式。

这种模式在调试任务中继续出现。在调查为什么 SSH 密钥转发在一个安装脚本中不工作时，Devin 死盯着脚本本身，从未考虑问题可能出在别处。这种隧道视野意味着它无法帮助我们找出真正的根本原因。同样，当被要求添加用户输入与数据库值之间的冲突检查时，一名团队成员花了几个小时研究 Devin 的尝试，最后放弃，自己在大约 90 分钟内写完了这个功能。

团队反思

经过一个月的密集测试，我们团队聚在一起梳理我们的经历。以下这些话最能表达我们的感受：

它能做的任务都是那些小到、定义明确到我完全可以自己做、更快、按我的方式做的任务。那些我可能看到时间节省的更大任务，我认为它很可能会失败。所以没有真正适合我用它的细分场景。- Johno Whitaker

我最初很兴奋，因为它离成功那么近，我觉得我可以微调几处。然后慢慢变得沮丧，因为我不得不改越来越多，最终到了我本可以从头开始、一步步来会更好的地步。- Isaac Flath

Devin 在使用 AnswerAI 至关重要的内部工具时很吃力，这加上其他问题，使它难以使用。尽管我们给 Devin 提供了大量文档和示例。我发现像 Cursor 这样的工具没有这个问题，在那里有更多机会更渐进地把事情推向正确方向。- Hamel Husain

与 Devin 相比，我们发现开发者主导更多的工作流（如 Cursor）避免了我们在 Devin 身上遇到的大部分问题。

结论

与 Devin 合作展示了自主 AI 开发所追求的目标。用户体验很精致——通过 Slack 聊天、异步观看它工作、看它设置环境并处理依赖。当它奏效时，令人印象深刻。

但问题就在于此——它很少奏效。在我们尝试的 20 个任务中，我们看到 14 次失败、3 次无定论的结果，只有 3 次成功。更令人担忧的是我们无法预测哪些任务会成功。即使是与我们早期成功相似的任务，也会以复杂、耗时的方式失败。看似有前途的自主性变成了负担——Devin 会花几天时间追求不可能的解决方案，而不是识别根本性的阻碍。

这反映了我们在 AI 工具中反复观察到的一种模式。社交媒体的兴奋和公司估值与现实世界的实用性关系甚微。我们发现最可靠的信号来自用户交付产品和服务的详细故事。目前，我们坚持使用那些让我们主导开发过程、同时沿途提供 AI 辅助的工具。

附录：用 Devin 尝试的任务

下面是我们交给 Devin 的项目表格，按以下主题分类：（1）创建新项目，（2）研究，（3）分析现有代码库，（4）修改代码库。

1. 创建新项目

项目名称	状态	描述	反思
Planet Tracker	成功	我想揭穿一些关于木星和土星历史位置的说法	Devin 搞定了。我实际上是通过 Slack 用手机和 Devin 交流的，它就把事情办成了。
将数据从 Notion 迁移到 Google Sheets	成功	我让 Devin 以编程方式从 Notion 文档中提取信息到 Google Sheet。这是我用 Devin 执行的第一个项目，它完成得很漂亮。Devin 自己阅读了 Notion 和 Google API 文档。Devin 还引导我进入 Google Cloud 控制台，并为我提供了所有需要点击的不同菜单的说明，如果我自己来做的话会花相当多的时间！最后，我得到了一个合理的 Python 脚本，执行了这项任务。	这是我与 Devin 的第一次互动，它完全按照我的要求执行了任务，这对我来说是一种全新的体验。此时我对 Devin 感到非常兴奋。
在 Railway 上部署多个应用	无定论	我让 Devin 将多个应用部署到单个 Railway 部署中，这样我就可以让不同的应用共享同一个本地数据库进行测试。	事实证明这个任务定义不清，因为如果我理解正确的话，这实际上是不可能做到的。然而，Devin 还是继续推进并尝试去做，还幻觉出了一些关于如何与 Railway 交互的内容。
生成合成数据并上传到 Braintrust	失败	我让 Devin 为一个我想测试的名为 Braintrust 的 LLM 可观测性平台创建合成数据。	Devin 创建了过于复杂、难以理解的代码，并在尝试修复错误时卡住了。我们最终使用 Cursor 以迭代的方式一步一步地完成了这个任务。
在两个应用之间创建集成	失败	我让 Devin 在 Circleback（我的 AI 笔记工具）和 Spiral.computer 之间创建集成，并提供了各自的文档指针。	我得到了非常糟糕的意大利面条式代码，读起来比我自己从头写还要令人困惑。所以我决定不再在这个特定任务上花更多时间使用 Devin。
通过 Google Scholar 链接抓取论文	失败	我让 Devin 使用 playwright 以编程方式从 Google Scholar 上抓取某位作者最新的 25 篇论文，如果遇到付费墙，跳过那篇文档也可以。	Devin 陷入了试图解析 HTML 的兔子洞，似乎无法脱身。它卡住了，然后去睡觉了。
创建最小的 HTMX 批量上传示例应用	失败	我让 Devin 阅读 HTMX 文档页面上的批量编辑示例，并据此加上假服务器代码，为 FastHTML Gallery 创建一个最小的 FastHTML 版本示例。	这个示例无法运行，也不够精简。Devin 使用了请求对象中不存在的对象，还添加了许多不必要的东西，比如 toast 通知（同样也无法运行）以及内联 CSS 样式。
创建与 FrankenUI 主题匹配的 DaisyUI 主题	失败	我让 Devin 创建 DaisyUI 和 highlight.js 的主题，使它们与 frankenui 主题匹配，并能在同一个应用中无缝使用	Devin 将 daisyUI 已有的主题映射到 frankenui 主题，但在很多情况下它们并不匹配。而且还有大量我不理解的代码改动，最终我没有使用其中任何内容，因为我太困惑了，不知道该怎么处理。

2. 进行研究

项目名称	状态	描述	反思
研究如何制作一个 Discord 机器人	成功	我让 Devin 研究一下我如何使用 Python 构建一个 Discord 机器人，用来汇总每天的消息并发送邮件。我还告诉它尽可能使用 Claudette 来完成这件事。最后，我让它把研究结果写在 notebook 里，并附上我可以用来测试的小段代码。	Devin 以 markdown 文件的形式产出了研究笔记，作为创建 notebook 的中间步骤，而这并不是我要求的。不过，看到一份关于实现可能如何逐步成形的分步计划还是相当有用的。它在 notebook 中提供给我的代码并非 100% 正确，但作为伪代码很有用，让我大致了解可以如何把这些东西拼起来。考虑到这更像是一个研究项目，而我只是想了解总体思路，我会说这是一次成功。
关于带准确时间戳的转录摘要研究	失败	我在总结转录文本时面临的一个问题是，我很希望能有与笔记配套的准确时间戳，这样我就可以把它用于 YouTube 章节摘要或类似用途。具体来说，从转录文本中获取准确的时间戳不是问题，但很难把时间戳与摘要关联起来，因为时间戳经常会被搞乱。所以这算是一种 AI 工程研究任务。	Devin 只是重复了一些与我问题相关的内容，但并没有真正着手处理，它在进行研究或尝试解决我试图解决的问题方面做得不好，还给了我一些没有帮助的代码和示例指引。
创建一个最小的 DaisyUI 主题作为示例	失败	我让 Devin 创建一个最小的 DaisyUI 主题作为示例。我的目标是获得一个可以开始的起点，因为让它以更完整的方式来做这件事没有成功。	Devin 忽略了将其做成 FastHTML 应用的要求，来回沟通了一阵才让它走上这条路。最终，它创建了一个看起来可以使用不同按钮类型的应用。虽然它给了一个看起来不错的链接，但当我尝试修改主题时，就很明显发现这个主题根本没有起作用。应用中的其他颜色都来自默认主题。这不是一个有用的起点。

3. 分析现有代码

项目名称	状态	描述	反思
对代码库进行安全审查	无定论	对于这个任务，我让 Devin 查看一个 GitHub 仓库，并告诉它评估其中的安全漏洞。该代码库不到 700 行代码。我让 Devin 把笔记写在一个 markdown 文件里，并在必要时附上示例代码。	Devin 确实识别出了一些安全漏洞，但过于激进，还幻觉出了一些并不存在的问题。也许这对 Devin 来说并不是理想的任务，因为这件事同样只需调用一次我最喜欢的 LLM 就能做得一样好。
审查博客文章并通过 pull request 提出改进	失败	我让 Devin 审查一篇博客文章，并通过 pull request 提出修改建议。最终，Devin 失败了，因为它弄不明白我使用的静态站点生成器 Quarto 是如何工作的。	我认为这个任务在类似 Cursor 这样的工具里本来会成功。看起来 Devin 没有很好地从项目结构和现有文件中学习，所以它搞砸了 front matter 以及正确编辑博客文章所需的其他约定。
审查一个应用并识别潜在的改进领域	失败	我让 Devin 查看我之前提到的计时应用，并提供了一个开放式任务，让它提出任何改进建议。	它提供的建议毫无道理。
调试为什么 ssh 密钥转发在设置脚本中不起作用	无定论	我让 Devin 弄清楚为什么当我使用脚本设置服务器时，ssh 密钥转发不起作用。	问题最终与脚本无关，而我以为脚本是问题所在，但 Devin 从未建议或暗示问题可能出在别处。这没有帮助，因为它没有帮我找出根本原因。

4. 修改现有项目

项目名称	状态	描述	反思
对 nbdev 项目进行更改	失败	我有一个用 FastHTML 和 nbdev 构建的简单时间跟踪应用，我想通过 API 路由将其与 Apple 快捷指令集成。	Devin 无法弄清楚如何在这个环境中成功操作，尽管它取得了令人印象深刻的进展。我注意到一个奇怪之处是，Devin 创建了 Python 脚本来编辑笔记本，而不是尝试直接编辑笔记本本身。然而，Devin 在那里给了我一些有用的笔记和我未曾考虑过的想法。但是，它试图编写的代码毫无道理。最终，我使用了别人的模板，没有采用 Devin 的任何建议。
将 Python 项目迁移到 nbdev	失败	我让 Devin 将一个项目迁移到 nbdev [为简洁起见，提示细节省略]	它陷入了可怕的困境，无法弄清楚基本的 nbdev 设置。看起来它没有很好地阅读 nbdev 文档。
将样式包集成到 FastHTML 中	失败	我让 Devin 将 MonsterUI 集成到我的一个应用中。	Devin 无法弄清楚如何使用 nbdev 仓库。
添加功能以检查用户输入与数据库之间的冲突	失败	我让 Devin 向一个应用添加功能，根据之前的运行情况比较用户输入值与数据库中的值，如果不匹配则给出 UI。	我花了几个小时慢慢让它正常工作，然后放弃了。我自己在大约 90 分钟内编写了这个功能。
生成包含每个 fasthtml 画廊示例内容的 LLMs 上下文文件	失败	我让 Devin 为 fasthtml 画廊创建 llms 文本文件	我很兴奋地看到它为每个示例创建了一个单独的 markdown 文件，然后最初尝试将它们汇总到 llms 上下文文件中。我没有想过这样做，一开始一切似乎都在那里。当我拉取下来并开始深入研究时，我开始发现我不喜欢的东西：llms 的格式不正确。即使我给了它使用 XML 标签来分隔示例的信息，它也没有这样做。它添加并固定了一个特定版本的 markdown 包作为依赖项并使用它，而不是使用已经使用且已经是依赖项的 markdown2 包。它做了一堆 pytest 相关的事情并添加了一个依赖项，尽管项目不使用 pytest。

脚注

这个演示被这个视频 ↩︎ 彻底揭穿了