月烧4万元，两工程师用Claude Code 跑出15人团队效率：值不值全网吵翻了！

近日，初创公司 Every 总经理 Kieran Klaassen 在 x 上表示自己用 Claude Code 编程时平均每天花 250 美元，也就是说一个月花费 6000 美元（约合 4.3 万人民币）。他还晒出了详细的花费列表：

帖子发出后，网友们纷纷对 Klaassen 的花费表示不理解：“你是买了 30 个 Max 套餐账户吗？还是说你用的是 API 付费方式？我不懂。”“如果你花了这么多钱，还不如直接雇个开发者呢！”

当然，也有开发者认为 Klaassen 的做法很有启发性，毕竟“6000 美元不算什么，只是高级工程师一周的薪资。”但批评的声音还是占了大多数。

随后，他在 x 上解释称，“花了 6000 美金，多个 Agent 并行运行，一天提交了 10 个 PR，还完成重构并部署上线了。”他还表示：

我知道这让你不爽。又一个“看看我 AI 开销”的爆款帖子，都是炒作，都是噪音。

但你翻白眼时，错过了关键点：这些智能体彻底改变了我们的构建方式，不只是更快——而是完全不同。就像从所有乐器的演奏者变成了交响乐团的指挥。音乐变得更丰富，而你与创作的关系也完全改变了。

我们只有两个工程师。服务数千用户。过去需要数月的功能，现在几天就能上线。不是因为我们写代码更快了，而是因为我学过音乐，学会了“指挥” 😅。只是这次，指挥的是智能体。

没错，账单看起来的确像是在博眼球。但成果呢？那些是实实在在的。当怀疑的人还在争论这是否可持续时，我们已经在交付成果了。当他们在抱怨炒作时，我们正在培育超越我们自身能力的系统。

软件开发变成了一场不同思维方式头脑之间的协作艺术。

你可以继续无视这些账单截图，把一切都当作炒作。但你每观望一天，理解它的人和无法理解它的人之间的差距就会更大一些。

在评论区，他也说明了并非实际花掉了 6000 美元，而是产生了与其价值相当的成本。他也认为每个月花 6000 美元有点贵，但每月支付 2000 美元是可以接受的。

Klaassen 推文中提到的成果也很显著：他和 Nityesh Agarwal 确实在一周内交付了六项新功能、五个 Bug 修复和三次基础设施更新。两人实际上在短短三个月内，通过 AI 工具完成了 AI 邮箱管理工具 Cora 的开发，并在发布后迅速吸引了超过 10,000 用户注册。

近期，Klaassen 和 Agarwa 两人在 Dan Shipper 的播客节目上详细演示了其是如何使用 Anthropic 的 Agentic 编程工具 Claude Code 工作并借此提升工程效率的。InfoQ 对此次访谈进行了翻译，并在不改变愿意上进行了增删，希望能给大家带来一些启发。其中，部分核心观点如下：

• 使用 AI 编程，不应仅限于写代码本身，还应用于调研和工作流程的构建，几乎涉及开发过程中的每一个环节。

• 该团队表示已经很久没有使用 Cursor 或者其他 Agent 类编程工具了，因为 Claude Code 的体验远胜一筹，几乎将复杂度降低了十倍。

• Cora 团队现在的方式是尽量让 AI 完成实际工作，而人类开发者专注于管理这些 AI 工具。

• 一个点子能带来很多后续产出，这就是所谓的“复利效应”。团队有六七个任务是同时进行的，因为每当有了新想法，就立刻开始执行。

• 务必记得在“价值最低”的阶段对 AI 的输出进行严格审核，确保尽早发现并修正问题。

放弃 Cursor，选择 Claude Code

主持人： 虽然 Cora 团队只有两个人，但整个开发节奏和产出却像是一个 15 人的团队。Kieran，你前几天说的一句话让我印象很深刻：你们正在探索所谓“复利式工程（compounding engineering）”的可能性——每完成一个任务，都会让后续任务变得更容易。我觉得你们的经验值得被更多人了解，因为我们拥有了新的工具，就需要建立新的原则和工作流。

Kieran： 开发 Cora 是一件非常有趣的事情，更有趣的是能在 Enjoy 这样的环境中工作，这里不仅有先进的工具，还有丰富的思想资源和全新的工作方式。这让我们重新思考“如何构建产品”本身。我们正在一边做产品，一边尝试新方法，这种探索本身就很吸引人。

