一只LLM可以熟练重构整个代码库，却建议你走路去洗车——这种荒谬的“锯齿形能力”并非bug，而是RL训练数据分布的经济学产物。Karpathy在Sequoia的发言揭示了这一点，但行业仍在假装AI是均匀智能体。本文论证：只有接受锯齿，才能建造真正的AI-native产品。

核心观点：LLM能力的锯齿形分布不是暂时缺陷，而是由数据分布和强化学习的经济逻辑决定的根本特性，理解这一点才是构建可靠AI应用的前提。

如果你在过去一年里密集使用过任何主流大语言模型，你大概率遇到过这样的场景：你让它为一套十万行的代码库做一次跨模块重构，它给出的方案逻辑清晰、注释完整、甚至贴心地处理了边界情况。你感到惊艳。然后你随口问它：“我车脏了，怎么弄？”它一本正经地告诉你：“你可以步行去附近的洗车店。”你没有车。你住在郊区。最近的洗车店在三公里外。你陷入了沉默。

这不是段子。这是LLM能力分布的日常切片——安德烈·卡帕斯在最近一次红杉资本Ascend 2026炉边谈话中，把它概括为“锯齿形能力模式”。同一个模型，在同一轮对话里，可以完成博士级别的代码推理，同时犯下连小学生都不会犯的常识错误。这不是偶然的bug，而是一种系统性的结构特征。更关键的是，卡帕斯的演讲暗示了一个更深层、也更令人不安的判断：这种锯齿不是模型“还不够好”的证据，而是由强化学习训练数据的分布逻辑和背后的经济激励共同决定的。换句话说，这是LLM作为一种技术的存在状态，而不是它成长中的过渡性瘙痒。

如果我们真的相信我们将进入一个“AI-native”的经济——产品和服务被分解为传感器、执行器和逻辑单元，分布在经典计算、神经网络和LLM三种范式上——那么锯齿问题就不再只是工程师调prompt时的烦恼，而是整个AI-native产品架构必须面对的第一性原理问题。一个无法均匀可靠的推理核心，如何支撑一个可靠的系统？那些宣称“LLM可以替代一切”的叙事，是否在刻意忽略这个致命的非均匀性？

为了逼近答案，我们首先需要理解锯齿的来源。卡帕斯在谈话中提出了一个关键解释：LLM在哪些任务上表现出色，取决于该任务是否位于强化学习训练数据的分布内。当你在“轨道上”——也就是任务类型和格式被RL阶段的数据集充分覆盖——模型表现如鱼得水。代码重构正在轨道上：GitHub上有数亿个仓库、PR描述和重构commits，OpenAI和Anthropic们有足够的理由花费算力去生成和筛选这类数据的RL训练对。因为软件工程是一个巨大的市场，有明确的收入。而“判断用户是否需要步行去洗车”这种任务，没有被打包成任何有经济意义的RL训练分布。用户不会为此付费。所以模型在这个领域处于“丛林越野”状态——凭模糊的泛化能力胡乱挥刀，结果荒腔走板。

这个解释的残酷之处在于，它指出了锯齿的不可消除性。不是技术做不到，而是经济学不允许。为每一种边缘的、低商业价值的认知任务收集RL训练数据，成本远高于可能带来的回报。前沿实验室不是在做慈善，他们在优化的是那些能产生最大收入的认知技能包。所以LLM在某些领域会持续强大，在某些领域会持续愚蠢——而且这个差距不会随着模型变大而自动弥合，它只会沿着商业价值的等高线重新分布。

这就引出了一个反直觉的推论：试图让LLM成为一个“通用智能体”的路线图可能是自欺欺人的。那些鼓吹AGI即将到来的叙事，往往依赖于一个隐含假设——智能是均匀的，只要算力够多、模型够大，所有能力差距都会消失。但卡帕斯的分析表明，智能均匀化面临的根本障碍不是算力，而是经济激励结构。除非出现某种全新的训练范式，让模型能够在没有明确经济回报信号的情况下自主补齐所有能力短板，否则锯齿将是LLM的永久特征。

那么，接受锯齿之后，AI-native产品设计应该怎么做？卡帕斯给出了一个方向：对信息进行“最大程度的可解读性”改造。这听起来技术官僚味十足，但背后的逻辑很直接——既然LLM在非分布任务上表现糟糕，那就把非分布任务转化为分布任务。怎么做？通过改变信息的呈现方式。一个经典的例子是“install.md取代install.sh”：传统上，安装软件需要写一个bash脚本，这是精确但脆弱的代码。而新的做法是写一个Markdown文档，用自然语言描述安装步骤，然后让LLM去执行。对一个脚本而言，指令是硬编码的，任何环境偏差都会导致失败；但对LLM而言，自然语言指令是灵活可调的，而且它可以利用在线资源自我纠正。这里的关键不是LLM变得更聪明了，而是我们把问题的形式从“LLM不擅长执行精确步骤”变成了“LLM擅长理解并自适应执行自然语言描述”。同一只模型，因为任务被重新打包进了它的能力分布内，就从“愚蠢”变成了“能干”。

