当LLM能重构十万行代码却建议你开车去洗车，我们面对的不是一个更聪明的工具，而是一个畸形的智能。这种锯齿形能力分布催生了三个新物种：完全被LLM吞噬的应用、以自然语言为安装脚本的技能、以及传统代码无法处理的知识基。它们指向一个根本性的转变——从软件1.0的确定性计算，到软件3.0的概率性推理，中间夹着一个正在消亡的2.0。

核心观点：LLM真正的革命不在加速旧任务，而在创造了全新计算范式——这种能力分布极端不均衡（锯齿形），迫使我们必须重新思考什么是产品、什么是服务，以及一个'代理原生'的经济意味着什么。

上周在红杉资本2026年度大会上，Andrej Karpathy做了一场炉边谈话。他没有泛泛谈论AI的进步，而是抛出了一个尖锐的问题：当LLM能同时做到两件事——把十万行代码重构得井井有条，又告诉你'走到洗车店去洗车'——我们该怎么理解这种能力的极度不均衡？这不是一个技术bug，而是LLM能力的本质特征。Karpathy称之为'锯齿形'（jaggedness），并试图从训练数据分布和经济学角度解释：凡是落入RL训练数据分布内的任务（比如编程），LLM就像在轨道上飞驰；凡是偏离这一分布的任务（比如常识推理），LLM就像在丛林里挥着砍刀。这不仅是能力分布问题，更是一个经济问题——收入和市场总量决定了前沿实验室选择把什么装进训练数据。

但这种锯齿形最有趣的地方不在分析，而在它催生了什么。Karpathy举了三个例子，每一个都在挑战我们对'计算'的既有定义。第一个是menugen——一个完全被LLM吞噬的应用。输入一张图片，输出一张图片，整个逻辑由LLM原生完成，没有任何一行古典代码。这不是'用AI辅助写代码'，而是'用AI替代了代码本身'。第二个更激进：用安装.md技能代替安装.sh脚本。传统的软件安装需要写复杂的bash脚本，根据操作系统、依赖环境、硬件配置做大量条件判断，而现在你只需要用自然语言写一份安装说明，然后对LLM说'照着这个做'。LLM成为英语的'高级解释器'，能智能适配你的环境，现场调试、自动修复。第三个例子是LLM知识库——这是古典代码根本无法完成的任务，因为它是对非结构化数据（知识）的计算，这些数据来自任意来源、任意格式，包括纯文本文章。你看，这三个例子的共同点不是'让已有的东西跑得更快'，而是创造了以前根本不存在（或不该存在）的功能。

这就是我们正在面对的计算范式转移。传统的软件工程建立在确定性上——写下精确指令，得到可预测结果。LLM引入的是概率性计算——输入模糊意图，输出合理结果。这两种范式之间的差距不是线性递进，而是空间维度的跳跃。Karpathy在谈话中隐隐勾勒了一个三层计算架构：软件1.0（古典代码）、软件2.0（机器学习）、软件3.0（LLM原生）。我倾向于认为，2.0是一个过渡层，它用统计方法代替手工规则，但本质上仍然运行在确定性硬件上，而3.0才是真正的'神经计算'，它不再需要指令集，只需要意图和上下文。这不是科幻，menugen已经在实践了。

当然，反对者立刻会指出：LLM的不确定性是致命的。你不能用概率模型控制核反应堆，也不能用它运行银行核心系统。这没错，但恰恰是这种不确定性催生了新的经济形态——'代理原生经济'（agent-native economy）。Karpathy提出了一个分解框架：任何产品和服务都可以拆解为传感器、执行器和逻辑。在代理原生经济中，逻辑层被拆分为软件1.0/2.0/3.0三种计算范式，分布在不同的组件中。传感器和执行器负责与物理世界交互，而逻辑层由LLM主导——不是全部替代，而是根据任务特性分配。那些需要确定性的底层操作（比如数据库事务）仍然由古典代码处理，而需要理解、推理、生成的复杂任务交给LLM。这种混合架构不是妥协，而是必然：锯齿形能力决定了LLM不能包办一切，但也决定了古典代码无法触及许多新领域。

