编译器在计算机科学里占据着一个特殊的位置。它是计算机科学教育中的经典课程。亲手写一个编译器，几乎像是一种成人礼。因为你必须直面软件到底是如何工作的：语言、抽象、硬件，以及人类意图与机器执行之间的边界。
编译器曾经帮助人类与机器对话。如今，机器开始帮助人类构建编译器。
我职业生涯中很大一部分时间都在做编译器与编程语言相关的工作，所以当 Anthropic 发布 Claude C Compiler（简称 CCC）时，我格外留意。我的基本结论很简单：这是真正的进步，是行业的一个里程碑。我们并没有走到世界末日，但这也绝不是纯炒作，所以大家先深呼吸一下。
AI 能构建一个 C 编译器并不“彻底革命”，但它确实揭示了 AI 编程已经走到什么程度，以及下一步可能走向哪里。
在展开之前，我先给出我的核心要点总结：
- AI 已经不再局限于写一些零碎的小片段代码，它开始参与构建大型工程系统。
- AI 正在从“局部代码生成”跨越到“全局工程参与”：CCC 能在跨子系统的层面维持架构一致性，而不仅是写函数。
- CCC 的设计带有“LLVM 风格”（这并不意外）：当模型训练于几十年的编译器工程实践时，产物自然会被那段历史塑形。
- 法律体系往往落后于技术进步，AI 正在推动法律边界：专有软件的护城河是否正在被“煮熟”？
- 好软件依赖判断力、沟通与清晰的抽象，而 AI 放大了这些因素的重要性。
- AI 编程本质上是对“实现”的自动化，因此“设计与治理”会变得更重要。
- 手工重写、迁移、翻译类工作正在变成 AI 原生任务，自动化了大量工程工作量。
- AI 若使用得当，应当能产出更好的软件，前提是人类确实把更多精力投入到架构、设计与创新。
- 架构文档正在变成基础设施：AI 会放大结构化知识，也会惩罚缺乏文档的系统。
- 对工程团队的影响是真实且立刻发生的。文章最后，我会分享我如何把这些洞察转化为我对 Modular 团队的具体期望。
什么是编译器？为什么它能成为 AI 的基准测试？
要理解 Claude C 编译器为什么重要，我们得先理解：为什么编译器本身是一个如此“揭示智力”的测试对象——无论是对人类还是对人工系统。
编译器位于多个困难领域的交叉点：形式语言设计、大规模软件架构、严苛的性能约束，以及毫不留情的正确性要求。
大多数应用程序可以容忍一些 bug，编译器不行。一个错误的变换可能悄无声息地产生错误程序，影响无数用户的生产力。编译器的每一层都必须维持严格的不变量，并与其他层配合协作。
历史上，这也是编译器成为计算机科学教育“成人礼”的原因。它迫使工程师跨越抽象层思考：把文本变成结构，把结构变成意义，把意义变成经过优化的机器行为。
这个过程映射到更深的一件事：把人类意图翻译成精确执行。这也是为什么编译器对于 AI 系统整合来说，是一个独特而有趣的基准。
更早一代的 AI 编程工具，在局部任务上已经很厉害：写函数、生成脚本、补齐缺失代码。这类任务主要考验模式识别与短程推理。
Claude C 编译器则代表了不同层级的进展。它展示了一个 AI 系统能够在整个工程系统范围内保持连贯性：协调多个子系统、维持架构结构、通过测试与失败在时间维度上迭代逼近正确性，并在复杂反馈回路中运作。AI 正在从代码补全走向工程参与。
更深层的原因在于：编译器的工程架构通常高度清晰且结构化。编译器有分层抽象、一致命名、可组合的 pass，以及确定性的反馈标准（“能工作”或“不能工作”，成功标准很清楚）。这些属性让编译器对人类可学，也让在海量源码上训练的机器学习系统同样更容易“学会”。
从这个角度看，CCC 其实也是对几十年软件工程实践的一次验证：编译器工程师发展出的抽象足够结构化，以至于机器如今能够在其中推理并行动。这是一个非常惊人的里程碑。但它同样暗示着一个重要限制。
走进 Claude C 编译器内部
CCC 最有趣的一点在于：Anthropic 公开了完整的源码历史。与许多 AI 演示不同，这不是一个“包装好的成果”或单一基准分数，而是一个任何人都能检查的工程产物：整个仓库，包括提交历史、设计文档与未来计划，都可以直接审阅。这意味着我们能真正研究系统是如何构建一个编译器的。我也确实花了一些时间做了这件事。
第一个重要提交几乎是“一次性”把系统的基本架构定了下来。从一开始，CCC 就遵循经典编译器结构。仓库里的主要子系统都配有相当出色的设计文档，包括：
- 一个前端：负责预处理、解析与语义分析（这是所有编译器的共同部分）
- 一个中间表示与优化体系：明显直接受 LLVM 启发
- 一个后端：负责代码生成，支持四种架构（x86-32、x86-64、RISC-V、AArch64）
整个仓库里做出的选择，几乎都反映了成熟的编译器实践：大学课程里教的东西，以及 LLVM、GCC 这类主流编译器广泛采用的技术。它的 IR 中包含许多 LLVM 开发者一眼就熟悉的概念，比如 GetElementPtr、基本块的 terminator、Mem2Reg 等指令与 pass。它显然对常用编译器设计技术掌握得很扎实。
LLVM 与 GCC 的代码显然属于训练集的一部分——Claude 在 CCC 里等于是把其中相当一部分翻译成了 Rust。设计文档也显示它对两套系统的理解很细，并且对自己的实现方式有经过思考的取舍。有人批评 CCC 是从既有成果中“学来”的，但我觉得这种批评很荒谬——我当年做 Clang 时也大量学习 GCC！
Pushpendre Rastogi 写过一篇很棒的博客，讨论 CCC 与 agent scaling laws，并展示了迭代式 agent 工作流如何逐步扩大实现范围与测试覆盖：
综合来看，CCC 更像一个“能力不错的教科书实现”，类似一个很强的本科团队在项目早期阶段能做出来的那种系统——尚未经过多年打磨，但结构上已经相当像样。仅这一点就已经非常惊人。
Claude C 编译器做错了什么？
CCC 最揭示问题的部分，恰恰是它的错误。有些设计选择看起来更像是在优化“过测试”，而不是像人类工程师那样构建可推广的抽象。例如：
- 代码生成器更像“玩具级”，优化器甚至会重新解析汇编文本，而不是使用 IR；代码生成器的模块化拆分也不够好。
- 解析器的错误恢复能力与可用性似乎较弱，并且存在一些错误的边界情况。
- CCC 似乎无法解析系统头文件（系统头通常比应用代码“难啃”得多），因此它把测试所需的一些东西硬编码了。
最后这一点尤其关键，它强烈暗示 CCC 很难在测试集之外泛化，而 bug tracker 似乎也印证了这一点。这些缺陷与其说“令人意外”，不如说“信息量很大”：它表明当前 AI 系统擅长组装已知技术、并朝可度量的成功标准优化，但在构建生产级系统所需的开放式泛化能力上仍然吃力。
而这就直接引出了更深的问题：这对 AI 编程本身意味着什么？
Claude C 编译器揭示了 AI 编程的什么本质？
CCC 最重要的启示不在于“AI 能写编译器”，而在于它“是怎么写的”。CCC 并没有发明新架构，也没有探索陌生设计空间。相反，它复现了一个非常接近编译器工程几十年沉淀共识的东西：结构正确、风格熟悉、基于成熟技术。
现代大语言模型是极其强大的“分布跟随者”。它们从大量既有工作中学习模式，并生成靠近集体经验中心的解决方案。当它训练于由 GCC、LLVM 与学术文献塑造的几十年编译器史时，产物自然会体现那条谱系。这与 Richard Sutton 的 Bitter Lesson 高度契合：可扩展的方法会重新发现那些广泛成功的结构。
打个比方：在英语文学上训练的模型可以写出莎士比亚式的文字，并不是因为文学在 1600 年代就停止演化，而是因为莎士比亚处于训练分布中一个极其密集的区域。模型会学习那些被大量书写、反复强化的东西。相同的机制也出现在编译器设计上（是的，编译器也会这样，吼！🐉）。
CCC 证明 AI 系统可以内化一个领域的“教科书知识”，并在系统规模上保持连贯应用。AI 现在能够可靠地在既有工程实践之内运作。这是一个真正的里程碑，它会减少大量重复性苦力，让工程师从更接近“当前最佳实践”的起点出发。
但它也凸显了一个限制：
实现已知抽象，并不等同于发明新抽象。在这份实现里，我没有看到任何新颖的东西。
历史上，编译器的进步并不是来自“更快地组装标准组件”，而是来自概念性飞跃：新的 IR、新的优化模型、新的程序与硬件交互方式、新的系统组织方式。同样重要的是，进步也来自让一群人协作——这需要以新的方式去启发并激励工程师。
当前 AI 编程系统在成功标准清晰且可验证的场景里表现极佳：能否编译、能否过测试、性能是否提升。在这种环境中，迭代式改进非常有效：红绿测试驱动开发（TDD）确实能跑通！但创新不同。发明一个新抽象时，成功尚不可度量。一个尚不存在的想法没有测试集，而“好设计”也很难量化。
因此，AI 编程更适合被理解为自动化的又一次跃迁。它显著降低了实现、翻译与打磨的成本。当这些成本下降时，稀缺资源就会向上移动：决定应该存在什么系统，以及软件应该如何演化。
当写代码变得更容易，设计软件就比以往更重要。当定制软件更便宜，真正的挑战变成选择正确问题、并管理随之而来的复杂性。我同样看到一个巨大的开放问题：到底谁来维护这些越来越多的软件？
知识产权法与专有软件护城河
CCC 也提出了一些重要但令人不舒服的知识产权问题。如果一个在几十年公开代码上训练的 AI 系统能够复现熟悉的结构、模式，甚至某些特定实现，那么“学习”和“复制”的边界到底在哪里？一些观察者指出，CCC 在某些地方似乎重新生成了与现有实现高度相似的产物，包括标准头文件与工具代码，尽管它声称是“洁净室（clean room）”开发。这些例子凸显：现行法律框架很难描述这样一种系统——它并非显式引用源代码，而是对海量既有作品进行统计学习。
与此同时，这件事并非全新。人类也是通过研究既有系统来学习、内化模式，并在新语境中重用思想。区别在于规模与自动化。AI 把几十年的工程知识压缩进一个生成模型中，能够瞬间复现解决方案。这挑战了关于“所有权”的传统假设：底层思想可能广泛共享，但具体表达仍然带有许可与权利边界。
我们正在进入一个“自动化重实现专有软件”的新时代，但这并不意味着旧范式突然失效。AI 降低了复现既有设计的成本，这会把竞争优势从孤立的代码库转移到执行力、生态系统与持续创新之上。这也将迫使法律与制度规范演化，类似当年 Linux 与开源软件广泛普及时发生的变化。正如那些转型一样，我押注我们会看到：由人类协作形成的生态系统引力，取代那些无法在快速变化时代跟上的旧生态。
自动化、创新与软件的未来
如果 AI 编程主要是在自动化“实现”，下一步会发生什么？
历史有一个清晰模式：当构建某物的成本大幅下降时，我们并不会仅仅用更便宜的方式造同样的东西。我们会开始造全新的东西。
编译器本身就是典型例子。早期程序员手写汇编，但当编译器足够可靠之后，开发者的野心被极大释放，整个产业因抽象让复杂性可控而出现。当写代码变得更容易，结果很可能不是“更少程序员”，而是“更多软件”。我们会看到更多实验、更多专用工具，以及对过去不值得自动化的问题的解决方案。
会改变的是工程工作的经济学，尤其是大规模消除机械性任务：重写、迁移、样板代码实现。这些工作必要但很少创新，而 AI 系统恰恰非常擅长它们。工程师会从“敲实现”转向“指挥系统”：更清晰地表达意图、验证结果、塑造架构。
当实现变便宜，工程师的角色会上移。稀缺技能会变成选择正确抽象、定义有意义的问题、设计能让人类与 AI 一起持续演化的系统。这会越来越模糊软件工程与产品思维之间的边界。限制因素不再是软件能不能构建，而是决定应该构建什么，以及如何管理随之而来的复杂性。AI 会放大好结构，也会放大坏结构，所以我们可以预期：管理不善的代码会更快地膨胀成难以理解的噩梦。
这又引出下一个问题：如果编程正以这种程度改变，那么软件工程师会怎样？
软件工程师角色的演化
软件开发的每次重大迁移，都会改变“做程序员意味着什么”。早期工程师直接操作硬件，后来的工程师学会信任编译器与更高级语言。每一次转变都减少手工劳动，同时抬高了对工程师能力的期待。AI 编程是这条演化链的下一步。
当实现越来越自动化，软件工程的核心技能就会从逐行写代码，转向塑造系统：决定什么该存在、组件如何拼合、如何让复杂性在时间里仍然可理解。好软件依赖判断力、沟通与清晰的抽象，而 AI 会放大这些人类品质，而不是替代它们。
最有效的工程师不会在产出代码上与 AI 竞争，而会学会与 AI 协作：用 AI 更快探索想法、更广泛迭代，把人类精力集中在方向与设计上。这些工具正在快速成为软件开发栈的一部分，就像过去的编译器、版本控制、持续集成一样。学会有效使用 AI，很快会成为核心职业技能。今天忽视 AI，就像二十年前拒绝使用源代码管理一样。
成功拥抱 AI 工具的团队与未拥抱的团队之间的差距，已经可以被衡量，并且正在快速扩大。根据 CircleCI 的 2026 年《软件交付现状报告》，工程团队中前 5% 的产出同比几乎翻倍，而后 50% 基本停滞。2025 年生产力最高的团队，其吞吐量大约是 2024 年冠军的 10 倍。
这提出了一个非常实际的问题：团队应该如何调整，才能成功？
接下来我会分享：我如何把这种变化翻译为对 Modular 的具体期望。
我希望 Modular 如何适应 AI 工具
像 Claude C 编译器这样的进展，改变了我对工程工作的看法，也改变了我对团队的要求。要真正从 AI 工具中获益，需要一次刻意的跃迁：几十年形成的习惯不会自动改变，而组织也不会因为出现更好的工具就自然完成转型。
同时我们必须务实。AI 系统很强，但远不完美。进步来自与 AI 的协作，而不是把责任甩给它。目标不是把人从回路中移除，而是把人移到回路中更高杠杆的位置。
因此我提出三个期望。
1）积极采用 AI，但保持问责
每位员工，无论是工程、综合管理与行政（G&A），还是市场拓展（GTM），都应当主动采用 AI 工具来加速生产力与决策。世界变化太快，我们必须拥抱变化。
关键是：这不意味着把责任转移给工具。比如，构建大规模生产系统的工程师仍然要对正确性、设计质量与长期可维护性负责。AI 扩展了我们的能力，但不能外包判断。使用 AI 产出的工作，也必须像手写工作一样被理解、验证并拥有。个人声誉仍然建立在结果上，而不是提示词上。
2）把人的投入上移到更高层
历史上，大量工程努力都花在机械性工作上：重写代码、适配接口、系统迁移、在新环境里复刻既有模式。AI 正在迅速变得比人更擅长这些事情。我们不应在机械性工作上与自动化竞争。相反，工程师应该更严格地澄清意图，用测试验证结果，提升设计质量。
人类精力应该集中在创造力与判断力最重要的地方：并且所有工程师现在都拥有管理责任。当迁移与实现大幅加速，架构演化的限制因素不再是人类能多快重写软件，而是我们能多清晰地定义系统下一步该走向哪里。
3）投资结构与社区
AI 会放大结构。
文档良好、结构清晰的系统，会变得更容易扩展与演化；结构糟糕的系统，会更快地扩张成混乱。文档、清晰接口、显式设计意图，如今是运营杠杆，而非可选的“额外开销”。
当实现成本趋近于零，稀缺资源会从写代码转向对齐人。最大的机会在于建立志同道合者的社区，让他们围绕共同目标协作，形成生态系统，让开发者一起向前，而不是反复重建过去。
对我的团队而言，这意味着专注于能帮助其他开发者成功的工具与平台：推动既有代码向前演进、解锁现代算力、让人类与 AI 能共同协作的系统。这与 Modular 的使命直接一致：让 AI 算力民主化，扩展全球程序员能够创造的边界。
结语
Claude C 编译器并不标志着软件或编译器工程的终结。恰恰相反，它把门推得更开了。实现越容易，就越有空间容纳真正的创新。
降低实现门槛不会削弱工程师的重要性；它会抬高愿景、判断力与品味的重要性。当创造变容易，“决定什么值得创造”就成了更难的问题。AI 加速执行，但意义、方向与责任仍然根本上属于人类。
写代码从来不是目标。构建有意义的软件才是。未来属于愿意拥抱新工具、挑战旧假设，并设计出让人们能共同创造的系统的团队。
这正是 Modular 从一开始就坚持的未来，也是我相信 AI 新时代能够实现的未来。