GPT Pilot - 一款可完成 95% 编码任务的开发工具 [第 2/3 部分 - 编码工作流程]

GenAI LIVE! | 2025年6月4日

这是由三部分组成的系列博文的第二篇，我将在其中介绍我们是如何创建GPT Pilot 的——这是一款旨在大规模运行并在开发人员的帮助下构建可投入生产的应用程序的 AI 编码代理。在本系列的第一部分中，我概述了 GPT Pilot。我们的想法是，AI 现在可以完成我们开发人员 95% 的编码工作。您可以看看我如何使用 ChatGPT 在 2 小时内编写出一个完整的 Redis 代理，而这通常需要开发人员 20-30 个小时。然而，如果应用程序不能完全运行或解决用户的问题，它就毫无用处。因此，在真正的通用人工智能 (AGI) 到来之前，您需要一名开发人员。

GPT Pilot 就是这样诞生的。它旨在完成 95% 的必需编码，并要求开发人员进行审核，例如当它卡住无法继续运行，或者需要应用程序外部的东西（例如 API 密钥）时。

在这篇文章中，我将带您了解 GPT Pilot 编写应用程序的整个过程。我分享了一些图表，以便直观地展示 GPT Pilot 幕后发生的一切。我是一个注重视觉的人，所以我总是创建图表。为了理解 GPT Pilot 的编码工作原理，需要了解三个概念：上下文回放、递归对话和 TDD。请参阅我在本系列第一部分中对这些概念的介绍。

GPT Pilot 编码工作流程包含 8 个步骤：

1. 按照计划完成下一个开发任务

2. 将任务分解为开发步骤

3. 迈出下一步发展步伐

4. 获取当前实现的代码

5. 为当前步骤编写代码

6. 运行代码或命令

7. 测试新的代码更改

8. 调试开发步骤或进入下一步

编码工作流程是 GPT Pilot 中我最喜欢的部分，所以让我们深入了解一下。以下是它的视觉示意图：

#1 任务分解

这篇博文将会提到两个重要概念——开发任务和开发步骤。

GPT Pilot 的工作方式是，在分解应用程序开发规范后，它会创建开发任务，最终完成一个功能齐全的应用程序。开发任务本质上是对开发人员需要完成并开始实施的工作的高级描述。可以将它们想象成 Jira 中的任务（顺便说一句，我讨厌 Jira……不知道是否有人有同感，但我只是想把它从我的系统中清除出去）。以下是一个开发任务的示例：

在上图中，您可以看到 3 个任务属性：

• 描述：完成这项任务需要实现什么

• 用户评审目标：首席开发人员如何确定当前任务是否完成？GPT Pilot 的一个重要支柱是开发人员必须参与整个编码过程，以确保开发过程按计划进行，并在此过程中了解代码库。

• programmatic_goal：GPT Pilot 应该编写的自动化测试类型，用于测试整个开发任务是否按预期运行。在开发步骤之后，GPT Pilot 会编写单元测试；在开发任务之后，它会编写集成测试或端到端测试。 

现在，当您开始在 Jira 中开发一项任务（开发任务）时，您会将其拆分成更小的块（我们称之为开发步骤），这些块是您可以在代码库中实施的可操作项目。每个开发步骤可以是以下之一：

1. 命令运行——需要在机器上运行的命令，例如安装依赖项的命令、启动应用程序以检查先前实施的步骤是否有效或创建文件夹的命令。

2. 代码变更——最重要的开发步骤，它解释了为了完成当前步骤，实际代码中究竟需要实现哪些功能。它可以包含需要编写的新代码，也可以包含需要更改的代码。其工作原理是，代码变更是对需要实现内容的详细、易读的描述。它既包含需要实现的代码，也包含其用途的描述。这与您要求 ChatGPT 编写代码时非常相似。它会提供代码以及编写该代码的原因说明。

   • 原因在于代码实现并非如此简单。有时，我们需要在现有代码中添加代码片段或更改现有实现。因此，我们将代码变更的概要（此开发任务）与 CodeMonkey 代理专用的变更实际实现分开。我将在“#3 编码”部分深入探讨这一点。以下是代码变更的示例：

