打开网易新闻 查看精彩图片

前言：Cursor 用 AI 做浏览器翻车

当前，人工智能编程正经历一场深刻而关键的转型，技术发展路径的分野日益显著。

不久前，技术圈被一则消息引爆：Cursor 联合创始人 Wilson Lin 高调宣布：「用 AI Agent 从零构建浏览器，一周生成 300 万行代码」。然而，这一雄心勃勃的尝试最终以失败告终：生成的代码无法编译，模块之间缺乏基本的接口协调，系统架构严重缺失，功能实现几近于零，被全网嘲讽为「AI 泔水」。

但这场闹剧并非终点，当 Cursor 的“软件工厂”梦碎时，一支中国团队采取不同的技术路线，悄然用 AI 实现了以往不可能的任务：使用一门新编程语言在 10 天内生成了一个商业级别的 C 编译器，性能接近行业标杆。

从外部视角审视，这或许并不止于“AI 写了一个编译器”，而在于它展示了一种相对稳定、可持续的“用 AI 构建软件”的方式。换句话说重要的不是一次性生成的结果，而是一条可以自举、可以回归、可以持续优化的工程曲线。

如果这种路径并非偶然，而是可以被系统性复制的，那它背后那套可复用的工程机制构建起的 AI 自动流水线生产的软件工厂，对整个软件工程领域都具有相当大的意义。

用 AI 合成一个 C 编译器
（技术实现过程）

MoonBit 团队是国内 AI 编程语言领域的顶尖力量，也是国内唯一具有工业级语言与工具链快速落地能力的团队（世界范围有谷歌，微软、苹果等）。团队由 IDEA 研究院首席科学家张宏波领导，他们打造的 MoonBit 语言专为 AI 与云原生等场景设计，支持多后端编译，性能卓越。目前，MoonBit 已应用于清华、北大等高校课程，并获海外云服务商采用，核心用户超 10 万 +，目前库近 4 千个，按照增长速度推测 26 年底将有数万个库，届时生态将与苹果的 Swift 持平。

我们观察到 MoonBit 不仅在国内积累了大量用户，而且已经在海外得到广泛响应，特别是日本技术社区和 X（推特）上不断刷新出大量关于 MoonBit 的技术内容。GitHub 上也有众多开发者在贡献生态库，有位日本技术大 V 评价：「一旦人们意识到 MoonBit 的价值，他们就会蜂拥而至」。

打开网易新闻 查看精彩图片

最近 MoonBit 团队公开表示在 「AI 软件工厂」上有突破性进展，现在 MoonBit 「 AI 软件工厂」展示出可以高效复刻大型软件的可能性，并且实现的质量更好，可靠性更高。值得一提的是，这并非一次性代码生成能力，而是一种可重复、可验证的软件生产流程。

得益于大模型的迅速发展，AI 生产软件的速度和质量大幅度提升，一个标准 3.5 万行代码的大型软件的生产速度从过去百天到一年左右提升到目前 10 天以内。我们现在有理由相信未来大多数软件将通过自动化流水线的软件工厂生产。

但整个生产流程中的几个关键节点的跨越并不轻松，分别是 60% 节点、90% 节点。以 Cursor 生成的浏览器为例就是完成了 60 %，但在后续迈向 90% 时失败。原因在于 Cursor 对于编程语言掌控力、AI 原生工具链和测试等多方面能力的缺失。

打开网易新闻 查看精彩图片

软件工厂生产软件发展趋势

以 C 编译器为例的生产过程

来自 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

我们设定了一个极具挑战的目标：从零开始构建一个 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 生成，可读性极高。

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

「MoonBit 软件工厂」下一步最自然的演进，是把已经跑通的工程流程固化下来，变成一套可以反复调用的软件生产能力。一旦这种能力稳定存在，它就不再局限于编译器，而是可以扩展到更多软件类别——从基础库、工具链组件，到更贴近业务侧的系统。当这样的产能开始规模化之后，或许将开启一个新时代。

从 AI 写代码到“软件工厂”
（技术架构解读）

MoonBit 把软件完成率从 60 % 提升到 100% 的原因主要有以下几点：

语言设计

MoonBit 语言确立了“AI 原生”的核心理念，摒弃传统编程语言中为人类习惯服务，但对 AI 造成理解负担的复杂语法结构，如嵌套作用域、隐式类型转换与重载机制。

其采用“平坦化”语法设计，具备极简的语法规则、高度清晰的语义表达与强大的静态类型系统，所有语言特性均经过 AI 可理解性与生成友好性的系统评估，确保模型在推理过程中不会因歧义而产生错误。这种设计显著降低了大模型在语义解析、上下文推断与代码生成过程中的歧义成本，极大提升了生成结果的准确性、一致性与可预测性。

