GPT Pilot：自动生成生产级代码的AI工具

在这篇博客中，我将介绍 GPT Pilot 背后的技术。GPT Pilot 是一款使用 GPT-4 编写完整、可用于生产环境的应用的开发工具。

它的核心前提是：如今，AI 已经可以编写一款应用的大部分代码，甚至能达到 95%。

听起来很棒，对吧？

但问题是，只有所有代码都能完整运行，应用才能真正工作。那么，怎样才能做到这一点？这篇文章是我的研究项目的一部分，目的是验证 AI 是否真的能够完成开发者 95% 的编码任务。为此，我决定使用 GPT-4 开发一款工具，让它在开发者的监督下编写可扩展的应用。

我会介绍 GPT Pilot 背后的核心思路、构建它所依赖的关键概念，以及进入编码阶段之前的工作流程。

目前，它还处于早期阶段，只能创建简单的 Web 应用。不过，我仍会完整介绍它如何实现规模化工作的整体构想，并展示当开发者作为 Tech Lead 监督整个开发流程时，AI 究竟能够完成多少编码任务。

下面是我使用它创建的一些示例应用：

GPT Pilot 是如何工作的？

首先，你需要输入想要构建的应用描述。接下来，GPT Pilot 会与一个 LLM（目前是 GPT-4）协作，澄清应用需求，最后编写代码。它使用了多个 AI Agent，模拟一家开发公司的工作流程。

在你描述完应用后，Product Owner Agent 会拆解业务规格，并针对任何不明确之处向你提问。

在你描述完应用后，Product Owner Agent 会拆解业务规格，并针对任何不明确之处向你提问。

接下来，Software Architect Agent 会拆解技术需求，并列出构建应用时将使用的技术。

接下来，Software Architect Agent 会拆解技术需求，并列出构建应用时将使用的技术。

然后，DevOps Agent 会根据架构，在机器上搭建运行环境。

然后，DevOps Agent 会根据架构，在机器上搭建运行环境。

接着，Tech Team Lead Agent 会把应用开发流程拆分成多个开发任务。每项任务都需要包含：任务描述（这是 Developer Agent 随后创建代码时所依据的主要描述）；需要编写的自动化测试描述，以便 GPT Pilot 遵循 TDD 原则；人工验证说明，也就是作为人类开发者的你，应当如何检查任务是否成功实现。

接着，Tech Team Lead Agent 会把应用开发流程拆分成多个开发任务，每项任务都需要包含：

任务描述（这是 Developer Agent 随后创建代码时所依据的主要描述）

需要编写的自动化测试描述，以便 GPT Pilot 遵循 TDD 原则

人工验证说明，也就是作为人类开发者的你，应当如何检查任务是否成功实现

最后，Developer Agent 和 Code Monkey Agent 会逐个领取任务，开始为应用编写代码。Developer 会把每项任务进一步拆分成更小的步骤。这些步骤属于更底层的技术需求，可能不需要人工审查，也不需要通过自动化测试验证，例如安装某个 package。

最后，Developer Agent 和 Code Monkey Agent 会逐个领取任务，开始为应用编写代码。Developer 会把每项任务进一步拆分成更小的步骤。这些步骤属于更底层的技术需求，可能不需要人工审查，也不需要通过自动化测试验证，例如安装某个 package。

在下一篇博客中，我会更详细地介绍 Developer 和 Code Monkey 的工作方式（这里先放一张展示编码工作流的预览图）。不过现在，我们先来看看 GPT Pilot 构建于哪些核心支柱之上。

GPT Pilot 的三大支柱

我把它们称为“支柱”，是因为 GPT Pilot 本身是一个研究项目，我希望在开发过程中始终提醒自己牢记这些原则。我的目标是探索 AI 在提升开发者生产力方面究竟能做到什么程度，因此，我做出的所有改进都必须服务于这个目标，而不是只造出一个能编写简单、可完整运行的应用，却无法规模化工作的工具。

