用 MoonBit 合成一个 C 编译器（附仓库地址）

先上仓库地址： https://github.com/moonbit-community/fastcc

我们设定了一个极具挑战的目标：从零开始构建一个 C 编译器 。

最初的目的是探索一下 AI 的能力边界，尝试让 AI 在几乎 0 干预的情况下，自己完成一个大型软件项目。

传统观念认为从零开始构建一个完全符合规范的 C 编译器是一项高难度任务，涉及词法分析、语法解析、语义检查、优化和代码生成等多个复杂环节，需要深厚的编译原理知识和对硬件架构的理解，通常需数月甚至数年才能完成。

整个过程像一部科幻小说。我戴上耳机，开启语音模式，对 AI 下达指令：“从零构建一个 C 编译器，贴近 tcc ，支持 arm64 架构。”

之所以选择 tcc 作为示例是因为它是世界上最快的 C 编译器,，编译速度本身对 MoonBit 的开发体验尤为重要。且 Native 后端同时支持 LLVM 和 C ，C 后端如果有自己的编译器的话，可以实现完全自举。而且 tcc 不安全，缺乏维护，有优化替代空间。为了快速验证，我们只让 AI 支持 arm64 架构。

在第七天的时候，它就已经实现了自举，这里需要解释下自举，先使用 moon 工具链构建 Fastcc.mbt（项目名称），生成 Fastcc.exe，再用 Fastcc.exe 去编译 Fastcc.mbt 自身代码经过 moon 工具链生成的 C 代码，生成 Fastcc1.exe，最后用 Fastcc1.exe 去执行 Fastcc.mbt 本身的测试，验证正确性。也能够编译 tcc 的源码，我们使用 v.c（ vlang 编译器的单个 c 文件 snapshot ）用以测试编译性能，当时和 tcc 的 gap 是 60x （也就是说 Fastcc.mbt 比 tcc 慢 60x ）。

一直到第十天，我几乎很少使用键盘。Agent 自主分解任务：先设计 AST （抽象语法树），生成基础模块；再用多 Pass 方案优化性能，而非照搬 tcc 的单 Pass 结构尽管提示词要求“贴近 tcc”，但 AI 选择了更可靠的路径。

每天工作的间隙，我会抽空看看 AI 的进度，偶尔需要做一些纠偏和指示：AI 自主使用 lldb 调试定位 Bug ，在指示下调用 Xcode 命令行工具做性能分析，自己写脚本识别热点代码并针对性优化。第七天，惊喜发生编译器成功自举：先用 MoonBit 工具链生成 Fastcc.exe ，再用它编译自身代码，验证通过测试。

整个过程中，AI 像一个不知疲倦的优秀程序员团队，在 MoonBit 的生态里流畅运作。最终，10 天，3.5 万行代码由 Agent 生成，可读性极高。-能够实现 tcc 、quickjs 、sqlite 并通过对应项目的测试，编译速度是 clang -O0 的 4 倍

值得一提的是这并非偶然，而是 MoonBit 软件工厂工具链及语言设计产生的确定性结果。

其他「 MoonBit AI 软件工厂」公开展示的示例：

• PDF 工具： https://github.com/moonbitlang/mbtpdf
• wasm 编译器： https://github.com/Milky2018/wasmoon
• Javascript： https://github.com/Lampese/NocturneJS
• d2ang： https://github.com/moonbit-community/diago
• ...