原文：Josh Bleecher Snyder，《Claude Is Not a Compiler》，发布于 2026 年 7 月 20 日，blog.exe.dev。本文为摘要整理，供个人学习参考。
一、从"Claude 是编译器吗"说起
作者在 2025 年初曾写过一篇《Is Claude a Compiler?》，当时给出的答案是"不知道"。这次他给出了更明确的判断：这个类比本身就是范畴错误——Claude 不是比编译器差一点或好一点，而是完全不同的东西，某种意义上"更好"。
理由要从软件是怎么分层构建的说起。
二、软件的分层与"决策"
作者提出一个高度简化的模型：软件从"愿景"到"二进制文件"要经过一层层加工——愿景变成战略，产品计划变成编码计划，代码变成二进制。每一层通常由不同角色负责：高管、VP、产品经理、架构师、工程师、编译器。
关键点在于：每一层都在做决策。从源码到二进制这一层，是编译器的工作——内联、寄存器分配、要不要报警告还是直接拒绝编译，这些决策会直接影响性能、稳定性和失败模式。一个好的、可信赖的编译器能把工程师从这些决策中解放出来，绝大多数工程师并不需要理解编译器内部原理也能高效工作。
在 2025 年，人们更多把 LLM 当作生成小段代码的工具，编程 Agent 被想象成插在"工程师"和"传统编译器"之间的新一层：把自然语言"编译"成代码，替工程师做决策。它的价值和它的可靠性、能处理的决策规模成正比。
三、问题在于：分层模型本身是假的
作者指出，这种"整整齐齐的分层"模型其实是虚构的——抽象会泄漏，层与层之间会摩擦，即便理论上不摩擦，人们实践中也会主动去戳破它。
他用帝国大厦的建造案例作对比：这座楼能在一年内、预算内建成，很大程度上是因为系统性地跨层协作——比如决定外墙镀铬镍钢材料时，业主代表、建筑师、承建商、分包商、金属加工与安装工人、质检人员会被拉到同一场会议上，共同讨论一个复杂的技术问题。
道理听起来很简单，但现实中人们经常做不到：一部分原因是不知道该问什么、不知道谁值得问；一部分是轻视一线经验；更大一部分则是纯粹的沟通和组织成本——分层的存在本身就是为了"隐藏信息"，从而让组织能够规模化运作。
作者认为，Claude 之所以比编译器更强，正是因为它可以纵向贯穿整个技术栈工作：从战略、产品、架构、代码，一路谈到机器码。它未必在单项任务上比一位资深专才做得更好，但它可以同时覆盖所有层级，而不需要开会、不需要层层审批。
四、一个具体案例：给 exe.dev 造一个分布式 DNS
exe.dev 的虚拟机会分配 vm-name.exe.xyz 这样的域名。最初的做法很直接：VM 创建时加几条 CNAME 记录。但公司自建的 VM 启动速度太快，用户反而要等 DNS 传播生效（有时要等几分钟）。
第一次迭代：团队自己写了一个 DNS 服务器，让 DNS 记录始终和真实数据源保持同步。
第二次迭代：随着业务上了多地区部署，DNS 因为只从美国俄勒冈一个地方提供服务，反而成了新的延迟瓶颈，部署时还会造成短暂的 DNS 中断。于是团队需要一个"地理分布但强一致"的 DNS 服务器——这是个不小的工程挑战。
作者选择的方式，用他自己的话说，是"vibe-engineer"出一个针对自身需求定制的分布式 DNS 服务器：
- 明确目标、留白细节：降低远地区用户延迟、提升可用性是清晰的目标，但具体行为、失败模式下的表现、架构选型都还没定。
- 高层决策当面拍板：团队当面确定了通用型 DNS 服务器 + 定制行为、hub-and-spoke 拓扑、只追加（append-only）的复制策略、边缘节点持久化等关键架构决策。
- 让 LLM 做纵向研究和实现：用 LLM 调研分布式 DNS 的标准设计、补齐 DNS 协议的细节知识、梳理历史上的安全漏洞、探索实现方案（比如放弃了 AXFR/IXFR）、调研开源方案、推演失败场景、规划测试策略。
- 多个并发 Agent 各自实现一版：每个 Agent 在实现过程中都会在各个层级提出问题——从大的结构性方案到具体代码写法。作者在回答这些问题的过程中，逐渐把学到的东西沉淀成简短的书面设计指南。
- 差异化审查：让新的 Agent 去对比不同实现，寻找有意思的分歧点。结果发现，很多重要决策 Agent 从未主动询问，而是自行做出了完全不同的选择。
书中举了一个典型例子：复制机制本应是"只追加"的，但数据库回滚这种小概率事件会打破这个假设。不同 Agent 给出的方案完全不同，作者最终选定的方案是给每一行数据加一个随机生成的"timeline"字段，用来标记该行所在的"时间线"；一旦同步请求发现时间线不匹配，就说明历史被改写过，此时会退回到完整的全量同步。
不同 Agent 实现出来的系统在风格上也有明显差异——Claude 和 Codex 都认为 Claude 写出来的系统更优雅，但 Codex 的实现更细致周全。
这个"设计 → 多方实现 → 差异对比 → 补充书面指南"的循环，作者反复跑了两遍以上，呼应了 Fred Brooks 那句关于"计划报废一版原型，你终究还是会报废"的经典说法。
最终交付物包括单元测试、端到端测试、用于生产环境灰度验证的影子模式，以及一套面向 Agent 撰写的精简文档。整个项目占用了作者大约一周的注意力，而他读过的实际代码量非常少。项目上线后，作者去休了假；一个月后 DNS 相关事故数为零。
五、"vibe-coding" 与 "vibe-engineering" 的区别
作者特别强调：这次经历中，Claude 并不只是一个"编译器"——他没有简单地把任务甩给 Agent，让它自主做一堆决策然后把结果落地，那种做法叫 vibe-coding。
真正发生的是：Claude 成了一个纵向整合的资源、一个"多重编译器"，它跨层工作的能力放大了作者本人在不同层级上做决策（以及判断哪些决策真正重要）的能力——绝大多数具体代码行其实并不值得单独决策。这种模式，作者称之为 vibe-engineering。
他表示自己在所有重要意义上都"理解"这套代码：如果现在要手动改代码，会有一段学习曲线，但他不需要这么做；更重要的是，他能对这个系统进行推理、能和同事交流架构思路、能指导 Agent 完成后续工作，而且沉淀下来的文档记录了跨越所有层级的关键设计决策，能在未来的 bug 修复和代码变更中持续发挥作用。
六、哪些"层"会消失，哪些会留下
作者认为，这个时代的核心问题之一是：软件工程师到底需要理解系统的哪些部分？
选得好的分层能提供理解力——就像经典力学虽然不如基本物理定律"全面"，但在解释"为什么坐大巴比坐小车更安全"这类问题上反而更有用。
一些软件层正在消失，因为它们只提供便利，不提供额外的洞察力（作者举了 Tailwind 作为例子）。但那些能让人以可理解的方式表达重要设计决策的层，会留存下来。
工程师的注意力正在向技术栈上层转移，但并没有完全放弃底层——就像 Go 标准库绝大部分用 Go 写成，但少数关键例程仍然用汇编手写，编译器在那里是不可依赖的。
七、结语
作者的结论很直接：软件工程师正被"拉伸"到更宽的能力范围里，这个过程令人兴奋，也令人疲惫。但可以确定的一点是——在不远的将来，vibe-engineering 就只是……engineering。
本文根据 Josh Bleecher Snyder 原文整理，原文地址：blog.exe.dev/claude-is-not-a-compiler，仅供个人学习参考。