我们常常会遇到各种新模型、新研究工具，别人问我们怎么看，我们就在边用边学的过程中不断尝试。最近几周，Nityesh 和我都明显感受到一种转变正在发生：一场由新模型、思维方式、MCP 等推动的系统性变革。

主持人：具体改变了什么？你们目前逐步成型的工作流程大致是什么样的？

Kieran： 对我来说，最关键的转变是我意识到“AI 编程”不只是代码本身的生成。它应该贯穿整个流程，从前期的研究到设计工作流程，再到具体执行，每一步都能借助 AI。如今的 Agent 已经足够强大，能胜任几乎所有环节，因此我们需要彻底重新思考整个开发方式。

以前我们用 Cursor 或 Windsurf 之类的工具，属于更传统的“代码补全”阶段。而现在，我们开始直接给 Agent 布置任务就能完成。尽管最终的产出仍然需要人工协作与指引，但我们要学会更深入地拥抱这一方式。

Claude Code 就是一个非常优秀的编码 Agent，能很好地理解和执行复杂指令，尤其在与新模型结合之后，能力显著提升。突然之间，我意识到：我们已经进入了那个“Agent 时代”。这不再是实验室里的概念，而是真正能用来构建真实产品的技术。我们就是在用它做应用，而且它真的在工作。

主持人：你们怎么使用 Claude Code？

Kieran：Claude Code 是 Anthropic 推出的一款编码 Agent，底层使用的是 Claude 模型，它以命令行界面（CLI）的形式运行在本地终端中。对于不太懂技术的人来说，命令行可能看起来有些吓人，但我已经成功说服一些非技术背景的朋友尝试使用 Claude Code，他们也觉得很好用。

主持人： 打开的终端是那种黑底白字的经典界面，看起来像 DOS 系统。Kieran 只输入了 “Claude”，屏幕上就出现了 “Welcome to Claude Code” 的欢迎信息，并有一个输入框可以键入命令。

Kieran：Claude Code 和普通的 Claude 模型不同，它拥有对本地目录和计算机的访问权限，能浏览文件、运行本地命令、截取网页截图，甚至进行网页搜索，内置的工具远比普通 Claude 丰富。这点很关键，因为做工程开发不仅仅是写代码。你需要知道 GitHub 上的需求和任务状态，了解 CI/CD 流程是否正常，测试是否通过等等。而拥有这些功能的编码 Agent，才真正具备完成一个完整工作流程的能力。

我可以让它自动执行我平常要做的事。这正是“复利式工程”产生作用的地方——Agent 不仅写代码，还参与了整个开发上下游流程。大多数工程师的时间并不主要花在编写代码上，而是花在搞清楚“下一步要做什么”，如何理解用户反馈并作出响应。这些事情，Claude Code 现在都可以帮上忙。

比如我现在就可以让它帮我查看我们上周发布了哪些内容，然后整理成清单。这不仅可以用于团队同步，也可以为产品营销提供素材。例如它会总结出我们修复的 bug、主要新功能，像简报摘要、聊天面板状态、邮箱汇总、XML 标签、时区自动识别等等。

主持人： 而且这些内容的组织方式很清晰，既能让工程师读懂，也方便非技术团队使用。

Kieran： 我们现在几乎全力在推进“让 AI 做事、我们来管理 AI”的模式。比如，有人来问我某个功能现在的状态或下周发布什么内容，我可以直接让 Claude 查 pipeline，看即将推出的内容。

大家应该已经能感受到 Claude Code 的逻辑了：一旦你把所有信息系统接入它，使用起来就非常顺畅。对我来说，Claude Code 是目前最灵活的工具，不仅能解决编程问题，还能参与整个工程流程。很多编码 Agent 只聚焦在写代码上，但我希望它能成为整个工程工作的辅助系统。

Anthropic 的团队在设计这款工具时，显然考虑到了这一点。它没有被限定在某个特定用例上，而是保持了高度的通用性，同时又能精准解决问题。它能理解上下文、分析自己哪里做错了并进行修正。这些能力结合起来，才真正让它具备了现在可以投入实际使用的水平。

主持人：传统的“写代码”和现在的“Agent 协作编程”之间，最本质的区别是什么？

