计算机祖师爷Dijkstra的警示：自然语言编程的陷阱与真相

来源：徽声在线市场资讯

（来源：徽声在线图灵人工智能）

您渴望了解的人工智能深度知识，我们第一时间为您呈现

作者：王勃，清华大学硕士，独到科技首席技术官

原文链接：

https://zhuanlan.zhihu.com/p/2019985504695768622，已获得转载许可

一段48年前的深刻“预言”

回溯至1978年，计算机科学领域的泰斗之一Edsger Dijkstra撰写了一篇颇具挑衅意味的短文，编号为EWD667，其标题直截了当：

《论“自然语言编程”的荒谬性》（On the foolishness of "natural language programming"）

他的核心观点十分鲜明：有人认为编程过于严苛，梦想着有朝一日能用自然语言与计算机交流。

然而，Dijkstra却认为这一愿望不仅不切实际，而且方向大错特错。在他看来，形式化符号并非程序员的负担，而是其独有的特权。

时光荏苒，48年后的2026年，大语言模型的崛起使得自然语言编程似乎成为了现实。

Karpathy透露，自去年12月起，他几乎未再亲手编写过代码；Anthropic Claude Code的产品负责人Cat Wu撰文指出，产品经理的核心产出正从文档转变为可运行的原型；Stripe更是每周有1300个无人值守的Agent PR被合并。

那么，Dijkstra是否错了呢？

我带领团队使用AI编程工具已逾一年，从最初的抵触到如今全员采用Cursor，从Vibe Coding的兴奋到Planned模式的回归。回顾这段历程，我认为Dijkstra的观点部分正确——而且是最为关键的部分。

Dijkstra究竟说了什么？

EWD667全文虽短，但论证逻辑严密，核心观点有三：

其一，形式化符号是推动文明进步的引擎，而非累赘。

他通过数学史来佐证：希腊数学因停留在口头和图形描述而停滞不前；穆斯林代数曾短暂尝试符号化后退回修辞风格而消亡；现代科学的崛起，得益于Vieta、Descartes、Leibniz、Boole等人精心设计的符号系统。

他写道：

形式化文本的美在于，其操作仅需遵循少数简单规则；它们是排除各种胡说八道的有效工具——而当我们使用自然语言时，胡说八道几乎难以避免。

其二，自然语言的“自然性”实则是一种危险的舒适。

这是全文最为犀利的一句：

所谓自然语言的“自然性”，归根结底，不过是我们能轻松地用它说出那些荒谬性并不显而易见的话。

换言之，自然语言让你轻易说出自己都未意识到的模糊和矛盾，还自以为表达清晰。

其三，拓宽接口未必减轻负担，反而可能使双方更累。

他指出，接口设计并非简单的劳动分配。让机器理解自然语言，不仅给机器增加了负担，跨接口的沟通成本也会上升，最终可能双方都更疲惫。因此，他主张“窄接口”（narrow interface）：约束越明确，合作越高效。

一年AI编程实践的验证

去年，我要求团队全面使用Cursor，原则是不限量、善用模型。

初期虽有阻力，但很快大家便感受到了效率的飞跃。前端岗位大幅减少，我们要求前端人员转向全栈。产品经理也开始利用Cursor编写文档、制作交互式原型。许多项目一个人就能完成需求分析加开发。

Vibe Coding的甜蜜期确实存在：用自然语言描述需求，AI几分钟就能生成一个可运行的demo。Demo效率大增，我们开始接受“无需想得太清楚就可以开始”的工作方式，产品和研发共同探索前行。

然而，甜蜜期过后，问题逐渐浮现——而这些问题的出现，恰恰印证了Dijkstra 48年前的预言。

AI常常遗漏需求。你以为自己表达清晰，AI也似乎理解了，但交付的东西总是缺少几个关键点。本质上，这就是Dijkstra所说的：自然语言让你轻易说出荒谬性并不显而易见的话。你的需求描述存在模糊地带，自己都未察觉，AI便按其理解填补了空白。

代码缺乏架构感。AI生成的代码能运行，但结构松散，易受现有代码风格影响。因为自然语言描述天然缺乏架构约束——你说“帮我写一个用户管理模块”，这句话中没有任何关于分层、依赖关系、接口设计的形式化信息。

上下文越长越“降智”。对话一长，AI的服从性反而成为问题——它会被之前对话中的错误信息污染，然后在错误的方向上越走越远，最终放弃或胡乱尝试。这就是Dijkstra所说的“接口变宽，双方都更累”的现代版本。

编写代码快并不意味着深思熟虑。这一点我们团队深有体会。AI可以快速编写代码，但速度掩盖了思考的缺失。不推荐所有标榜对编码特化的模型，除非代码用一次就扔。

形式化并未消失，只是形态发生了变化

