文章指出，Claude并非编译器，而是比编译器更高级的工具。编译器仅处理从源代码到二进制文件的底层决策，而Claude能处理从愿景到代码的多个抽象层级的决策，体现了更强大的判断力。

好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节，并删减了与主题无关的冗余内容。

标题：Claude 不是编译器

2025年初，我曾撰文探讨“Claude是编译器吗？”，当时我的答案是“不确定”。如今，我确信答案是否定的，并且这是一个范畴错误——它比编译器更强大。

计算机程序极其精密复杂，不存在“模糊处理”的CPU指令。在理想化的软件构建模型中，每一层都增加规格说明，隐藏“不必要”的细节：愿景变为战略，产品计划变为编码计划，代码变为二进制。每一层都由不同角色处理：高管、副总裁、产品经理、架构师、工程师、编译器。

关键在于，每一层都涉及大量决策。编译器从源代码到二进制，就做出了大量决策（如内联、寄存器分配），这些决策直接影响性能、稳定性和故障模式。一个优秀的编译器能解放软件工程师，让他们无需操心这些底层决策。

2025年，我们使用LLM生成小段代码，在这种模式下，编码代理可能作为软件工程师和传统编译器之间的新层级，将自然语言“编译”成代码。其价值取决于可靠性和决策规模。

然而，这种理想化的模型是错误的。抽象会泄露，层级会摩擦。跨层级工作极具价值，机械共鸣至关重要。例如，帝国大厦能在一年内、预算内建成，部分原因就是系统性地跨层级协作：建筑师、建造商、分包商、金属工人、检验员等各方共同参与决策。

Claude优于编译器，因为它能垂直贯穿整个技术栈。LLM现在能讨论战略、产品、架构、代码乃至机器码。它可能无法像经验丰富的人类专家那样出色地完成单项任务，但它能完成所有任务，且无需安排会议或请求许可。

以下是一个具体例子。我们的虚拟机有域名，但DNS传播延迟成了问题。我们编写了自己的DNS服务器，但增加区域后，延迟和部署时的DNS中断再次成为瓶颈。于是，我们“取巧”地构建了一个针对特定需求优化的分布式DNS服务器。

我们当面敲定了最高层的战略和架构决策：构建一个通用DNS服务器，叠加特定行为调整，采用中心辐射模型、追加复制策略，并在边缘节点实现持久化。

接着，我让LLM研究分布式DNS系统的标准设计、教授DNS的细节和怪癖、指出历史安全缺陷、探索替代实现策略、研究开源方案、模拟故障模式并规划测试策略。在有了初步设计草图后，我提示多个并发的代理循环来构建整个系统，包括测试和对抗性代码审查。它们提出了大量问题，涵盖从主要结构方法到代码行级细节的各个层面。我通过回答这些问题，将所学转化为非常简洁的书面指导，将重要的决策固化下来。

然后，我让新的代理比较完成的实现，寻找有趣的差异。令人震惊的是，代理们从未询问就自行做出了许多重要决策，且决策方式各不相同。例如，在复制策略中，数据库回滚会破坏“仅追加”的约定。不同代理的解决方案截然不同。我最终采用的设计是为每一行数据添加一个“时间线”字段，通过随机生成的时间线值来检测历史是否被篡改，从而回退到完全重新同步。

我重复了两次完整的“差异规格分析”过程。在准备构建最终版本时，我积累了一份“伤疤文档”，它足以指导代理在每一层做出大部分重要决策，从高层目标到架构，再到底层细节。

最终系统包含单元测试、端到端测试、用于降低生产部署风险的影子模式，以及一套由代理编写、供代理使用的简洁文档。这总共花费了我大约一周的注意力，我阅读的实际代码量微乎其微。当同事提问时，我能自信地回答所有问题。一个月后，DNS事故数为零。

在这里，Claude不仅仅是编译器。我从未将任务交给代理，让它自行做出一堆决策来简化实现——那是“氛围编码”。相反，Claude是一个垂直整合的资源，一个“多编译器”。它跨层级工作的能力加速并增强了我做出不同层级决策的能力，包括判断哪些决策是重要的。这就是“氛围工程”。