这个思路可以推广：AI-native设计的第一原则不是“让AI变强”，而是“让输入适应AI的分布”。这也解释了为什么像“menugen”（输入图像直接输出图像，整个应用被LLM完全内化）这样的想法如此诱人——它完全绕过了经典软件的逻辑层，把一切交给了LLM的端到端生成能力。但同时也需要警惕：如果一个应用的所有逻辑都依赖于LLM，那么任何一次锯齿的咬合错位都可能导致整个产品的失败。你必须精确知道你的LLM在哪些任务上是在轨道上，哪些任务是在丛林里。不知道就是赌博。

反对者可能会说：这太保守了。开源社区正在疯狂迭代，Mistral、DeepSeek、OpenCode Go等模型正在迅速缩小差距，也许锯齿只是一个暂时的工程问题，随着模型上下文长度的增加和推理能力的提升，一切都会自然平滑。这个观点的吸引力在于它允许我们继续持有“AI正在快速变强”的乐观叙事。但卡帕斯的数据点提供了一个冷水：即使是DeepSeek V4 Flash这样强大的模型，在非分布任务上的表现依然充满惊喜（意外的好）和惊吓（意外的差）。更为根本的是，如果锯齿是由经济激励驱动的，那么开源社区也无法绕过它——开源模型的训练同样需要选择数据分布，同样面临投入产出比的问题。没有实验室有动力去花几百万美元训练一个“如何帮你判断是否需要走路去洗车”的技能。

另一个反驳来自“涌现能力”的支持者。他们相信，随着模型规模的进一步扩大，那些目前表现糟糕的领域可能会突然涌现出能力，就像语言翻译和逻辑推理在大模型身上涌现一样。这个假设不能完全排除，但它有一个致命弱点：我们对涌现机制的理解还极其原始。没有可靠的理论能预测哪个能力会在哪个参数规模、哪种训练数据配置下涌现。把产品赌在涌现上，和赌下一张牌的翻牌率没什么区别。

更务实的态度是：把LLM当作一个高度专业化、但在能力空间上不连续的推理引擎。对于AI-native产品的构建者而言，这意味着在系统架构上必须引入“锯齿检测层”——实时监控模型输出的置信度和合理性，在模型进入丛林时及时切换策略或回退到经典代码逻辑。这不是对AI的背叛，而是对AI的诚实表达。卡帕斯在谈话中暗示了类似的方向：未来的AI原生系统将不是纯神经网络，而是神经网络与经典CPU协处理器的混合体。神经网络负责那些它擅长的大规模、模糊模式匹配任务，经典代码负责那些需要确定性、可验证性的任务。这不是一个过渡状态，而可能是长期的稳定架构。

但即使采取这种混合架构，仍然存在一个更深层的麻烦：我们如何知道LLM什么时候在轨道上？卡帕斯本人承认，他还没有完全满意的模型来解释LLM能力分布的精确边界。“still not 100% satisfied with this，”他说。这是一个令人尊敬的诚实态度。但对产品构建者来说，不确定性是不能被接受的。你无法在不知道模型何时会犯傻的情况下可靠地部署一个面向客户的系统。

这正是目前AI行业最隐蔽的危机。一方面，资本和舆论在推动“AI正在取代一切”的叙事；另一方面，真正在构建产品的工程师每天都在与锯齿作斗争。那些最成功的AI产品——比如GitHub Copilot——之所以成功，恰恰是因为它们把任务限制在了一个非常狭窄的分布内（代码补全），并且保留了大量的人工审查环节。这不是AI-native，这是AI-assisted。而任何试图把AI推向更核心决策位置的产品，都必须在锯齿的阴影下重新思考自己的架构。

所以，回到开头的问题：当我们说“AI-native经济”时，我们在说什么？如果我们指的是一个由LLM驱动一切的世界，那将是一个锯齿形的、充满意外崩溃和推理短路的世界。如果我们指的是一个精心设计、让LLM只做它擅长的事、同时用经典工程兜底的世界，那可能是一个更稳定但也更无趣的未来。卡帕斯的谈话暗示了后者。而我认为这是对的。

真正重要的不是LLM什么时候变得均匀智能，而是我们什么时候停止假装它已经是均匀智能的。锯齿不是bug，它是新的基线。接受它，设计适应它，而不是幻想它消失——这才是2026年AI-native设计的真正起跑线。