GPT Pilot - 编写 95% 代码的开发工具！

在这篇博客介绍了GPT-pilot的研发细节，原作者将探讨GPT Pilot的技术内核 —— 一款基于GPT-4编写的开发工具，可以生成生产使用代码的应用。

你有没有想过，95%的应用代码，可以由AI编写，就像《钢铁侠》里的贾维斯一样？

那么，如何实现这个目标呢？

我找到了基于GPT-4开发一个工具——GPT Pilot，能在开发人员的监督下编写出可扩展的应用。

我将向你展示GPT Pilot背后的主要思想，它所依赖的关键概念，以及到编码阶段的工作流程。

目前，GPT Pilot处于初级阶段，只能创建简单的Web应用。然而，我相信之后这将全面覆盖到各种领域。

GPT Pilot是如何工作的？

1、首先，你输入要构建的应用的描述。

然后，GPT Pilot配合LLM（目前为GPT-4）明确应用需求，并最终编写代码。它使用多种AI代理（AI Agents） 来模仿开发机构的工作流程。

在你描述应用后，产品负责人Agent会解析业务规范并向你提问以澄清任何不明确的地方。然后，软件架构师Agent会解析技术需求，并列出将用于构建应用的技术。然后，架构师Agent会根据架构在机器上设置环境。然后，技术团队Agent将应用开发过程分解为开发任务，每个任务需要具备：

任务的描述（这是开发人员代理稍后创建代码的主要描述）
需要编写的自动化测试的描述，以便GPT Pilot可以遵循TDD（测试驱动开发）原则
人类验证的描述，基本上就是你作为人类开发人员，如何检查任务是否成功实施

最后，程序员Agent会逐一接手任务，并开始为应用编写代码。开发者将每个任务分解为较小的步骤，这些是较低级别的技术要求，可能不需要人类审查或自动化测试（例如安装某个包）。

GPT Pilot的三大特点

开发者需要参与创建应用的过程

正如我之前提到的，我认为我们距离一个能通过CLI独立运行并创建任何应用的LLM还有很远的路要走。

然而，GPT-4在编写代码方面表现得出奇地好。我一直在使用ChatGPT来加快我的开发过程 - 特别是当我需要在新的技术上工作，或者需要创建一个独立的脚本时。

我第一次意识到它的强大是在几个月前，我用ChatGPT花了2小时创建了一个Redis代理，通常这会花费20小时从头开发。我在这篇文章中写了整个过程。因此，为了使AI能生成一个完全工作的应用，我们需要让它紧密地与开发者合作，开发者会监督整个开发过程，并充当技术团队的领导，而AI会写大部分的代码。因此，开发人员需要能在任何时候修改代码，而GPT Pilot需要继续使用这些更改（例如添加API密钥或在AI卡住的情况下修复问题）。

以下是发展者可以参与到开发过程中的地方：

每个开发任务完成后，开发人员应该审查它，确保它按预期工作（这是你通常会提交最新更改的时刻）
在每个失败的测试后或者运行的命令后，可能对开发者来说更容易进行调试（例如，如果你的机器上的一个端口被保留，但生成的应用试图使用它，则你需要硬编码另一个端口）
如果AI没有访问外部服务的权限 - 例如，你可能需要从环境中获取并添加API密钥

应用需要分步编码

假设你想创建一个简单的应用，你知道所有你需要编写的内容，并且在你的头脑中存有整个架构。即使在这种情况下，你也不会完全地编写、同时运行和一次性调试所有问题。相反，你会把应用开发分解为更小的任务，执行其中一个（如添加路由），运行它，调试，然后再进行下一个任务。这样，你可以随着问题的出现解决问题。 AI编写代码的情况也应该是这样。

正如人类一样，它肯定会犯错误，因此为了让它方便地进行调试，并且让开发人员理解生成代码中发生了什么，AI不应该一口气吐出整个代码库。相反，应该像开发人员一样，逐步生成和调试应用 - 例如设置路由，添加数据库连接等等。

其他的代码生成器，如Smol Developer和GPT Engineer，工作方式是你写一个关于你想要构建的应用的提示，他们将尝试编写出整个应用，一次性给你整个代码库。

虽然AI很强大，但离一次尝试就能编写出完全工作的应用还很远，所以这些工具给你的代码库是非常难以理解的，更重要的是，要进行调试无比困难。我认为，GPT Pilot如果能逐步创建应用，那么AI和监督它的开发人员将能够更容易地修复问题，整个开发过程将流畅得多。

GPT Pilot需要能进行扩展

GPT Pilot必须能创建大型生产可用的应用，而不仅限于小型应用，其中整个代码库可以装入LLM的上下文中。问题在于，LLM的所有学习都是在上下文中进行的。

或许有一天，LLM可以针对每个具体的项目进行微调，但是现在，这看起来像是一个非常缓慢和多余的过程。 GPT Pilot通过上下文回溯，递归对话和TDD来解决这个问题。

上下文回溯上下文回溯背后的思想相对简单 - 对于解决每个开发任务，第一条消息到LLM的上下文大小必须相对一样。例如，在实现开发任务＃5时，第一条LLM消息的上下文大小必须和任务＃50的第一条消息的上下文大小大体相同。因此，每个任务完成后，需要回溯到第一条消息。

对于GPT Pilot来说，要任务＃5和＃50相同，它必须理解到目前为止的代码，以及所有已编写代码背后的业务上下文，这样，它才能创建针对当前任务的新代码，而不是重写整个应用。但本质上，当GPT Pilot创建代码时，它会为它编写的每个代码块制作伪代码，以及创建的每个文件和文件夹的描述。所以，当我们需要实现每个任务的时候，在一个单独的对话中，我们向LLM展示最新的文件夹/文件结构，它只选择与当前任务相关的代码，然后，我们将只添加该代码到有同样任务需要的实际执行任务的原始对话。

GPT Pilot - 递归对话递归对话是用LLM设置起来的对话，它们是递归使用的方式。例如，如果GPT Pilot检测到一个错误，它需要调试它，但让我们设想在调试过程中出现了另一个错误。那么，GPT Pilot需要先停止调试第一个问题，解决第二个问题，然后回来继续修复第一个问题。对我来说，这是一个重要的概念，我相信，它们需要像这样工作才能使AI构建大型和可扩展的应用。通过回溯上下文和分别说明每个错误，一旦完成最深层的错误修复，我们就会上升在递归中，继续修复错误，直到整个递归都完成。

测试驱动开发（TDD）为了让GPT Pilot扩展代码库，提高质量，改变需求，并添加新功能，它需要能够在不破坏之前编写的代码的前提下生成新代码。达到这个目标的最好方法就是遵循TDD方法。对于GPT Pilot编写的所有代码，它都需要编写测试，检查代码是否按照预期工作，以便每次进行新的更改时，可以运行所有回归测试以检查是否出现任何破坏。