正如前面提到的，我认为距离这样一种 LLM 仍然很遥远：只需要把它接入 CLI，它就能完全独立地创建任何应用。尽管如此，GPT-4 在编写代码方面的表现依然惊人。我一直在使用 ChatGPT 加速开发流程，尤其是在需要使用某项新技术、某个 API，或者需要创建一个独立脚本时。几个月前，我第一次真正意识到它有多强大：借助 ChatGPT，我只用了 2 小时就创建出一个 Redis proxy，而从零开始开发同样的东西通常需要 20 小时。我还专门写了一篇完整的文章介绍这件事。

因此，要让 AI 生成一个可以完整运行的应用，我们需要让它与监督开发流程的开发者密切协作。开发者扮演 Tech Team Lead 的角色，而 AI 负责编写大部分代码。开发者必须能够随时修改代码，而 GPT Pilot 也必须能够基于这些修改继续工作，例如添加 API key，或者在 AI 卡住时修复问题。

下面这些环节允许开发者介入开发流程：

每项开发任务完成后，开发者都应该进行审查，确保它能够按预期工作（通常，你会在这个节点提交最新的改动）

每项开发任务完成后，开发者都应该进行审查，确保它能够按预期工作（通常，你会在这个节点提交最新的改动）

每当测试或命令运行失败后，都可以由开发者介入，因为有些问题由开发者调试起来可能更容易。例如，你机器上的某个端口已经被占用，但生成的应用却试图使用它，这时就需要硬编码另一个端口

每当测试或命令运行失败后，都可以由开发者介入，因为有些问题由开发者调试起来可能更容易。例如，你机器上的某个端口已经被占用，但生成的应用却试图使用它，这时就需要硬编码另一个端口

当 AI 无法访问某个外部服务时，例如需要获取一个 API key，并把它添加到运行环境中

当 AI 无法访问某个外部服务时，例如需要获取一个 API key，并把它添加到运行环境中

假设你想创建一个简单的应用，并且清楚需要编写的所有代码，整个架构也已经装在脑子里。即便如此，你也不会先把所有代码一口气写完，然后第一次运行应用，再集中调试所有问题。相反，你会把应用开发拆分成多个较小的任务，先实现其中一个任务，比如添加 routes，然后运行、调试，再继续处理下一个任务。这样一来，你就能在问题出现时及时修复。

当 AI 编写代码时，也应该采用同样的方式。

和人类一样，AI 肯定也会犯错。因此，为了降低它的调试难度，同时让开发者理解生成的代码究竟发生了什么，AI 不应该一次性吐出整个 codebase。相反，应用应该像开发者亲自开发时一样，按步骤生成和调试，例如先设置 routes，再添加数据库连接，依此类推。

Smol Developer 和 GPT Engineer 等其他代码生成工具的工作方式是：你先通过 prompt 描述想要构建的应用，它们尝试一次性写完整个应用，然后直接把整个 codebase 交给你。虽然 AI 很强大，但距离第一次尝试就写出一个完全可用的应用仍然很遥远。因此，这些工具交付的 codebase 往往很难上手，更重要的是，调试难度会高出无数倍。

我认为，如果 GPT Pilot 能够一步步创建应用，那么无论是 AI，还是负责监督它的开发者，都能更轻松地修复问题，整个开发流程也会顺畅得多。

GPT Pilot 必须能够创建大型、可用于生产环境的应用，而不能仅限于那些整个 codebase 都能塞进 LLM context 的小型应用。问题在于，LLM 的所有学习都是在 context 内完成的。或许有一天，我们可以针对每个具体项目对 LLM 进行 fine-tune，但就目前而言，这似乎会是一个非常缓慢且重复冗余的过程。

GPT Pilot 通过 context rewinding、recursive conversations 和 TDD 来解决这个问题。

