文章认为大型语言模型(LLM)虽然可以像编译器一样将高级指令转换为代码，但不应该被当作编译器使用，因为LLM缺乏编译器的精确性和可靠性，更适合作为辅助工具而非完全替代传统编译器。

大语言模型可以是编译器，但不应该是编译器

作者：Alperen Keles

核心观点： 1. 虽然大语言模型(LLM)能够将自然语言转换为可执行代码，但这种"编译"过程与传统编译器存在本质区别 2. 传统编译器通过严格定义的语言规范和可验证的语义保证，将高级语言转换为底层指令；而LLM基于模糊的自然语言，缺乏精确的语义定义 3. 关键问题不在于LLM的"幻觉"，而在于自然语言编程本质上是一种功能未充分定义的接口，导致实现细节由模型自行填补 4. 这种编程方式带来新的风险：开发者可能逐渐丧失对软件行为的精确控制，成为软件消费者而非创造者 5. 未来软件开发的核心技能将转向精确的规范制定和验证能力，这将成为新的瓶颈

详细分析： - 编程语言发展史显示，真正的抽象是通过放弃部分控制权来减轻认知负担（如内存管理、代码布局等） - 传统抽象层提供可验证的语义保证（如C语言的malloc/free契约），而LLM生成的代码缺乏这种确定性 - 自然语言描述的"笔记应用"可能对应无数种实现方案，模型选择的不一定符合用户真实意图 - 危险在于开发模式可能演变为：模糊描述→生成代码→检查结果→调整描述的循环，开发者不再深入理解系统 - 即使没有幻觉问题，过度依赖LLM也会助长规范制定的惰性，导致软件质量隐患

结论建议： 应当将LLM视为辅助工具而非完整编译器，重点培养： 1. 精确规范制定的意识和能力 2. 完善的验证测试机制 3. 对生成代码的深入理解 只有保持对软件行为的明确控制，才能避免在AI时代沦为被动的软件消费者。

评论内容总结

1. 反对LLMs作为编译器的观点
   主要认为LLMs的非确定性使其不适合作为编译器，且效率低下。

   • "LLMs are not deterministic, so they are not compilers... it is the wrong tool for the job." (codingdave)
   • "LLMs hallucinate, so they aren’t reliable building blocks." (rawanon1111)

2. 支持LLMs用于代码生成的实用观点
   认为只要生成的代码通过测试，工具并不重要。

   • "If code generated by an LLM passes a real test suite... the authoring tool is secondary." (Daviey)
   • "How is that any different than when someone is testing LLM generated C code?" (rawanon1111)

3. LLMs的潜力与改进方向
   认为LLMs在代码生成中有潜力，但需要迭代改进和人类反馈。

   • "iteratively make things more and more specific... building from the top down with human feedback." (explosion-s)
   • "LLMs may have an easier time understanding what people will use/pay for than what a specific developer wants." (somesortofthing)

4. 技术局限性讨论
   指出LLMs的高成本和非确定性是主要障碍。

   • "LLMs being trillions of times more expensive... as an opening bid." (jerf)
   • "Compilation isn’t stable... you don’t get a bit-for-bit exact copy." (fragmede)

5. 语言与规范的思考
   讨论自然语言编程的模糊性和规范的重要性。

   • "Natural language leaves gaps; many distinct programs can satisfy the same prompt." (plastic-enjoyer)
   • "We need to write better requirements." (jtrn)

6. 历史与未来展望
   对比编译器发展历史，认为LLMs需要时间成熟。

   • "Compilers have had around three quarters of a century years to get where they are today." (fragmede)
   • "The Pandora box is already open... there are enough people trying to make it happen." (pjmlp)

总结：评论围绕LLMs是否适合作为编译器展开，反对者强调其非确定性和效率问题，支持者则认为实用性和测试通过率更重要。改进方向包括迭代生成和人类反馈，同时需注意成本与规范清晰度。历史对比显示技术成熟需要时间。