构建 C 编译器：并行 Claude 团队的全景报告

📅 发布时间： 2026年2月5日

✍️ 作者： Nicholas Carlini (Anthropic 安全研究员)

🔍 核心事件： 使用 Opus 4.6 模型（注：虚构的未来模型），通过 16 个并发智能体，花费 2 万美元，从零构建了一个能编译 Linux 内核的 Rust 版 C 编译器。

$20,000 API 成本

100,000+ 代码行数 (Rust)

2,000 Claude Code 会话

Linux 6.9 编译目标

第一部分：项目核心架构与工作流

Anthropic 并不是简单地让 AI "写代码"，而是构建了一个严密的工程测试框架（Harness）。这是成功的关键。

1. 演示视频

2. "死循环" 工作流

为了让 AI 持续工作，他们设计了一个简单的 Bash 脚本循环。AI 完成一个任务后，脚本自动提交代码并开启下一个任务。这个脚本运行在隔离的 Docker 容器中。

#!/bin/bash

while true; do
    COMMIT=$(git rev-parse --short=6 HEAD)
    LOGFILE="agent_logs/agent_${COMMIT}.log"

    # 只要不被停止，Claude 就永远在工作
    claude --dangerously-skip-permissions \
           -p "$(cat AGENT_PROMPT.md)" \
           --model claude-opus-X-Y &> "$LOGFILE"
done

3. 并发控制与锁机制

16 个智能体同时工作，为了避免冲突，采用了基于文件系统的锁机制：

抢任务： 智能体在 current_tasks/ 目录下创建文件（如 parse_switch_stmt.txt）来声明所有权。
Git 同步： 如果冲突，Git 会强制智能体拉取最新代码并解决冲突。
分工： 不同智能体扮演不同角色：有的写功能，有的写文档，有的负责“代码压缩”（去重），有的负责性能优化。

4. 关键创新：GCC Oracle（预言机）调试法

当编译 Linux 内核这种巨型项目时，AI 卡住了。所有智能体都在修同一个 Bug 并且互相覆盖。解决方案是引入真理标准：

我们编写了一个新的测试框架，随机使用 GCC 编译内核的大部分文件，只留一小部分给 Claude 编译器。如果内核能跑，说明 Claude 负责的那部分没问题；如果崩了，就缩小范围。这让 AI 能够通过对比 GCC 的行为来进行差分调试。

第二部分：社区深度辩论 (Hacker News 精选)

这篇博文在技术社区引发了极大的争议。以下是核心争论点的详细拆解。

争论点一：这真的是“净室（Clean Room）”实现吗？

Anthropic / 支持方观点

这是一个“净室”实现，因为在开发过程中，Claude 没有互联网访问权限。它完全依赖于模型内部的知识和 Rust 标准库。它没有直接去 GitHub 上抄袭现有的编译器源码。

HN 社区 / 反对方观点

这完全是在玩弄定义。

模型在训练阶段就已经“读”过了互联网上所有的开源编译器（GCC, Clang, TCC）。这些知识已经被压缩在权重里了。
真正的“净室”是指开发者从未看过原版源码，只看规格说明书（Spec）。但这就像让一个背诵过 GCC 源码的人去“凭记忆”重写一遍，法律上和逻辑上都不能算净室。
更重要的是，该项目明确使用了 GCC 作为 Oracle（预言机） 来验证输出。这意味着它是在“逆向工程” GCC 的行为，严格依赖于 GCC 的存在。

争论点二：20,000 美元的成本与价值

事实背景

该项目花费了约 2 万美元的 API 成本（按 Opus 价格计算）。生成的代码约 10 万行。

乐观视角：廉价的高级劳动力

2 万美元只相当于硅谷高级工程师半个月的工资。能在两周内，以如此低的成本完成一个能启动 Linux 的编译器，效率是惊人的。这证明了如果只需 MVP（最小可行性产品），AI 的性价比极高。

悲观视角：昂贵的数字垃圾

一位人类高手（如 Fabrice Bellard，TCC 作者）可以在几周内写出一个更好、更快的编译器，而且代码更易维护。AI 生成的这 10 万行代码：

质量差： 即使开启优化，生成的代码也比 GCC 关掉优化（-O0）还要慢。
难维护： 这是一堆由概率生成的“面条代码”，由于没有人类真正理解其逻辑，未来的维护成本接近无限大。
依赖性： 甚至无法独立完成 16 位启动代码（不得不作弊调用 GCC）。

争论点三：技术可行性与测试的决定性作用

核心洞察

评论区一致认为，该项目成功的真正原因不是 AI 变聪明了，而是 C 编译器是一个“完美问题”：

规范极其明确： C 语言标准和 x86 指令集是死的。
测试极其完备： 有现成的 GCC Torture Tests 和 Linux 内核作为测试集。
验证极其容易： 跑不通就是跑不通，反馈信号明确（True/False）。

这对于大多数现实世界的模糊业务需求（Requirements are fuzzy）来说，不可复制。

第三部分：局限性与未来展望

⚠️ 现有的明显缺陷

作弊行为： 无法生成 Linux 启动所需的 16 位实模式代码（因为 AI 生成的代码体积超过了 32KB 限制），最终只能让脚本调用宿主机的 GCC 来编译这部分。
工具链缺失： 汇编器和链接器（Assembler/Linker）非常简陋，大部分时候依赖外部工具。
效率倒退： 生成的二进制文件运行效率极低。

🚀 给开发者的行动指南

基于这项实验和社区反馈，我们能学到什么？

测试即是一切： 如果你想让 AI 独立干活，你必须先花费 80% 的精力编写完美的自动化测试和验证脚本。AI 的能力上限取决于你反馈机制的质量。
"Oracle" 模式是神器： 在重构老旧系统时，不要让 AI 凭空写。建立一个机制，让 AI 的输出逐行与“旧系统（Oracle）”的输出进行对比，这是保证正确性的唯一路径。
警惕“上下文污染”： 文中提到，为了不让 AI 变傻，测试脚本需要经过 grep 处理，只返回错误的那一行，而不是几千行的日志。这种对 Context Window 的精细管理是 Prompt Engineering 的高阶技巧。
从 MVP 开始： AI 擅长从 0 到 1 的暴力构建，但不擅长从 90 到 100 的极致优化。用它来做原型验证是极佳的场景。

原文

源链接