Karpathy不仅是AI大牛，更是概念缔造者：从“幻觉”到“软件3.0”，他命名或推广了诸多重塑AI与编程的关键理念。
原文标题：「幻觉」竟是Karpathy十年前命名的？这个AI圈起名大师带火了多少概念？
原文作者：机器之心
冷月清谈：
文中详细介绍了Karpathy定义或使其广为人知的多个里程碑式概念。例如，他于2017年提出的“软件2.0”代表了神经网络时代，编程不再是显式编写指令，而是通过数据训练模型权重；紧随其后，他又提出了“软件3.0”，即提示词时代，强调用户能够通过自然语言直接指示AI生成代码，使得“会说话就能编程”成为现实。
近年来，Karpathy还开创性地提出了“氛围编程”和“细菌式编程”等理念。“氛围编程”鼓励开发者在与大语言模型互动中，摆脱传统代码束缚，顺着直觉完成开发；而“细菌式编程”则提倡代码小巧精简、模块化且易于复制粘贴，以促进快速原型开发和社区共享，并将其与“真核生物基因组”的复杂系统构建进行类比。
此外，他的一次转发评论也让“上下文工程”这一概念迅速出圈，强调在构建智能体时，提供完整且结构化的上下文信息远比巧妙的提示词更为关键。文章强调，命名在科研领域扮演着创造知识和建立共享焦点的奠基性角色，Karpathy通过精确的命名和概念推广，为AI科学做出了独特而深远的贡献。
怜星夜思：
2、随着软件2.0、3.0和氛围编程等新范式的兴起，未来程序员的工作重心会发生怎样的变化？传统“写代码”的能力是否变得不那么重要了？
3、Karpathy通过命名很多概念，推动了AI领域的发展。你认为一个好的技术命名，除了能推广概念，还能在哪些方面影响技术的发展和被接受程度？
原文内容
机器之心编辑部
取名大王 Karpathy。
万万没想到，「幻觉」这个词，竟然是 AI 大牛 Andrej Karpathy 命名的。
最近，一位网友在「The Thinking Machine」（一本新书）里发现了这么一段描述：「Karpathy 承认他的（神经）网络有局限性：它只是在模仿言语，而不必真正理解其含义，当遇到它不理解的概念时，它就会『骄傲地』生成一些无意义的内容。Karpathy 将这类错误称为「幻觉」（hallucinations）。 」
这个帖子，Karpathy 本人也看见了，并留言说：「 我相信这是真的，我在我 2015 年写的《RNN 非凡的有效性》（Unreasonable Effectiveness of RNNs）这篇博文中就使用了这个词。而且，据我所能记起的，这个词本身也是我『幻觉』出来的。」
按照 Karpathy 的说法，我们找到了这篇博客，发现里面确实有包含「幻觉」的表述。当时，Karpathy 就已经指出，模型会「幻觉」出网址以及数学题方面的东西。但直到 2022 年 ChatGPT 横空出世，这个词才真正火起来，并作为一个热门领域被研究。
不过，要想知道在 2015 年之前，是否有人使用「hallucination」或「hallucinate」来描述类似现象，可能需要查阅很多文献。
这个有趣的溯源故事再一次证明了，Karpathy 是 AI 圈「实至名归」的取名大师，因为 2017 年的「软件 2.0」、2025 年的「软件 3.0」、「氛围式编程」、「细菌式编程」都是他提出来的，「上下文工程」虽然不是他提出来的，但也因为他的转发评论而出圈。可以说，在推广新概念这块，没有哪个 AI 大牛的影响力可以比肩 Karpathy。
在科研领域，不要小看「命名」的力量。正如 Gemini 所总结的，命名是「创造知识的奠基行为」，精确的命名是用于分类的「地址」、一个可供全球科学家共同对焦的「稳定靶标」。
这十年来，Karpathy 命名的那些概念逐渐受到重视，这也是他对科学做出贡献的一种重要方式。
软件 2.0、软件 3.0
早在 2017 年， Karpathy 就提出了软件 2.0 一词。
来源：https://karpathy.medium.com/software-2-0-a64152b37c35
在这篇文章中，Karpathy 表示软件 1.0 时代的经典堆栈 —— 用 Python、C++ 等语言编写。它由程序员编写的显式指令组成。通过编写每一行代码，程序员可以在程序空间中识别出具有某些期望行为的特定点。
相比之下，软件 2.0 是用一种更加抽象、对人类不友好的语言编写的，比如神经网络的权重参数。人类不会直接编写这种代码，因为参数数量极其庞大（普通网络可能有数百万个权重），而直接手动调整权重几乎是不可能的。
为了更清晰地类比，文中提到，在软件 1.0 中，由人类编写的源代码（比如某些.cpp 文件）通过编译生成可执行文件，从而完成实际任务。而在软件 2.0 中，源代码通常包含两部分：1）定义预期行为的数据集，2）提供神经网络架构（但具体细节由权重参数填充）。训练神经网络的过程，本质上就是将数据集编译成最终可用的二进制文件 —— 即训练好的神经网络模型。
总结来说，软件 1.0 是经典代码时代，借助 Python 或 C++ 等，要求开发人员精确地理解语法和逻辑，以便逐步指导计算机。
软件 2.0 是神经网络时代，开发人员不再需要手动编写规则，而是通过输入数据来训练模型。这些代码成为模型的权重，通过优化而非明确的指令进行改进。
有意思的是，软件 3.0 也是 Karpathy 提出的新概念，即提示词时代。开发人员、甚至非开发人员，只需用简单的英语描述他们想要什么（例如，构建一个跟踪我日常任务的网站），AI 就会生成相应的代码。
软件 3.0 让会说话就能编程从梗变成现实，Prompt 成了源代码，LLM 成了运行时，而人类第一次用母语直接向计算机下达复杂指令。
来源：https://www.latent.space/p/s3
Karpathy 还强调了软件 3.0 的几个关键特点：
LLM 作为计算平台：将大语言模型比作电力这样的基础设施。训练一个大模型需要巨大的前期投入，就像建设一整套电网；而通过 API 使用它们，则像是按使用量付费。这一类比强调了大模型作为一种可扩展、可访问的计算资源的角色。
自主滑块：Karpathy 借鉴其在特斯拉关于自动驾驶方面的经验，提出了自主滑块的概念。这允许用户调整 AI 的控制程度 —— 从最低限度的辅助（例如，建议代码片段）到完全自主（例如，生成整个应用程序）。根据任务和用户偏好提供灵活性。
氛围编程
氛围编程（Vibe Coding），是 Karpathy 在今年 2 月造出的。
简单来说，氛围编程就是鼓励开发者忘掉代码，进入开发的氛围之中。更简单地讲，就是向 LLM 提出需求，然后「全部接受」即可。
来源：https://x.com/karpathy/status/1886192184808149383
正如 Karpathy 所言，在氛围编程中，你会完全沉浸在氛围里，顺着感觉走就行，甚至忘了自己其实是在写代码。这种方式之所以可能，是因为大语言模型现在已经强大到足够离谱。Karpathy 还表示，自己在氛围编程中，基本不用碰键盘，和大语言模型聊天，像个懒人一样提出请求，最后选择全部接受就可以了。
即使有出错的地方，直接把错误信息粘贴进去，也不用解释，模型就能自己改好。甚至 LLM 修不了的 bug，让模型乱改几下，问题也会消失。
这种方式已经不能算传统意义上的编程了，你只要看到东西，说出想法，运行程序，复制粘贴，然后程序大致就能跑起来。
这不禁让我们想起在程序员圈子里广为流传的硬核名言「Talk is cheap. Show me the code」。
最早可追溯到 2000 年 8 月，Linux 之父 Linus Torvalds 在 Linux-kernel 邮件列表里的一次回帖。当时有人长篇大论地描述某个设计思路，Linus 直接甩下这句话 Talk is cheap. Show me the code。
如今变成了「code is cheap, show me the talk（Prompt）」。
细菌式编程
「细菌式编程」，即像细菌一样编写代码。
来源：https://x.com/karpathy/status/1941616674094170287
这种编码方式受到细菌代码（基因组）的启发，具有以下特点：
-
一是小而精简。要知道每行代码都有成本，就像细菌基因组中每个基因都消耗能量，因此保持代码精简能够让自己写的代码「 生存 」得更好。
-
二是模块化，即代码应该被组织成可交换的操纵子群组。
-
三是自包含，代码要能够轻松地通过「水平基因转移」进行复制粘贴。
这种编码风格的核心思想是：如果你的代码块足够小巧、模块化、自包含且易于复制粘贴，那么开源社区就能通过「水平基因转移」—— 也就是开发者之间的代码共享 —— 而蓬勃发展。
Karpathy 还提出了一个有趣的检验标准：当你写一个函数或类时，问问自己 —— 别人能否在不了解你其余代码、不需要导入任何新依赖的情况下，直接「拿走」你的代码并从中获益？你的代码能否成为 GitHub 上的热门代码片段？
这种「细菌式编码」让细菌能够在从极寒到炙热、从酸性到碱性的地球各个角落生存，甚至在太空真空中也能存活，并发展出令人惊叹的多样性。它非常擅长快速原型开发，但也有局限性 —— 无法构建复杂的生命体。
相比之下，真核生物的基因组就像一个更大、更复杂、更有组织的单体仓库（monorepo）。虽然创新性较低，但却是构建复杂生命、整个器官以及协调它们活动所必需的。
Karpathy 的建议是：利用智能设计的优势，两者兼顾。必要时构建真核生物式的单体仓库骨架，但要最大化细菌式 DNA 的使用。这样既能保持代码的灵活性和可复用性，又能支撑起复杂系统的构建需求。
一次转发，带火上下文工程
以前 AI 圈流行提示词工程，上下文工程却很少有人讨论。
其实这一术语并不新鲜，近两年很多智能体构建者一直在关注这个事情，只是一直不温不火的。经过 Karpathy 转发并点评后，迅速火出圈，现在相关帖子浏览量高达 2.2M。
图源：https://x.com/karpathy/status/1937902205765607626
很多人搞不懂提示工程和上下文工程的区别，之前，LangChain 发表的一篇博客提到了两者的关系：可以将提示工程视为上下文工程的一个子集。
在传统的提示工程中，开发者通常侧重于精心设计提示语，以期得到更好的答案。然而，随着应用复杂度不断增加，单纯依赖提示已无法满足现代智能体的需求。如今，提供完整且结构化的上下文信息比任何巧妙的提示词更为重要。上下文工程就是为此诞生的。
感兴趣的读者可以参考《》《》。
除了这些已经有名字的概念，其实 Karpathy 平时的一些推文也让一些问题得到业内关注，比如他在一个帖子中指出，未来大家会把 99.9% 的内容都交给 AI 去读，这是一种不可逆的趋势，所以从现在开始大家就应该注重文档的「可读性」，转变写文档的方式，比如 Markdown 可能就是一种理想的格式。这种从「为人类优化」转向「为 AI 优化」的提议得到了很多人的赞同。
你还记得 Karpathy 提出或带火的哪个概念？欢迎在评论区留言指出。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：liyazhou@jiqizhixin.com
以前是你对着电脑一行行敲，以后是你要对着AI“叽里呱啦”说需求，还要把它生成的代码“调教”好。传统写代码的能力当然还是根基，但更重要的是解决问题的能力、抽象思维能力和与AI协作的能力。那些能把复杂需求清晰地表达给AI、并能识别AI生成结果潜在问题的人，才是未来的香饽饽。