Claude 不是编译器

LLM 与编译器

• 许多人认为 LLM 不是编译器：编译器是确定性的，会把定义良好的源语言映射到定义良好的目标语言，并且大体上保留操作语义。
• LLM 会从定义不足的自然语言中以概率方式生成代码，哪怕只改动一点点提示词也可能让行为剧烈变化，而且未必保留原意。
• 但也有人仍然觉得“LLM 作为编译器”的类比在宽泛、历史性的意义上有用：二者都会改变软件的生产方式，也都能把更高层的描述转换成更低层的产物。
• 还有人认为，LLM 与其说像编译器，不如说更像解释器、转译器，或者“货物崇拜式开发者”。

确定性、混沌与算法

• 确定性被强调为关键区别：编译器对同一输入会产生同一输出；LLM 通常不会。
• 即使把 LLM 做成确定性的，它们仍然是“混沌”的：微小的提示变化就可能产出完全不同的程序，这与编译器对源码改动的反应大多不同。
• 关于“算法”究竟是什么也有争论；有人指出，从广义可计算性的角度看，编译器和 LLM 都是算法，但编译器是演绎式的，而 LLM 是归纳式/启发式的。

规格、提示词与开发流程

• 有几位反对“一个很长的规格说明天然就存在，然后把它喂给 LLM”这种想法；规格和代码是在反馈回路中共同演化的。
• 提示词常被视为不够明确的规格；LLM 很擅长补全空缺，但可能会做出隐藏且影响深远的设计选择。
• 有人设想未来会以更高层的规格为中心，再确定性地编译成代码，并获得类似 lockfile 的保证，同时由 LLM 帮助起草规格和测试。
• 也有人反驳说，规格并不真的比代码“更高层”，更像草图之于完成的画作；实现层面的决策仍然至关重要。

Vibe Coding 与代码质量

• 支持者称赞“vibe coding”适合快速原型和低摩擦地搭建基础设施，尤其适用于小项目或低风险项目。
• 批评者则对“别读代码”的态度保持警惕，表示自己对 vibe-coded 软件体验不佳，并担心细微的长期 bug 和缺失的领域知识。
• 这里存在一种张力：要么审查所有 AI 生成的代码（就失去速度），要么只依赖测试（就有可能得到不完整或错误的系统）。

DNS 与分布式系统问题

• 有一大段分支在分析文中描述的自定义分布式 DNS 系统：
  • 讨论 DNS 传播、缓存、TTL，以及负缓存（NXDOMAIN）。
  • 有人认为如果把 TTL 调得合适，这种做法是合理的；也有人说上游缓存仍然占主导，并质疑它究竟解决了什么问题。
  • 还有人建议使用通配符记录、anycast 以及现成的 DNS 软件；从讨论中并不清楚这个定制系统在现实中能带来多大收益。

概率工具、验证与风险

• 有人把 LLM 比作概率图灵机或 Las Vegas 算法：它们不是确定性的，但具有某种准确率分布。
• 一些人认为非确定性是特性而非缺陷（类似 UDP、SGD、推测执行），前提是要配合强验证器：测试、基准测试、形式化方法。
• 也有人强调，当前对 LLM 的炒作淡化了错误率，而健壮的风险评估与纠错机制仍然不成熟。

生态、能源与对炒作的怀疑

• 有些评论把这篇博客看成 AI 热潮中的“卖铲子”营销，把这个故事框成一则经过润色的内部成功轶事。
• 大家质疑到底真正节省了多少时间、AI 做出的隐性产品决策会如何经受时间考验，以及如何衡量长期成本。
• 对能源使用也有短暂争论：一方批评为了避免人与人协作而“燃烧恐龙血”；另一方则不认同“能源不好”的说法，认为反对能源是不亲人的，并把更多能源视为进步的标志。