同时，语言层面内置了对 AI 反馈机制的支持，如类型提示注入、错误定位标记与自然语言注释映射，使得自然语言需 求能够被高效、准确地转化为可执行代码，大幅度提高了“意图到代码”的转化。

打开网易新闻 查看精彩图片

MoonBit 运行性能与 Go 和 Swift 持平，甚至在某些场景下优于 Go 和 Swift。在公开的基准测试中，MoonBit 的编译速度快于 Rust 的10 到 100 倍。

相应的就是 MoonBit 软件工厂的反馈速度极快，在 AI 生产软件的场景下，对比以往人类编写代码对于编译速度的需求有了指数级提升，AI 一天可以跑上千次的编译，此时编译速度变得异常重要，MoonBit 软件工程的优势也愈发明显。

AI 安全重构

在软件工厂生产或重构软件时，MoonBit 工具链不会让 AI 盲目随意地修改代码，而是为 Agent 提供了一套可调用、可验证的重构基础设施。

moon ide是一个面向 AI Agent 的 IDE 工具，覆盖定义跳转、引用查找、重命名、结构分析和文档查询等能力。 这些接口不是“给人点的功能”，而是以稳定、可解析的命令行协议直接暴露给 Agent 使用。

以其中一个功能rename为例，moon ide rename不会生成模糊的文本替换结果，而是直接输出符合 OpenAI Codexapply_patch规范的结构化补丁。 换句话说，重命名不再依赖模型猜测上下文，而是由工具链给出确定的修改范围和精确的变更结果。

这带来几个直接收益：

  • 重构基于语义和符号表，而不是字符串匹配

  • 修改边界清晰，不会引入结构性漂移

  • 每一次变更都可以立刻进入编译、测试和静态分析流程验证

打开网易新闻 查看精彩图片

传统 AI 编程工具的工作路径，本质上还是围绕人类开发者转的。人写提示词，模型生成代码，IDE 把结果展示出来，再由人决定改哪里、跑什么测试、要不要提交。看起来自动化了，其实反馈回路仍然是“人 → 界面 → 模型 → 人”，节奏慢、信息损耗大，也很难真正形成闭环。这种模式下，AI 更像一个助手，而不是工程系统的一部分。

「MoonBit 软件工厂」理念是不再假设中间一定要有一个“给人看的 IDE 层”，而是把理解代码、查结构、跑测试的能力，直接暴露成可以被程序化调用的接口。换句话说，AI 面对的不是一堆 UI 按钮，而是一套可以直接对话的工程系统。这种交互关系一旦成立，节奏就会完全变样：反馈不再是“等人点一下”，而是“改完立刻验证”；决策不再是“要不要继续写”，而是“这次修改有没有通过约束”

工具链

整套工具链沿用 「AI 原生」理念，专为 Agent 优化设计——调试器、性能分析、覆盖率工具、测试框架全部可调用，反馈回路大幅度缩短，可靠性也相应提高，可避免低级错误。

从这个例子看，AI Agent 在编写 C 编译器（Fastcc.mbt）的过程中可以直接调用调试器去定位错误，用性能分析工具去找热点，再用基准测试卡住回退。这听起来像普通工程流程，但关键在于：这一整套流程对 AI 是完全流畅可调用的。

这就解释了一个看起来有点反直觉的结果：在没有并发、全程只用一个 codex agent 的情况下，项目依然能在十天里从“能跑”推进到“可优化”，速度比 clang - O0 快四倍左右，这里真正决定速度的，其实不是生成吞吐，而是验证反馈回路的长度。每一轮修改，都要经过编译测试、反复验证。这种节奏，更像是在推进一条软件工厂的流水生产线。

QuickCheck

QuickCheck 是开创性的具体实现，2000 年由 Koen Claessen 和 John Hughes 为 Haskell 开发。它首次将"自动生成随机测试数据来验证程序属性"这个想法变成了实用工具。

Property-Based Testing 是 QuickCheck 所代表的测试方法论的通用名称。核心思想是：你声明代码应该满足的"属性"（比如 reverse(reverse(list)) == list），测试框架自动生成大量随机输入来尝试反驳这个属性。这个术语现在用来指代所有采用这种方法的测试，不限于 Haskell 或 QuickCheck 本身。

Fuzz Testing（模糊测试） 是一个更宽泛、历史更久的概念，起源于 1980 年代末的安全测试领域。它的核心是向程序投喂随机或半随机的输入，观察是否会崩溃或出现异常行为。传统 fuzzing 不一定有明确的"属性"定义，往往只是看程序会不会挂掉。

