最近在研究 NL2SQL 项目时，愈发感觉到这条路存在难以逾越的瓶颈。业界往往倾向于将问题归咎于模型能力的不足，但剥开表象真正的症结或许在于自然语言本身的模糊性。
业务往往期待“一句话问数”的极致体验，但 SQL 的本质却要求条件与字段的绝对确定。举个最简单的例子，“帮我查一下销售额”，模型面临的却是巨大的逻辑黑洞： 是查询最新时间点的数据，还是历史总和？是仅仅查销售额一个数字，还是包含同比、环比等辅助字段？想要高准确率，问题就必须描述的足够详尽，但描述一旦详尽，又与“一句话问数”的便捷初衷背道而驰，这本身就是个死结。自然语言的模糊性从根本上限定了 NL2SQL 的能力边界。
这种模糊同样出现在 Vibe Coding 中，《人月神话》中有一个概念叫“本质复杂性”。构建一个软件系统，如果其内部逻辑、状态流转、边界条件极为复杂，那么这种本质复杂性不会凭空消失，只会转移。我将其称为“复杂度的守恒”。
很多人认为传统开发的重点是“写代码”。但实际上重点在于“翻译”——将模糊的自然语言需求，翻译成精确的机器代码。对于 Vibe Coding，我们只是将这个“翻译”的工作外包给了模型。但核心问题在于，模型是在“猜”，而不是在“确认”。
当你要做一个图书馆管理系统时，开发会向你确认：“页面需要哪些按钮？”“借书超期怎么算？”但模型大概率不会，它会基于概率自然而然地去猜测并实现。就像你说你要一个查询接口，除非你显式告诉它，否则模型很难猜到需要支持“模糊匹配”。
不够清晰、不够详尽的自然语言描述，必然带来的是一个低本质复杂性的系统。然而，实际生产中高可用、便于维护的系统，必定伴随着高复杂度。这就对 Vibe Coding 的描述提出了极高的要求——必须足够精准，足以覆盖那些繁琐的边界条件。
你用代码写下的每一个 if，不会因为你使用了 Vibe Coding 而消失，它只会转移到你的自然语言描述里。反直觉的是，这个问题与模型能力无关，也不会随着模型能力的提升而彻底解决。“一句话开发一个系统”自始至终都是一个悖论。
我相信，随着模型能力的提升，“写代码”这个动作是可以被替代的。但是，“开发”这件事——即通过模糊的自然语言去精准描述一个系统——真的是一件简单的事情吗？
或许有人会说：“我用 Vibe Coding 也很简单地做出了很复杂的系统。”但请扪心自问：模型猜出来的功能，是否真的完全符合你的要求，还是说，其实你并不知道你真正需要什么要求？在你能看到的地方，模型放了一个按钮，你觉得不满意，让模型去改，而在你看不到的地方，模型又会“猜”错多少内部逻辑？一次次的澄清与修补，本质上就是在一次次地增加系统的复杂度，而这种先做再打补丁的方式，会不会在未来带来更大的技术债？
复杂系统的 Vibe Coding，往往通过需求拆解来实现，拆解到模型确切知道每一步实现的功能、每一步的输入输出、每一个if判断的内部逻辑。但到了这一步，自然语言描述的效率，又能比写代码高出多少？而详尽的自然语言描述，是不是成为了另一种形式的伪代码？
归根结底，这一切都遵循着一条最朴素的物理定律：信息量守恒。构建一个确定的系统所需的总信息量是固定的，它不会因为执行者是人类还是模型而增减，只会在载体之间转移。
或许，我们对 Vibe Coding 的期待需要做一次微调：它并不能通向“一句话生成系统”这样的完美乌托邦，而是一面映照人类表达精确性的镜子。
我们必须承认，模型虽能通过上下文推理部分简单逻辑，但仍有大量隐匿于脑中的关键规则，必须被显式地给出。复杂系统的实现，或许不再仅由代码的行数决定，也将取决于描述的精确程度。
我们也要坦然接受：即便写描述比写代码更简单，也绝不意味着描述可以被简化。未来的创作者，将需要一种新的素养——既能洞察业务本质，又能用足够精确的自然语言为模型锚定边界。
这并非编程的终结，而是一场迁移：编程仍在，只是语言从符号走向了语义。