context rewinding 背后的思路相对简单：在解决每一项开发任务时，发送给 LLM 的第一条消息，其 context size 都必须大致相同。例如，实现开发任务 #5 时，发送给 LLM 的第一条消息所占用的 context size，应当与开发任务 #50 的第一条消息基本一致。正因为如此，每次开始处理新任务时，都需要把 conversation 回退到第一条消息。

为了让 GPT Pilot 以相同的方式解决任务 #5 和任务 #50，它必须理解到目前为止已经编写了哪些代码，以及当前所有代码背后的业务背景。只有这样，它才能仅针对当前正在解决的任务创建新代码，而不是重写整个应用。

我会在下一篇博客中深入介绍这个概念。简单来说，GPT Pilot 在创建代码时，会为写出的每个 code block 生成 pseudocode，同时也会为需要创建的每个文件和文件夹生成描述。因此，当我们需要实现某项任务时，会在一个独立的 conversation 中向 LLM 展示当前的文件夹与文件结构；LLM 只选择与当前任务相关的代码，然后我们仅把这些代码添加到最初那个负责完成任务实际实现的 conversation 中。

recursive conversations 指的是以一种可以“递归”使用的方式组织与 LLM 之间的 conversation。例如，GPT Pilot 检测到一个错误后，需要对它进行调试；但假设在调试过程中又出现了另一个错误，那么 GPT Pilot 就需要暂停调试第一个问题，先修复第二个问题，然后再回来继续修复第一个问题。我认为，这是让 AI 能够构建大型、可扩展应用时必须实现的一个关键概念。其工作方式是回退 context，并分别解释递归过程中的每一个错误。最深层级的错误修复后，我们再沿着递归层级向上返回，继续修复其他错误，直到整个递归过程完成。

为了让 GPT Pilot 能够扩展 codebase、改进代码、变更需求和添加新功能，它必须能够创建新代码，同时不破坏之前已经编写的代码。要做到这一点，没有比采用 TDD 方法更好的方式了。对于 GPT Pilot 编写的所有代码，它都需要编写相应的测试，检查代码是否按预期工作。这样，每当做出新的改动时，就能运行所有 regression tests，确认是否有任何功能被破坏。

我会在下一篇博客中深入介绍这三个概念，并拆解 GPT Pilot 的整个开发流程。

在第一篇博客中，我介绍了 GPT Pilot 工作方式的高层概览。在第 2 篇和第 3 篇中，我会向你展示：

Developer Agent 和 Code Monkey Agent 如何协作实现代码，包括编写新文件或更新现有文件。

Developer Agent 和 Code Monkey Agent 如何协作实现代码，包括编写新文件或更新现有文件。

recursive conversations 和 context rewinding 在实际场景中如何工作。

recursive conversations 和 context rewinding 在实际场景中如何工作。

如何回退应用开发流程，并从任意一个开发步骤恢复。

如何回退应用开发流程，并从任意一个开发步骤恢复。

所有 Agent 是如何组织的——你可能已经注意到，GPT Pilot 中包含多个 Agent，其中一些 Agent 目前可能显得有些多余，但我认为它们会随着时间不断演进。因此，我希望像组织普通代码一样，以模块化的方式构建这些 Agent。

所有 Agent 是如何组织的——你可能已经注意到，GPT Pilot 中包含多个 Agent，其中一些 Agent 目前可能显得有些多余，但我认为它们会随着时间不断演进。因此，我希望像组织普通代码一样，以模块化的方式构建这些 Agent。

不过，在等待后续文章期间，不妨前往 GitHub，clone GPT Pilot repository 并亲自试一试。如果你成功运行了它，请告诉我。既然已经到了那里，也别忘了给 repo 点一颗 star——这对我来说意义重大。

感谢阅读 🙏，下一篇文章见！

如果你有任何反馈或想法，请在评论区告诉我，或者发送邮件至 zvonimir@pythagora.ai。如果你希望在下一篇博客发布时收到通知，可以在这里留下你的电子邮箱。

部分评论已被文章作者隐藏——了解更多

如果需要采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。