助力软件完成率从 90% 到 100% 的就是 Fuzz Testing 和 Property Based Testing ，Cursor 那类“生成速度很快但不可控”的失败，本质上不是“AI 不会写”，而是缺少把结果持续拉回正确轨道的质量约束。MoonBit 软件工厂之所以能把项目从“能跑”推进到“可用、可维护、可优化”，关键就在于把质量校验做成了可自动执行的门禁，其中最有效的一类就是 QuickCheck / Property-based Testing（性质测试）。

传统单元测试更像“举例子”：我给你 10 个输入，期待 10 个输出。其覆盖面相当有限，也容易被 AI 的“看起来对”骗过去 (hacking) 。性质测试则更像“写规则”：不去枚举样例，而是声明程序必须永远满足的性质（property / invariant），然后让测试框架自动生成海量随机输入去“撞墙”。一旦撞出反例，框架还会自动shrink（缩减）反例，把复杂失败用例缩到最小、最容易复现和定位的那一个，这对 Agent 来说非常关键：它拿到的不是含糊的“某处错了”，而是一个可重放、可最小化、可稳定回归的失败证据。

这种方法在编译器、PDF 和表格（Excel）这类系统里尤其有效，因为它们天然存在大量“结构等价 / 语义不变 / 往返一致”的可验证性质：

  • 编译器：同一段 C 代码，换不同编译器跑，结果应该一致；做了“优化”，只允许变快，不允许把答案变掉。

  • PDF/ 文档工具：文件“打开→保存→再打开”，内容和排版不应该突然变形或丢东西。

  • 表格 /Excel：公式计算结果稳定；保存加载前后语义一致；依赖关系不应出错（比如不该出现自相矛盾的循环依赖）。

这种测试会迫使 AI 使它不再靠“自信输出”赌正确，而是被迫在可验证的约束系统里迭代。每一次修改都要过编译、过测试、过性质校验；每一次性能优化都要在不破坏性质的前提下推进，因此系统更加能够在验证过程中不断趋近真正的可靠软件。

First Class Reasoning

打开网易新闻 查看精彩图片

MoonBit 在语言层面原生支持形式化推理能力，这是 AI 软件工厂中确保代码正确性的另一道重要防线。

具体而言，MoonBit 允许开发者（或 AI）为循环标注循环不变式（Loop Invariant），并支持编写semi-formal 的证明过程。这一设计有两个关键特点：

  • 可执行的规约：循环不变式本身是合法的 MoonBit 代码，而非孤立的注释或外部标注。在 debug 模式下，这些不变式会作为运行时断言被动态检查——一旦违反，立即报错；而在 release 模式下，这些检查会被自动擦除，不影响生产环境的性能。这种"写一次，两种用途"的设计，既保证了开发阶段的严格验证，又避免了运行时开销。

  • AI 可验证的证明：semi-formal 的证明过程不要求完全的形式化证明（那对 AI 和人类都是巨大负担），而是一种结构化的推理步骤描述。这些证明可以借助 AI 工具进行检查和补全——AI 既可以根据代码自动生成候选的不变式和证明草稿，也可以验证人类或 AI 编写的证明是否自洽。

这种设计对 AI 软件工厂的意义在于：它把"代码正确性"从模糊的直觉判断，变成了可检查、可迭代的工程约束。当 AI 生成一段带循环的关键代码时，不再只能依赖测试用例碰运气，而是可以通过不变式和证明过程，从逻辑层面确认代码的行为符合预期。这在编译器这类对正确性要求极高的软件中尤为重要。

总 结

MoonBit 目前支持三种后端，分别是 WebAssembly (Wasm)、JavaScript (JS) 和 Native，特别是在 WASM 上 MoonBit 优势明显，拥有最成熟的模块，性能优异，可以将软件工厂生产的大型软件移植到浏览器中高效运行。且自带沙箱，设计上集成了基于 Wasm 的隔离运行环境，对于开发者 或 AI 应用使用者，都可以在不牺牲安全性的前提下，快速部署和测试代码，很适合构建可信的 AI 辅助开发环境或边缘计算场景。（前文提到的 C 编译器还展示了 Web 版本：https://moonbit-community.github.io/fastcc/ ）

MoonBit 正在推动软件工程从“人工编码”迈向“自动化工厂”的新时代：人类角色将转向需求定义与关键决策，而 AI 则在严谨的工程框架下完成构建与迭代。随着生态快速扩张，MoonBit 不仅会是中国在 AI 编程语言领域的重大突破，更有希望重塑全球软件生产的底层范式。

InfoQ 联合 MoonBit 发起大型软件合成挑战赛 ：

赛事以“AI 原生软件工厂”为核心理念，基于「 MoonBit 软件工厂」探索在大模型与 MoonBit 编程语言及工具链协同条件下，如何将复杂软件的开发过程，从依赖个人经验的一次性实现，逐步转变为可复用、可演进、可持续的软件工程流程。