Nityesh： 相较于我们熟悉的 Cursor 和 Windsurf 等工具，Agentic Coding 其实提供了类似的能力，但 Claude Code 更进一步，把整件事简化了一个数量级。

Kieran： 虽然命令行界面对有些人来说可能看起来很复杂，但其实它比像 Windsurf、Cursor 那样的图形界面更简单。Claude Code 的界面只有一个文本输入框，没有快捷键、没有界面按钮，只有纯文本交互。因为底层 Claude 模型能力更强了，它可以持续工作、调用更多工具，所以反而变得更强大。虽然它和 Cursor 背后都是 Claude，但 Claude Code 简洁的界面带来了更大的灵活性。

我今天早上就用它查了一下数据指标。当时我在想：“为什么这份用户反馈表单完全没有任何回应？”

Nityesh： 给大家补充点背景：我们每周会发一份问卷，问用户如果不能再用 Cora 会有多失望，用来判断产品的价值。我们也每周开会看这些指标，但 Kieran 发现这周根本没人填写这份表单。

Kieran： 对，我感觉肯定是哪里出问题了，也许表单压根没发出去。我就问 Claude Code：“14 天前是不是出了什么问题？帮我查一下。”

Claude Code 的反应是列出一组待办事项，比如检查 controller 的最近代码改动、搜索代码库等。它自动查到了在那个时间点，我们删掉了负责把用户加入表单的那段代码。Claude 还告诉我：“你只需要加回这段代码就行了。”我就说：“那你帮我加回去，并创建一个 Pull Request。”它就立刻执行了。我还补了一句：“顺便也生成个脚本，把之前漏掉的用户补回来。”它也做到了。

整个过程特别轻松，我几乎没有费什么精力。这就像我在 GitHub 上记一个任务备忘一样简单，只不过这次它直接帮我做完了。

用 Claude Code 研发的细节

主持人： 如果没有 AI，这样的排查和修复任务可能要花 30 分钟到几小时不等。而且关键不是时间长短，而是你必须停下手头的事，专心处理它。而现在，你可以把它当作“发个请求”，然后再发一个、再发一个，有多个任务可以并行进行。具体说说你现在的工作流程是什么样的？比如你到底在干嘛？你自己还会写代码吗？

Kieran： 或许可以先讲一下我们最早拿到 Claude Code 的时候做了什么，当时我们都非常兴奋。

Nityesh： 对，那是在 Claude 发布直播的前一天。我们当时觉得，从明天起编程方式就会被彻底改变，我们将获得一个能力更强的模型，就像拥有一个“编程神灯精灵”。

于是我们决定，最有生产力的做法不是继续日常工作，而是开一个两小时的会议，集中列出所有希望新模型能帮我们解决的问题。我们确实做到了，列了大约 20 个 issue，包括 bug 修复、功能开发等，还为 Claude Code 的到来提前准备好了系统。

Kieran： 当时挺有意思的，Nityesh 还用 ChatGPT 生成了一个 prompt，大概内容是：“明天我们就有 AGI（通用人工智能）了，帮我们列出我们需要它完成的一切。”然后我们把这个 prompt 输入到 Anthropic 的 prompt 优化器中，再拿这个优化后的 prompt 去生成具体任务。

主持人： 你们当时在 GitHub 中用的是那种类似 Trello 的看板系统吗？每个 issue 都是一个卡片，不管是新功能还是 Bug，每个卡片都有详细文档，包括问题描述、解决方案、技术要求，甚至还有实现步骤和预估所需时间。

Kieran： 对，比如这张卡片里写的功能是“生成 AI 合成数据”，它的文档里从问题定义、解决思路、技术要求，到实施步骤都写得很清楚。

我们用 Claude Code 配合一个自定义的 prompt（在 Claude Code 中叫 command）来生成这些任务文档。哪怕是用 ChatGPT 来生成也挺费劲的，因为你得读很多代码，还得思考、整合，这其实是个挺重的脑力活。所以我们做了一个 command，目的是把这个流程自动化。

主持人： 你说的 command 是 Claude Code 里的命令，还是 Cursor 里的？

Kieran： 我是用 Cursor 编辑代码，但运行的还是 Claude Code。我还有个命令，就是语音转文字（voice to text）直接启动。我和 Nityesh 经常一起头脑风暴：“如果我们做这个会怎么样？听起来不错！”然后我就直接语音输入，它就开始跑。比如我刚刚说：“我想在 Cora 加一个无限滚动功能，当我读完一个简报（brief）后，它应该自动加载下一个，直到所有未读的简报都读完为止。”

