UBC教授开喷：我根本不知道生成式AI何时有用学术头条
近期，一篇题为（Against Vibes: When is a Generative Model Useful）的博客，在全球知名创业者、开发者社区 Hacker News 上引发了广泛讨论。
博客链接：https://www.williamjbowman.com/blog/2026/03/05/against-vibes-when-is-a-generative-model-useful/
作者为英属哥伦比亚大学计算机科学助理教授 William J. Bowman，他一针见血地写道：“令我沮丧的是，当人们声称智能体（agent）非常有用时，却无法说明其何时、为何、如何真正有用。”
Bowman 的研究方向聚焦于让程序员能够更准确地向机器表达意图，并在编译过程中完整保留这种意图，具体研究领域包括安全与验证编译、依赖类型编程、程序验证、元编程和互操作性等。
这一研究背景，让他对当下生成式模型热潮的质疑，显得不那么苍白无力。
在这篇文章中，Bowman 并没有讨论 AI 的伦理或社会问题，而是直指一个更基础的问题：生成式模型，究竟在什么时候才是有用的？“我真正想知道的是，生成式模型在什么时候才是有用的。我不想只是“感觉它们有用”，那只是一种 Vibe。”
核心观点如下：
判断生成式模型是否有用，不是一种 Vibe，而是一个需要科学建模的工程问题。
判断生成模型是否有用，需要同时考量三个维度。相对编码成本、相对验证成本、以及任务是否依赖过程本身而非仅仅依赖产出。
生成式模型的“可信度”恰恰是其最大的风险所在。输出看起来合理并不等于正确，而这种似是而非的输出会大幅提高验证成本，尤其在复杂任务中。
使用生成式模型仍然需要领域专业知识。没有专业知识的用户，根本无法判断输出是否满足要求。
对于过程本身具有价值的任务，生成式模型无法替代。学习、研究、工程设计，这些任务的意义不只在于产出，更在于完成过程中所创造的知识与能力。
学术头条在不改变原文大意的情况下，做了简单的编译。全文如下：
假设我想回答这样一个问题：工具 X 对于任务 Y 是否有用？
如果我用科学方法来回答这个问题，我会分析工具 X 的性质并建立一个模型，同时分析任务 Y 及其需求并建立另一个模型，然后利用这些模型来预测：在任务 Y 的情境下，工具 X 的行为会是什么样。
“我可以用木材代替不锈钢作为这个结构的支撑梁吗？”
“这种酸能否作为该化学反应的合适溶剂？”
“这种编程语言能否提供所需的实时性能保证？”
然而，围绕生成式模型的讨论却不是这样的。相反，你听到的是诸如“软件工程已死”（software engineering is dead）之类的论断，以及不加思考地把生成式模型塞进一切场景中的尝试。
搜索？生成式模型。
代码补全？生成式模型。
摘要生成？生成式模型。
语音转文本？生成式模型。
库存图片？生成式模型。
任何对此提出批评的尝试，往往都会陷入循环争论，或者变成各说各话。
生成式模型对互联网搜索有用吗？
嗯，它确实能生成一些看起来与输入提示相关的文本。
这并没有回答问题。
人们又会说：最新的模型已经好得多了！
好在什么方面？
当有人称之为“提示工程”（prompt engineering）时，我对此感到很沮丧，因为我没有发现任何工程的迹象，而是一系列关于如何在特定模型的特定版本中措辞提示的 Vibe（氛围），这有时会产生与输入提示看似相关的输出，因此也可能与你的预期接近。
如今更令我沮丧的是，当人们声称智能体（agent）非常有用时，却无法说明其何时、为何、如何真正有用。他们能提供的，通常只是一些感觉自己更高效的 Vibe，而这种 Vibe，其实已经被真实的科学研究所质疑：当把客观生产率指标与主观报告进行对比时，两者往往并不一致。
或者，他们只会举一些例子，说系统生成式了大量看起来合理的输出。
（当然，也确实有一些研究者在做真正的科学研究，并发表论文。我这里谈论的，是当这些技术被迅速引入学校、工作场所等现实环境时，人们所使用的那些论证方式。）
我真正想知道的是，生成式模型在什么时候才是有用的。我不想只是“感觉它们有用”，那只是一种 Vibe。从一开始，我基本上就是一个生成式模型的怀疑者。我一直无法说服自己相信生成式模型是有用的。但同时，我也对自己的主观体验持怀疑态度。
我可以想象：一个能够从自然语言生成代码的模型，在某些我尚未发现的使用场景中，可能确实是有用的。我相信，应该存在某种模型，能够回答这样的问题：在什么条件下，生成式模型 X 对任务 Y 是有用的。
本文不涉及伦理、政治或社会层面的问题，只谈论与技术本身的能力问题。
仅作背景说明：我认为，这项技术如此广泛的部署是极其有问题且不负责任的，在当前规模下继续对其进行投资，几乎是一种接近犯罪级别的受托责任失职，且很可能造成经济损害。我也认为，这一切背后的伦理问题令人深感忧虑。
但就目前而言，我只想弄清楚一件事：从技术上看，它们到底能够做到什么。
将生成式任务编码为提示词与直接产出 artifact（成果）相比，其成本如何？这是一个涉及任务、模型和用户三者的函数。
验证生成 artifact 是否满足要求与直接产出 artifact 相比，其成本如何？这主要是任务和用户的函数，但也涉及生成式模型本身。
任务在多大程度上依赖于产出物本身，而非依赖于产出过程？这是任务本身的函数。
这三个因素分别触及了许多人曾经讨论过的问题。但我认为，只有把这三点同时考虑，才是关键。这样一来，我们才能以一种更科学的方式来讨论生成式模型的使用问题。
如果你想要宣称某个新模型“更有用”，必须明确所有这些变量：需界定任务类别，并证明对特定用户群而言，编码成本低于直接产出 artifact；或即使编码成本更高，但验证设计要求的成本更低。
更重要的是，如果我想预测一个生成式模型是否会有用，我现在有了一个可供使用的模型框架。
我的模型预测：随着任务复杂度的增加，生成式模型的有用程度可能会下降。原因在于，生成式模型本质上是概率性的。因此，当任务的要求变得更加复杂时，其输出满足要求的概率会降低，尤其当要求偏离训练数据的常见模式时。更糟的是，当要求与常见模式存在细微差异时。验证复杂要求同样困难，其难度远高于让人类遵循良好工程流程产出易于验证的输出。
另一方面，当出现以下情况时，生成式模型应该是非常有用的：直接创建 artifact 对用户来说很困难，但验证 artifact 却非常容易。这种情况可能出现在需要交叉引用极其具体信息的 artifact 上，这对用户来说耗时费力，但一旦完成，验证起来却很容易。
还有一种情况是：生成式模型被集成到形式化验证系统中，验证过程高度自动化且非常可靠。在这种情况下，用户甚至不需要理解生成的 artifact，系统就能自动验证其正确性。
但总体来说，如果是一个领域新手试图生成复杂的 artifact，这种模式通常不会成立。因为用户缺乏足够的专业知识，无法判断生成结果是否真的符合要求。
这预示着：使用生成式模型的人仍然需要具备领域专业知识。
该模型还预测：对于高度依赖过程的任务，生成式模型基本上是没有用的。原因是，生成式模型所能做的，只是通过一个黑箱过程生成 artifact。
相对编码成本
许多支持生成式模型有用性的论点，本质上都是在谈相对编码成本。要让生成式模型真正有用，将任务编码为提示词的总成本，必须低于直接生成 artifact 的总成本。
总编码成本包括两部分：编写提示词所投入的全部精力，以及运行提示词所消耗的全部算力。如果一项任务很容易用提示词表达，总编码成本就低。如果一项任务不仅容易写成提示词，直接完成又繁琐或困难，那么相对编码成本就更低了。
随着模型能力的提升，更复杂的提示词也能被轻松表达：可以使用语义密度更高的提示词，参考训练数据中更多的信息。一个能够在初始提示后自动优化或重试任务的 Agent，也许只需一条简单的提示，就能完成一项复杂任务。
然而，上述两种情况都会增加提示词的算力成本，有时甚至大幅增加，从而推高总编码成本。更“强大”的模型或许能以更高的概率生成正确输出，从而减少因补充信息而反复调整提示词的成本（即“提示词工程”），并可能降低验证成本。
此外，随着用户能力提升，其直接完成任务的速度可能远超引导模型完成的速度，从而推高相对编码成本。
有人或许会说，最新的模型“更强大”了，或者“真的智能”了，诸如此类。但这些说法，本质上都是不科学的论断。
这些说法的科学表述应该是：“对于某一类任务，新模型的总编码成本低于旧模型。”如此表述之后，很明显这仍然不意味着新模型是有用的。
就我自己的大多数任务而言，相对编码成本一直都很高。我的许多软件工程任务是构建小型、语义密度高的程序，具有非常具体的设计需求，使用的语言比英语更简洁，而我能够流畅地书写这种语言。系统地设计并实现这样的软件，比把需求规格编码成一条生成式模型的提示词，要快得多。
举个例子，我曾尝试用 Claude Opus 4.6 生成一个程序，用于解析我自己为排版语法所设计的一套自定义 DSL，并生成对应的 Haskell 类型定义。经过 8 小时的提示词交互、消耗了数百万个 token 之后，它生成的代码仍然完全没有用。代码通过了我在提示词中给出的测试，但只要看一眼代码本身，就能轻易发现类型错误，以及专门针对测试中特定标识符做特殊处理的逻辑。标识符清理部分的逻辑一团糟，还会偶尔生成空字符串。而一个正确的实现，我自己写也不过三四百行代码，肯定用不了 8 小时。