在一切重要的方面，我都理解这套代码。当然，如果现在要我手动编辑它，会有学习曲线，但我无需这么做。更重要的是，我能推理这个系统，与同事交流观点，并指导代理进行未来的工作。我们留下了一份持久的工件，它封装了设计中核心的、有意的、值得记录的所有方面。

这个时代的问题之一是：软件工程师需要理解他们工作的系统到什么程度？精心选择的层级能提供理解。一些软件层级正在消亡，因为它们只提供便利，而不提供额外的洞察。但那些能让我们以可理解的方式表达重要决策的层级，将会留存。

我们正将更多注意力转移到技术栈的上层，但并未完全放弃底层。代理不是让我们放弃对系统深层理解的特权。软件工程师正在被拉伸，这既令人兴奋又令人疲惫。但越来越清晰的是，在不久的将来，“氛围工程”就是工程本身。

根据评论内容，主要围绕“Claude是否可被视为编译器”以及“AI生成代码的可信度与审查问题”展开讨论，观点分歧明显。以下为总结：

1. 关于“Claude是编译器”的类比争议 - 支持类比的观点：部分评论认为Claude在代码生成模式上类似编译器，如LiquidHaskell，能根据规范自动生成代码（评论18）。另有观点指出，LLM改变了编程方式，从历史角度看与编译器有相似性（评论13）。 - 反对类比的观点：多数评论强调编译器是确定性的，而LLM是非确定性的，会犯错（评论9、13、20）。评论9指出：“A compiler almost never produces a wrong output... Claude makes mistakes”。评论13补充：“The non deterministic nature of an llm breaks the metaphor that they are like a compiler”。评论16提出更精确的类比：“Claude is more like a Probabilistic Turing Machine”。

2. 对AI生成代码的信任与审查问题 - 信任但需验证：评论20提出两种选择：审查所有代码（失去速度优势）或通过强测试套件验证（可能遗漏错误）。评论14强调需关注“decision exhaust of agents”，即AI做出的决策痕迹。 - 不信任AI生成代码：评论24直言：“if I know something is vibe coded, I just won't use it”，认为质量不可靠。评论12指出Claude会遗漏工程师、系统管理员等角色本应发现的步骤和错误。 - 对“不读代码”的批评：评论10表示：“I don't get not reading (or at least familiarizing yourself with) the code that you will deploy to prod”。评论21反驳作者声称“理解代码”的说法：“If there's a serious learning curve to editing code then you don't understand the code”。

3. 对AI辅助开发流程的反思 - 积极体验：评论3称赞exe.dev的服务：“it's really cool to just vibe code a little website with Shelley and have it running in minutes”，认为降低了摩擦。 - 流程问题：评论15批评“spec-first”思路：“Specs do not appear out of nowhere, they co-evolve with the code”。评论19讽刺地指出：“Waterfall is dead, long live waterfall!”，暗示AI辅助开发可能回归瀑布模型。 - 未来展望：评论17提出未来可通过spec/prompt引用代码，并用哈希确保完整性。评论18预测人类语言可被形式化，产生优于LLM的规范语言。

4. 技术细节与风险 - DNS架构问题：评论4指出DNS缓存问题无法从服务器端解决：“it doesn't matter how fast your own DNS implementation is, as the users lookup request wont hit your DNS server, it'll hit an intermediate cache”。评论23担忧AI做出的架构决策可能产生未预期后果。 - 非确定性风险：评论16列举计算机科学中非确定性的合理应用（如UDP、随机梯度下降），但强调需要“Las Vegas algorithm, a probabilistic machine with a cheap verifier”。

总结：评论普遍认为“Claude是编译器”的类比过于简化，忽略了LLM的非确定性和错误倾向。对AI生成代码的信任度存在分歧，多数人主张必须审查或通过测试验证。AI辅助开发可能改变工作流程，但需警惕“不读代码”的风险和架构决策的潜在问题。