00:00:00如果你一直关注这个频道,
00:00:01你一定熟悉我们介绍过的各种上下文工程工作流。而谷歌也发布了另一个。我希望能说它比其他工作流更好,
00:00:09但事实并非如此。这存在很多问题。即使你认为它更适合 Gemini 生态系统,
00:00:15它仍然不够好。在深入探讨为什么没必要发布这个之前,
00:00:19让我们快速休息一下,
00:00:20谈谈 Automata。在教了数百万人如何使用 AI 构建之后,
00:00:25我们开始自己实施这些工作流。我们发现我们可以比以往更快地构建更好的产品。我们帮助将你的想法变为现实,
00:00:33无论是应用程序还是网站。也许你看过我们的视频后想,
00:00:37我有一个很棒的想法,
00:00:38但我没有技术团队来构建它。这正是我们的用武之地。
00:00:42把我们想象成你的技术副驾驶。我们将教给数百万人的相同工作流直接应用到你的项目中,
00:00:48将概念转化为真正可用的解决方案,
00:00:50而无需承受招聘或管理开发团队的麻烦。准备好将你的想法加速变为现实了吗?请通过 hello@automata.dev 联系我们。
00:00:59现在,
00:01:00在我解释为什么这只是上下文工程工作流的又一次糟糕尝试之前,
00:01:04让我们先深入了解 Conductor 实际上是如何工作的。这是文章,
00:01:09我会在下面的描述中放上链接。最后,
00:01:11你会得到一个命令,
00:01:12可以在 Gemini CLI 中将其作为扩展安装。对于那些不知道的人来说,
00:01:18扩展是命令、
00:01:18MCP 和其他规则的集合,
00:01:20它们被打包在一起,
00:01:22制作成一个包,
00:01:23人们可以托管并与他人分享。Claude 也有类似的东西,
00:01:26叫做插件。所以要真正启动工作流,
00:01:29你使用命令进行安装。安装后,
00:01:31你可以在 Conductor 中使用它的斜杠命令。你会得到这五个实际控制 Conductor 以及如何使用工作流的命令。现在你要使用的第一个命令是设置命令。
00:01:41这个命令的作用是首先检查现有的 Conductor 文件,比如设置状态和其他告诉它项目是否已经初始化的文件是否可用。
00:01:51它不是创建故事,而是创建这些叫做轨道的文件,并逐个完成它们。
00:01:56之后,
00:01:57它初始化了一个新的 GitHub 仓库并询问要构建什么。为了测试它,
00:02:03我创建了一个简单的项目,
00:02:05但我确实想测试它制定的架构是否真的好。所以为了实际测试它是否会推荐我真正需要的东西,
00:02:12我告诉它应该是生产就绪的,
00:02:14并且可以扩展到更多用户。之后,
00:02:17它创建了 product.md 文件,
00:02:20其中包含了我想构建的实际概念。为了实际完善和制定它,
00:02:25它开始向我提问,
00:02:26最后,
00:02:27因为这些问题实际上没有任何进展,
00:02:29而且非常简单,
00:02:31我就让它自动生成了一切。在它批准并保存了产品指南后,
00:02:35它想创建另一个文件,
00:02:37即产品指南,
00:02:38主要关注产品的样式和一些设计原则。它也批准并保存了产品指南。之后,
00:02:44它定义了技术栈,
00:02:45这是工作流不好的原因之一。它搞乱了提供给我的技术栈,
00:02:49因为它知道我的整个项目,
00:02:52但仍然没有真正推荐合适的东西。在我纠正之后,
00:02:55它也批准了技术栈并更新了那个 MD 文件。它还有这些叫做代码风格指南的文件。如果我进入实际文件夹,
00:03:04这些是它拥有的唯一语言,
00:03:06如果它认为我们将在项目中使用其中任何一种,
00:03:10它会在初始化期间将它们添加到我们当前项目的代码风格指南中。它使用的默认工作流实际上相当不错。默认情况下,
00:03:19它包含 80% 的代码测试覆盖率,
00:03:22在设置和编写基础组件时,
00:03:24它确保测试也在编写,
00:03:26完成任务后也在测试它们。同时,
00:03:28它在每个任务后提交更改,
00:03:30并使用 git notes,
00:03:33这样我们就可以实际跟踪出错的地方或时间。完成初始设置后,
00:03:38它创建了一些高级产品需求,
00:03:40以便我们可以进入初始轨道。这是它试图实施的第一个轨道。
00:03:45同样,
00:03:45这太宽泛了,
00:03:46需要分解成更小的轨道。这在一个轨道中要做的太多了,
00:03:50如果同时做这么多,
00:03:51出错的可能性很大。所以完成后,
00:03:54你可以通过运行 implement 命令开始工作,
00:03:58在轨道文件夹中,
00:03:59你有不同的轨道,
00:04:00它会逐个实施。每个轨道有两个文件,
00:04:03一个 plan.md 和一个 spec.md。spec.md 包含目标以及从技术栈和我们在开始时输入的信息中提取的技术细节。plan.md 实际上包含了它需要逐个实施的任务。当你实际使用 implement 命令时,
00:04:19它会查看 tracks.md,
00:04:22基本上查看每个轨道,
00:04:23根据状态,
00:04:24它实际知道该做什么。所以如果是空的,
00:04:27就是没有开始。这意味着正在进行中,
00:04:29这意味着轨道已经完成。如你所见,
00:04:32当前这个轨道正在进行中。至于其他命令,
00:04:35status 命令会给你一个状态报告,
00:04:38告诉你当前正在进行什么,
00:04:40哪些轨道正在进行,
00:04:41哪些还没有完成。如果你使用 new track 命令,
00:04:45它会再次为新任务向你提出不同的问题。我还在一个预先存在的仓库中实施了它,
00:04:51过程基本相同。有点不同,
00:04:53因为它会查看现有文件,
00:04:54只是向我提出澄清问题,
00:04:56并没有要求新轨道。
00:04:57我不得不自己将新轨道作为新功能实施。然后还有 revert,
00:05:02另一个非常聪明的功能,
00:05:04实际上可以减轻任何损害,
00:05:06并且能感知 git。所以它使用 git 在代理在任何地方出错时提供帮助。现在,
00:05:12文件管理和结构还不算太糟。它将新功能或现有任务实施到轨道中,
00:05:17然后跟踪它们的方式实际上相当不错。但是指令的编写方式或这些命令文件的编写方式确实需要改进,
00:05:24因为它们并没有真正管理上下文循环,
00:05:27需要检查所有内容。如果有变化,
00:05:29那么它需要如何改变。因为即使在这个初始过程中,
00:05:33也有很多错误。第一个错误是,
00:05:35在请求创建每个文档时,
00:05:37它并没有真正正确剖析我的想法。我不得不在很多事情上指导它。当我认为足够时,
00:05:43我就让它自动生成其余内容。同样,
00:05:46正如我之前提到的,
00:05:47在定义技术栈时,
00:05:49它也遗漏了很多东西。选项 B 是好的。但由于我告诉它我想要一个完全可扩展的应用程序,
00:05:55可以支持大量用户,
00:05:57它遗漏了很多我不得不澄清并明确告诉它还需要的东西,
00:06:01然后它修改了计划。当生成初始轨道时,
00:06:04我实际上进去查看了它生成的计划和规格,
00:06:07数据库架构完全不完整。它遗漏了很多对设置应用程序至关重要的东西,
00:06:12我不得不再次指导它并将其引导到正确的方向。现在,
00:06:16Gemini 实际上是一个非常好的模型。所以我不得不怀疑是已实施的命令导致它以这种方式运行。
00:06:23我认为即使设置本身实际上是好的,
00:06:26但我不会使用它的最大原因是主斜杠命令存在很多问题,
00:06:30尤其是工作流程 MD 文件,
00:06:32因为在我告诉它我想更改 NPM 之后,
00:06:35它搞砸了很大一部分内容。相反,
00:06:37我想使用 PNPM,
00:06:38因为我之前忘记提到了。出于某种原因,
00:06:41它首先尝试进行备份。
00:06:43在执行备份时,
00:06:44它声明需要删除使用 NPM 创建的文件。但它最终删除了整个 conductor 文件夹本身,
00:06:51该文件夹包含了所有的规划文件。删除之后,
00:06:54它一直在寻找该文件夹。当找不到时,
00:06:57它说将使用其上下文和内存中的所有内容来重建 conductor 文件夹。
00:07:02所以基本上,
00:07:03它必须重写所有内容,
00:07:04而不是像正常的上下文工作流程那样,
00:07:07更改应该只影响主要的上下文文件和与该特定任务相关的文件,
00:07:11这就是 Be Mad 高效运作的方式。现在,
00:07:15如果我没有要求它突然更改某些内容,
00:07:17也许会进行得很顺利。但尽管如此,
00:07:20当它初始化所有任务时,
00:07:22我要求它开始实施第一个任务,
00:07:24它开始初始化项目和我需要的其他核心服务。现在,
00:07:27当涉及到为 Supabase 连接配置环境变量时,
00:07:31出于某种原因,
00:07:32它自动将任务标记为已完成,
00:07:34同时显然在其中放入了一个虚拟密钥。它甚至没有要求我设置 Supabase 项目或为它提供实际密钥。然后它自动尝试推送数据库架构。由于没有实际密钥,
00:07:45它失败了。然后它要求我仔细检查字符串。所以即使是任务也没有被正确更新,
00:07:51它并没有真正正确地遵循它们。老实说,
00:07:53我现在不会使用它进行端到端的规范开发。Be Mad 是一个更好的选择。对于小型项目,
00:08:00我仍然制作自己的上下文文件。这就是本视频的结尾。如果您想支持本频道并帮助我们继续制作这样的视频,
00:08:07可以使用下方的超级感谢按钮。一如既往,
00:08:10感谢观看,
00:08:11我们下期再见。