但这里有一个更深层的问题：我们准备好了吗？我在浏览大量技术讨论时发现一个现象：大多数人对LLM的理解仍然停留在'更好的搜索引擎'或'更聪明的代码助手'。Karpathy提到的三个新方向，在主流技术社区几乎没有讨论。更令人担忧的是，整个教育体系、开发工具、评估标准都是为软件1.0设计的。我们训练程序员写精确的代码，但LLM需要的是能清晰表达意图的'提示工程师'；我们推崇可测试、可验证的软件质量，但LLM输出本质上是概率性的。这不是修修补补能解决的，而是需要重建整个技术栈的上层建筑。从代码仓库到持续集成管道，从错误日志到性能监控，每一个环节都需要重新设计以适应'概率计算'这个新物种。

还有一个被忽视的维度：经济激励。Karpathy敏锐地指出，LLM的能力分布受经济因素影响。训练数据的选择取决于哪个领域有最大的收入和市场总量。这就是为什么编程能力突飞猛进而做饭建议仍然一塌糊涂——编程有数十亿美元的开发者工具市场，而家常菜谱的变现能力几乎为零。这种'经济驱动的能力分布'正在制造一种新的智能不平等：资本密集型领域（金融、医疗、法律）将获得越来越强大的LLM能力，而劳动密集型领域（家政、养老、教育）可能被智能边缘化。这不是技术问题，而是分配问题。如果我们放任市场力量决定AI能力的分布，我们将得到一个高度偏斜的智能社会——对富人来说无所不能，对穷人来说聊胜于无。

那么，我们该怎么办？一个务实的起点是重新定义'技能'的概念。Karpathy提到'install .md skills'，本质上是在说：未来的技能不再是写代码，而是写文档。你不需要知道bash，但你需要知道如何用自然语言精确描述安装过程；你不需要懂汇编，但你需要理解LLM擅长什么、不擅长什么。这是一种新的元技能——'LLM literate'能力。它不是编程，而是沟通；不是逻辑，而是意图。另一个方向是重新设计界面。传统的GUI是基于确定性操作的——按钮、菜单、对话框都是精确触发的。未来的UI可能需要'意图输入'——你不点按钮，而是告诉系统你想做什么，系统（LLM）负责理解并协调多个组件完成。这听起来抽象，但menugen已经做了：输入一张猫的图片，输出一张梵高风格的猫。没有按钮，没有菜单，只有输入和输出，中间由LLM全权处理。

但最根本的挑战是社会层面的。我们正在进入一个'代理原生'的世界，其中LLM不仅是工具，而且是'居民'——它们是传感器、执行器和逻辑之间的中介，是产品和服务的设计者、部署者和维护者。这种转变比云计算或移动互联网更深刻，因为它改变的不是交互方式，而是计算的本体。当我们说'一个应用被LLM吞噬'，我们说的不只是效率提升，而是计算范式的替代：确定性让位给概率性，指令让位给意图，算法让位给上下文。这听起来像技术问题，实际上是一种新的认知方式——我们不再'命令'计算机做什么，而是'协商'它应该做什么。

这场转变不会一帆风顺。锯齿形能力意味着LLM在今天仍然是一个不可靠的伙伴。它能重构整个代码库，却在简单的常识问题上犯低级错误。这种不稳定性让许多人对代理原生经济持怀疑态度——你怎么把一个关键业务交给一个会犯'走到洗车店去洗车'这种错误的东西？但历史告诉我们，从来不是技术完美了才被广泛采用。Web 1.0的网页加载慢得像蜗牛，但人们开始在上面购物；移动互联网的电池只能撑半天，但人们开始用手机工作。不完美是新范式的通行证，不是拒签单。LLM的锯齿形不是缺陷，而是特征——它告诉我们哪些领域已经被重塑，哪些领域还在等待下一个突破。

最后，我想引用Karpathy谈话中的一个暗示：'也许某种完全神经化的计算方式，在古典CPU协处理器的协助下，能处理绝大多数计算。'这句话的意思是，未来的计算主力不是CPU，也不是GPU，而是'神经处理器'——也就是LLM本身。CPU和GPU退居二线，成为'协处理器'，处理那些需要确定性、可预测性的操作。这是一个大胆的设想，但并不是空想。menugen、.md技能、LLM知识库已经在朝这个方向走。它们不是未来的预言，而是现在的实证。问题不在于'这个未来会不会来'，而在于'我们能不能在它来的时候做好准备'。