Karpathy 最新访谈：Vibe Coding 只是开始，真正重要的是 Agentic Engineering

Karpathy 最新访谈：Vibe Coding 只是开始，真正重要的是 Agentic Engineering Karpathy 最新访谈：Vibe Coding 只是开始，真正重要的是 Agentic Engineering Modified April 30 他认为，很多公司还没有重构面试流程。如果仍然给候选人一组小 puzzle，让他们现场解算法题，这还是旧范式。它测不出一个人是否会在 Agentic Engineering 里高效工作。 更好的测试应该是大项目。比如让候选人做一个 Twitter clone：不仅要能跑，还要做得好、做得安全。然后再用多个 Agent 去攻击这个网站，尝试破坏它，看看系统能否经得住。 面试本该是这样的：甩给候选人一个极大的项目，比如做个给 Agent 用的 Twitter 仿盘，要求做得绝对安全。然后，我挂上 10 个 Cursor 当作“红队”，放开手脚去攻击你做出来的这个网站。 这套评估方式的核心，不是看候选人能不能手写某个算法，而是看他能不能： 把模糊目标变成清晰规格；指挥 Agent 完成大规模实现；识别安全和架构风险；设置测试与验证；在模型生成的大量代码里保持质量判断；让最终系统经得起外部攻击和压力。 【10】Agent 能写代码，但还会把付款绑到错误邮箱上 Zhan 问：Agent 做得越多，什么人类技能会变得更有价值？ Karpathy 的答案是：品味、判断、审美、监督，以及规格设计。 他把当前 Agent 比作实习生。这个比喻很准确，但不能过度拟人化。Agent 不是真的有人类动机的员工，它只是执行能力越来越强，同时会在一些人类觉得显而易见的地方犯错。 Karpathy 举了 MenuGen 的一个实际问题。用户用 Google 账号登录，但购买 credits 时使用 Stripe 账号。Google 和 Stripe 都有邮箱地址。Agent 在实现购买逻辑时，试图用 Stripe 邮箱去匹配 Google 邮箱，把购买的 credits 归到对应用户身上。 这听起来好像合理，但在工程上是危险的。一个人完全可能用一个邮箱登录 Google，用另一个邮箱付款。如果系统用邮箱关联资金，就可能出现购买记录无法归属、资金错配或账户混乱。正确做法应该是使用系统内部稳定的 persistent user ID 来绑定用户身份和支付记录。 你为什么要用邮箱地址来交叉关联资金？它们可以是任意的，你可以用不同的邮箱。这种做法太奇怪了。 这类问题没有语法错误，代码可能能跑，测试可能还过，但系统设计是错的。Agent 没有真正理解身份、支付和资金归属的风险。 所以 Karpathy 说，人必须负责 spec ，也就是规格。你要告诉 Agent：所有资金和用户状态必须绑定到内部唯一用户 ID，而不是绑定到外部邮箱。你要负责顶层设计、约束条件和判断标准。Agent 可以填补实现细节，但不能替你理解系统边界。 他接着举了一个更技术的例子。现在他已经不再记 PyTorch 、 NumPy 、 pandas 之间很多细碎 API 差异，比如 keepdims 还是 keepdim ， dim 还是 axis ， reshape 、 permute 、 transpose 分别怎么写。这些细节可以交给 Agent，因为模型记忆很好。 但他仍然强调，人必须理解底层概念。比如张量（ tensor ）是什么， view 和 storage 的关系是什么，什么时候只是改变同一块内存的视图，什么时候会复制数据。如果不懂这些底层机制，就可能让模型写出低效甚至错误的代码。 这给“什么值得学”提供了一个非常具体的答案： 细节可以外包，理解不能外包。 API 名称可以忘，但概念结构不能丢。 【11】模型写出的代码能跑，但有时“很丑” Zhan 追问：taste 和 judgment 会不会随着模型进步而越来越不重要？ Karpathy 没有把话说死。他希望模型会进步，也认为没有什么根本原因阻止它们在品味、审美和简洁性上变好。但他指出，至少现在，这些能力还没有被很好地训练出来，可能因为它们没有进入足够好的 RL 奖励环境。 他看模型生成的代码时，有时会“心脏病发作”。代码能跑，但不一定好。它可能很臃肿，有很多复制粘贴，有别扭的抽象，结构脆弱，维护起来很难。 有时我看到它写出来的代码，会有一点心脏病发作的感觉。它能跑，但真的很恶心。 他还提到 MicroGPT 项目。他想把 LLM training 简化到极致，让训练过程尽可能小、清晰、可理解。他不断要求模型“再简化一点”，但模型做不到。那种感觉像“拔牙”一样困难。 我不断地让 LLM“再简化一点”，它就是做不到。你能感觉到你在 RL 回路之外。就像在拔牙。 Karpathy 的解释是，这个任务可能走出了模型被 RL 覆盖的能力回路。模型擅长生成常见工程形态，却不擅长极简、克制、优雅的抽象压缩。 【12】我们不是在造动物：Karpathy 说我们召唤的是“幽灵” Zhan 问：你写过一篇关于 animals vs ghosts 的文章，核心意思是我们不是在造动物，而是在召唤幽灵。这个框架为什么重要？ Karpathy 说，他写这篇文章，是因为自己也在试图理解这些模型到底是什么。如果你对模型是什么有一个更好的心智模型，你就会更擅长使用它。 “幽灵”这个词听起来神秘，但 Karpathy 的意思并不玄学。他是在对比两种智能来源。 动物智能来自进化、身体、环境互动、内在动机、好奇心、乐趣、持续学习。动物会在世界中行动，被后果塑造，会在生命过程中不断适应。 LLM 不是这样。今天的前沿 LLM，首先来自大规模预训练：模型在海量人类文档上学习统计结构。然后再叠加强化学习、偏好数据、工具调用等后训练过程。它们不是动物式智能，而是由人类文档、统计模式和奖励函数塑造出的模拟实体。 在访谈里，他把这个比喻落到一个很朴素的使用原则上： 不要把 LLM 当动物。 你对它大喊大叫，不会让它因为害怕而更努力。你鼓励它，也不是在激发它的内在动机。模型没有动物式情绪。它的行为来自统计模拟、上下文、工具、训练数据和奖励机制。 如果你对它大吼，它不会因此工作得更好或更差，也没有任何影响。 Karpathy 也承认，“幽灵”框架有哲学化的一面。他没有说它能直接产出五条系统优化建议。它更像一种防止误用的提醒：不要笼统地问“AI 聪不聪明”，要问它在哪些训练分布里强，哪些奖励信号塑造了它，在哪些任务上可能出现锯齿状断崖。 【13】Agent first 基础设施：一句话构建并部署 MenuGen Zhan 问：当 Agent 不只聊天，而是拥有权限、本地上下文，并能代表人采取行动时，世界会变成什么样？ Karpathy 说，几乎一切都要重写。今天的工具、文档、服务和设置流程，仍然主要是为人设计的。 比如一个框架的文档会告诉你：去某个 URL ，点击某个设置，复制某个 key ，打开某个菜单，配置某个 DNS 。Karpathy 的反应是：为什么还在告诉我该怎么做？我不想做这些事。我想知道的是，哪一段东西可以复制给我的 Agent，让它自己去做。 为什么还有人在告诉我该做什么？我什么都不想做。“给我复制粘贴给 Agent 的东西是什么？” 这不是懒，而是范式变化。 Agent first infrastructure 的目标，是把世界拆成 Agent 能读懂的输入，以及 Agent 能安全调用的动作接口。 在软件基础设施里，这意味着文档、API、权限、日志、部署、配置、账单、回滚，都要变得更适合 Agent 使用。不是让 Agent 模拟人去点网页，而是让 Agent 直接理解状态、调用动作、收到反馈。 Karpathy 又回到 MenuGen。他说，做 MenuGen 最麻烦的部分其实不是写代码，而是部署：在 Vercel 上部署，连接各种服务，进入不同设置页面，配置 DNS，把所有东西串起来。 他希望未来的测试标准是：给 LLM 一句 Build MenuGen ，它不仅能写代码，还能完成部署，上线到互联网，配置好依赖服务，而且整个过程不需要人去一个个菜单里操作。 更远一点，他设想每个人、每个组织都可能有自己的 Agent representation。以后安排会议、处理细节、协调事项，可能变成“我的 Agent 和你的 Agent 去谈”。 【14】智能变便宜后，最贵的是理解 Zhan 最后问：当智能变得便宜，什么仍然值得深入学习？ Karpathy 引用了一句话： 你可以外包你的思考，但不能外包你的理解。 这句话容易被写成励志格言，但 Karpathy 的解释很具体。 他仍然是系统的一部分。信息必须进入他的脑子里。他觉得自己正在变成瓶颈：要知道到底在建什么，为什么值得做，怎样指导自己的 Agent。思考步骤可以让模型跑很多遍，但如果人没有理解，就无法判断哪条路线是对的，无法写出好的规格，也无法发现 Agent 在身份绑定、系统结构、代码质量上的错误。 我感觉自己正在变成瓶颈：我要知道我们到底在建什么，为什么值得做，以及怎样指导我的 Agent。 这也是他对 LLM knowledge bases 感兴趣的原因。他喜欢把文章、资料、事实重新投影成 wiki，因为不同的信息组织方式能帮助他获得洞见。对他来说，这不是让 AI 代替理解，而是用 AI 增强理解。 这一点和前面的工程例子连在一起： • Agent 可以记 API 细节，但人要理解 tensor 、 view 、 storage 和内存效率； • Agent 可以写支付逻辑，但人要理解用户身份和资金归属； • Agent 可以生成大量代码，但人要判断抽象是否臃肿、结构是否脆弱； • Agent 可以帮你思考很多方案，但人要知道目标是否值得做。 所以， 智能变便宜之后，学习不是不重要了，而是学习的重心变了。 更少时间花在机械记忆和低层执行上，更多时间花在系统理解、问题定义、质量判断、因果关系和领域直觉上。 他认为，很多公司还没有重构面试流程。如果仍然给候选人一组小 puzzle，让他们现场解算法题，这还是旧范式。它测不出一个人是否会在 Agentic Engineering 里高效工作。 更好的测试应该是大项目。比如让候选人做一个 Twitter clone：不仅要能跑，还要做得好、做得安全。然后再用多个 Agent 去攻击这个网站，尝试破坏它，看看系统能否经得住。 面试本该是这样的：甩给候选人一个极大的项目，比如做个给 Agent 用的 Twitter 仿盘，要求做得绝对安全。然后，我挂上 10 个 Cursor 当作“红队”，放开手脚去攻击你做出来的这个网站。 这套评估方式的核心，不是看候选人能不能手写某个算法，而是看他能不能： 把模糊目标变成清晰规格；指挥 Agent 完成大规模实现；识别安全和架构风险；设置测试与验证；在模型生成的大量代码里保持质量判断；让最终系统经得起外部攻击和压力。 【10】Agent 能写代码，但还会把付款绑到错误邮箱上 Zhan 问：Agent 做得越多，什么人类技能会变得更有价值？ Karpathy 的答案是：品味、判断、审美、监督，以及规格设计。 他把当前 Agent 比作实习生。这个比喻很准确，但不能过度拟人化。Agent 不是真的有人类动机的员工，它只是执行能力越来越强，同时会在一些人类觉得显而易见的地方犯错。 Karpathy 举了 MenuGen 的一个实际问题。用户用 Google 账号登录，但购买 credits 时使用 Stripe 账号。Google 和 Stripe 都有邮箱地址。Agent 在实现购买逻辑时，试图用 Stripe 邮箱去匹配 Google 邮箱，把购买的 credits 归到对应用户身上。 这听起来好像合理，但在工程上是危险的。一个人完全可能用一个邮箱登录 Google，用另一个邮箱付款。如果系统用邮箱关联资金，就可能出现购买记录无法归属、资金错配或账户混乱。正确做法应该是使用系统内部稳定的 persistent user ID 来绑定用户身份和支付记录。 你为什么要用邮箱地址来交叉关联资金？它们可以是任意的，你可以用不同的邮箱。这种做法太奇怪了。 这类问题没有语法错误，代码可能能跑，测试可能还过，但系统设计是错的。Agent 没有真正理解身份、支付和资金归属的风险。 所以 Karpathy 说，人必须负责 spec ，也就是规格。你要告诉 Agent：所有资金和用户状态必须绑定到内部唯一用户 ID，而不是绑定到外部邮箱。你要负责顶层设计、约束条件和判断标准。Agent 可以填补实现细节，但不能替你理解系统边界。 他接着举了一个更技术的例子。现在他已经不再记 PyTorch 、 NumPy 、 pandas 之间很多细碎 API 差异，比如 keepdims 还是 keepdim ， dim 还是 axis ， reshape 、 permute 、 transpose 分别怎么写。这些细节可以交给 Agent，因为模型记忆很好。 但他仍然强调，人必须理解底层概念。比如张量（ tensor ）是什么， view 和 storage 的关系是什么，什么时候只是改变同一块内存的视图，什么时候会复制数据。如果不懂这些底层机制，就可能让模型写出低效甚至错误的代码。 这给“什么值得学”提供了一个非常具体的答案： 细节可以外包，理解不能外包。 API 名称可以忘，但概念结构不能丢。 【11】模型写出的代码能跑，但有时“很丑” Zhan 追问：taste 和 judgment 会不会随着模型进步而越来越不重要？ Karpathy 没有把话说死。他希望模型会进步，也认为没有什么根本原因阻止它们在品味、审美和简洁性上变好。但他指出，至少现在，这些能力还没有被很好地训练出来，可能因为它们没有进入足够好的 RL 奖励环境。 他看模型生成的代码时，有时会“心脏病发作”。代码能跑，但不一定好。它可能很臃肿，有很多复制粘贴，有别扭的抽象，结构脆弱，维护起来很难。 有时我看到它写出来的代码，会有一点心脏病发作的感觉。它能跑，但真的很恶心。 他还提到 MicroGPT 项目。他想把 LLM training 简化到极致，让训练过程尽可能小、清晰、可理解。他不断要求模型“再简化一点”，但模型做不到。那种感觉像“拔牙”一样困难。 我不断地让 LLM“再简化一点”，它就是做不到。你能感觉到你在 RL 回路之外。就像在拔牙。 Karpathy 的解释是，这个任务可能走出了模型被 RL 覆盖的能力回路。模型擅长生成常见工程形态，却不擅长极简、克制、优雅的抽象压缩。 【12】我们不是在造动物：Karpathy 说我们召唤的是“幽灵” Zhan 问：你写过一篇关于 animals vs ghosts 的文章，核心意思是我们不是在造动物，而是在召唤幽灵。这个框架为什么重要？ Karpathy 说，他写这篇文章，是因为自己也在试图理解这些模型到底是什么。如果你对模型是什么有一个更好的心智模型，你就会更擅长使用它。 “幽灵”这个词听起来神秘，但 Karpathy 的意思并不玄学。他是在对比两种智能来源。 动物智能来自进化、身体、环境互动、内在动机、好奇心、乐趣、持续学习。动物会在世界中行动，被后果塑造，会在生命过程中不断适应。 LLM 不是这样。今天的前沿 LLM，首先来自大规模预训练：模型在海量人类文档上学习统计结构。然后再叠加强化学习、偏好数据、工具调用等后训练过程。它们不是动物式智能，而是由人类文档、统计模式和奖励函数塑造出的模拟实体。 在访谈里，他把这个比喻落到一个很朴素的使用原则上： 不要把 LLM 当动物。 你对它大喊大叫，不会让它因为害怕而更努力。你鼓励它，也不是在激发它的内在动机。模型没有动物式情绪。它的行为来自统计模拟、上下文、工具、训练数据和奖励机制。 如果你对它大吼，它不会因此工作得更好或更差，也没有任何影响。 Karpathy 也承认，“幽灵”框架有哲学化的一面。他没有说它能直接产出五条系统优化建议。它更像一种防止误用的提醒：不要笼统地问“AI 聪不聪明”，要问它在哪些训练分布里强，哪些奖励信号塑造了它，在哪些任务上可能出现锯齿状断崖。 【13】Agent first 基础设施：一句话构建并部署 MenuGen Zhan 问：当 Agent 不只聊天，而是拥有权限、本地上下文，并能代表人采取行动时，世界会变成什么样？ Karpathy 说，几乎一切都要重写。今天的工具、文档、服务和设置流程，仍然主要是为人设计的。 比如一个框架的文档会告诉你：去某个 URL ，点击某个设置，复制某个 key ，打开某个菜单，配置某个 DNS 。Karpathy 的反应是：为什么还在告诉我该怎么做？我不想做这些事。我想知道的是，哪一段东西可以复制给我的 Agent，让它自己去做。 为什么还有人在告诉我该做什么？我什么都不想做。“给我复制粘贴给 Agent 的东西是什么？” 这不是懒，而是范式变化。 Agent first infrastructure 的目标，是把世界拆成 Agent 能读懂的输入，以及 Agent 能安全调用的动作接口。 在软件基础设施里，这意味着文档、API、权限、日志、部署、配置、账单、回滚，都要变得更适合 Agent 使用。不是让 Agent 模拟人去点网页，而是让 Agent 直接理解状态、调用动作、收到反馈。 Karpathy 又回到 MenuGen。他说，做 MenuGen 最麻烦的部分其实不是写代码，而是部署：在 Vercel 上部署，连接各种服务，进入不同设置页面，配置 DNS，把所有东西串起来。 他希望未来的测试标准是：给 LLM 一句 Build MenuGen ，它不仅能写代码，还能完成部署，上线到互联网，配置好依赖服务，而且整个过程不需要人去一个个菜单里操作。 更远一点，他设想每个人、每个组织都可能有自己的 Agent representation。以后安排会议、处理细节、协调事项，可能变成“我的 Agent 和你的 Agent 去谈”。 【14】智能变便宜后，最贵的是理解 Zhan 最后问：当智能变得便宜，什么仍然值得深入学习？ Karpathy 引用了一句话： 你可以外包你的思考，但不能外包你的理解。 这句话容易被写成励志格言，但 Karpathy 的解释很具体。 他仍然是系统的一部分。信息必须进入他的脑子里。他觉得自己正在变成瓶颈：要知道到底在建什么，为什么值得做，怎样指导自己的 Agent。思考步骤可以让模型跑很多遍，但如果人没有理解，就无法判断哪条路线是对的，无法写出好的规格，也无法发现 Agent 在身份绑定、系统结构、代码质量上的错误。 我感觉自己正在变成瓶颈：我要知道我们到底在建什么，为什么值得做，以及怎样指导我的 Agent。 这也是他对 LLM knowledge bases 感兴趣的原因。他喜欢把文章、资料、事实重新投影成 wiki，因为不同的信息组织方式能帮助他获得洞见。对他来说，这不是让 AI 代替理解，而是用 AI 增强理解。 这一点和前面的工程例子连在一起： • Agent 可以记 API 细节，但人要理解 tensor 、 view 、 storage 和内存效率； • Agent 可以写支付逻辑，但人要理解用户身份和资金归属； • Agent 可以生成大量代码，但人要判断抽象是否臃肿、结构是否脆弱； • Agent 可以帮你思考很多方案，但人要知道目标是否值得做。 所以， 智能变便宜之后，学习不是不重要了，而是学习的重心变了。 更少时间花在机械记忆和低层执行上，更多时间花在系统理解、问题定义、质量判断、因果关系和领域直觉上。 Q&A 速览 问：2025 年 12 月发生了什么？ 答：最新模型生成的代码不需要修改了，可靠性在持续的项目中也保持住了。 问：Software 3.0 和以前有什么不同？ 答：以前的代码处理结构化数据，现在你可以处理任意信息。以前做不了的东西现在可以了。这不是加速，是新的可能性。 问：为什么最先进的 AI 模型在简单任务上犯低级错误？ 答：能力分布取决于 RL 训练覆盖的领域和实验室的数据选择。可验证的领域能力飙升，其余领域可能很弱。 问：Vibe Coding 和 Agentic Engineering 的区别？ 答：Vibe Coding 是提升所有人的下限，Agentic Engineering 是保持专业标准的前提下利用 Agent 加速。 问：什么时候人的品味和判断会不重要？ 答：可能会，但前提是实验室把审美奖励纳入 RL 训练目标。目前 Agent 的代码经常“能跑但很难看”。 【最后】 这场访谈里，Karpathy 的判断有几个值得注意的张力。 第一，他一边说 Agent 写出的代码丑得让他心脏病发作，一边说他自己已经停止修改了。“信任并没有解决品味的问题”——能跑的代码和好代码不是一回事。可这种“用着丑的，但用着”的状态，可能比任何 hype 都更接近真实的 Vibe Coding 现状。 第二，他暗示有“被低估的 RL 机会”领域却不愿公开。一个不愿在台上发含糊推文的人主动回避，本身是个信号：窗口期还没关。值得注意的是，他的公司 Eureka Labs 做的是 AI 教育，而教育恰好是一个输出可以被评估、可以被标准化考核的领域。 第三，他给“动物 vs 幽灵”这个框架自己降了级别，又用“你可以外包思考，但不能外包理解”给整场对谈收束。把这两件事放在一起读：他的判断是， 真正稀缺的不是任何一个具体技能，而是判断“我们到底要做什么、为什么值得做”的能力。 如果“几乎所有领域最终都能被验证”这个判断成立，那么瓶颈最终不在执行端，而在目标设定端。 但这里有一个隐含的时间问号。Karpathy 自己也承认，品味和判断之所以暂时不可替代，原因只是“实验室还没做”。如果这个判断成立，那么所谓人类不可替代的部分，不是因为人类独一无二，而是因为训练方法还没到位。这就把“外包思考但不能外包理解”这句话的有效期打了一个问号。 未来 6 12 个月值得盯三个具体信号： 1. 前沿实验室在编程/数学之外，往哪些领域注入 RL 数据——那里的能力会突然冒出来 2. Agent first 的基础设施（部署、auth、payments）会不会有第一波收敛——MenuGen 部署的痛苦如果还在，“自动化社会”的路就长得多 3. 模型的下一代更新是否包含审美和代码质量相关的 RL 目标 原始视频：https://www.youtube.com/watch?v=96jN2OCOfLs No access c8a6135d21cb4e96b17000b55282df94 00:00 No access c8a6135d21cb4e96b17000b55282df94 00:00 🔗 原文链接： https://mp.weixin.qq.com/s/Ru3Z7wUV... https://mp.weixin.qq.com/s/Ru3Z7wUV... 原创 宝玉 宝玉 宝玉AI2026年4月30日 06:19 美国 Andrej Karpathy 说，他已经记不清上次修改 AI 生成的代码是什么时候了。 Karpathy 参与创建了 OpenAI，在 Tesla 领导过 Autopilot 视觉团队，去年一条推文发明了“凭感觉编程”（Vibe Coding）这个词，后来被 Collins 词典选为 2025 年度词汇。 2026 年 4 月，Karpathy 在 Sequoia Capital 的 AI Ascent 现场接受合伙人 Stephanie Zhan 的访谈。这场 30 分钟的对话覆盖了他对编程范式剧变的亲身感受、Software 3.0 的实质、AI 为什么在某些地方极强而在另一些地方离谱地弱，以及“凭感觉编程”之后更严肃的下一步是什么。 原始视频：https://www.youtube.com/watch?v=96jN2OCOfLs • 2025 年 12 月 是 Karpathy 个人的转折点：AI 输出从“有帮助但常要修补”变成“直接可用”，他进入完全凭感觉编程的状态。 • Software 3.0 的关键 不是“用自然语言写代码”，而是通过 prompt 和 context 操作 LLM 这个新的信息处理解释器。 • MenuGen 案例 让 Karpathy 意识到，一些 AI 应用不是会被做得更快，而是会被模型原生能力直接吞掉。 • LLM 的能力高度不均匀 ：它可以重构 10 万行代码、找零日漏洞，却可能在“去 50 米外洗车该走路还是开车”这种常识题上犯错。 • Vibe Coding 抬高所有人做软件的下限 ；Agentic Engineering 则是在使用 Agent 提速时，保住专业软件的质量、安全和责任门槛。 • 人类不必再记住每个 API 细节 ，但必须理解系统结构、底层机制和质量标准，否则无法监督 Agent。 • Karpathy 用“幽灵”形容 LLM：它不是动物式智能，而是由人类文档、预训练统计和强化学习奖励塑造出的锯齿状实体。 • 智能变便宜后 ，教育的重点不是抵制外包思考，而是确保理解仍然进入人的大脑。 【1】2025 年 12 月：一个程序员的投降 Zhan 问：你几个月前说，自己从未像现在这样觉得作为程序员落后。这是兴奋还是不安？ Karpathy 说两者都有。 过去一年他一直在用 Cursor 等智能体编码工具。早期这些工具有用，可以生成一些代码块，但经常出错需要修改。真正的转折出现在 2025 年 12 月。那段时间他正好休假，有更多时间折腾 side project，明显感觉到最新模型生成的代码块开始“直接能用”。 一开始，他只让模型写一点。结果不错，就继续让它写更多。再往后，他发现自己已经很久没有亲自纠正模型输出了，信任感不断增加。最后他进入了自己后来称为 Vibe Coding 的状态。 我记不得上一次我需要纠正它是什么时候了。然后我就越来越信任这个系统。 这里的 Vibe Coding，不适合硬译成“氛围编程”。更准确地说，它是一种“凭感觉让 AI 写代码”的开发方式：人用自然语言持续提出意图，模型生成、修改、调试代码，人不再像过去那样逐行写、逐行读 diff。Karpathy 2025 年 2 月在 X 上提出这个词时，描述的是一种“放弃对代码本身的直接控制、顺着感觉让模型往前走”的开发体验。 但这场访谈里，Karpathy 的重点已经不只是 Vibe Coding。他强调，很多人对 AI 的印象还停留在“一个类似 ChatGPT 的东西”上：你问一句，它答一句。到 2025 年底以后，值得重新看的是 Agentic coherent workflow ——一种更连贯的智能体工作流。模型不只是回答问题，而是能连续规划、写代码、调试、执行、根据环境反馈继续修正。 很多人去年体验到的 AI，还是一个类似 ChatGPT 的东西。但你真的必须重新看一眼，而且要看 12 月之后的版本。 过去程序员的速度主要取决于他能写多少代码、记住多少 API、怎样调试。 现在，速度越来越取决于他能否正确地指挥一组强大但会犯错的 Agent。 【2】Software 3.0：给 Agent 复制粘贴一段文字，这就是编程 Zhan 问：你说 LLM 是一种新计算机，不只是更好的软件。如果一个团队真的相信这一点，它会怎样不同地构建产品？ Karpathy 从自己那套软件分期讲起。 Software 1.0 是传统软件：人写显式代码，计算机按规则执行。 Software 2.0 是神经网络时代：人不再直接写所有规则，而是设计数据集、目标函数和神经网络架构，通过训练得到模型权重。Karpathy 早在 2017 年就写过《Software 2.0》，把神经网络视为一种新的软件开发方式。 Software 3.0 则是大语言模型时代。LLM 经过大规模任务训练之后，变成一种可编程的计算机。你不再只是在代码编辑器里写函数，而是在 prompt 、 context window 、文件、工具调用和外部环境之间，组织一段给模型执行的“上下文程序”。 context window 可以理解为模型一次调用中能看到的全部信息：指令、历史对话、文件、错误日志、代码片段、图片、工具返回结果。Karpathy 的说法是，这个上下文窗口成了人操纵 LLM 解释器的“把手”。 他举了一个安装 OpenCL 的例子。传统做法是写一个 shell script ，让它适配各种机器、平台和环境。随着目标环境变多，脚本会不断膨胀，最后复杂到很难维护。但在 Software 3.0 里，安装说明本身可能就是一段可以复制给 Agent 的文本。Agen