主持人： 我想让大家了解一件事：Kieran 几乎从不敲键盘。他基本上全程通过语音输入来操作，比如刚才他是直接用语音在终端中输入，通过 Claude Code 进行交互。我记得他用的是一个目前还未正式发布的内部孵化项目——叫 Monologue，他是该工具的第四大用户。虽然这个工具还在保密阶段，但我们在这里算是提前预览了一下。

从我观察来看，它的工作方式是这样的：Kieran 说出任务内容后，这个系统会将语音转录成文本，并插入到任务说明中，然后自动执行一系列操作。

Kieran： 对，Monologue 会把我说的内容填入“功能描述”区域，接着执行一整套步骤。首先，它会在代码库中查找相关实现，相当于先了解现有内容；然后它会上网搜索最佳实践，包括开源项目中的常见模式；最后它会生成一个计划并让我审核。我很喜欢这个“人类审核环节”，虽然偶尔它会搞错，但大多数时候都能命中要点。确认后，它就会创建 GitHub issue，并自动分配到正确的工作流中。

主持人： 原来你们是在 GitHub 的看板里，把想要实现的功能直接用语音讲出来，然后 Claude Code 会自动完成所有调研，生成完整文档，最后转成 GitHub issue。

Kieran： 对，这是个很关键的环节。它和 Cursor 编码方式很不同。在 Cursor 里你可能会跳过这一步，因为它主要是用来写代码的。虽然你也可以在那里面写 Markdown，但它不是专为任务管理设计的。相比之下，Claude Code 的设计更贴近 issue 跟踪系统——这本来就是开发者熟悉的工具，我们可以直接把文档交给开发者去实现。

主持人： 当我们第一次看到 Claude Opus 4 的时候，我们都震惊了，因为它能一直运行，无需人工干预，最终还能给出很好的结果。虽然我们以前也见过一些 Agent 模式，但 Claude 的这种自动化和完成度完全不一样。它像是在稳定、高质量地一项项完成清单上的任务，这是其他 Agent 循环很难做到的。

Nityesh： 我和 Kieran 之间还在玩一个小游戏，看谁能让 Claude Code 连续运行更久，Kieran 现在是领先者。

Kieran： 我这次运行了 25 分钟。

Nityesh： 我目前只跑了 8 分钟。

主持人：Kieran，你是怎么做到让它跑这么久的？

Kieran： 我给了一个特别长的计划，内容很复杂，还包括大量测试任务。我让它运行所有测试并修复全部失败项，这样整个过程就会持续很久。

主持人：你那个能自动生成调研文档的 prompt 是怎么写出来的？你是靠感觉拼的，还是也用了 Claude 的 prompt 改写器？

Kieran： 这就涉及我们所说的“复利式工程”了。最早是 Nityesh 给我发了一个 prompt，他写得很戏剧化：“AGI 已经实现了，我们可以开始写软件了。”我当时觉得这个 prompt 还行，但我也问了一句：“你知道 Anthropic 的 prompt 改写器吗？”这个工具非常好用。你只要粘贴一个 prompt，然后点击“生成”，它会帮你优化改写。看起来简单，但效果很不错。你甚至不需要花很多时间验证它好不好用——有时候试一试，不好就删掉，成本很低。

那天我们要写 30 个调研任务，所以必须先有一个好用的 prompt。于是我就把刚刚那个 prompt 粘进去，生成一个版本，然后把它当作基础 prompt 用。之后，我们只需更改参数，就能反复复用。

主持人： 本质上，你们做的第一步是花时间写了一个 prompt，这个 prompt 的作用是自动生成其他 prompt。而那些调研文档，其实本质上也是给 Claude Code 的任务指令。

也就是说，你们不再需要每次都手动写“先调研、再拆解需求、再规划执行细节”等等，而是只要讲出一个简单的功能需求，Claude 就能自动展开所有细节，写出一整份完整计划。以前每次都要手动说清楚的那些内容，现在都可以自动生成了。

而且更有趣的是——它现在就在我们聊天的时候运行着，这完全改变了写代码的方式。我们前几周在通话时测试过这个系统，我当时甚至在通话中就上线了一个功能，这种边说话边构建功能的“社交式编程”在以前是不可想象的。

