
Datawhale干货
访谈:Andrej Karpathy
一、一个真实的转折点:2025年12月
Andrej Karpathy 是 OpenAI 联合创始人、前 Tesla Autopilot 负责人,也是"Vibe Coding"这个词的发明者。他几个月前公开说,自己作为程序员"从未感到如此落后"。
这场访谈,就是从这句话聊起的!
访谈地址:https://www.youtube.com/watch?v=96jN2OCOfLs&t=457s
这场访谈里,他第一次系统讲清楚了一个新的概念:Agentic Engineering,智能体工程。它不是 Vibe Coding 的升级版,而是另一层。Vibe Coding 把做软件的门槛拉到了前所未有的低,让所有人都能上手;Agentic Engineering 解决的是另一个问题:当 Agent 能写代码、能跑流程、能交付结果,谁来为质量负责?
Karpathy 给出的答案很具体:不是模型,是人。但人要负责的东西也变了,从写代码本身,变成了管理认知、设计规格、守住理解。
Datawhale 在不改变原意的前提下,对这场访谈做了整理和编排。
二、Vibe Coding:“程序”的定义被改写了
去年他发明了 Vibe Coding 这个词。它形容的是一种工作状态:看到结果、说出意图、跑一下,不行就让模型改,复制粘贴一下,大概就 work 了。这个词后来被柯林斯词典选为 2025 年度词汇。
但 Vibe Coding 能 work,背后藏着一个根本性的转变:程序长什么样,已经变了。
Karpathy 把软件分成三层。最早的 Software 1.0 是人写代码,机器按规则执行。后来神经网络火了,他在 2017 年提出 Software 2.0:人不再直接写规则,而是设计数据集和目标函数,规则从训练里"长"出来。而现在,Software 3.0 来了。你既不写代码,也不训权重,你写 prompt。模型本身就是一个可以被自然语言编程的解释器。
这件事最直观的画面,藏在 Anthropic 给 Claude 写的安装方式里。Karpathy 注意到,传统装一个工具,你写一段 shell 适配各种环境,脚本随支持环境的增加越写越臃肿、越难维护。而 Claude 给你的不是脚本,是一段文本,让你复制粘贴给 Agent。Agent 会自己读你的机器环境、自己执行步骤、遇到错误自己 debug。
安装这件事的"程序",从一段精确脚本,变成了一段可以扔给 Agent 的描述。
他看完的反应是:"我那个 MenuGen 全是多余的,它还在旧范式里,那个 app 本身就不该存在。"
他否定的不是自己做得不好,而是中间那一整层工程结构。OCR、生图、排版,这是旧范式的产物。新范式里输入是一张图,输出是一张图,中间不需要 app。
这两个例子合起来,是 Vibe Coding 真正的底层。它能 work,不是因为 AI 让你"写代码"变快了,是因为源代码本身换了一种形态。过去是代码文件,现在是你扔给模型的那一整段上下文:图片、需求、约束、错误日志、文档。
Vibe Coding 解决的问题是:"能不能跑起来?"它把做软件的门槛拉到了一个前所未有的低。不会写代码的人也能做出小工具,会写代码的人能更快搭出原型。它的真实贡献是把下限拉高了。
但地板不是天花板:原型不是系统,跑得快不等于工程做对。
三、Agentic Engineering:工程师从执行者变成管理者
地板之上的那一层,Karpathy 把它叫做 Agentic Engineering,智能体工程。
它不再问"能不能跑起来",而是问一系列完全不同的问题:它在哪里会出错?我怎么验证它的输出?我怎么在加速的同时保住质量?当出问题时,我能不能回滚、能不能追责?
Vibe Coding 拉高的是地板,让更多人开始做软件。Agentic Engineering 守的是上限,别因为 AI 让你快了,专业软件就出问题。这两层不矛盾,但解决的不是一个问题。前者面向所有人,后者面向那些必须为软件结果负责的人。
Karpathy 给了一个具体的工作方法:把 Agent 当实习生,而不是神谕。实习生需要清晰的任务、相关文件、边界、checklist、测试、审查。它能做真正的活儿,但它不会替你承担后果。
这件事最实操的画面,藏在他对招聘的吐槽里。他说,大部分公司还在用旧范式招工程师。给一道现场算法题,让候选人手写代码。这种考法测不出一个人能不能在 Agentic Engineering 里高效工作。
更接近未来的考法是这样的:给候选人一个大项目,比如做一个给 Agent 用的 Twitter 仿盘,要求不仅能跑,还要做得绝对安全。然后挂上 10 个 coding agent 当红队,让它们放开手脚攻击候选人做出来的系统,看能不能扛住。
工程师的核心技能,正在从"写代码",变成"管理认知"。Karpathy 自己说,他看到 Agentic Engineering 这条路的天花板非常高。以前业内常说"10x 工程师",他觉得这个数字现在远远不够,真正熟练的人产出速度,可能比这高得多。
四、要管好这个东西,先看懂它是什么
Karpathy 在访谈里反复强调一个判断:不要把 LLM 当动物。
动物有身体,有生存压力,有内在动机,会从经验里学。你训一只狗,奖惩有效,因为它在世界里活着。LLM 不是这样的存在。它没有身体,没有生存压力,没有连续的记忆。它是被你"召唤"进上下文里,说几句话,然后消失的。它的能力是从人类写过的文字里学出来的,再被奖励函数调教过一轮,最后变成一个模拟出来的东西。
他用了一个很狠的词形容它:幽灵。这个比喻有非常具体的工程含义!
第一,它的智能是不均匀的。Karpathy 自己举的例子很有冲击力:同一个 state-of-the-art 模型,可以重构十万行代码、可以找出零日漏洞,但你问它"50 米外有个洗车店,我应该开车去还是走路去?",它会让你走路(它没意识到你要洗的是车)。更早一点的版本里,"草莓里有几个 r"它都数不对。一个模型,上限和下限可以差出十万八千里,这件事本身就是 jagged 的定义。它不会因为前一个任务做得好,就在下一个任务上不犯傻。你得搞清楚,自己手上这件事,到底踩在它会的那一片,还是不会的那一片。
第二,可验证性是真正的瓶颈。数学和代码进步那么快,不是因为模型整体变聪明了,而是因为这些任务有明确的验证信号。能跑通吗?测试过吗?漏洞复现了吗?凡是能被快速验证的任务,AI 就是放大器。凡是验证不了的任务,AI 就是一个让你越来越自信、但也越来越容易错的机器。
Karpathy 提了一个细节:从 GPT-3.5 到 GPT-4,国际象棋能力跃升非常大。很多人以为是模型整体变聪明了,但他后来发现,真正的原因是 OpenAI 有人决定把大量国际象棋数据塞进了预训练。数据进了分布,能力就跟着上去了。
一件事在 LLM 上能不能做好,背后是两个条件叠加:这件事本身可不可验证,以及实验室关不关心。可验证的东西能做 RL,但实验室不一定愿意花资源去做。模型在哪里强、哪里弱,最终是这两个条件共同决定的。你以为是涌现,可能只是有人做了选择。
第三,最适合 Agent 的环境,是现实会回推你的环境。代码之所以成为 AI 第一个攻陷的领域,是因为编译器、测试、运行结果、diff 都会立刻告诉你对错。你给 Agent 的任务越接近这种环境,它就越靠谱。
走出这个区域,你能立刻感觉到。Karpathy 提到他做 microGPT 项目时,想让模型把 LLM training 代码"再简化一点、再简化一点",模型就是做不到。他形容那种感觉"像拔牙"。代码能写,但写不出极简、克制、优雅的抽象压缩。那种钝感,就是模型在告诉你:这件事,它没在 RL 里被奖励过。
使用 LLM 的本质,不是"教它干活",而是为它设计上下文、工具、记忆和约束。给这个幽灵搭一套能让你看见错误、纠正错误、验证错误的流程。
五、人不能交出去的那一部分:Spec、判断与理解
访谈最后,Stephanie Zhan 问了一个所有人都会问的问题:当智能变得便宜,什么还值得人类深入学习?
Karpathy 没有给出一个励志答案。他引用了一句最近一直在他脑子里转的话:
你可以外包你的思考,但不能外包你的理解。
他在 MenuGen 上踩到一个很具体的坑。MenuGen 用 Google 账号登录、用 Stripe 付费,两边都有用户邮箱。Agent 写购买逻辑时做了一个看起来很聪明的判断:把 Stripe 上付费用的邮箱,和 Google 登录用的邮箱当成同一个键来对账,把 credits 归到对应的 Google 账号上。
这听起来合理,工程上却是错的。一个用户完全可以用一个邮箱登 Google、用另一个邮箱付款。真正稳定的做法,是让所有资金流都绑到内部唯一的 user ID 上,而不是绑到任何外部邮箱上。代码能跑、测试可能也过、语法也没错,但系统设计是错的。Agent 不理解"用户身份"和"资金归属"这件事的真正约束,它只是看到两边都有 email,就把它们对齐了。
Karpathy 由此说出了一句很关键的话: 人必须负责 spec,也就是规范。你要告诉 Agent:所有资金必须绑定到内部唯一 user ID。你负责顶层设计、约束条件和判断标准。Agent 负责填空和实现。
MenuGen 那个 user ID 的坑,本质上和他对"还要学什么"的回答是同一件事:哪些东西可以交给 Agent,哪些东西必须自己装在脑子里。Agent 可以记住 PyTorch 和 NumPy 之间所有琐碎的 API 差异,keepdims 还是 keepdim、dim 还是 axis、reshape 还是 permute,这些 Karpathy 自己说他已经记不住了,也不需要记。但你必须知道 tensor 是什么、view 和 storage 是怎么回事。比如你以为只是换了个角度看同一块数据,其实底层可能已经在悄悄复制内存。API 的写法可以委托,底层概念不行。
他说自己越来越觉得,人在这个流程里正在变成瓶颈,不是执行的瓶颈,是理解的瓶颈。你要知道在做什么、为什么值得做、怎么指挥 Agent。Agent 能跑很多遍,但如果你没有理解,你判断不了哪条路线对、写不出好的规格、也发现不了 Agent 在哪里悄悄犯了错。
但他不是只在讲一个困境,他自己有一套对付这件事的方法,正好就是过去一年最火的一类应用:LLM 知识库。
Karpathy 自己的用法是这样的。每次读到一篇文章,他都会把它叠进一个正在累积的个人 wiki 里,然后让 LLM 从不同角度提问、用不同方式重新组织这堆信息。他说每看到一种新的投影方式,自己就多得到一点 insight。"这本质上就是让 LLM 在一份固定数据上,给我做大量的合成数据生成。"
注意他这个用法的方向:不是让 LLM 替他读、替他懂,而是帮自己把这份东西真正吃透。理解这件事,LLM 帮不上忙,只能自己来。
这个区别在今天尤其重要。市面上大量"AI 第二大脑"、"个人知识库"类的产品,很容易滑进另一种用法:让 AI 替你总结、替你记住、替你整理。短期很爽,长期的代价是,你以为自己懂了,其实只是 AI 帮你存了一份你看不懂的笔记。Karpathy 的做法是反着来的,他用 LLM 逼自己换角度重看同一件事,每一次新投影,都是在锻炼自己的理解,而不是替代自己的理解。
不光是写代码,凡是 AI 能帮上忙的事都一样,分析、设计、写作、决策都是这样。AI 可以替你起草、检索、重构、生成方案。但最终那个"对"的答案,还是得你自己拍板。
结语:从代码的作者,变成系统的负责人
回到开头 Karpathy 说自己"落后"那句话。他真正落后的不是写代码这件事,写代码这一层 AI 已经搞得差不多了。他在意的是适应速度本身:能不能跟上工具的变化、能不能搞清楚模型落在哪一片能力分布里、能不能给这个幽灵搭一套能验证它的流程、能不能在所有人都在外包思考的时候,仍然守住自己的理解。
从 Vibe Coding 到 Agentic Engineering,变的不是写代码的方式,是工程师的位置。从指令的执行者,变成认知的管理者。从代码的作者,变成系统的负责人。
一起“ 点 赞 ” 三连 ↓
金牛配资提示:文章来自网络,不代表本站观点。