36kr-科技 06月05日 16:48
大神Karpathy炮轰复杂UI应用没有未来,Adobe首当其冲,网友:不提供文本交互,就是在阻挡AI浪潮
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

本文探讨了在人工智能与人高度协同的时代,应用程序未来发展方向。Karpathy认为,仅依赖复杂UI界面的应用将面临淘汰,因为它们无法与大模型有效协同。文章分析了支持和反对这一观点的声音,并讨论了如何让应用程序与AI更好协作。Karpathy还强调了编程中“判别”的重要性,以及非专业人士对编程认知的偏差。文章最后提到了Karpathy正在研发的AI辅助编程工作流,旨在减少验证负担。

🤔 Karpathy 认为,在人与 AI 高度协同的时代,只有复杂 UI 界面而没有文本交互的应用将面临淘汰,因为它们无法与大模型形成有效的人机协同。

🗣️ 支持者认为,仅依赖复杂可视化 UI 阻碍了 AI 浪潮;反对者则认为,某些专业软件的用户群体特殊,不应一概而论。

💡 文本交互并非要消灭 UI,而是 UI 应构建在“文本”之上,形成转换机制,以更好地与 AI 协作。

🧐 Karpathy 强调,编程的本质是“盯着代码看”的判别过程,而非仅仅是写代码。他认为,大模型编程“重生成轻判别”,未能有效减少程序员的验证负担。

🛠️ Karpathy 正在研发 AI 辅助编程工作流,旨在减少验证负担,他设想将代码库视觉化,通过“镜头”查看代码,以提升编程效率。

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

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

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

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

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

其中提到的部分软件,长这样:

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

只有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

本文来自微信公众号“量子位”,作者:克雷西,36氪经授权发布。

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

Karpathy AI UI界面 文本交互 编程
相关文章