初创公司使用 AI “码农” Devin 一个月的体验
编者按： 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。
图片来源：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）任务，但我们发现这种做法并不太实用。）
图片来源：Cognition 的 Devin。使用 Devin 的聊天界面是最快捷的指派新任务方式。
当你分配给 Devin 一个新任务时，它首先会通过审查代码库来制定行动方案，并确定它认为应该进行的代码修改，从而制定行动计划。你可以实时在 web app 中观察它审查文件的过程和所做的代码修改（这一功能相当酷炫），一旦完成，它就会运行代码检查和代码测试（如果有的话），解决遇到的问题，并创建一个 PR（pull request）。你可以在 PR 中留下评论，指导 Devin 进行代码修改或修复 bugs。
简而言之：Devin 的使用体验既直观又易于与工程团队的工作流程融合。
03 Devin 的强项
Devin 最擅长的是进行范围狭窄、定义明确的代码修改，这些代码修改仅涉及单个组件和少数代码文件。我们最初让它完成的任务包括：优化饼图的显示格式，修正 API 在返回数据时遇到的边界问题，以及在创建新数据源时设定默认的更新计划。这些任务如果由人工来完成，每个大约需要一个小时的时间来研究、实施和测试。而有了 Devin，只需花费一两分钟来描述任务，并在将其完成的工作合并前用五分钟来检验。
图片来源：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 无法完成任务时，你会因为资金浪费而感到失望。
06 总结与展望
AI 软件工程师的前景无疑是光明的，我们大力支持这种模式：将部分工作交给 AI 处理，从而让我们可以集中精力处理更为关键的事务。从用户体验的角度来看，Devin 确实能够有效地支持这一过程。
然而，就像 AI 领域的许多创新一样，这目前仍处于起步阶段。我们很乐意尝试使用 Devin，但我们的看法是，它尚未达到初级软件工程师的水平。Devin 擅长处理那些一个人大概需要一个小时就能解决的、定义明确的任务。一旦超出这个范围，结果就会大相径庭。
我们坚信 Devin（及其底层技术）将会不断进步，随着技术的成熟，它实现这一承诺（能够像一名初级软件工程师那样工作）的能力也将不断提升。就目前而言，软件工程师们还不需要担心会因此失去工作，这一天还有很长的距离。
Thanks for reading!
Hope you have enjoyed and learned new things from this blog!
About the authors
Vikram Sreekanti
Co-founder & CEO of RunLLM
Joseph E. Gonzalez
Professor at UC Berkeley and Co-Founder at Run LLM
本期互动内容 🍻
❓2-10 美元解决一个小时的编程任务，这个投入产出比你觉得值得吗？团队在考虑引入类似工具时，你最关心哪些因素？
🔗文中链接🔗
[2]https://www.cognition.ai/blog/introducing-devin
[3]https://www.cognition.ai/blog/devin-generally-available
[5]https://www.answer.ai/posts/2025-01-08-devin.html?utm_source=changelog-news
[6]https://frontierai.substack.com/p/the-rise-of-ai-work
[7]https://frontierai.substack.com/p/ai-products-should-be-built-for-human
[8]https://joincolossus.com/episode/building-cognition/
原文链接：
