引言

Devin 是一款相当谦逊、有自知之明的工具。它对自己的定位是，在得到明确指导的情况下，能够像一名初级软件工程师那样完成任务。根据相关经验，它大约能独立工作 3 小时，之后才需要考虑是否会出现偏差。这种预期管理既清晰明确又非常实用，与我们此前关于 AI 工作流程^[6]与人类工作交接^[7]的论述不谋而合。

Cognition 公司的 CEO Scott Wu 在采访中透露了他们团队使用 Devin 的思路^[8]，颇为引人入胜：正确的使用方法是在每天早上给 Devin 分配任务，然后让它在你忙于其他工作的时候自行运行。几小时后，你再回来查看它的工作进度，并提供必要的指导。到了一天工作结束时，Devin 应当能够完成你所布置的任务。这种合作模式，与你在团队中与初级工程师的合作非常相似。

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 的使用体验既直观又易于与工程团队的工作流程融合。

Devin 的强项

Devin 最擅长的是进行范围狭窄、定义明确的代码修改，这些代码修改仅涉及单个组件和少数代码文件。我们最初让它完成的任务包括：优化饼图的显示格式，修正 API 在返回数据时遇到的边界问题，以及在创建新数据源时设定默认的更新计划。这些任务如果由人工来完成，每个大约需要一个小时的时间来研究、实施和测试。而有了 Devin，只需花费一两分钟来描述任务，并在将其完成的工作合并前用五分钟来检验。

图片来源：Cognition 公司的 Devin。通过一个实时仪表板，我们可以看到 Devin 在 shell、代码编辑器等环境中的操作过程。

尽管它有时会在通用最佳实践与特定代码库的特定规则之间犹豫，但它很快就能根据你的指导做出反应 —— 随着时间的推移，它会建立一个针对特定代码库的知识库，我们可以对其进行检查和编辑修改。例如，Devin 最初尝试安装并导入了 @tanstack/react-query 库，但这个库并不适用于 RunLLM 的代码库。当我们指出应参考其他文件的实现方式时，它立刻进行了自我纠正。

根据我们的经验（我们不确定这是否是普遍现象），Devin 在处理前端代码时似乎表现得比处理后端代码更为出色。例如，它能够轻松处理相当复杂的 Redux stores 来优化状态管理，然而却在使用 Python 的 FastAPI 框架时遇到了困难 —— 即便面对的是相当基础的功能实现。

简而言之：Devin 在前端代码库中修复小 bugs 或进行细微的优化时，能够有效节省时间。

Devin 的局限

在完成了一些基础任务后，我们决定交给 Devin 一个更具挑战性的全栈任务，我们认为这个任务适合初级工程师去完成。这项任务需要添加一个新的（且独立的）数据库表，创建一个新的 API 接口，并将该接口集成到前端交互中。每处单独的改动并不复杂，但需要将各个部分整合在一起。正常情况下，工程师可能需要几个小时就能搞定。

然而，事情并没有按预期进行。在最初的任务描述中，我们明确指出没有现成的数据库表来记录所需信息。Devin 找到了一个功能类似的旧 API 接口，并试图在此基础上进行调整，但它似乎误以为旧接口的存在意味着数据库中已有相应的信息。尽管我们反复多次提示，它仍然无法在数据库的 schema 中添加新表。

在前端部分，Devin 将新按钮添加到了一个仅在特定条件下才会显示的位置。我们多次要求它让按钮在所有情况下都显示，但同样，尽管反复提示，它还是无法实现这一需求。

在尝试了多种不同的提示词来解决上述问题后，我们决定自己接管这部分工作，看看能否基于 Devin 的工作“半成品”将这个 PR 调整到可用的状态。但仔细检查后发现，Devin 添加的用于前端与新增 API 接口连接的代码大多不可用 —— 它忽略了我们之前教给它的最佳实践，处理 API 响应的代码也是一团糟。此时，我们决定从头开始实现这一功能，因为这样比修复 Devin 编写的代码要容易得多。

有趣的是，我们还发现 Devin 很容易陷入一种死循环，它试图解决代码检查器发现的问题，却又在之前所做的代码更改之间来回打转。在这个循环过程中，它似乎并没有优先考虑用户对 PR 中需要改进之处的反馈。

我们并不清楚是什么原因导致 Devin 出现这种混乱。每个组件的任务应该都相当简单，因此我们推测，跨多个组件的协同工作可能是最让 Devin 困扰的部分。它似乎无法将自身的规划或我们提供的反馈独立应用于特定组件。

简而言之：一个我们期望初级工程师能在一天内完成的全栈任务，对 Devin 来说却是一个难以逾越的挑战。如果这是一个新招聘的工程师，我们可能不会考虑将其留在团队中。

在 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 无法完成任务时，你会因为资金浪费而感到失望。

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