PS：本项目的后继者是 smol-dev-js：https://github.com/PicoCreator/smol-dev-js

The English Compiler

你只需要英语

我们知道，所有伟大的™项目都始于一份出色的™详细功能规格说明。
这份说明通常是用英语或其众多其他口语替代语言编写的。

那么，如果我们不根据功能规格说明来编写代码，而是直接将其编译成代码，会怎样呢？

迈向一个未来，在那里，我们几乎可以用书面文字取代一切。

在较小规模上，它可以将如下所示的小型规格说明，而不是生成庞大的类文件

转换成以下代码

它能用吗？是的
它适合生产环境吗？不

这只是一个概念验证。不过，如果你希望进一步探索，可以尝试一下。

更多详情，请观看 3 分钟的 YouTube 演示视频

这比 ChatGPT 好在哪？

现有的 OpenAI 模型对其输入和输出的大小有上限。
这限制了它们目前只能用于处理小型代码片段。

我们通过使用大量不切实际的提示链和工程技巧来绕过这个限制。这样我们就能生成跨多个文件的完整应用程序，或者非常大的（Java）文件，或者两者兼有。

OAuth2 集成规格说明及其带注释的代码结果有多大的一个示例

不幸的是，这意味着这个过程很慢

为了构建一个大型代码文件，需要进行多次 AI 调用（图中的几乎每个箭头都是一次 AI 调用）

如果图表还不够清楚，每个文件需要 10 多次 AI 调用：这个庞大的过程慢得要命

但重点不在于其实用性，而在于验证一个可能未来的实用性。在这个未来中，AI 可能成为现有现代编程语言之上的一个新的抽象编译层。
就像现代编程语言是操作系统 API 的抽象层，而操作系统 API 又是机器代码的抽象层一样。

如何安装？

最简单的方法是通过 NPM 安装

npm install -g english-compiler

如何配置？

在你希望基于其进行构建的项目中，至少应该有一个用于存放规格说明文件的文件夹和一个用于存放源代码的文件夹。
然后你可以设置一个 english-compiler.jsonc 文件，其中应包含所有必需的设置，包括 OpenAI API 密钥。

出于显而易见的原因，请不要将你的 OpenAI API 密钥提交到公共仓库。

以下是一个设置示例：

{
    // Openai API key
    "openai_apikey": "REPLACE-WITH-YOUR-ACTUAL-KEY-AND-DO-NOT-CHECKIN",

    // 提示缓存目录，可用于缓存和加速构建过程，
    // 尤其是在规格说明（或代码）没有发生变化时。
    //
    // 当你遇到 OpenAI 速率限制（或他们的服务器因 chatGPT 而过于繁忙）时，
    // 此缓存也至关重要，因为构建会中止。
    //
    // 缓存提示可以让你继续构建，而无需从头开始。
    "prompt_cache_dir": "./prompt_cache",

    // 规格说明目录，用于扫描 `*.spec.md` 文件
    "spec_dir": "./spec",

    // 源代码输出目录
    "code_dir": "./src",

    // 测试代码输出目录（目前仅支持 JS）
    "test_dir": "./test",

    // 添加一些个性化的评论，如果你想跳过此功能以节省 token 消耗（此功能只是为了好玩），
    // 请设置为 false/null
    "personality": "Sassy & Sarcastic"
}

运行我们的一个演示！

请注意，演示包含了 AI 编译过程的预计算缓存，因此除非你更改了规格说明文件的一部分，否则无需更新设置中的 OpenAI 密钥。

所有演示都预装了规格说明文件

以及预构建的代码输出（你可以删除并重新构建）

另外，是的，输出中存在一些小的 bug。这是一个概念验证。

我花了超过 4 个小时，试图慢慢修改规格说明并修复所有 bug。但编写-编译-测试的循环实在太慢了，而且我的黑客马拉松时间用完了。

演示 1：构建一个简单的“Twitter 克隆”演示

这是一个没有登录或身份验证的简单完整 Twitter 克隆应用程序。
包括 UI 和 API 端点。