Kieran： 刚才我们在聊天的时候，其实 Claude 已经完成了调研，并自动生成了一个 issue。而且我们那会儿同时跑了六七个任务，因为我们当时的状态就是“有新想法就立刻执行”。我们一边翻看用户反馈、读邮件，把能找到的信息都整理出来，一边不断头脑风暴。

这种状态真的很有趣——你只要一有想法就能立刻启动一个 Agent，然后等一会儿再集中审阅它们的结果。这也是我非常同意的一点：在语音通话中协作是一种很棒的体验，因为这种碰撞中常常会有“魔法时刻”。

当然，目前仍然需要人类来做复审。我们发现必须检查输出是否合理、是否遗漏了什么，这就需要经验、判断力和直觉。比如我之前修复了一个邮件无法发送的 bug，Nityesh 也用 Claude Code 做了类似的事，但它给出的解决方案却错了。我在 prompt 里特别强调了“查看历史记录”，这引导 Claude 朝正确方向思考。而 Nityesh 没有加那句话，它就说“看起来一切正常”。

所以，确实需要人类的判断。这不是靠“神奇 prompt”一劳永逸的问题，而是你是否知道如何正确地使用它，把它的长处发挥出来。

“我每天觉得自己什么都不会”

主持人：Nityesh，我很好奇你怎么看待这一切。毕竟 Kieran 是一个非常资深的开发者，而你在编程上的经验可能还比较早期。你是怎么适应这种全新的协作方式的？

Nityesh： 对我来说，这整个过程非常震撼。我真正接触编程是从 ChatGPT 出现后才开始的，那时候我觉得 AI 出现正好是机会，于是决定自学编程，构建我一直想做的 SaaS 应用。后来转到 Cursor，接着又用上 Windsurf。我一直觉得自己已经站在最前沿了，我周围的朋友都没有这么用 AI 的。但直到我加入了 Every，开始和 Kieran 一起工作，才发现他完全是另一个层次。他在会议中从不敲代码，基本上都是对着电脑说话。而 Claude Code 发布后，Kieran 推动我去用它，现在它已经成为我们主要的编程方式了。

过去三周里，我和 Kieran 几乎都没再碰 Windsurf 或 Cursor，哪怕用了也只是因为我们没装 VS Code。本质上，如果只是为了看代码内容，用哪个编辑器都无所谓了，因为所有核心 AI 交互都发生在 Claude Code 里。而且真的很神奇，整个编程的方式每三个月就会发生一次巨变，让你不断意识到“没人真的站在最前面”。

主持人： 我真的有点羡慕你们这些在 ChatGPT 时代开始学编程的人，我是二十年前靠看书学的……

Kieran：《PHP for Dummies》。

主持人： 对对，还有什么《24 小时学会 Basic》那种……你刚才说以为自己已经处在 AI 编程的前沿，结果加入 Every 跟 Kieran 一比就发现完全不是，这让我想到《星球大战前传》里有一幕。他们在水下被怪物袭击，看起来要没命了，结果突然有个更大的怪物出来把那个怪物吃掉。主角说了一句：“总有更大的鱼。”Kieran 就是那个更大的鱼。

Kieran： 其实我自己也有同样的感觉。你刚才说我很厉害，但我每天也觉得自己什么都不会，还在拼命追赶。有太多东西要做，太多想法要实现。这就是当下 AI 编程的真实状态：总有更多的东西，但核心还是要练习。你必须每天都练习使用 AI，持续推动自己，否则就会错过很多令人兴奋的东西。

主持人：像你们这种“几乎不写代码、而是在更高抽象层次操作”的方式，会带来新问题吗？你们是如何应对这些问题的？又发展出了哪些新的工程实践，以保证整个过程的高效与稳定？

Nityesh： 对我来说，一个最重要的认识来自一本老书——《高产出管理》，是 Intel 的 CEO 在五十年前写的。它在第一章提到一个观点：所有问题都应该在“价值最低的阶段”被解决。

今天，AI 尤其是 Claude Code 已经能帮我们完成很多任务，这让“前期阶段”的质量变得格外关键。比如，我们会用 AI 生成一份非常详细的 GitHub issue 文档，那很容易让人想直接调用 Claude Code 去实现它。但如果 issue 本身的方向就偏了，Claude 就会在错误的路径上继续推进，结果只会浪费时间。

