当AI工具替你做完一切,你到底还有多少价值

Karpathy 最近做了一件让工程师们沉默的事。

他说自己写的 App—MenuGen是多余的。这曾是一个已经发布被大家点赞爆炸的产品：拍照、识别菜名、生成图片、重新排版。每一行代码都严丝合缝，每一个流程都逻辑自洽。这是 初代模型范式的骄傲，是工程师思维的结晶。

直到他看见了 Software 3.0的方案，不需要部署，不需要中间件，不需要结构化数据。只需要把照片丢给模型，说一句话：“把这些菜品图叠加回菜单。”模型直接返回了一个符合需求的菜单，通过老板交付给了用户；

Karpathy 愣住了。他意识到，自己引以为傲的那个 App，是多余的。这不仅仅是一个技术迭代的故事，这更多是一个关于原点思考的反思，甚至在这个时代是一个动态变化的反思。

我们正站在一个危险的十字路口：模型越来越强，但指挥模型的人，却越来越忘本。

当 Karpathy 还在用工程师思维拆解任务——流程是什么？接口在哪？怎么部署？——模型已经跳过了所有中间环节。它不需要你告诉它”怎么做”，它只需要你告诉它”要什么”。这看起来是巨大的范式跃迁。

那些我们曾经引以为傲的工程能力——流程设计、接口对接、组件拼装——正在被压缩成一句自然语言指令。

于是，一个尖锐的问题浮出水面：

如果模型能直接交付结果，我们的价值到底在哪？

答案藏在 Karpathy 的反思里，那个多余的的 App，表面上看是技术路线之争，实际上暴露了一个更深层的问题：

我们常常在用工程手段，模拟问题的解法，而不是真正解决问题，产生新的体验。Which means我们都兴奋与功能的跃迁，而忽略了回归到场景和痛点角度给够任务的真实场景去设计产品，当然了解模型的同学知道模型还有很多不足不足以去支撑所有确定性结果，但这依旧不是理由，产品生来为了场景应用而生。

真正的需求从来不是”给一个看不懂的菜单配图”，而是”人类点餐需要看实物图，管他背后是多语言还是文字抑或就是个符号”。

前者是技术范式，后者是需求挖掘也就是产品定位的一部分。

当我们沉迷于搭建 Agent，沉迷于设计工作流，沉迷于把任务拆解成节点时，我们常常忘了问自己一个最朴素的问题：

用户真正想要的是什么？

这就是当下最大的错配。模型的能力在狂飙突进，但定义第一性原理的能力却被抛置于脑后。

我们见过太多这样的场景：什么打着一键生成漫剧幌子的multi agent，纯纯的杵在那的数字人聊天。我不知道比起老土的方式，在体验分和实际的增量价值上，到底哪个涨了，可能是token；

结果是什么？模型返回了一堆看似正确、实则无用的内容。错不在模型，而在设计产品的人，有一种打铁花一般的炫技感。

一个自己都不会下棋的人，怎么可能指挥出一个棋神？一个自己都没跑通过业务流程的人，怎么可能设计出靠谱的 Agent？

所以，我们必须重新理解如何去使用模型，放大自己的优势，解决核心痛点，而不是写vibe coding，不是搭skill，不是tool use。

是定义问题，定义核心痛点，是看清实现路径，是知道”什么才是真正的解法”，这才能创造新的体验。

Karpathy 之所以能发现 MenuGen 是多余的，不是因为他代码写得快，而是因为他清楚：真正的价值不在工程实现，而在需求洞察。

这种对真实场景的理解，对用户心智的把握，对问题本质的穿透——这才是模型拿不走的东西，才能创造长期有价值的产品。

当然更进一步说，我们还有一道更深的护城河也许相对是一个领域选择时的确定性：一切不可重来的任务。

下棋可以重来，代码可以重构，生成图片可以反复调参，但真实物理世界不是这样。

一次手术、一场谈判、一个战略决策、一次产品发布——这些事情没有撤回键，没有重置选项，没有”再跑一遍”的机会。

模型可以给你一万个方案，但最终拍板的是人。

模型可以预测一万个结果，但承担后果的是人。

模型可以模拟一万个路径，但走在路上的，始终是人。

这种对”不可逆性”的敬畏，对真实后果的承担，才是人类最根本的底牌。当然终有一天模型能力到达的时候，这批用第一性原理已经跑通真实场景的人，更有机会去吃到这样的时代红利；

Karpathy 其实是在提醒我们：别被模型的强大迷惑了双眼，别让工具的便利消解了思考的深度。

当技术把门槛踩到地板上，真正拉开差距的，不再是”你会不会用工具”，而是”你知不知道自己要什么”和“你有没有能力交付更好的东西”。这个时代最稀缺的不是算力，而是判断力。

不是模型不够强，而是我们自己，得先成为一个会深度思考、有判断能力的人。

👆预告下：这是用我自己vibe的碎片化写作工具写的，现在edit还有点问题我自己手工改的，等完了发出来