Claude 的 C 编译器 vs GCC — AI 写的编译器到底行不行？
结论先行：CCC 证明了 AI 能写出一个「能用」的编译器，但离「好用」还差了三个数量级。字面意思。
发生了什么
Anthropic 上周干了一件挺疯狂的事：他们用 16 个并行的 Claude Opus 4.6 agent，从零写了一个 C 编译器，叫 CCC（Claude’s C Compiler）。纯 AI 生成，人类没写一行代码。用 Rust 实现，支持 x86-64、ARM 和 RISC-V 三个后端。
数字很夸张：近 2000 个 Claude Code session，$20,000 API 成本，产出 10 万行 Rust 代码。
我第一反应是：这是个很好的 demo。第二反应是：跑个 benchmark 看看？
果不其然，社区很快就有人做了独立测试。harshanu.space 上有一篇非常详细的 benchmark 报告，结果……怎么说呢，既在意料之中，又足够让人深思。
背景：16 个 Agent 怎么协作
先说说 CCC 是怎么被「写」出来的，因为这个工程方式本身就很有意思。
Anthropic 搞了一个 multi-agent 架构：16 个 Claude Opus 4.6 实例并行工作，每个跑在独立的 Docker 容器里，通过 git 文件锁 来同步任务分配。你可以把它想象成一个 16 人的远程开发团队，只不过每个「人」都是 LLM，沟通方式是 git 而不是 Slack。
这个架构设计本身挺聪明的。文件锁保证不会有两个 agent 同时改一个模块，git 作为 single source of truth 天然解决了版本冲突。但这也意味着——每个 agent 本质上是独立工作的，它们之间没有真正的「讨论」和「设计 review」。
这一点，后面会看到它带来的问题。
Benchmark 结果：能跑，但慢得离谱
Linux 内核编译
最震撼的测试是直接用 CCC 编译 Linux 内核。
好消息：CCC 成功编译了所有 .c 文件，0 个编译错误。这意味着 CCC 的 C 语言前端（parser、type checker、语义分析）做得相当完整，能正确处理 Linux 内核那种充满宏和 GCC 扩展的代码。
坏消息：链接阶段直接炸了。40,784 个 undefined reference errors。
四万个。
这说明什么？CCC 在代码生成阶段有系统性的 symbol resolution 问题。不是偶尔漏一个，是大面积地没有正确生成符号表。这种 bug 不是「修几个 case」就能搞定的，更像是 linker integration 的整体架构没做对。
SQLite Benchmark：慢 737 倍
SQLite 的测试更有说服力，因为它能编译成功并且跑出结果。
CCC 编译的 SQLite 功能完全正确——所有查询返回结果一致。但速度嘛：
| 指标 | CCC | GCC -O0 | 差距 |
|---|---|---|---|
| 整体性能 | 1x | 737x faster | 慢 737 倍 |
| 最慢查询 (NOT IN) | 1x | 158,129x faster | 慢 15.8 万倍 |
| 二进制体积 | 3x | 1x | 膨胀 3 倍 |
| 内存使用 | 5.9x | 1x | 多用 5.9 倍 |
注意对比对象是 GCC -O0，也就是 GCC 完全不做优化的情况。CCC 比「不优化」还慢 737 倍。
如果跟 GCC -O2 比呢？那个差距大到没有意义了。
根因分析：为什么这么慢
benchmark 报告做了很深入的分析，问题主要出在三个地方：
1. Register Spilling 灾难
CCC 生成的汇编代码有严重的 register allocation 问题。正常编译器会尽量把频繁访问的变量放在寄存器里，而 CCC 生成的代码几乎把所有变量都 spill 到栈上。
有多夸张？栈偏移量达到了 11,000 字节深。
如果你做过底层优化，你就知道这意味着什么——每次变量访问都要走一次内存 load/store，L1 cache 基本白费了。这不是「慢一点」的问题，是数量级的性能灾难。
2. -O2 是个空操作
CCC 声称支持 -O2 优化级别，但实际上加不加 -O2 生成的代码完全一样。
这其实不意外。编译器优化是整个编译器工程中最难的部分——constant folding、dead code elimination、loop unrolling、instruction scheduling、register allocation，这些 pass 之间还有复杂的依赖关系。一个 AI 生成的编译器，在没有经过系统性测试和 profiling 迭代的情况下，优化 pass 基本就是摆设。
3. 代码膨胀
CCC 生成的二进制体积是 GCC 的 2.78 倍，内存使用是 5.9 倍。这跟前面的 register spilling 是同一个根因——代码生成质量差，产生大量冗余的 load/store 指令和不必要的栈操作。
我的思考
这不是 AI 的失败，是期望管理的问题
说实话，我觉得 CCC 的结果其实 挺好的。
一个 AI 写的编译器，能正确编译 Linux 内核的所有 C 文件（哪怕链接失败），能生成功能正确的 SQLite——这在两年前是不可想象的。GCC 是几百个工程师花了 37 年 打磨出来的。拿一个 $20,000、几周时间的 AI 产物去跟它比性能，本身就不公平。
真正的问题是：Anthropic 自己怎么定位这个项目的？
如果是作为 “AI agent 协作能力的 demo”，CCC 非常成功。它证明了 multi-agent 架构能处理复杂的系统级工程任务。如果是想证明 “AI 能写出 production-ready 的编译器”，那 737 倍的性能差距说明我们还早得很。
编译器优化是 AI 的阿喀琉斯之踵
CCC 暴露的核心问题不是 AI「不会写代码」，而是 AI 不理解运行时行为。
编译器前端（parsing、type checking）是规则驱动的，有明确的规范（C 标准）可以遵循，这是 LLM 擅长的。但编译器后端的优化需要对硬件执行模型有深刻理解——cache hierarchy、pipeline stalling、branch prediction，这些东西不是「看文档」就能学会的，需要反复 profiling 和迭代。
这恰恰是当前 AI coding agent 最缺的能力：基于运行时反馈的迭代优化。agent 可以写代码、跑测试、修 bug，但它不会主动去跑 perf stat，然后根据 cache miss rate 去调整 register allocation 策略。
Multi-agent 的天花板
16 个 agent 用 git 文件锁协作，这种方式对「可并行分解」的任务很有效。但编译器的核心难点恰恰在于各个 pass 之间的紧耦合——register allocator 的决策会影响 instruction scheduler 的效果，loop optimization 会改变 register pressure。
这种需要全局视角的设计决策，很难通过「每个 agent 负责一个模块」的方式解决。你需要的不是更多的 agent，而是一个有全局架构视野的 agent（或者人类架构师）来做顶层设计。
结论
CCC 是 2026 年 AI 工程领域最有意义的实验之一，但不是因为它「成功」了，而是因为它精准地暴露了 AI 代码生成的能力边界：
- ✅ 规则驱动的代码：AI 做得很好（前端、parser、类型系统）
- ⚠️ 系统集成：能做但有系统性缺陷（40,784 个链接错误）
- ❌ 性能优化：基本不行（慢 737 倍，-O2 是空操作）
对于我们这些用 AI 写代码的开发者来说，takeaway 很明确：让 AI 写功能，自己盯性能。至少在当前阶段，AI 能帮你把事情做出来，但做得好不好，还是得靠人来把关。
不过话说回来，GCC 1.0 在 1987 年发布的时候，性能也没比当时的商业编译器好多少。给 CCC 几年时间，谁知道呢？
如果你对完整 benchmark 数据感兴趣，推荐阅读 harshanu.space 上的原始测试报告。
🧪 想自己动手试试 Claude Opus 4.6？ OfoxAI 提供一站式 AI API 接入，支持 Claude、GPT 等主流模型。首次充值输入优惠码
OFOXAI2026享 8 折优惠，使用推荐码AFF_KOGPMT还可获得 $3.00 免费 Credits。