所以，我们现在的做法是：必须在人类 review 阶段就尽早发现这些潜在偏差、提前修正，而不是等到 Claude 执行完了再回头返工。

主持人： 这让我想到杠杆原理：你越靠近杠杆末端，力量越大，但方向偏差带来的后果也越严重。哪怕一厘米的偏差，最后结果也可能相差几千公里。就像发射火箭时瞄准月球，初始角度偏一点，最后就完全偏离轨道。我自己其实很容易跳过计划阶段——对着一堆文档集中精力很困难。你们是怎么处理这个问题的？

Kieran： 老实说，大多数时候读这些文档确实挺无聊的。但我们会想办法让它“更有趣一点”。比如我会要求 Claude 给出更简洁的内容，但这样它又容易遗漏关键点。所以我更偏好让它聚焦在用户故事或问题清单上，比如：“一个优秀的产品经理会提出哪些问题？有哪些不同解法？”这种格式会更容易阅读，也更容易引发思考。

总的来说，传统的 PRD（产品需求文档）太无趣了。但我们可以加入更多例子或反问，把它“变形”为一个信息更丰富、也更易于人理解的材料。这也正是我们人类审查阶段要做的事：查找潜在问题、补充缺漏——因为这一步能为后面节省大量时间。

主持人： 这让我想到我们业务中另一个项目。我们在 Spiral 正在开发一个“写作 Agent”，有点像 Claude Code，但专为写作任务设计。我们也遇到类似问题：写作 Agent 如果只是“生成一堆内容”，那人类还是得花大量时间去筛选和修改。所以我们现在尝试让 Agent 主动“进入访谈模式”，先了解用户是谁、想要什么，再输出内容，这样更准确，也省事。听你们这么说，我感觉 Coding 这边其实也存在类似问题。也许 Claude Code 未来可以多问一些有启发性的问题，帮用户厘清思路，而不是只吐出一大堆文本。

Kieran： 是的，这确实是我们应该自动化并持续优化的事情。Claude Code 的强大之处在于它可以访问你的整个代码库，理解你的风格，这非常有用。

除了在一开始就尽量做好问题定义，我认为传统的测试方式和邮件通知也非常关键。否则你怎么知道自己改的东西真的能用呢？当然你可以打开控制台手动点击测试，但完全没必要。我们可以让 AI 写一个测试，比如最基本的 smoke test（冒烟测试），看看功能大致是否正常运行，这样 Claude 也可以根据测试结果自主修复问题。

我们还在尝试一项新工作流程。我们会用 Claude Code 实现 Figma 设计，然后截取移动端页面截图，与设计图进行对比，验证还原度。虽然我们还没在生产环境大量使用，但非常期待它的效果。这种方式本质上就是把原本人工执行的验证流程“编进系统里”。不仅仅是代码测试，对 prompt 也可以做 eval（评估），就像给代码写测试一样，给 prompt 写评估脚本。

上周我就让 Claude Code 运行一个邮件发送流程的 eval，让它跑 10 次，失败了 4 次，它告诉我失败原因是调用了错误的工具。我查看了一下提示词，不够具体，于是我让它继续尝试，不断优化提示词，直到能每次都通过测试。我中途还下楼喝了杯咖啡，回来一看，已经搞定了。

所以说，即便是最传统的测试流程，对 AI 编程同样重要——测试能告诉你提示词是否可靠，就像传统单元测试告诉你代码是否工作一样。乍一看枯燥，但其实非常有效。

给各编码类 Agent 打多少分？

主持人： 我想花五分钟时间，让 Kieran 来给各类智能编码 Agent 做一个从 S 级到 F 级的打分。我来报 Agent 的名字，你来给出评级。先从 Cursor 开始，拿最优配置的 Cursor 来看。

Kieran： 就算是传统的、在最好的设定下的 Cursor，也不是最好的 Agent。我喜欢某些 Agent 的原因就是它们明确告诉你，“这就是我们最好的版本”。而 Cursor 有点让人困惑。所以我会把它评为 A 级，它确实很不错，特别是在使用 Claude 的情况下。

主持人：Windsurf？

Kieran：C 级。因为他们还不支持 Claude 4，这让我很难理解。三周前我还会给它 A 级，但现在不行了。

主持人：Devin？

