摘要：这样说的原因，Karpathy解释，只有复杂的UI界面而不提供文本交互，就无法和大模型形成有效的人机协同。

克雷西 发自 凹非寺

在人与AI高度协同的时代，只有大量复杂UI界面的应用将会被淘汰。

大神Karpathy给出了对于应用程序未来的预言，并特别点名Adobe、CAD将首当其冲。

△ngmi是not gonna make it的缩写

这样说的原因，Karpathy解释，只有复杂的UI界面而不提供文本交互，就无法和大模型形成有效的人机协同。

换言之，这类软件没办法满足准专业用户的“氛围式编程”需求。

按照应用当中UI和文本含量的不同，Karpathy还给一些常见的应用划分出了四个“风险等级”。

其中提到的部分软件，长这样：

Karpathy还补充，虽然AI在UI界面操作上也会取得进步，但开发者如果守株待兔，照样不会有好的发展。

Karpathy的这番犀利言论，一经发出就引发了广泛的讨论。

支持者Karpathy的人表示，仅仅依赖复杂的可视化UI，而没有可脚本化的后端的产品，本质上是在筑起高墙，阻挡AI的浪潮。

还有人表示，现在Agent的水平已经与人类相当，所以软件开发者要同时考虑人类和AI，甚至是只考虑AI。

看到有人如此强调后端接口的地位，有网友直接给出灵魂拷问——

UI界面到底还值不值得做？

有人解释，使用文本交互不等于消灭UI，但UI应当构建在“文本”之上，能够在用户交互操作和文本之间形成一种转换机制。

反对Karpathy观点的人则认为，Karpathy提到的几个“高风险示例”（Photoshop、CAD等）本身都是面向专业用户的，甚至专门有学校教授这些软件的使用。

在他看来，这些应用与普通的软件不可同日而语，苹果同时保留Logic Pro和Garage Band（都是音乐创作软件）也是这个原因。

还有人认为，VSCode等（以文本交互形式的）应用并非适合所有人，那既然总要有一个适应，为什么不能让AI来适应人类的操作方式呢？

但无论支持还是反对，想要让应用程序和AI之间更好协作，人们可能还需要更加规范的语言和软件框架。

同一天，Karpathy还发了另一则推文，讨论了“验证差距”（verification gap）。

这则推文是在其他博主帖子的基础之上进行补充的，原帖内容大概是这么说的：

研究人员必须对AI生成内容的相关知识足够了解，才能判断是否正确，这就是针对评估和幻觉有大量研究的原因，但是“验证是人工智能用户瓶颈”这一概念，尚未得到充分讨论。

他还表示自己非常支持Karpathy提出“氛围式编程”，但同时也认为AI的纯文本输出非常难以验证。

Karpathy称这是一篇“非常好的帖子”，然后借用了GAN的工作过程补充说，几乎所有创造性工作中，生成和判别这两个阶段都是交替进行的。

而判别的过程，的确在不同创作媒介中难度不同，具体来说，Karpathy认为图像最容易，文本更难，最难的则可能是音频。

进一步地，Karpathy批判了现在大模型编程中“重生成轻判别”的模式：

你可以说，在编程中，大模型已经几乎将生成阶段压缩到了即时的程度，但在“判别阶段上几乎没有任何改进。

人仍然需要盯着结果，判断它们是否正确。

这正是我对LLM编程最大的批评：它们总是随意输出大量代码，复杂程度不一，仿佛第二阶段（验证）根本不存在一样。

得到这么多代码并不是好事，反而令人畏惧。

最后，Karpathy又补充，非专业人士实际上对编程工作也存在认知偏差。

Karpathy说，非专业人士以为编程就是写代码，但其实不是，编程的本质实际上是盯着代码看，类似大模型的判别过程。

如果只是让“写”代码变得更快，却没有减少“思考代码”的负担，那整体编程速度显然不会有明显提升。

而Karpathy自己也在研发一种AI辅助编程工作流，其中一项关键工作就是减少验证负担。

在回复当中，Karpathy认同将文本视觉化是一种可行的方式，但像目前Cursor当中的视觉形式非常糟糕，他设想将整个代码库布局在二维画布上，让程序员可以通过各种“镜头”来查看代码。

话说回来，你认为未来的应用，应该是什么样子的呢？

参考链接：
[1]https://x.com/karpathy/status/1930354382106964079
[2]https://x.com/karpathy/status/1930305209747812559

— 完 —

来源：量子位一点号