3. 人工干预——AI 无法独立完成的开发步骤，需要人工协助才能完成。然后，GPT Pilot 会要求开发人员执行某些操作，完成后，他们会输入“继续”，GPT Pilot 将继续执行。以下是可能需要人工干预的一些原因：

• 需要 API 密钥（例如，Twitter API 密钥用于从 Twitter 获取数据）

• GPT Pilot 在调试过程中陷入了困境，它要么填满了整个上下文长度，要么递归对话太深而无法继续进行递归深度。

• GPT Pilot 需要验证某些功能是否按预期工作 - 例如，GPT Pilot 不确定 Mongo 是否在机器上正确安装，可能会要求开发人员运行一些 sudo 命令并查看它是否按预期工作。

#2 获取当前实现的代码

AI 很容易编写一个包含代码的新文件，但实际上这种情况很少发生。大多数情况下，我们会写入现有文件，然后更改现有代码或添加新代码。现在，如果您提供所有现有代码以及需要实现的指令，AI 可以轻松完成此操作。当应用程序扩展并且代码库变得非常庞大以至于无法放入 LLM 上下文时，就会出现问题。这实际上是一种非常常见的情况——至少在我们拥有拥有 100 万个令牌的 LLM 之前是这样，但这似乎不会很快实现。

当您在大型代码库中执行任务时，您通常会查看代码库的较小部分（可能是 1,000 行）并仅使用该代码子集来实现该任务。

因此，为了解决这个问题，并使 GPT Pilot 真正具备可扩展性，使其能够创建和升级大型生产就绪代码库，我们必须创建一种方法，让 AI 能够选择代码库中较小的部分（例如，那 1000 行代码）来执行当前任务。完成后，我们可以简单地将完成的代码行添加回原始代码库。首先，让我解释一下 GPT Pilot 在编写代码并创建新文件和文件夹时会发生什么。对于它必须创建的每个文件和文件夹，它都需要编写一个描述，说明它想要创建的文件或文件夹背后的想法。例如，它可能想要创建一个文件夹 utils，它将在其中写入：

Contains utility modules that provide generic, reusable solutions to common problems encountered throughout the application.
These utilities are not specific to the app's core domain but offer auxiliary functionality to support and streamline the primary codebase.
They encapsulate best practices, reduce code repetition, and make the overall code cleaner and easier to maintain. Examples include functions for data formatting, error handling, debugging tools, string manipulation, data validation, and other shared operations that don't fit within specific modules or components of the app.

现在，对于 GPT Pilot 创建的每个函数，它都会编写一个关于该函数应该做什么的描述——这是整个代码库的伪代码。

现在您知道了 GPT Pilot 编写代码时发生的情况，您就可以了解它如何获取每个开发步骤的相关代码。

GPT Pilot 在编写每个步骤之前，首先会在一个完全独立的 LLM 对话中获取代码库的相关部分。该对话分为 3 个步骤进行设置。

1. AI 会获得开发步骤描述、整个项目文件/文件夹结构以及每个文件和文件夹的描述。LLM 由此告诉我们哪些文件与上述步骤相关。

2. 缩小必要文件范围后，我们为其列出的每个文件提供 LLM 伪代码，并要求它告诉我们哪些功能与当前开发步骤相关。

3. 一旦我们知道了它选择的伪代码，我们就可以获取实际代码并将其放入原始对话中，LLM 将在其中写下需要实现的内容的描述。

如果应用程序变得非常庞大，我们可以改进这一点，首先将文件夹提供给 LLM，它会从中选择文件夹，然后再提供相关文件。在执行每个步骤之前，我们还可以将对话回溯到开头，以便在上下文中留出更多空间。

以下是其外观的图表：

#3 编码

现在，我们可以创建一个包含执行特定任务所需的所有代码的 LLM 消息，然后就可以开始实际的编码过程了。这个过程分为两个部分：

1. 首先，LLM 会将需要实现的内容描述与代码一起写入。如果需要编写整个文件，LLM 的响应将包含所有代码；但如果只需要更改文件中的部分代码，LLM 会告诉我们类似“在 Mongo 设置完成后，添加以下几行代码……”之类的信息。可以想象，由于这是随机的而非确定性的，我们需要确保编写的代码被插入到适当的位置或被正确更改。

