转载说明： 本文转载并翻译自 Anthropic Engineering《Building a C compiler with a team of parallel Claudes》（发布于 2026 年 2 月 5 日）。原文链接：https://www.anthropic.com/engineering/building-c-compiler用并行协作的 Claude 团队构建一个 C 编译器 作者：Anthropic · 2026 年 2 月 5 日 去年年初，我们给 Claude Opus 4.1 下了一个雄心勃勃的任务：从零写一个 C 编译器。 在软件工程里，C 编译器属于最复杂的工具之一。靠人工从头打造，通常需要深厚的系统功底和多年投入。 但在仅仅 6 小时内，在工程师只提供方向、不直接手写代码的前提下，Claude 就产出了一个可工作的编译器。这个项目后来成为开源仓库：anthropics/anthropic-c-compiler。 这个里程碑的意义不只在于“做出了什么”，还在于“如何做出来”。项目采用了一个 Claude 协调多个 Claude 并行工作的模式。这个模式后来也影响了 Claude Code 的一些功能设计，包括 src/services/terminal/conductor 里的调度思路。为什么用 Claude Code 来做编译器？ 这个编译器项目使用的是 Claude Code 的早期版本，当时很多今天常见的能力还不存在。 那时它还不支持自定义斜杠命令，也没有成熟的多 Claude 并行工作流。 尽管如此，核心交互模式已经成立：人类给出高层目标，Claude 快速生成与重构代码，双方反复迭代。 项目早期，我们给 Claude 的提示词大致是：Build a C compiler in Python. It should support enough C to compile itself, then use this capability to optimize itself and compile a C codebase. Target x86_64 Linux first, then support x86_64 and ARM macOS. Let's call it c_compiler for now. 随后开发大致按这条路径推进：先把最小可运行编译链路搭起来持续补齐语言特性与后端行为逐步扩大并加严测试集用真实程序暴露出的错误做快速回归迭代 这个过程也揭示了关键事实：真正的工程瓶颈往往不是“模型写代码速度”，而是任务编排、评测体系和反馈质量。我们如何开发这个 C 编译器 第一阶段相对直接：先搭一个小而完整、且后续能扩展的编译器骨架。 真正困难的阶段出现在功能覆盖不断扩大之后。复杂度上升带来了回归问题，单线程串行迭代效率迅速下降。 为了提速，我们改成并行代理工作流：由一个 Claude 统筹多个专项 Claude 同时推进：语法解析与 AST类型系统与语义检查代码生成与 ABI 修复测试分流与缺陷定位并行运行 Claude 在规模化阶段，团队累计运行了 2,000+ 次 Claude 编程会话，API 计算开销约 20,000 美元。 并行化成为核心生产力杠杆。与其等待单条长链路慢慢收敛，不如把问题拆成可独立推进的轨道，并把通过测试的改动持续合并。 整个协作方式已经很像一个小型工程团队：先明确子问题边界给每个 Claude 代理分配限定上下文并发执行最后通过测试统一收敛 这个模式也清楚地暴露了能力边界。Claude 在首稿产出、重构和系统化修复上表现很强；但当需求定义不清晰，或缺乏人类对长期架构一致性的持续把控时，效果会明显下降。我们的评测方法 评测不是补充环节，而是推进速度的核心基础设施。 我们组合使用了多种测试机制：来自 C 生态现有测试集的正确性检查与 GCC 的差分行为对比边界条件与压力场景的 torture 风格测试面向真实代码的兼容性与运行验证 项目大量借鉴了编译器领域经典的 torture test 思路，并反复把输出行为和 GCC 做对照，以校准可信度。 随着测试覆盖变广，故障变得更隐蔽、定位更困难。为此，我们构建了一个调试 harness：先让 GCC 编译大部分文件，只让 Claude 的编译器编译选定子集。如果程序仍能正常工作，问题就不在这个子集；如果程序出错，再继续缩小子集范围。这种方法让故障定位明显加速。 随着关键解析、语义和代码生成问题逐步修复，基准表现显著提升。在一次代表性评测中，通过率从约 70% 提升到了接近 90%。Claude Code 当前的边界 即便有这些进展，这个项目仍然清晰地展示了当前上限。多 Claude 编程协作的经验人类方向仍然是…