进入 demo/twitter-clone 文件夹

向 AI 征求规格说明文件的建议

EnglishCompiler spec suggest spec/ui/index.spec.md

构建单个规格说明文件

EnglishCompiler build file spec/core/db.spec.md

构建所有规格说明文件

EnglishCompiler build all

如果你想真正验证它是否构建了文件，可以删除 src 目录，然后运行构建过程。

演示 2：更大的 Java 类

这是一个 Java 类的示例，一旦包含规格说明和代码注释，其规模将过大，超过 4000 多个 token。
如果不使用我们在这个项目中采用的技巧，直接通过 OpenAI API 生成是不可能的。

这个演示只有一个文件

进入 demo/java-class 文件夹

构建所有规格说明文件

EnglishCompiler build all

规格说明文件的格式是什么？

规格说明文件夹应包含 $NAME.spec.md 文件，这些文件与单个代码文件是一一对应的。

至少它应该有一个 Markdown 前置元数据，其中包含 type 参数，用于指定语言，例如：

---
type: javascript
test: true
---

# DB 模块

test 是一个可选参数（目前仅支持 javascript），当启用时，将通过一个单独的过程尝试生成相关的测试脚本。为了避免测试代码与源代码相互污染，这个过程是隔离进行的。

从那时起，剩下的就真的取决于你，你想怎么写你的 Markdown 规格说明都可以。

常见问题解答

我可以使用英语以外的其他语言吗？

可能可以，理论上任何 OpenAI 模型（或未来的 LLM 模型）支持的语言都应该可以。

与其为每个代码文件写一份规格说明，难道不能写一个更高层次的规格说明文件吗？

在这方面进行了一些实验，但由于时间限制，决定以 1 对 1 的方式映射它们。
我认为没什么不可以的（除了需要更多 AI 调用），我们可以采用类似处理大型 Java 类的方法，先进行一个初步步骤，询问 AI 需要从这个规格说明文件生成多少个文件。

这与 Uilicious 或 UI 测试有什么关系？

我们构建了自己的用于测试和代码生成的 AI 模型，这个项目的最初概念是读取产品规格说明，并使用我们微调过的 AI 模型（技术上，我们在提示链中同时使用了自定义微调模型和 OpenAI 模型）将其转换为 UI 和单元测试。

然而，很快就表明，在目前的状态下，这个过程太慢了，商业上不可行。因此，最初内部的 POC 在黑客马拉松期间被重写（移除了任何机密代码和密钥），成为现在开源的“English Compiler”。

旁注：OAuth2 规格说明文件是一个真实的规格说明文件，曾作为我们最初内部演示的一部分编写和使用。

有可能让这成为可能吗？

嗯，我们正在努力，尝试构建一个“不是更聪明”但拥有更大上下文 token 记忆的模型。
这大致基于：
- SalesForce 的 codegen 模型和数据集 ( https://github.com/salesforce/CodeGen )
- The Pile ( https://pile.eleuther.ai/ )
- EleutherAI 20B ( https://blog.eleuther.ai/announcing-20b/ )
- xP3 指令调优数据集 ( https://huggingface.co/datasets/bigscience/xP3 )
- （待添加）The Stack ( https://huggingface.co/datasets/bigcode/the-stack )

然而，我们的预算非常紧张，正在筹集资金以加快进度。
首先用于测试，这有更直接的实际用途，并且需要较少的上下文记忆和代码复杂度（即可使用较差的模型）。最终目标是通用的代码生成。

如此低效的编译器，怎么可能有用呢？

嗯，你可能说对了，对于当前的迭代版本来说。它有 bug，并且在 chatGPT 过载时可能无法编译。

但五年前我开发的“无用编译器”GPU.js，原本也从未打算用于生产环境。
结果它最终在成千上万的浏览器上运行了整个神经网络和数字艺术装置。

最初的 GPU.js 编译器没什么不同，同样问题多多。或者从技术上讲更糟（它只兼容部分 GPU）。