Claude两周独立写出C编译器,编译Linux内核

写在前面

刷到 Anthropic 的一篇博客，看完直接愣住了。

他们让 Claude Opus 4.6 写了个 C 编译器。10 万行 Rust 代码，能编译 Linux 内核。

重点是什么？人类基本没管。

给了任务，走开，两周后回来，编译器写好了。就像你给实习生布置了个作业，然后去度假，回来发现项目上线了。

这事儿听起来很科幻对吧？但它真的发生了。我花了点时间研究了他们开源的代码，觉得这个案例值得好好聊聊。

因为它展示的不只是 AI 能力的提升，更是一种完全不同的协作方式。

什么是 agent teams

我们先搞清楚一件事。

传统的 AI 辅助编程是什么样的？你写一段，AI 补一段。你问个问题，AI 给个答案。人类是司机，AI 是副驾驶。

但 Anthropic 这次玩的不一样。

他们提出的"agent teams"，核心思路很简单：让多个 Claude 实例并行干活，不需要人类盯着。

就像一个开发团队，只不过每个成员都是 AI。16 个 Claude 实例，跑了将近 2000 个会话，花了 2 万美元 API 费用。

人类做了什么？写测试用例。告诉 AI"你得过这些测试"，然后就不管了。

没有结对编程，没有代码审查，没有实时反馈。

这就像你给一群人扔了个需求文档和测试用例，然后把他们锁在房间里，两周后开门验收成果。只不过这群人是 AI。

为什么选编译器

你可能会问，为什么要让 AI 写编译器？

因为编译器是个完美的试金石。

首先，需求极其明确。输入 C 代码，输出可执行文件。中间的每一步都有严格规范（C 标准、ELF 格式、DWARF 调试信息）。没有模糊地带，没有"产品经理说了算"。

其次，复杂度够高。词法分析、语法分析、语义分析、IR 生成、优化、代码生成、汇编、链接……每个环节都是硬骨头。

最后，验证很直接。能不能编译 Linux 内核？能不能生成正确的二进制？能不能在不同架构上跑？这些都是硬指标。

Anthropic 选的目标是编译 Linux 6.9，支持 x86-64、ARM、RISC-V、i686 四种架构。这难度不低，因为 Linux 内核用了大量 C 语言的高级特性和编译器扩展。

如果 AI 能搞定这个，说明它已经不是玩具了。

它怎么做到的

代码已经开源了（claudes-c-compiler），我翻了一遍，确实全是 Rust 写的。

从零开始。

没有 LLVM，没有 GCC，前端、SSA IR、优化器、代码生成器、汇编器、链接器、DWARF 生成，全是自己实现的。

这意味着什么？意味着 Claude 不仅要懂 C 语言，还要懂 x86/ARM/RISC-V 指令集，还要知道怎么生成 ELF 文件，还要处理符号解析、重定位、调试信息……

这些东西每一个都够写本书了。

更绝的是，文档也是 Claude 写的。README 里明确说了："除了这一段，其他 100% 的代码和文档都是 Claude Opus 4.6 写的。"

当然，作者也很诚实：我不建议你用这代码。因为没经过人类验证，可能有 bug。

但这不重要。重要的是，它证明了 AI 已经可以独立完成这种规模的工程。

几个有意思的细节

翻代码时发现了几个巧妙的设计。

第一，它伪装成 GCC。报告自己是 GCC 14.2.0，接受大部分 GCC 参数（不认识的就忽略）。这样就能直接用在 Makefile、CMake、configure 脚本里。

这个设计很实用。因为现实世界的构建系统都是围绕 GCC 设计的。如果你不兼容 GCC，就没法用在实际项目里。

第二，它内置了汇编器和链接器。给它一个 .c 文件，它能直接输出可执行的 ELF 文件。不需要外部工具链。

当然你也可以通过 Cargo feature 让它调用 GCC，但默认是完全独立的。

第三，它支持交叉编译。同一份代码，编译出来的二进制名字不同（ccc、ccc-arm、ccc-riscv、ccc-i686），运行时根据名字选目标架构。

这个设计也很聪明。因为交叉编译在嵌入式和内核开发里是刚需。

这意味着什么

看完这个案例，我最大的感受是：AI 的能力边界又扩了。

以前我们觉得 AI 只能写简单函数。后来发现它能写完整模块。现在，它能独立完成 10 万行的编译器了。

但这不是说程序员要失业。恰恰相反，人类的作用依然关键：定义目标、设计测试、把控方向。

只是协作模式变了。

以前是"人写代码，AI 辅助"。现在可能变成"人定义需求，AI 团队实现"。人类从执行者变成了架构师和质检员。

这种变化会带来什么？

第一，效率会大幅提升。两周，2 万美元，10 万行代码。换成人类团队，可能要几个月。

第二，质量保障方式会改变。传统的代码审查、结对编程可能不再适用，取而代之的是更强的测试驱动和形式化验证。

一些担忧

当然，这模式也不完美。

最大的问题是可控性。16 个 AI 并行工作，你很难知道它们在干什么，也很难在出问题时及时介入。

Anthropic 说"mostly walked away"（基本上走开了），但"mostly"这个词很微妙。他们肯定还是做了些干预，只是没细说。

另一个问题是成本。2 万美元只是 API 费用。如果算上人类设计测试、搭基础设施、分析结果的时间，总成本可能高得多。

还有信任问题。作者自己都说"别用这代码"，因为没充分验证。那在生产环境里，我们敢不敢用 AI 自主开发的代码？

这些问题现在还没答案。但它们会随着技术发展逐渐浮现。

总结

Anthropic 的这个实验，本质上在探索一个问题：AI 能不能像人类团队一样协作开发软件？

答案是：在某些场景下，可以。

编译器这个案例证明了，对于需求明确、验证直接的工程任务，AI 团队已经可以独立完成相当复杂的工作。

但人类不能完全退出。相反，我们的角色更重要了：定义更清晰的目标，设计更完善的测试，建立更可靠的验证机制。

未来的软件开发，不是"人 vs AI"，而是"人 + AI 团队"。

这个未来，可能比我们想象的来得快。

P.S. 代码已经开源了，感兴趣的可以去 GitHub 上翻翻。虽然不建议直接用，但看看 AI 是怎么组织这么大规模的代码的，还是挺有意思的。

参考资料

Anthropic Engineering Blog - Building a C compiler with a team of parallel Claudes

GitHub - anthropics/claudes-c-compiler