“自然语言编程”的愚蠢之处（1978）
面向编码的自然语言界面重新唤起了一个由来已久的梦想，而 Edsger Dijkstra 早在 1978 年就认为这个梦想从根本上是错误的。评论者将他对形式语言精确性的强调，与当今的大语言模型进行对比，指出 AI 现在确实可以把模糊的英文请求转换成可运行的代码，但它仍然继承了自然语言的歧义性、缺乏保证以及对人工监督的依赖。许多人更倾向于把 LLM 看作随机性的初级开发者或代理，而不是“自然语言编译器”；它们有助于加速工作、提高抽象层次，但并不能取代传统编程语言、规格说明或严谨的软件工程。
“自然语言编程”的范围
- 许多人认为这篇文章至今仍适用：自然语言是非正式的、含糊的，不适合作为主要程序表示。
- 几位评论者强调，如今的“自然语言编程”实际上是把自然语言委派给一个代理，由它再写出传统代码。
- 少数人认为原始批评已经“无关紧要”，因为自然语言现在只是又一层会被编译成形式语言的抽象层。
LLM：编译器、开发者，还是别的什么？
- 强烈观点：LLM 并不会取代编译器；它们取代的是（或增强的是）把非正式规格翻译成代码的软件开发者。
- 也有人把 LLM 看作某种新的解释器，针对一种定义不充分的语言（提示词），也就是一种编程形式，只是语义是概率性的。
- 争论焦点在于，提示词到底算不算真正的“编程”，还是只是在给另一个类似程序员的实体下指令。
确定性、语义与可靠性
- 多条评论区分了确定性的编译器流水线和随机、上下文敏感的 LLM 输出。
- 有人反驳说人类在实践中也并非确定性的，但也有人坚持，随机性与单纯的变化是不同且更强的一种概念。
- 普遍共识是，编译器和丰富的类型系统对于语义保证、测试以及对 LLM 生成代码进行安全检查仍然至关重要。
规格说明、会议与系统理解
- 几则轶事强调，实际工作依赖于澄清含糊的自然语言规格，无论是由人还是由代理来做。
- 业务用户即使面对自然语言配置也常常吃力；“系统思维”和规格说明能力依然罕见且关键。
- 代理缺乏现实世界的上下文（基础设施、组织约束、责任归属），限制了分析师/工程师角色的完全自动化。
代码、提示词与事实来源
- 很多人坚持，版本控制中的语言（Java/Python 等）决定了系统“是用什么编程的”，不管这些代码是如何生成的。
- 有人预见，提示词或对话最终会被视为主要工件，这会带来可维护性和开源许可方面的问题。
- LLM 输出被类比为任何一次性的代码生成器：可维护性和可复现性依然是问题。
经验性体会与小众例外
- 用户报告称，通过代理“氛围编程”应用取得了成功，但也指出其会遗漏非功能性需求、基础设施细节和微妙的 bug。
- Inform7 和法律文书起草被引用为准自然语言的例子：可读，但仍受到高度约束，这凸显了真正的自然语言编程有多难。