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，变的不是写代码的方式，是工程师的位置。从指令的执行者，变成认知的管理者。从代码的作者，变成系统的负责人。
一起“ 点 赞 ” 三连 ↓
金牛配资提示：文章来自网络，不代表本站观点。
