Karpathy 在 Sequoia Ascent 2026 上提出的‘install .md skills’不仅是一个技术玩笑，它指向了一个正在发生的根本性变化：当 AI 能够直接解释和执行自然语言指令时，传统软件工程的基石——模块化、分层、显式编程——正在被一种去中心化、自适应的‘神经计算’范式所侵蚀。这不是速度之争，而是存在性之争。

核心观点：LLM 不只是加速既有流程，它正在创造一套全新的软件形态和开发逻辑，其中最激进的特征是传统代码被自然语言指令取代，而开发者的认知框架必须完成从“写代码”到“设计可执行文本”的转变。

在 Sequoia Ascent 2026 的炉边谈话中，Andrej Karpathy 抛出了一个看似简单却极具颠覆性的概念：“安装 .md 技能而不是 .sh 脚本。”这句话听起来像是对当前 AI 编程助手热潮的一个有趣注解，但它实际上指向了一个远比“提高编码效率”更为根本的变化：我们正在目睹传统软件工程的终结，以及一种全新计算范式的诞生。这不是渐进式的改进，而是一种范式的断裂——从编写确定性指令到设计可被 AI 理解并执行的自然语言文本。

为了理解这种断裂的深度，我们需要首先承认一个事实：过去十年间，所谓的“AI 辅助编程”本质上仍然是传统软件工程的一个子集。GitHub Copilot、Cursor、甚至是早期的 Codex，它们的目标都是加速代码生成，但底层逻辑没有变——最终交付的仍然是一个由函数、类和 API 组成的确定性系统。开发者仍然是架构师，AI 只是效率更高的打字员。Karpathy 提出的“menugen”应用——一个完全由 LLM 驱动、输入图像输出图像、无需任何传统代码的应用——则彻底打破了这一设定。在这种新范式中，开发者不再是编写逻辑，而是编写 prompt 和风格指南；系统的行为不是由 if-else 分支定义，而是由训练数据中的概率分布决定。

反对者可能会说，这不过是将业务逻辑从代码移到了模型权重中，本质上没有区别。这种观点忽视了关键的一点：传统软件开发的核心优势在于可验证性、可调试性和确定性。一个 100,000 行的代码库可以通过单元测试、集成测试和形式化验证来保证其行为。而一个由 LLM 驱动的应用，其行为本质上是不确定的——同一个 prompt 可能产生不同的输出，同一个输入可能触发不同的推理路径。这不仅仅是工程上的挑战，它改变了“软件正确性”的定义本身。当我们不再能断言“给定输入 X，系统必定输出 Y”，我们还能说这是“软件”吗？

这种不确定性的根源，Karpathy 称之为“锯齿效应”（jaggedness）。一个 LLM 可以同时做到两件看似矛盾的事：它能够连贯地重构一个 10 万行的代码库，同时也会告诉你“步行去洗车店洗车”。这种锯齿不是 bug，而是特征——它源自 LLM 的训练方式。在强化学习和人类反馈的驱动下，AI 在那些被充分覆盖的领域（如编程、数学）表现出接近人类的推理能力，而在那些数据分布稀疏的领域（如常识推理、物理世界模拟）则显得笨拙。这种不均衡的能力分布，使得设计一个可靠的 AI Agent 变得异常困难：你永远无法确定你的 Agent 是“在线飞行”还是“在丛林中用砍刀开路”。

但即便如此，反对的声音也无法阻挡这一趋势的推进。原因很简单：这种新范式解决了传统软件工程中一个长期存在的根本局限——处理非结构化数据的无能。Karpathy 提到的第三个例子——“LLM 知识库”——完美地说明了这一点。传统代码无法有效地对来自任意来源、任意格式的非结构化知识进行计算。你可以为特定的数据源编写解析器，可以构建复杂的 ETL 管道，但面对一个包含文本、图像、视频和语音的混合信息流，传统软件只能望洋兴叹。而 LLM 则天然地擅长处理这种非结构化的混乱。这就是为什么“install .md skills”这个概念如此强大：一个 .md 文件，本质上就是一段自然语言描述，它可以被 LLM 解释、执行、甚至自我修正。它不需要编译，不需要依赖管理，不需要版本控制（至少在传统意义上），也不需要运行时环境。它只需要一个足够强大的 LLM 来“阅读”它。