这时，CodeMonkey代理就派上用场了。它之所以被称为“代码猴子”，是因为它不做任何决策，而只是简单地执行开发者代理编写的代码。它会接收与当前任务相关的代码（这些代码先前由 LLM 在代码获取阶段选定）以及开发者代理在开发步骤 1 中创建的描述。之后，它唯一需要返回的就是完整的代码段/文件，我们可以直接在代码库中插入/替换它们。

#4 测试

测试在两个地方进行：（1）在每个开发任务之后，GPT Pilot 创建集成测试来测试高级功能是否按预期工作；（2）在每个开发步骤之后，创建较小的单元测试来确保所有功能都按预期工作。

GPT Pilot 可以进行 3 种不同类型的测试：

1. 自动化测试是测试步骤或任务的首选方法，因为它们将用于回归测试套件，以便 GPT Pilot 能够确保新的代码更改不会破坏旧功能。然而，自动化测试并非总是测试新代码的最佳方法。

2. 命令运行是一种测试，我们运行一个特定的命令，并将输出传递给 LLM，然后 LLM 会告诉我们执行是否成功。例如，我们不需要创建一个自动化测试来检查我们是否可以使用 npm run start 运行应用程序——对于这种情况，一个简单的命令运行就足以检查我们是否成功设置了环境。

3. 人工干预是测试应用程序的最终方法，当人工智能无法自行测试实现时，就需要人工干预。例如，当需要检查某些视觉方面（例如 CSS 动画）是否正常工作时，就需要人工干预。

每次运行测试后，如果成功，GPT Pilot 就会承担下一个任务或步骤并继续编码，但当测试失败时，GPT Pilot 需要调试错误。

#5 调试

调试过程需要非常健壮，以便无论错误是什么，都能在出现任何 bug 时启动。它还需要能够调试调试过程中发生的任何问题。这就是递归对话的用武之地，它与 LLM 的对话以“递归”的方式建立。

让我们看下图中的示例。它代表了 GPT Pilot 在执行包含 5 个开发步骤的开发任务时所经历的流程。在此示例中，在执行步骤 3 的开发过程中，发生了错误——假设它实现了特定的代码更改，但在运行测试后失败了。然后，它进入递归级别 1 来调试此问题。它将修复此问题所需的操作分解为 2 个步骤，但在执行第一步时，又发生了另一个错误。例如，修复错误 1 ​​所需的依赖项不存在。然后，GPT Pilot 进入递归级别 2，并将其分解为 3 个步骤。在第三步中，又发生了一个错误。然后，它进入只有 1 个步骤的第三递归级别。成功执行该步骤后，GPT Pilot 返回递归级别 2 并完成错误 2 的调试。之后，它会返回到调试错误 #1，最后，在修复错误 #1 之后，它会返回到开发步骤 #3，然后继续应用程序的实施。

当递归深度达到 5 级时，GPT Pilot 将停止调试过程，并要求开发人员修复最初遇到的问题。开发人员解决此问题后，会将结果写入 GPT Pilot。然后，GPT Pilot 就可以继续开发过程，就像它自己调试了这个问题一样。

结论

在本系列的第一篇文章中，我讨论了 GPT Pilot 工作原理的概述。在这篇文章中，我描述了 GPT Pilot 的编码工作流程，包括：

• 开发人员和 CodeMonkey 代理如何协同工作来实现代码（编写新文件或更新现有文件），

• 递归对话和上下文回放如何在实践中发挥作用，以及

• 倒回应用程序开发过程并从任何开发步骤恢复它。

在最后一篇文章中，我将深入探讨所有代理的架构。我们采用模块化方式构建代理，因为我们知道它们会随着时间的推移而不断发展。请前往 GitHub，克隆GPT Pilot 代码库，进行实验，并向我发送您的反馈。我希望 GPT Pilot 能够尽可能地帮助开发者，所以请告诉我您的想法、改进方法或哪些方面做得不错。请在本文底部留言，或发送电子邮件至zvonimir@gpt-pilot.ai。

🌟🌟🌟
最后，我们正在努力筹集资金以继续开发 GPT Pilot，因此如果您能为 GPT Pilot Github 代码库点赞或分享给您的朋友，我们将不胜感激。谢谢
🙏🌟🌟🌟