Kieran：B 级。集成度不高，搭建过程也稍微麻烦一些，代码质量也没有 Cursor 或 Claude Code 那么全面。我不确定它是不是用 Claude 4，但用起来没有其他工具顺畅。

主持人：Charlie？

Kieran：Charlie 主要用于代码审查，我们现在基本只在这个场景下用它。作为代码 Reviewer，我会给它 A，但作为 Agent 我只能给 B。

主持人：Friday？

Kieran： 我会把 Friday 排在 Cursor 之上，介于 S 和 A 之间。虽然它现在还没用 Claude 4，而是用的 3.7，但依然表现非常优秀。Friday 的流程非常有主见，能高效地把事情做完。你给它一个 issue，它就能自动生成计划、等待你确认、然后执行、提交 PR。我见过它成功一次性还原 Figma 设计，也完成过一些 Claude Code 做不到的任务。让我真的有种“看见未来”的感觉，而且它背后的团队规模很小。

主持人：Codeex？

Kieran：B 级。

主持人：Copilot 呢？

Kieran： 我没怎么用过。三年前用过一次，半年前又试了一次，但不到一分钟就关了。如果一定要打分，我只能给 D。它当时还不具备 Agent 能力。当然，我得承认还没用过它的新版本，所以也许并不完全公平。

主持人：Claude Code？

Kieran： 当然是 S 级。

主持人：Factory？

Kieran：Factory 在某些方面其实比其他工具都好。但它不是我的风格，更适合那些偏企业级的开发者，尤其是对代码质量要求极高的用户，比如做多仓库开发的。它用起来有些繁琐，因为是 Web 和本地混合部署。我会给它 B，略低于 Codeex 和 Devin。

主持人：AMP 呢？

Kieran：S 级，仅次于 Claude Code。它非常擅长完成任务，使用体验也很好。你能感受到 AMP 背后的团队是真正热爱 Agent 工具的开发者，他们自己也在用。

我更倾向于把智能 Agent 看作招聘开发者解决特定问题的过程。比如 Friday 非常擅长处理界面工作，遇到这类任务我会用 Friday；需要做调研时，我会选择 Claude；如果是代码审查，我则用 Charlie。Agent 之间是可以协同工作的，不必局限于只用一个。

主持人：Charlie 集成在 GitHub 上，你可以直接“@Charlie”，它就会对 Pull Request 进行代码审查。

Kieran： 对，我们用 GitHub、Pull Request 和常规的开发流程，这样人类开发者也能介入。我们能“聘用”专长于特定任务的 Agent 来审查代码，而闭环代码工具则执行具体工作。这套体系是经过我们几十年经验不断优化的，非常强大。也正因如此，Copilot 也许能适应这套流程，因为它本来就集成在 GitHub 里。

主持人： 你们最近似乎引入了一位真正的专家，并通过 Agent 化的方式协作，既达到了预期，也减轻了对方的负担。

Kieran： 是的。虽然当时还没有真正的“问题”要解决，但我们希望更清晰地掌握关键任务的交付进度。鉴于我自己对这方面并不十分擅长，我们就邀请了专家参与。做法是这样的：我们开了一个两小时的电话会议，我把整个对话录了音；会后，我把录音内容输入到 Claude Code，并要求它根据对话生成两个资源 issue。大约十分钟后，Claude Code 给出了初稿，我再请专家审核。他对结果非常惊讶——他平时对 AI 生成的方案往往持怀疑态度，毕竟有些任务 AI 目前还没那么擅长。但这次他不仅认可了文档，还提出了非常有价值的改进建议。于是我们又围绕这些建议快速迭代。第二天，专家完成了人工复审，我再用 Claude Code 实现了对应的代码，并一起做了 Code Review。整个流程本来可能要两周时间，现在几小时就搞定了。

主持人： 还有什么想说的吗？

Kieran： 我建议大家都去试试 Claude Code。哪怕你不是技术出身，也可以订阅 Max 或 Pro 计划，每月约 100 美元就能获得无限使用权。我一个朋友从 Cursor 转到 Claude Code 后，重做了所有工作流程，都觉得效率大增。大家真的应该多尝试，积极推动工具的使用。

Nityesh： 但务必记得在“价值最低”的阶段对 AI 的输出进行严格审核，确保尽早发现并修正问题。

参考链接：

https://www.youtube.com/watch?v=Lh_X32t9_po

文章来自于微信公众号“InfoQ”。