当然，这种范式转换并非没有代价。当代码从确定性指令变为概率性建议时，责任边界也随之模糊。谁为一个 AI Agent 的错误行为负责？是编写 prompt 的开发者，是训练模型的工程师，还是最终用户？法律和伦理框架几乎完全缺席这个领域。更微妙的是，这种范式会从根本上改变软件开发的组织形式。传统的软件工程依赖于分层抽象和团队协作——你不需要了解整个系统，只需专注于你负责的模块。但在一个 LLM 驱动的系统中，系统的行为高度依赖于 prompt 工程、训练数据选择和模型微调，这些往往是全局性的决策。一个 poorly written 的 system prompt 可能摧毁整个应用的用户体验，而一个微调不当的模型可能让所有下游 Agent 产生系统性偏差。

然而，最具颠覆性的可能还不是这些。Karpathy 在谈话中提到了一个更深层的愿景：“全神经计算”（fully neural computing），其中绝大部分计算由神经网络处理，传统 CPU 只扮演协处理器角色。这听起来像是科幻小说，但我们已经可以看到其雏形：像 Sonar 4.0 这样的个性化健康应用，本质上就是一个完全由 AI 驱动的“操作系统”，它管理着用户的健康数据、提供个性化建议、并随时间推移学习用户的行为模式。在 Sonar 4.0 中，传统的 UI/UX 设计已经被一个“围绕你的当前状态”的 AI 驱动界面所取代。这不只是一个新版本的应用，它是一个宣言：未来的软件将不再由菜单、按钮和表单构成，而是由对话、预测和自适应界面构成。

回到“install .md skills”这个概念。它的激进之处在于，它彻底消解了“安装”这一动作的传统含义。在软件 1.0 的世界里，安装意味着将二进制文件复制到指定位置，设置环境变量，解决依赖冲突。在“install .md”的世界里，安装意味着将一段自然语言文本提供给 AI Agent，由后者根据指令自动配置环境、调试错误、并完成安装。这种变化不仅是技术上的，更是认知上的。开发者不再需要理解操作系统的底层细节，不再需要掌握 shell 脚本的语法，甚至不再需要知道“安装”究竟做了什么。他们只需要知道“我想要什么”，而 AI 负责处理“如何做”。

这正是反对者最担心的地方：当开发者不再理解底层机制时，他们是否还能有效地调试系统？当“如何做”完全由 AI 决定时，是否会导致一种新型的“技术债务”——一种由模糊的 prompt 和不可解释的模型行为积累而成的债务？这些问题没有简单的答案。但历史告诉我们，每一次计算范式的转换——从机器语言到汇编，从汇编到高级语言，从本地部署到云计算——都伴随着类似的恐惧和不适。而最终，新的范式总是胜出，不是因为它们更“正确”，而是因为它们让更多的想法得以实现。

这场范式转换的最终赢家，不会是那些最擅长编写代码的人，而是那些最擅长定义问题的人。当“安装”变成一个 AI 动作，当“编程”变成一种自然语言交流，软件开发的门槛将前所未有地降低，但软件设计的复杂性将前所未有地升高。因为现在，每一个 prompt 都可能是一个 bug，每一个训练样本都可能是一个偏见，每一个模型更新都可能是一次行为漂移。开发者将不再是对抗编译器错误，而是对抗概率熵。

这听起来令人不安，但或许这正是软件工程的终极形态：从确定性走向可能性，从控制走向协商，从代码走向意义。而 Karpathy 的“install .md”玩笑，不过是这场宏大叙事的一个注脚。