经历挫折后，我们的工作流逐渐从Vibe Coding回归到了Planned模式。一个典型的开发过程变为：

描述需求

与模型对齐，确认其理解正确

让模型分析细化，排除矛盾

进行可行性预研，给出备选方案，由人来选择

提出测试需求

进行系统设计和关键算法设计，由人来审查

设计测试方案（自动化+端到端）

分拆任务，确定验收标准

执行并验收

看到了吗？这个流程的每一步，都是在将自然语言的模糊描述逐步转化为更形式化的约束——规格说明、测试用例、验收标准、任务分拆。

这不是倒退，而是Dijkstra所说的“窄接口”思想的现代实践。

今年，行业内出现了一个新概念——Harness Engineering（马具工程/驾驭工程），由Terraform的作者Mitchell Hashimoto提出。其核心原则是：每次发现AI犯错，就花时间工程化一个机制，防止其再次犯错。

这个概念的演进路线十分清晰：

• 2023-2024：Prompt Engineering

• — 如何与AI交流。本质是优化一次性的自然语言输入。

• 2025：Context Engineering

• — 给AI提供哪些信息。不再仅关注措辞，而是设计整个信息环境。

• 2026：Harness Engineering

• — 构建何种环境让AI可靠工作。验证闭环、架构约束、测试护栏、熵清理。

从Prompt到Context再到Harness，这条路线的方向是什么？是从自然语言走向形式化约束。

CLAUDE.md、AGENTS.md等配置文件，本质上就是写给AI的形式化规范。TDD测试套件就是用代码表达的验收标准。CI/CD管道就是自动化的质量闸门。

Dijkstra曾说“形式化符号是排除胡说八道的工具”。在AI时代，这句话变为：测试和约束是排除AI胡说八道的工具。

过去，CI/CD集成、TDD等被认为是昂贵的工程实践，许多团队因嫌麻烦而不做。但在AI编程时代，它们已从奢侈品变为必需品。AI由于实现机制的原因，无法保证100%稳定不出错，因此在兜底防御方面投入再多精力也不为过。

AI真正改变的是什么？

说到这里，可能有人认为我在唱衰AI编程。恰恰相反。

Dijkstra的洞察在LLM时代依然成立，但他有一件事未预见：形式化的生产成本可被AI大幅降低。

以前，编写一套完整的测试用例、设计一份严谨的接口规范、维护一份结构化的需求文档——这些形式化工作本身就需要大量人力，因此许多团队干脆不做。代码裸奔、需求口头传递、测试靠手点，这是大多数团队的现实。

现在不同了。你可以用自然语言描述需求，让AI帮你生成测试用例、类型定义、接口文档、验收标准。然后你审核和修正这些形式化产物。

这个变化的意义在于：不是用自然语言替代了形式化，而是用AI作为自然语言到形式化的桥梁。

自然语言是优秀的输入层——它降低了表达意图的门槛。形式化是必要的验证层——它保证意图被正确执行。AI是两者之间的翻译器——它让形式化变得便宜了。

这三层结构，才是AI编程真正可持续的工作模式。

我们团队现在的做法是：产品用自然语言编写规格说明，AI帮忙转化为结构化需求；开发用自然语言描述功能，AI生成代码同时生成测试；测试人员利用AI增强能力，从手工点点点转向编写自动化测试。每个环节，自然语言是入口，形式化是出口，AI在中间做翻译。

消耗token的速度直接反映了你的AI编程能力——这句话听起来有些夸张，但实际确实如此。对编程工具的驾驭能力和并行工作的能力，直接决定了你消耗token的速度。别吝啬token，浪费的是你的时间和成长速度。

如果Dijkstra活在今天

Dijkstra在EWD667的最后写了一句颇有意思的话：

我有一种直觉可以让我感到安慰：能用我们的母语编程的机器，无论是荷兰语、英语、美语、法语、德语还是斯瓦希里语——它们既该死地难以制造，也该死地难以使用。

制造这件事，LLM做到了。但“该死地难以使用”这个预言，某种意义上也成真了——不是难在操作界面上，而是难在如何让自然语言的模糊性不变成系统性的质量问题。

如果Dijkstra活在今天，看到我们先用自然语言让AI编写代码，然后又花大量精力构建测试、约束、验证闭环来确保AI不犯错，他大概会说：

「你们终于造出了能听懂自然语言的机器，然后发现还是得用形式化来约束它——这不正是我说的吗？」

编写代码的成本降低了，但思考的成本并未降低。

驾驭AI的能力，本质上是构建形式化约束的能力——将模糊的意图转化为精确的规则，将不可验证的期望转化为可执行的测试，将“我觉得差不多了”转化为“测试全部通过”。

这件事，48年前Dijkstra就想明白了。只不过他当年是对着编译器说的，我们今天是对着大语言模型说的。

工具变了，思想未变。