GPT Pilot——一款可编写 95% 编码任务的开发工具

可扩展开发工具的 MVP，可在开发人员监督实施的同时从头编写可用于生产的应用程序

在这篇博文中，我将解释GPT Pilot背后的技术- 这是一个使用 GPT-4 编写整个可投入生产的应用程序的开发工具。

主要前提是人工智能现在可以为应用程序编写大部分代码，甚至 95%。

听起来很棒，对吧？

嗯，除非所有代码都能正常工作，否则应用程序就无法运行。那么，如何做到这一点呢？这篇文章是我研究项目的一部分，旨在探究人工智能是否真的能完成开发人员 95% 的编码任务。我决定使用 GPT-4 开发一个工具，在开发人员的监督下编写可扩展的应用程序。

我将向您展示 GPT Pilot 背后的主要思想、它所基于的关键概念以及直到编码部分的工作流程。

目前，它还处于早期阶段，只能创建简单的 Web 应用。不过，我将全面介绍它如何大规模运行，并演示在开发人员作为技术主管监督整个开发过程的情况下，AI 可以完成多少编码任务。

以下是我使用它创建的一些示例应用程序：

1. 实时聊天应用

2. Markdown 编辑器

3. 计时器应用

好的，让我们开始吧。

GPT Pilot 如何工作？

首先，您需要输入要构建的应用程序的描述。然后，GPT Pilot 会与法学硕士（目前为 GPT-4）合作，明确应用程序的要求，最后编写代码。它使用许多模拟开发机构工作流程的 AI 代理。

1. 在您描述应用程序之后， 产品负责人代理 会分解业务规范并向您提问以澄清任何不清楚的区域。

2. 然后， 软件架构师代理 分解技术要求并列出将用于构建应用程序的技术。

3. 然后，  DevOps Agent 根据架构在机器上设置环境。

4. 然后， 技术团队首席代理 将应用程序开发过程分解为开发任务，每个任务需要具备以下条件：

   • 任务描述 （这是开发人员代理稍后创建代码的主要描述）
   •   需要编写的自动化测试描述，以便 GPT Pilot 能够遵循 TDD 原则
   •  人工验证的描述，这基本上就是您（人类开发人员）如何检查任务是否成功执行

5. 最后， 开发人员 和 Code Monkey 代理逐一完成任务，开始编写应用程序。开发人员将每个任务分解成更小的步骤，这些步骤是较低级别的技术要求，可能不需要人工审核或自动化测试（例如，安装某些软件包）。

在下一篇博文中，我将更详细地介绍开发人员和 Code Monkey 的工作原理（这里有一个展示编码工作流程的预览图 ），但现在，让我们看看 GPT Pilot 构建的主要支柱。

GPT 试点项目的三大支柱

我之所以称之为“支柱”，是因为这是一个研究项目，我希望在开发 GPT Pilot 的过程中能够时刻牢记这些支柱。我希望探索人工智能在提升开发者生产力方面所能发挥的最大作用，因此我所做的所有改进都必须以这个目标为导向，而不是创造出一些只能编写简单、功能齐全的应用程序，却无法大规模运行的东西。

支柱1：开发人员需要参与应用程序的创建过程

正如我上面提到的，我认为我们距离一个只需连接到命令行界面 (CLI) 就能独立开发任何应用程序的 LLM 还很遥远。尽管如此，GPT-4 在编写代码时表现惊人。我一直使用 ChatGPT 来加快我的开发进程——尤其是在我需要研究某些新技术或 API，或者需要创建独立脚本的时候。几个月前，我第一次意识到它的强大，当时我用 ChatGPT 只花了 2 个小时就创建了一个 Redis 代理，而从头开发通常需要 20 个小时。我 在这里写了一篇完整的文章来介绍它。

因此，为了让 AI 能够生成功能齐全的应用程序，我们需要让它与负责监督开发流程并担任技术团队负责人的开发者紧密合作，而 AI 则负责编写大部分代码。因此，开发者需要能够随时更改代码，而 GPT Pilot 需要能够持续处理这些更改（例如，添加 API 密钥或修复 AI 卡住的问题）。

以下是开发人员可以干预开发过程的领域：

• 每个开发任务完成后，开发人员应该对其进行检查并确保其按预期工作（这是您通常提交最新更改的时间点）

• 每次测试或命令运行失败后 - 开发人员可能会更容易调试某些东西（例如，如果您的机器上的某个端口被保留，但生成的应用程序正在尝试使用它 - 那么您需要对其他端口进行硬编码）

• 如果 AI 无法访问外部服务 - 例如，你需要获取 API 密钥并将其添加到环境中

支柱2：应用程序需要逐步编写代码

