Devon 是异步的。一旦你启动一个 Devon 会话，Devon 就会开始工作并浏览代码，但你不需要全程陪在旁边。就像你给实习生布置了一个项目，实习生自己去完成一样。
Devon 是我团队里最喜欢的实习生，而且我有无限多个。你选一个可能想为产品做的任务，给我们展示一下你会如何端到端地完成它，怎么样？我会说：“请去研究 chat PRD MCP server。” 这样会为我们生成一个 pull request。你通常会同时运行好几个这样的任务。这就像是一种很好的方式，可以并行推进多个任务，然后分别查看进度。从“我如何用 AI”的角度来看，这样做的一个好处是，你可以借助这类工具实现多线程处理，同时推进 2、3、4、5、10 个不同项目，而不必觉得自己必须坐在那里盯着。
欢迎回到 how I AI。我是 Claire Vo，产品负责人，也是 AI 狂热爱好者，致力于帮助你用这些新工具打造更好的产品。今天这期节目对我来说非常特别，因为我们邀请到了 Scott Wu，Cognition Labs 的 CEO 兼创始人，也是我最喜欢的一款 AI 产品 Devon 的打造者。我们将听他讲述如何使用 Deep Wiki 和 Devon 启动定义明确的任务来完成工作；如何在 Slack 里把 Devon 当作他最喜欢、被@次数最多的员工；以及如何自然地把 ChatGPT 语音功能带进会议。让我们开始吧。本播客由 Google 赞助支持。大家好，我是来自 Google DeepMind 的 Shishta。Gemini 2.5 系列模型现已全面上线。2.5 Pro 是我们最先进的模型，擅长对复杂任务进行推理。2.5 Flash 在性能和价格之间找到了最佳平衡点。而 2.5 flashlight 则非常适合低延迟、高并发的任务。请访问 AI.dev，在 Google AI Studio 开始构建。
Scott，感谢你作为 Devon 在 X 上的头号回复者加入 how I AI。我对这次对话非常期待，也很高兴你能展示你和你的公司如何使用这款产品——至少它让我非常开心，也肯定让很多软件工程团队感到开心。欢迎。非常感谢邀请。说实话，我是你们的大粉丝，非常荣幸能来到这里。太好了。我们有很多内容要聊，但我们真正想做的是深入了解你如何使用 AI，尤其是如何使用你打造的产品。我认为，作为 AI 产品的构建者，有一点非常有趣：你每天都在使用它，并且变得非常擅长，同时还能向听众和观众展示一些使用你自己打造的产品的小技巧，这些技巧可能是他们之前没想到的。所以，我们将获得关于如何与 Cognition 产品协同使用 AI 的专家视角。你首先要展示什么？当你在做工程工作或推进产品时，有哪些常见的工作流？当然。对我们自己来说，作为一群程序员，打造一个能写代码的 AI 肯定是我们能花时间做的最酷的事情之一。我想展示几个我们如何使用 Devon 技术栈的流程，因为其中涉及几个不同的部分，与 Slack 和 Linear 的集成、wiki，还有 ask Devon，以及启动 Devon 会话并从中获得 pull request。我认为这里面确实有一些微妙的差别，比如与 Devon 作为团队成员协作的正确流程是什么，因为它与市面上很多工具真的很不一样——那些工具更像是 IDE 或终端 UI，而 Devon 首先更像是你团队里的一名工程师。是的，完全同意。那么你使用 Devon 时，哪些功能对你来说作为软件工程师真的能起到关键作用？我们喜欢把 Devon 描述为一名初级工程师。所以 Devon 不会去解决什么非常困难的架构问题，或者做出什么重大的战略决策——那种你需要参与并在接下来一个月里执行的事情。我们当然也在努力让 Devon 晋升为高级工程师，会帮 Devon 争取晋升的。但 Devon 可以帮助你做决策，比如引用正确的资料、提供几个选项或输入。不过我认为 Devon 真正擅长的地方，用我们的话说就是“任务而非问题”。当你有一个非常明确的需求，比如“这就是我们要做的，这是任务，这是所有细节”，Devon 非常擅长去执行，并且能大大加快速度。那么接下来很自然的问题就是，你如何确定 spec，或者你想要做的任务具体是什么。很多其他工具，比如 wiki 和 search，你不需要……嗯，或者说 sphere，让你能够就理解代码库或需要做什么提出正确的问题，然后把任务组装起来。实际上，我们最常见的用例可能排第一的就是梳理你的 issue 积压。每当我们出现一个 issue，或者我们在很多 Slack 频道里讨论 issue 时，每个频道里我们都会先 @ Devit 来做第一轮处理。这是很大的一类。比如有人说：“哦，我们需要去修复前端里的这个东西”，或者“也许我们需要去支持另一个 MCP，我们稍后会展示”。然后还有很多其他工程师的杂活用例，Devon 也做得非常好。比如去做版本升级、在整个代码库里添加文档、为某个特定功能添加单元测试、响应刚收到的崩溃报告并尝试诊断出了什么问题。是的，我喜欢你所说的 Devon 是一名初级工程师。我说 Devon 是我团队里最喜欢的实习生，而且我有无限多个。我也喜欢这个“任务而非问题”的理念。我认为这是人们在使用 AI 时，甚至在工程领域之外使用其他 AI 工具时，需要真正思考的一点：以任务为导向能帮你取得成功，或者至少一系列任务会非常有帮助。那么你选一个可能想为产品做的任务，给我们展示一下你会如何端到端地完成它，怎么样？好的，没问题。你可能知道，我其实是 chat purity 的忠实粉丝，我自然想到的就是我们需要集成 chat purity 的 MCP server。所以我在研究如何用 Devon 来做这件事。我通常会先做的第一件事就是打开我们所谓的 Deep……基本上对于任何代码库，无论是公开还是私有的，你都可以进来获取一份完整的 AI 生成文档。那么在这种情况下，这就是 Devon 的 web app 仓库，恰如其分。这里没有什么太敏感的内容，但基本上，它解释了 Devon 是什么。它从 readme 中提取了很多信息，或者说理解了系统架构，我可以搜索并调出不同的内容。因此，如果我想了解 MCP marketplace 是如何设置的，它会指出这里有哪些特定的组件，或者哪些特定的文件叫什么。我可以查阅这些，从而准确理解这是如何配置的。接下来我自然会问的一个问题是：好的，不错。但请告诉我 MCP server list 是在哪里实现的。于是它会检索我们的仓库，而且此时 Devon 已经在 dev web app 仓库中做了大量工作。我自己也了解一些。这很有帮助，也就是说，Devon 会随着时间的推移构建起代码库的表征，我们可以看到这里在发生什么。它掌握了所有这些信息。因此，你既能得到关于 server list 如何实现的自然语言解释，同时对于没有观看屏幕的人来说，在右侧还能看到实际的代码片段和参考文件，你可以查看这些来真正理解代码的深层细节。所以你拥有了一种组合：先是解释工作原理，然后是具体的细枝末节。没错。英语和代码的结合。这很有意思，我觉得总有一天可能全都会变成英语，但我认为尤其是在当下这个时期，我们实际上正处于这样一个时代：显然，作为工程师，你想要同时查看英语和代码两者。你可以看到，这里它给出了关于正在发生什么的答案。特别是，它会指出：好的，这就是我们拥有的所有不同 marketplace servers 的列表。我们有 Atlassian MCP，有 HubSpot MCP，等等，对吧？从这里出发，我接下来自然想做的事——这也是我们发现对用户来说非常重要的一个流程——就是利用这个来生成一个给 Devon 的 prompt。整体思路是，既然我们已经处于这个上下文中，我们知道所查看代码库的哪些部分与问题相关。这为 Devon 提供了很多可以起步的信息，如果我们心中有一个具体任务，就可以启动它。所以我会说：请去研究 chat PRD MCP server，并把它添加到这个列表里。这样做的效果是，我基本上会基于这些信息构建一个 Devon prompt。这个 prompt 包含了我刚刚输入的内容，虽然还不算非常精炼。但它也包含了我们所在代码部分的所有细节，以及我们正在查看的组件等等。然后它会为我生成这个 Devon prompt，我就可以直接拿去使用。你可以看到，它会告诉你要遵循现有 server 的模式，比如 Atlassian 和 HubSpot。这里使用的正是具体的 type definition 结构。这些是你应该查看的函数。还有这些是你应该检查以确保其正常运行的内容。关于工作流程，有一点我想提醒大家：很多人，包括我自己在内（抱歉了 Devon），本来会直接发送那个 prompt，也就是“把 chat pods MCP server 添加到列表里”。但我认为，有一个非常简短却重要的环节：拿到这个 prompt，结合上下文将其转化为一个有效的 prompt，然后再把它发送到任务中去，这能省去很多麻烦。虽然当时感觉像是额外增加了摩擦，但我相信很快这将成为工具本身要完成的任务之一——也就是说，这个环节是否会通过推理模型或某个应用层而变得无形？——其次，这对人们来说是值得的。所以，当你想发送一个五字 prompt 时，不如改为说：“这是我的五字 prompt，帮我生成一个更好的 prompt。”然后再把它发送到你的系统中。是的，确实如此。我觉得这点说得非常好，因为正如我们所说，Devon 是异步的，对吧？所以从这一点来说，它的好处在于，一旦你启动了一个 Devon session，Devon 就会开始工作，翻阅代码，上网查阅关于 chat 的资料，等等。它会做所有这些事，但你并不需要一直陪在它旁边，对吧？它会独立工作。就像你给实习生布置了一个项目，实习生就去着手做了。他们可能会在 Slack 上找你，问些问题，或者你可以快速去看一下实习生进展如何。但你没必要每一步都坐在 Devon 旁边盯着。所以我们描述这种方式时是这么说的：很多任务通常都有一个同步部分和一个异步部分，对吧？而搜索和 wiki 的很多用途，就是在你进入异步阶段之前完成任务的同步部分。比如说，如果你有一个实习生，你会只给他们发一个五字的消息就不管了吗？也许有时候对于特别清楚的事情会这样。但更常见的是，你会坐下来和他们聊两分钟，说：好的，你知道我们有这个 MCP marketplace，然后我们一起看一下，读一下具体的代码行，接着你说：好的，那我们把 chat PRV 加进去，你去看看那个 MCP server 是怎么实现的，确保把它加到列表里。然后你就在那里交接了。所以你会先花两分钟和你的实习生 Devon 来回沟通。而一旦你点击执行 Devon prompt，你就预期它进入更异步的状态，不再需要你在循环中参与。对了，还有一点我想提醒那些正在构建 AI 产品的人，比如你，也比如我：在这些同步产品中，延迟真的很重要。人们对等待时间很容易感到沮丧。但如果你把产品设置为真正的异步模式，你实际上会在等待时间上赢得很多用户好感，因为不存在那种即时反馈的预期。就像你不会说：“嘿实习生，去调研另一个 MCP，给我提个 PR，弄好了再回来。”你知道，你不会期望实习生立刻就做完回来。从产品角度而言，你也不会期望 Devon 立刻返回结果。现在，从我个人使用 AI 的角度来看，这样做的一个好处是，你可以用这类工具进行大量多线程操作，同时启动两个、三个、四个、五个、十个不同的项目，而不必觉得自己得坐在那里盯着。所以我想问，当 Devon 在运行时，你会去开会或者喝杯咖啡吗？这种异步工作流为你带来了什么？说实话，我一天中大部分时间都在开会，所以能够直接把这些任务丢出去就太好了。或者你有一个 issue backlog，又或者你想说：嘿，今天我有三四件事希望能处理一下。你会用 Devon 来启动每一个任务，然后它们会异步执行，对吧？它会在 GitHub 上为你创建 PR，并展示 diff 以及它完成的工作过程。如果是类似 chron change 这样的改动，它还会给你发送前后对比的截图，对吧？你可以看到它正在去查阅研究资料。不得不说，显然我的 MCP 页面 SEO 做得不好，但 Devon 确实帮我做了 MCP 主页，所以它现在就在顶部导航里。真有意思。对我来说，它应该知道这些。对。很好。所以这就是……
是的。所以我认为毫无疑问，你通常会同时运行好几个这样的任务，而且就像你说的，这是一种很好的方式，可以让你并行推进多个任务，然后逐个查看进展。没错。那么，这个任务会做什么——也许等它思考完成后我们可以再回来看——它会去做研究。它会找到 Devon 为我们做的 MCP 服务器文档页面，然后拉取那份文档，接着你就能从中获得实际的代码。所以，你做这件事的目标是得到一个 PR，对吧？是的。这会为我们生成一个 pull request。然后我会去审查这个 PR，如果看起来没问题，我就会合并它。显然，我们将在接下来的七周内把它发布出去。太棒了。那你的 prompt 会变得好多了。我感到有点不好意思，所以我这就把 MCP 主页通过 Slack 发给你，你可以把它交给 Devon 去处理。没问题，没问题。你在这里看到的是一场真正的实时演示。是啊。这就好比你的实习生跑回来说：“嘿，我刚才在查这个，但找不到，你能告诉我在哪儿吗？”
好的，发给你了。chatp.aimcp。好的。里面有代码片段之类的所有内容。好的，好的，来了。太好了。这是一个很好的例子，说明你已经完成了调研。你用调研结果创建了一个更好的 prompt，再用这个 prompt 启动任务。这个任务会像一名初级工程师那样异步工作，包括研究你业务之外的代码，然后基于你仓库的上下文去做 PR、发布这个功能。而本来你是得专门找人来做的。我会想到……
对我来说，我会想到那些人……
做这种事你得牵扯到的人，比如你得去找写 MCP 服务器代码的那位资深工程师。对。然后请他给我解释一下。你还得花时间写一份详细的需求文档，说明你要做什么，然后再指派给某个人去实际实现。所以我认为，你把一个可能需要三个人参与的流程压缩到了大约十分钟就能完成。是的。而且我发现，很多真正喜欢 DET 并以这种方式使用它的人，往往是 tech leads、产品经理或者类似角色的人。一方面，你已经习惯了这样的流程：先弄清楚一个问题，深入了解情况，然后交接任务，明确说明我们需要构建什么，对吧？另一方面，对于那些整天开会、日程排得很满的人来说，异步工作流程天然就是一种快速启动和查看任务的好方法。所以，如果你不是一直开着 IDE，从网页应用或者 Slack 发起任务是一种很轻量的方式。当然，你也可以从 IDE 启动任务。但我们看到，这种工作流程在 leads 和 PM 中非常常见，他们通常需要在各种事务之间来回切换。是啊。我最近越来越常跟别人说的一点是，作为产品经理入职培训的一部分，你现在应该给每个人开通 GitHub 权限，但这在很多产品型组织里并不是常规做法……
……你知道，在很多产品组织里，通常不会给 GitHub 权限，也不会给这类工具权限，但我认为这确实能让产品经理做更多事情。所以，趁这个任务还在运行，我想聊聊——就是我们开播前，你跟我说最近一个月有点忙，处理了一些跟业务相关的有趣事情。而且我知道你肯定还想写代码、和团队待在一起。那么，这种异步特性，以及这种随叫随到的初级工程师，你在日常中是怎么利用它来应对团队里涌进来的各种事务的？我不是说“我有一个功能想建，咱们去建吧”——我们刚才已经看过那个流程了——而是公司里那些被动响应的事务，你是怎么用 AI 来跟进并保持高速运转的？对我们来说，很大程度上就是在 Slack 和组织里设置正确的工作流。Devon 显然具备知识库功能，这意味着随着你不断使用，它会逐步学习你的代码库，或者你也可以主动告诉它某些功能的具体实现方式。很多事情上，我们几乎已经把 Devon 制度化地变成了第一响应人。我可以举几个例子。关键在于，要让 Devon 成为我们提交的各种事务中第一个被指派的人，对吧？虽然 Devon 没法在第一次尝试时就一次性搞定所有事情，但通常你可以跟 Devon 来回协作，它会先提交一个 PR，如果最后还需要一些微调或者补充开发，你再去处理即可。我们有很多频道用来讨论问题或者各种需要开发的事项。比如，我们有专门处理崩溃的频道，有核心基础设施事项的频道，还有这个——这是我们网页应用的频道，希望这个敏感程度低一点。你可以看到，这里大家讨论的每一件事，我们都是从 devon session 开始的。比如，“嘿，你能把这三个层级的字体大小、间距和样式统一一下吗？”然后我们就开启 dev session，Devon 会创建 PR，再经过审核流程。这个最终被合并了，因为中间有一些来回反馈。所以 Devon 会去做修改。让我看看。Devon 创建了这个 BR，经过几轮修改后，我们的工程师 Dave 合并了它。这就是我们日常的工作方式。这又是一个很好的例子：“嘿 Devon，能不能做到当用户 command+点击通知时，在新标签页中打开对应页面？”
嗯，这个功能很可能是某位用户提出的需求。你开启一个 Devon 会话，Devon 就会给你进度更新：目前我在做这些，我正在查看这些文件，以及我发现了什么。顺便说一句，在这个例子中，它其实提到的是 conference medium，然后有人说：“不不不，你应该看看这个东西。” 我想强调一个很酷的点：正因为如此，Devon 天然就是一种 multiplayer 体验。我们经常会有几个人来回交流，或者如果其他人在看这个问题，又或者有人是代码库这一部分的专家，他们就会在这里给出自己的意见，Devon 也会和他们来回互动。所以这其实就是一条线程，你们一群人在上面沟通，想办法解决这个问题，Devon 只是线程中的一个参与者。比如 Ethan 进到 Walden 的线程里说：“嘿，记得用 tanstock router 的 link 元素。” 然后给出了反馈，接着 Devon 就去 pull request 里做了修改。所以你可以看到，Devon 先做了一个初始版本，后来又提交了一些额外的 commit，最后改成了用 Tanac router 的 link。作为 AI 创始人，你习惯于冲刺产品市场契合点、下一轮融资，或是第一份企业合同。但对 AI 创业公司而言，速度还不够。买家从一开始就期待安全性、合规性和透明度。正因如此，真正认真的 AI 创业公司都在使用 Vanta。凭借深度集成和为高速迭代的 AI 团队打造的自动化工作流，Vanta 让你快速做好审计准备，并在你的模型、基础设施和客户不断演进时，通过持续监控保障你的安全。Langchain、Writer 和 Cursor 等 AI 创新者正是通过在早期就把安全做对了，才得以更快扩张、签下更大的订单。听众可以在 vanta.com/howiaai 领取 1000 美元专属优惠。你知道，我很喜欢的一点是，对于那些想在团队中推动更多 AI 应用的人来说，尽可能公开地做这件事真的对学习很有帮助。我在 LaunchDarkly 管理工程团队时就有过这样的经历：当我们开始把 Devon 以及类似 Devon 的 agent 放到公开频道里，我们看到团队在采纳这些 agent 方面有了很大提升，也学会了如何与它们对话、如何获得理想的结果。对了，我们之前聊的时候我说过，我总是给 Devon 发私信。因为我没有员工，没人可聊，它是我唯一的伙伴。我确实总是给 Devon 发私信，我们会有一些旁支的对话，它就像我身边的实习生。不过在更大的组织里，我非常主张在公开频道里做，在人们能看到的地方做，因为这样一来工作能完成，二来能形成肌肉记忆，立刻把这些工具拉进来，另外还能学习怎么使用它们，什么样的 prompt 有效，它擅长什么、不擅长什么，这些对于整体使用这些工具都非常有用。所以我觉得，在组织里隐藏你对 AI 的使用大概是你能做得最糟糕的事。因此，我说全都要公开做。没错。我想补充的是，说到这种 multiplayer 体验，其实有两方面的好处。一方面是对 agent 本身的知识传递，我觉得越来越多的产品都开始具备这一点了：一个人用了 Devon，或者用了这个工具、那个工具，这些就会增加到工具本身的知识里，所以一周后当别人再开会话时，Devon 会说：“嘿，对啊，我上周刚处理过这块代码，我完全明白你在说什么，让我去找找。” 另一方面则是教育人类，你们互相展示各自的经验，能够在同一个流程里协作。我完全同意，正因为有这两方面的原因，我认为我们会看到越来越多 AI 生产力工具变得更具 multiplayer 属性。是啊，这是我的期望。好，在结束 Devon 以及你把它用于工程开发这个话题之前，我想聊得具体一点。这样，你先讲，然后我再讲。你最常用的五大任务是什么？就是那种人人都可以直接交给 Devon 去做的任务。你来选五类任务，我也选五类。好的，没问题。那我的前五是：第一，各种前端杂项修复，这个特别棒。因为通常这整个流程，出于各种原因，就像你说的，得拉三四个人进来：我们先定好方案，然后找个人看代码，再找个人做 review 之类的。而现在你直接 @ 他们，说明一下，附张截图，比如“我想把这个按钮做得更圆一点”，或者“我想在这里调一下设计”等等，对吧？Devon 就会去做，它会找到代码里对应的部分，完成实现，还会给你发修改前后的对比截图。你可以直接在那里面 review。这是一个非常好的应用场景，一方面对 agent 来说它是可验证的，另一方面对人来说也是可验证的。对了，你说这个的时候，我正好可以举一个例子。让我分享一下屏幕，我很少有机会这么做，挺激动的。窗口……分享 Slack 总是让人兴奋。如你所见，我唯一的朋友就是 agent。这是我最近刚做的一个例子：我在做 chat parody 的主页，Devon 很快给我反馈了一个我喜欢的新 hero 图，我也能直接在上面提意见。这正是你刚才说的那种情况：我们想做些改动，然后立刻在工作流里得到即时反馈。没错。修复、新组件、前端想做的改动，这些都特别特别好用，因为就像你说的，你基本上可以直接在里面把这些事全办了。所以对我来说这大概是第一类。第二类我能想到的是版本升级、迁移之类的事。比如升级你的 Node 版本，或者升级到最新的包等等。这非常省时间，我们都得做这些事，而且新包不知怎么就出得这么快。但显然，难点在于细节：你发现新版本会说，“哦，这个组件的每个实例，我们建议你改用这种结构”之类的，Devon 就能去做 semantic search，找到每个组件，然后做出正确的修改。第三类我想说的是写文档，这也是个大事。比如我们的 Devon 文档，我们自己的文档页面，对外的文档页面，基本上整篇都是 Devon 写的。当然 Deep Ricky 本身也算是它的延伸，但哪怕是你自己写文档页面或者整理材料，它也能做。
Devon 做的很多事情是深入处理代码库，理解这里引用了那里，以及这部分功能是做什么的等等。这挺有意思的，因为严格来说它不总是写代码的场景，但我认为它与写代码紧密相关，很多相同的能力在那里也非常有价值。我想第四点应该是即时响应。我们设置了这样一个机制：每当发生崩溃时，第一道防线，也就是值班人员，基本上是 Dev。于是 Devon 会收到告警并启动，开始运行一个会话。显然，你可能也希望有真人参与，尤其是在处理重大事故时，以确保掌握情况。但好处在于，比如在凌晨四点，你半睡半醒地走到电脑前，Devon 已经写好了报告：我看了下，我认为是上周或昨天的某个变更导致的，错误追溯就在这里。所以我们经常用这个功能，对我们来说简直是救命稻草。然后第五点，Rick C.，我想说的是补充测试，这对我们来说很重要。这种情况很常见，尤其是对个体工程师来说，他们在开发功能时，你有了整个 PR，你把功能搭起来了，构建了一个新特性，而在发布前最后一件事总是要去补充单元测试，确保你的东西能正常运行，对吧？同样很棒的是，Devon 会去做这件事。它会编写测试，然后在本地运行这些测试，确保它们通过，这样我们就能和你一起迭代，确保 lint 通过、CI 通过等等。基本上就是帮你把这些都补上。好的。我们（的看法）非常接近，我的五个（场景）也非常接近。所以我很喜欢这些。我来总结一下，并在你的基础上补充我的。第一是前端修复。我对前端修复的具体理解是，这些 AI 工具能帮你打磨出非常精美的交互式用户体验，而这些是你通常没时间去做的。所以那些你不想在前端上耗费精力去实现的奇妙小互动，我觉得它很擅长。第二是文档，我觉得这被低估了。我实际上设置了一个 GitHub action，每当有 PR 创建，Devon 就会审查它，重写 PR 描述，然后在 PR 关闭后，Devon 会将我们的内部文档同步到代码仓库里，这样 Devon 就能访问这些文档了。所以我认为它是一位出色的技术写作者。第三，我也一样把 Devon 作为事故的第一道防线。Devon 实际上有 Sentry 账号，会登录 Sentry，浏览我们所有未解决的问题，然后开始为我们修复。第四是 upgrades。然后还有一个你没提到但我认为更具运营和个人价值的点：7×24 小时随时在线的 rubber ducking。就是当你在开发某个东西时，你会想，你能不能帮我看看这个，我是不是疯了？这想法是不是太疯狂了？比如在周日晚上、周一晚上或者周六早上，你真的很不想打扰同事的时候，我觉得有个能陪你 rubber ducking 的对象真的挺好的。这些就是我的使用场景，非常相似。好的，Scott，最后我们想聊一个 Devon 生态之外的高层级用例，就是语音。你之前跟我讲过一个 Chat GPT voice 的有趣用例，我之前从没听说过。你介意花几分钟跟我们讲讲吗？没问题。我是语音交互的忠实拥趸。实际上我觉得这有很多有意思的地方，我们也尝试过，我们在 Windsor 里现在也加入了语音功能，从 wave 11 开始就有，部分也是因为这个原因。简而言之，我是这么看的：大概二三十年前的 Google，本质上就是一个更好的百科全书，对吧？你有各种想查的东西，想汇总的信息，它基本上能让你更快地得到答案，而且信息更新。而我觉得用语音聊天就像是“更好的 Google”，你能获得更快的答案，完全同步，可以在对话中进行。而且显然，它还能去做研究，做很多其他事情，细节也很丰富。我经常这样做：如果我在开会，我们在讨论事情，总会有问题冒出来。比如昨天我在一个会上，我们就在聊这个话题——世界上有很多组织拥有大量软件工程师，所以我们就在想，那些拥有一万名以上软件工程师的公司都有哪些？全球大概有多少家？你显然会想到，那些大银行有数万名软件工程师，大型科技公司也是，这是最先想到的几类，还有像 Accenture、Infosys 这类公司，这是最先浮现在脑海里的，但除此之外还有哪些公司拥有这么多软件工程师呢？自然，在会议中如果你突然拿出手机，完全不理会大家两分钟去查东西，这是挺不礼貌的。所以我通常会做的是，直接打开 Chat，开启语音模式，这基本上就像是给每段对话都配了一个聊天助手。然后我就会问：嘿，你能告诉我们，大概有多少家公司拥有一万名以上的软件工程师吗？然后无论是语音对语音，还是先语音再文字回复，这两种模式我都经常用。我发现这是一种非常自然的过渡方式，语音把摩擦降低到了真正重要的程度。我想说，在百科全书时代，如果你想查点什么，大概要花五分钟，你得去找对应字母分类，然后翻找；而 Google 把它缩短到了十秒左右；语音则像是从十秒进一步缩短到一两秒，你能立刻连上，直接说出你想问的。我认为这很重要，因为你可以来回追问，或者随口提出那些即兴的、灵光一闪的问题。是啊。我想说，你可能改变了我的想法，因为我以前觉得语音模式在社交上很具破坏性，在会议中说话感觉很不自然。但如果你换个角度想，“不，这只是我引入房间的另一位会议参与者”，那它实际上更具社交包容性。每个人都能听到结果，对吧？你不用在 Slack 里发链接，然后大家开着笔记本边听边读。每个人都能同步接收到这些新信息。所以，如果我要和人开会的话——不是想炫耀，但我几乎没什么会议——那我或许也会把 Chat GPT 带进去。好了，我们进入快速问答环节，好让你回去工作。第一个问题就像在儿女之间做选择。IDE、终端，还是 agent？什么样的形态将主导 AI 工程？我其实认为，未来我们所说的 coding agent 以及诸如此类的东西，本质上就是下一代人机交互界面。我喜欢这样讲：Tony Stark 是没有笔记本电脑的，某种程度上你也不需要，只要你接入了 Jarvis，跟你的 agent 来回沟通，它就去帮你把事情办了。你可以想象，构建软件的过程更像是，你不再盯着代码看，而是直面自己的问题，看着自己的产品说：“嘿，把这个按钮弄圆一点。在这儿加个新功能。保存一下，再向用户要些信息。”你就是在产品里实时做修改，而你的 agent 自然会在背后帮你实现。所以我认为这确实很 agentic，但说到底，无论我们叫它 IDE、agent 还是别的什么，它本质上其实就是一种不同的人机交互界面，让你直接看着产品本身，而不必去翻遍所有代码什么的。我认为这才是未来的形态。不过要说当下，我觉得很大程度上取决于用户群体。比如我自己就总在开会，因此我觉得 Slack agent 的工作流其实是一种非常自然的方式，或者像在 Linear 里 @Devin 这样。而对于一位每天能写八到十小时代码的工程 IC 来说——再次感叹，那可真幸福——IDE 仍然是最自然的起点。也就是说，你会有在后台运行的任务，有异步进程在你干活时持续推进，但目前要从哪里开始，我觉得还是 IDE。我也觉得，这个时代的好处就在于，形态可以主动适配你，你可以决定什么样的界面最适合你的工作流。好了，既然大家都知道，Devin 是我的好伙伴。我相信你们收到了海量对话，这些能很好地引出我的收尾问题：当你对我们可爱的实习生 Devin 感到沮丧时，你的 prompting 技巧是什么？我知道你们会监控这些，因为有时候我沮丧了，会收到一点 credits 返还，一点 credits 返还，就像是“你搞错了”的补偿。所以我知道你们见识了大量人类对 agent 说的自然语言，但你的策略是什么？当你感到沮丧或卡住的时候，你会怎么做？我可以给点建议，但我不能说自己总能严格遵守自己的建议。尤其是对于 agent 来说，我觉得 agent 和 chatbot 有一点不同，chatbot 可供参考的信息更少，该怎么说呢。用 chatbot 时，你问个问题，它答错了，你只能回“不对，答案错了”，也就到此为止了。但面对 agent，你可以做的一件很好的事是去翻看它的全部历史记录，看看它到底做了什么。就像刚才我们遇到的例子，Devin 卡住了，我看到这个 chapter page 没有 MCP 服务器，我在找相关文档。如果我们去翻日志，就会看到它去 Google 了，找到了一些别的东西，问题就出在这儿。然后你就可以拿着这些信息，明白过来：哦，Devin 漏掉了这个页面的链接，然后你把这个发给它。所以我觉得，面对 agent，很多时候其实就像跟实习生结对编程或结对调试一样。你得先去梳理一遍：好的，这是你走过的所有步骤。对了，顺便说一句，我觉得你漏掉了一个文件，就是这个的下游引用，所以才有了这个 bug 什么的。我认为这才是真正能推动进展的关键。明白了。所以要回顾历史，找出问题所在，然后重新下指令。Scott，这次聊得太开心了，谢谢你给我们展示这些。我们在哪里可以找到你，又能帮上什么忙呢？没问题。我们在 Twitter 上是 Cognition 和 Devin。我们正式拿到了 Cognition 的 Twitter 账号，这很棒。然后显然，如果你想用产品的话，是 Devin.ai。太好了，非常感谢，感谢你抽出时间。客气了，谢谢邀请。感谢收看。如果你喜欢这期节目，请在 YouTube 点赞订阅，或者更好的是，留言告诉我们你的想法。你也可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上找到我们。欢迎留下评分和评论，帮助更多人发现这个节目。访问 howiipod.com 可以看到所有剧集并了解更多信息。下期再见。