标题：Claude 不是编译器
2025 年初，我写过一篇《Claude 是编译器吗？》，当时我的回答是：不确定。
现在我很确定答案是“不，那是个范畴错误，它比编译器更好。”不过，这需要稍微拆开来讲。
计算机程序的复杂和精细是出了名的。程序运行在对精度的极致要求之上，根本没有“糊弄一下”这种 CPU 指令。与此同时，高层目标往往缺乏明确的细节描述。
在一个高度简化的世界观里，软件是分层构建的，每一层都在补充规格、隐藏“无关紧要”的细节。愿景变成战略，产品计划变成编码计划，代码变成二进制。每一层由不同角色负责：高管、副总裁、产品经理、架构师、工程师、编译器。
关键在于，每一步都要做大量决策——这正是“提升规格细化程度”的含义。（这也是我招聘工程师时两个关键指标之一：判断力，另一个则是协作精神。）
最底层，从源码到二进制，就是编译器干的活。编译器要做很多决定：内联、寄存器分配、是输出警告还是直接拒绝程序。这些决定很重要，它们影响性能、系统稳定性、可预测性和故障模式。编译器工程师的工作，就是让编译器始终做出好的决策。
一个好用的、值得信赖的编译器，能让软件工程师摆脱这些决策负担。大多数工程师并不清楚编译器内部原理，但他们不需要懂也能高效工作。
2025 年，我们活在用大语言模型（LLM）生成小段代码的世界里。在这种思维模型下，编码智能体就像插在软件工程师和传统编译器之间的一个新层级：它把自然语言“编译”成代码，代替工程师做决策。它的价值，取决于它的可靠性以及它能代劳的决策规模。
问题是，这个高度简化的世界观是错的。抽象会泄漏，层次之间会摩擦。即便不泄漏，我们也会主动去捅破它们。
跨层工作非常宝贵——对底层机制的理解至关重要。
Claude 不是编译器
帝国大厦之所以能在预算内、不到一年时间建成（没错，这是真的），靠的一部分诀窍就是系统性地进行跨层级协作。举个例子，在决定外墙使用铬镍钢覆层时：
无论是建筑师、施工方还是分包商，没人觉得不经过充分协商就能独自解决这个复杂的技术施工问题。因此，经过前期充分讨论后，他们召集了一次全员会议，参会者包括业主代表、建筑师和施工方、轧制材料的分包商、负责制造金属件的工人、负责安装的工人，以及在各个制备阶段对所有板材进行检测的质检员。
无论是建筑师、施工方还是分包商，没人觉得不经过充分协商就能独自解决这个复杂的技术施工问题。因此，经过前期充分讨论后，他们召集了一次全员会议，参会者包括业主代表、建筑师和施工方、轧制材料的分包商、负责制造金属件的工人、负责安装的工人，以及在各个制备阶段对所有板材进行检测的质检员。
这话说出来，谁都觉得理所当然。
可在实际工作中，我们偏偏总在这个环节翻车。我光是想象一下那些金属工人有机会去引导设计，让活儿不再那么又慢又受罪，就觉得他们肯定开心坏了。
翻车的原因之一，是我们根本不知道哪些事情值得去问。顶尖高管之所以对自己的行业了如指掌，不是没有道理的。我猜另一部分原因可能是轻视（"一个流水线上的金属工人能告诉我什么？"）。但更大的一块，其实是沟通和组织上的成本。层级存在是有道理的——信息隐藏让组织能够规模化。
标题：Claude 不是编译器
Claude 比编译器更好，因为它能垂直贯穿整个技术栈。如今，大语言模型（LLM）能讨论战略、产品、架构、代码，甚至机器码。在大多数单项任务上，它（目前还？）比不上经验丰富、专注的资深工程师，但它能包揽所有任务，而且不用开会，也不用等待审批。
下面是个具体例子。
exe.devVMs 的虚拟机有漂亮的域名：vm-name.exe.xyz。新开一台 VM 时，我们加一两条 CNAME 记录就行。很简单，对吧？
但我们的 VM 启动很快，快到就算在创建 VM 之前就把 DNS 记录配好，用户还是得等 DNS 传播——有时要等好几分钟，而不是几秒。
我们做了最直观的事：自己写了一个 DNS 服务器，让 DNS 总能立刻匹配数据源。问题解决了。
可延迟很重要，所以我们又加了多个区域。这一加，DNS 又成了瓶颈——因为所有 DNS 请求还是从俄勒冈流出。另外，部署时还会导致短暂的 DNS 宕机。要解决这些问题，我们需要的只是一个地理分布且完全一致的 DNS 服务器。
面对这个棘手问题，我们采取了明智工程师的惯用手法：偷懒。我们用“氛围感工程”搞了一个针对自身需求定制的分布式 DNS 服务器。
目标很清晰：降低俄勒冈以外用户的延迟，提高服务的容灾能力。但其他方面都没头绪。从我们想要的具体行为（特别是各种故障场景下的表现），到如何融入公司整体规划，再到最能实现这些目标的架构，一直细化到具体的实现细节——我们得把这些全部摸索清楚。
我们当面敲定了最高层的战略和架构决策：做一个相对通用的 DNS 服务器，再叠加上我们自己特定的行为调整；采用中心辐射模型；用追加复制策略；边缘节点做持久化。
剩下的事就是真正把它造出来了。