Claude不是编译器，而是全栈多编译器
Claude Is Not a Compiler
2025年我曾疑惑Claude是否是编译器，如今我确信这是个范畴错误——它比编译器更强大。传统编译器处理从源码到二进制码的底层决策，而Claude能跨越战略、产品、架构到代码的全栈层级。在构建分布式DNS服务器时，我并未简单将任务丢给AI，而是利用Claude在每一层辅助决策，从高层规划到细节实现。它像一位垂直整合的‘多编译器’，加速并增强了我跨层级做决策的能力，而非仅仅生成代码。这种工作模式打破了传统分层壁垒，让抽象层之间的协作成为可能。
Claude之所以优于编译器，是因为它能垂直跨越整个技术栈进行工作。
HN 评论区
162- gritzko
LLM-is-a-compiler 确实是一种过于简化的观点。我昨天针对 Cursor 的那篇文章写了一篇反驳文，或许可以在此复用：https://replicated.live/blog/follow-up
认为一份 835 页的规范“凭空存在”，然后我们只需运行一个 LLM 去实现它，这种想法完全站不住脚。规范不会无中生有，它们是随代码共同演化的。如果你已经有了代码，为什么还要重新生成一遍？
优秀的软件是无数次反馈循环的产物，而 LLM 能让你更快地运行这些循环。但它们并不能替代整个流程。
归根结底，一个好的产品就是提炼后的反馈之桶。
- couchand
当你拆解这里的论点时，会发现它简直荒谬透顶。
1) 帝国大厦之所以能高效建成，很大程度上得益于人与人之间深度的协作。
2) 难道我们烧掉一堆恐龙的血液（化石燃料），就能说服自己不再需要其他人了吗？这难道不是很棒吗？
- cadamsdotcom
标题属实，文章内容虚假。
AI 存在于“形式化”的边界上。当你足够理解某事，能够用确定性的方式将其表达出来时，就没必要反复向 AI 询问同一件事了——你应该将其形式化（codify）。
但等等，我听到你在说？AI 拥有知识！我们可以依赖这些知识，再稍微加几句简短指令，它就能把事情做对，并自行搞定细节！
这就是规范驱动开发（spec driven development）。
而且这仅在一次性场景下很完美。然而，知识是会变迁的。你实际上是将自己已形式化的部分内容，以语言模型知识的形式外包给了整个社会。你同时也信任当前及未来的模型总能产出符合要求的结果，永远不会在你不知情的情况下被量化（quantized），并且尽管它是一个没有记忆的随机概率系统，下次也能产出完全相同的结果，诸如此类。
更好的做法是将一切在你的代码库中固定下来，以获得可预测的结果——换句话说，将其形式化！让我们把那个按钮的预期状态存储在一个几十年前就存在的、非常复杂的叫“字符串”的东西里，这样它永远显示“Finish”，绝不会变成“Done”——哪怕我们重新生成了整个应用。
这听起来很无趣，也解释不了数十亿美元的投资。这意味着那些手里有代币要卖的人绝不会告诉你这个。但如果你想做出人们真正想要的东西，这就是你必须做的。
- davidpapermill
我听过很多次类似这样的说法：“Claude 就像编译器：源代码就是新的目标代码，你再也不需要看它了”。
但我并不认为这是真的。编译器通常是确定性的，虽然我们可能会发现边缘情况，但这与一个 AI 代理为你编写所有代码的情况完全不同。
我认为，鉴于 Claude 是一个代码生成器而非编译器，你只有两个选择：(a) 审查大部分或全部代码以确保其逻辑合理，或者 (b) 信任但通过强大的测试套件进行验证（该套件可能也是由 Claude 生成的）。
(a) 的问题在于你会损失掉大部分的速度提升。(b) 的问题在于你失去了人工监管，代码可能不完整、设计糟糕，或者干脆就是错的。
目前我们审查所有代码，因为正确性对我们所做的工作至关重要，但这也是有代价的。
我目前不知道这里的一般性答案是什么。信任会随着时间积累吗？模型会变得足够好，以至于我们可以信任它们零失误吗？
- eigencoder
我真的很喜欢 exe.dev 正在做的事情。他们关于云服务如何运作的理念令人惊叹。我订阅了他们的月度服务，真的很有趣，只需和 Shelley 一起“凭感觉”（vibe）写点代码，几分钟内就能跑起来一个小网站。我觉得使用他们的服务非常有趣，花在思考成本或选择哪种云服务上的时间少了很多。与其他云服务相比，它简单得多，摩擦也少得多。
- kloud
规范（Specs）可能会成为应对日益增长的代码审查需求的一种解决方案。规范是比代码更高一层的抽象，而代码又是比机器码更高一层的抽象。行业曾经完成过一次向更高抽象层的过渡，范式正在改变，所以这可能会再次发生。
我想象的工作流是：要么从对话中推导规范，要么将代码逆向工程为规范，然后审查并编辑规范（这应该更紧凑、压缩度更高），最后确定性地将规范编译为代码。当然，我们不想只做“规范优先”，那会回到瀑布模型，而是要进行来回迭代。
现在，Claude 不是编译器，因为它是封闭且非确定性的（他们在服务器端进行不透明处理，隐藏推理 token），但 LLM 未来可能是。我们通过名称引用 npm/pip 中的代码片段来下载代码。然后我们使用包含哈希值的 lockfile 来确保完整性。目前我们是在“凭感觉”（vibing）操作，但未来我们可以通过提示词/规范来引用代码片段，并通过推理获取代码。为了确保完整性，lockfile 将是开放权重和推理代码的哈希值（并解决因 GPU 调度等导致的非确定性等实现细节）。
- trjordan
> Claude 在这里不仅仅是一个编译器。我从未将任务完全移交，让代理自行做出一堆决定从而将其付诸实践。
> 我会说，在所有重要的方面，我都理解这段代码。
我认为这里的认知失调非常重要，而且绝非坏事。许多决定确实交给了 AI，但它们并非作者所关心的那些决定。这正是 AI 的一大卖点！如果某件事能用电脑完成，它就会搞定。30 分钟和 2 亿 token 之后，它会把任何想法都变成“功能已完全实现”。
困难的部分在于弄清楚在哪里注入这种摩擦，以便你能看到它在为你做哪些重要的决定。作者通过逐步构建事物，在每一步都进行审查、试探和推敲，从而处理了这个问题。在一堆设计讨论之后投入一周的注意力，这很快，但这仍然不是微不足道的廉价成本。
我希望看到我们更多地讨论代理的“决策耗散”（decision exhaust），因为模型越好，我们就越希望它们做出更多决定。
我在这里写了一些更多内容：https://tern.sh/blog/compiler-never-says-no/
- xav_authentique
> 我实际阅读的代码量微乎其微。
这种情绪让我有点难过。我完全支持燃烧 token 来编写一次性代码，仅仅为了原型验证某个解决方案，但我无法理解为什么不阅读（或者至少熟悉）你即将部署到生产环境的代码。