假设你想创建一个简单的应用，并且你已经了解了编写代码所需的一切，并且整个架构都已在脑海中构思好。即便如此， 你也不会先把代码全部写出来，然后第一次运行它并 一次性调试所有问题。相反， 你会把应用开发拆分成更小的任务，先实现一个任务（比如添加路由），运行它，调试它，然后再进行下一个任务。这样，你就可以随时解决问题。

AI 编码时的情况也应该如此。

和人类一样，AI 肯定会犯错。因此，为了方便调试，也为了让开发者理解生成的代码，AI 不应该一次性输出完整的代码库。相反，它应该像开发者一样，一步一步地生成和调试应用，例如设置路由、添加数据库连接等等。

其他代码生成器，例如 Smol Developer 和 GPT Engineer，其工作方式是，你编写一个关于想要构建的应用程序的提示，它们会尝试编写整个应用程序的代码，并一次性提供完整的代码库。虽然人工智能很棒，但距离第一次尝试就能编写出一个完全正常运行的应用程序还很遥远，因此这些工具提供的代码库非常难以理解，更重要的是，调试起来也极其困难。

我认为， 如果 GPT Pilot 逐步创建应用程序，那么 AI 和监督它的开发人员都将能够更轻松地解决问题，并且整个开发过程将更加顺畅。

支柱3：GPT Pilot 需要具备可扩展性

GPT Pilot 必须能够创建大型生产就绪的应用程序，而不仅仅是那些整个代码库都能融入 LLM 环境的小型应用程序。问题在于，LLM 的所有学习都是在特定环境中进行的。也许有一天，LLM 可以针对每个具体项目进行微调，但目前看来，这将是一个非常缓慢且冗余的过程。

GPT Pilot 解决这个问题的方法是使用 上下文回放、递归对话和 TDD。

上下文回溯

上下文回溯背后的理念相对简单—— 在解决每个开发任务时，发送给 LLM 的第一条消息的上下文大小必须相对相同。例如，在执行开发任务 #5 时，第一条 LLM 消息的上下文大小必须与开发任务 #50 时的第一条消息大致相同。因此，在执行每个任务时，对话都需要回溯到第一条消息。

为了让 GPT Pilot 以相同的方式解决任务＃5 和＃50，它必须了解迄今为止已编码的内容以及当前编写的所有代码背后的业务环境，以便它可以仅为当前正在解决的任务创建新代码，而不是重写整个应用程序。

我将在下一篇博文中深入探讨这个概念，但本质上，当 GPT Pilot 创建代码时，它会 为其编写的每个代码块生成伪代码 ，并为 需要创建的每个文件和文件夹生成描述 。因此，当我们需要执行每个任务时，我们会在单独的对话中向 LLM 显示当前的文件夹/文件结构；它只会选择与当前任务相关的代码，然后，我们只会将这些代码添加到将编写任务实际实现的原始对话中。

递归对话

递归对话是指与 LLM 的对话，其设置方式使其可以“递归”使用。例如，如果 GPT Pilot 检测到错误，它需要对其进行调试，但假设在调试过程中又发生了另一个错误。那么，GPT Pilot 需要停止调试第一个问题，修复第二个问题，然后再返回修复第一个问题。我认为，这是一个至关重要的概念，需要努力让 AI 构建大型且可扩展的应用程序。它的工作原理是回溯上下文，并分别解释递归中的每个错误。一旦最深层的错误得到修复，我们就会继续向上递归，继续修复错误，直到整个递归完成。

TDD（测试驱动开发）

为了扩展代码库、改进代码库、更改需求并添加新功能，GPT Pilot 需要能够在不破坏现有代码的情况下创建新代码。没有比使用 TDD 方法更好的方法了。对于 GPT Pilot 编写的所有代码，都需要编写测试来检查代码是否按预期运行，以便每当进行新的更改时，都可以运行所有回归测试来检查是否存在任何中断。

我将在下一篇博文中更深入地探讨这三个概念，并在其中分解 GPT Pilot 的整个开发过程。

下一步

在第一篇博文中，我概述了 GPT Pilot 的工作原理。在第二篇和第三篇博文中，我将向您展示：

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

• 递归对话 和 上下文回放 实际上如何 发挥作用。

• 我们如何才能回溯应用程序开发过程并从任何开发步骤恢复它。

• 所有代理是如何构成的——您可能已经注意到，有 GPT Pilot 代理，有些现在可能是多余的，但我认为这些代理会随着时间的推移而发展，所以我想以模块化的方式构建代理，就像常规代码一样。

但在等待期间，请前往 GitHub，克隆GPT Pilot 代码库，并进行实验。如果成功，请告诉我。同时，别忘了为该代码库点赞——这对我来说意义重大。

感谢您的阅读🙏，我们下篇文章再见！

如果您有任何反馈或想法，请在评论中告诉我或发送电子邮件至zvonimir@pythagora.ai，如果您想在下一篇博客文章发布时收到通知，您可以 在此处添加您的电子邮件。