ESC
↑↓ 选择↵ 打开esc 关闭⌘K 唤起
← Home NO.12
第 12 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日

从VibeCoding到智能体工程

AK
Andrej Karpathy · Sequoia Capital
视频 29:44 原文约 3.3 万字 预计阅读 31 分钟 来源视频 ↗ 中英对照全文
双人对谈 · 本期速读电台 00:00 / 37:35
TL;DR · 三句话
  1. 2025 年 12 月是 Karpathy 的明确转折点:此前他用 agentic 工具已一年,"它擅长生成一段段代码,有时出错你得手动改,但总体还算有帮助";12 月他在休假、时间更多,突然发现最新模型生成的代码"就是没问题(the chunks just came out fine)",不断追加需求也没问题,"想不起上次纠正它是什么时候了",于是越来越信任系统、一头扎进 vibe coding。这种又兴奋又不安的混合感,让他作为程序员"从未感觉如此落后"。→ 详细
  2. 软件正进入 3.0 范式:1.0 是人写显式代码,2.0 是训神经网络(编程=组织数据集),3.0 是把 LLM 当成一台"可编程的计算机"——编程变成写 prompt,context window 是你操纵这台"解释器"的杠杆。很多 app(如他写的 MenuGen)在新范式下"根本不该存在",因为神经网络可以直接端到端把活干完。→ 详细
  3. vibe coding 抬高"人人能做软件"的下限,agentic engineering(智能体工程)则要在提速的同时守住专业软件的"质量底线";而当智能变得廉价,唯一无法外包的是"理解(understanding)"——你可以外包思考,但没法外包理解。→ 详细

Sequoia「AI Ascent」炉边对话现场:Andrej Karpathy(左)与主持人对谈

01

12 月的转折点:从"偶尔有用"到"想不起上次纠正它是什么时候"

Karpathy 复盘 12 月那次

转折前是"还算有帮助"而非"惊艳"。过去一年 Karpathy 一直在用 agentic 工具(参照物是"类似 Alpha Code 那一类"——能自主写代码的 AI),原话:"它在生成一段段代码(chunks of code)这件事上已经做得很好了。有时候会出错,你得自己去改,但总体还是挺有帮助的。"——一个"能用但要盯着"的阶段。→ 详细

2025 年 12 月是"明确的转折点(clear point)",触发条件很具体:他在休假、时间更多。体感是层层递进的——"用最新这些模型,生成出来的那一段段代码就是没问题。然后我接着让它生成更多,结果还是没问题。然后我想不起来上一次去纠正它是什么时候了。再然后,我就越来越信任这套系统。然后我就开始 vibe coding 了。"注意这条因果链:质量稳→敢加需求→不用改→信任度上升→彻底放手。他特意在 Twitter/X 上反复强调"你得重新看一眼":"很多人去年体验的 AI 更多像 ChatGPT 那类,但你真的需要再重新看一眼,而且得从十二月这个时间点去看,因为情况已经发生了根本性的变化(changed fundamentally),尤其在这种 agentic 的、连贯的工作流(agentic coherent workflow)上,它真的开始能跑通了。"结果是一头扎进"无穷无尽的副项目(infinity side project)"兔子洞——"我的副项目文件夹现在塞得满满的,里面全是各种乱七八糟的东西,我就是一直在写代码。"→ 详细

02

软件 1.0 / 2.0 / 3.0:编程范式的三次跃迁

把

编程范式三跃迁:1.0 人写显式代码(每条规则一行行写清);2.0 用数据"训"出权重——"我其实通过创建数据集、训练神经网络来'编程',编程某种程度上变成在组织安排数据集,可能再加上一些优化目标(objectives)和神经网络架构";3.0 LLM 本身变成一台"可编程的计算机"——"如果你在足够庞大的一组任务上训练这些 LLM,本质上是隐式地(implicitly)训练,因为你在整个互联网上训练、不得不同时处理(multitask)所有那些任务,这些模型某种意义上就变成了一种可编程的计算机。"于是"你的编程现在变成了写 prompt,而 context window 里的内容就是你操纵那个'解释器'(interpreter)的杠杆,这个解释器就是 LLM"。把 LLM 类比成 CPU/解释器、prompt 类比成程序,是理解整场对话的总钥匙。→ 详细

03

软件 3.0 的两个震撼案例:Open Claw 安装 与 MenuGen

Open Claw 安装:按 1.0 直觉装软件该是 bash/shell 脚本,但"为适配很多平台、很多电脑,这些脚本通常越来越臃肿、极其复杂";3.0 的方式是"把一大段文本复制粘贴给你的 agent……它就会帮你装好"——"你不必精确写清每个细节,agent 有它自己的智能,去看你的环境、执行一系列智能操作让事情跑起来,并在循环中自己调试问题(debugs in the loop)"。他一句点破新范式:"要复制粘贴给你 agent 的那段文本是什么?这才是现在的编程范式。"MenuGen(更极端):痛点是"去餐厅菜单没图片,大概 30% 甚至 50% 的菜我不知道是什么";旧范式(他真写的 app)= 上传照片→跑 Vercel→OCR 出菜名→图像生成器配图→重渲染整份菜单;3.0 版本 = "拍下照片交给 Gemini,说'用 Nano Banana 把这些叠加到菜单上',它就返回一张图、把不同菜品真的渲染进了像素里(into the pixels)"。结论很重:"我整个 MenuGen 都是多余的(spurious),那个 app 根本就不该存在。"3.0 的形态"要原始得多(a lot more raw)——神经网络承担越来越多工作,你的 prompt/context 就是那张图片,输出也是图片,中间根本不需要 app"。更普遍的洞见:这不是"编程变快",是"信息处理(general information processing)整体可自动化"——以 LLM 知识库 项目为例,"让 LLM 为你的组织或个人创建 wiki,这甚至不是一个程序,是以前根本不可能存在的东西",可以"拿这些文档用另一种方式重新'编译'(recompile)、重排,创造全新的东西"。他强调真正兴奋的不是"现有东西变快"而是"以前根本不可能的全新事物","我甚至觉得那些更让人兴奋"。主持人追问引出下一段:2026 年的"相当物"会是什么(像九十年代做网站、2010 年代做 app、上一个云时代做 SaaS)——"有什么东西事后看会显得理所当然、但今天基本还没人去做(mostly unbuilt today)?"→ 详细

04

外推的终点:神经网络成为"宿主进程"

把 MenuGen 推到底是"完全由神经构成的计算机"——"喂原始视频/音频进一个基本上是神经网络的东西,用 diffusion(扩散模型)渲染出一个 UI,这个 UI 为那个特定时刻而独一无二定制(unique for that moment)",界面不再写死、由模型实时"画"出来。历史类比:"计算早期人们对'计算机会像计算器还是像神经网络'有些困惑,五十、六十年代走哪条路并不明显,最后走上了计算器那条路、构建出经典计算(classical computing),神经网络现在是虚拟化地跑在现有计算机之上的。"他预测这会"反转"——"神经网络变成'宿主进程'(host process),CPU 变成某种'协处理器'(co-processor)",依据是台上那张图"智能计算正向神经网络转移,将成为占主导地位的算力支出(dominant spend of flops)"。终局:"神经网络承担大部分繁重工作,把工具调用(tool use)当作历史遗留的附属物(historical appendage),只用来处理某些确定性任务。"他诚实补一句:这是"极其陌生(extremely foreign)"的终点,"我们大概会一点一点走到那里",但"那个演进过程还有待观察(TBD)"。→ 详细

05

可验证性:决定什么会被快速自动化

  • 一句话总纲:"传统的计算机可以轻松自动化那些你能用代码来明确指定(specify in code)的东西。而最近这一轮的 LLM,某种意义上可以轻松自动化那些你能去验证(verify)的东西。"——上一代自动化的门槛是"你能不能把规则写死",这一代是"你能不能判断答案对不对"。→ 详细
  • 机制:前沿实验室训 LLM 时"这些是巨大的强化学习环境(giant reinforcement learning environments),所以模型会得到一个验证型的奖励(verification rewards)"。RL(强化学习)通俗讲=让模型反复试、做对给奖励做错不给,而"做对没做对"必须能被自动判定,所以"可验证"是前提。→ 详细
  • 后果:模型成了"参差不齐的实体(jagged entities)"——"在可验证的领域(数学、代码及相邻领域)能力达到峰值,在不属于那个空间的领域能力停滞不前,边缘地带显得比较粗糙、毛糙(rougher on the edges)"。jagged(像锯齿)是全场关键意象:不是整体均匀地强或弱,而是有的尖峰冲天、有的塌陷见底。→ 详细
  • jaggedness 的成因是双重的:既看训练方式,也看"实验室在意什么 + 恰好喂了什么数据"——"有些东西在经济上价值明显更高,最后就被构建出更多训练环境……代码就是一个很好的例子";反面是"可能还有大量可验证的环境他们能想到、但恰好没纳入,因为让模型具备那些能力其实没那么有用(not that useful)"。→ 详细
  • 最有说服力的实证·国际象棋:"从 GPT-3.5 到 GPT-4 下棋能力提升很多,很多人以为是整体进步的一部分,但实际上——这是公开信息,我在网上看到的——大量国际象棋数据进入了预训练集(pre-training set)。仅仅因为它在数据分布里,提升幅度就比默认大得多。所以 OpenAI 有个人决定加入这部分数据,于是你就得到一项能力、它的峰值被显著抬高了。"——一项能力的强弱可能只取决于"有没有人把对应数据塞进训练集"这一偶然决定。结论:"我们某种程度上是受实验室所做之事的摆布的(at the mercy of whatever the labs are doing)。"→ 详细
  • "电路(circuits)"的比方:"它没有说明书(no manual),在某些场景能用、另一些不行……如果你正好处在那些参与了 RL 训练的'电路'里,你就如鱼得水(you fly);处在数据分布之外的电路里,你就会很吃力。你得搞清楚在你的应用里自己到底处在哪些电路上,如果不在,那你就真得考虑做微调(fine-tuning)、做一些自己的工作了,因为它不一定能开箱即用。"→ 详细
06

参差不齐的荒诞案例:能重构十万行代码,却让你走路去洗车场

  • 旧例子·strawberry 数字母:"大家最爱举的例子是 strawberry 这个词里有几个字母,模型曾经在这个问题上出尽洋相、答错"——他补一句"模型现在已经把这个补上了(patch this)",即这个具体洞已被修补。→ 详细
  • 新例子·洗车场距离:"我想去洗车店洗车、它在 50 米外,我应该开车还是走路?今天最先进的模型会告诉你走路去,因为太近了。"——这里他是把它当"答得对、但下一句反差荒诞"的引子。→ 详细
  • 荒诞对比(金句级):"怎么可能最先进的 Opus 4.7 一边能重构一个十万行(100,000 line)的代码库、或者找出 zero-day 漏洞(尚未被发现/修补的安全漏洞),结果却告诉我走路去这家洗车店?这太离谱了(This is insane)。"——同一个模型,一头是顶尖工程师级能力、另一头是常识级的"过度热心",这就是 jagged 最直观的画面。→ 详细
  • 给使用者的两条警示:"无论模型多大程度上仍参差不齐,这都是一个信号:第一,也许有什么地方稍微不太对劲(something slightly off);或者第二,你确实需要稍微留在循环里(be in the loop),把它们当作工具来对待,跟它们正在做的事保持联系。"→ 详细
07

给创业者的建议:押注可验证领域

主持人(Sequoia 合伙人)抛出

  • 主持人的担忧:你想解决一个"可解的、属于可验证范畴"的问题,但"那些实验室已经真的、真的开始进入逃逸速度(escape velocity)了,它们最显而易见的方向就是数学、编程之类"——实验室会不会把这些领域吃干抹净、创业者无路可走?→ 详细
  • Karpathy 的反驳:"可验证性在当前范式下让一件事变得可解(tractable),因为你可以朝它砸进海量的 RL。换个角度看,即便实验室没有直接关注它,这一点依然成立。所以如果你处在一个可验证的场景里、能创建出这些 RL 环境或样例,那其实就为你自己做微调打下了基础。"→ 详细
  • 关键判断:微调是"就是管用、能拉杠杆"的成熟技术——"这从根本上是一种'就是管用'的技术(technology that just works)。你可以拉动一个杠杆(pull a lever):如果你有海量、多样化的 RL 环境数据集,就可以用你最喜欢的微调框架拉动那个杠杆,得到一个其实效果相当不错的东西。"通俗讲:只要你能在自己的细分领域造出"会判分的练习题",就能把通用模型调成你这行的专家,技术上不是难题。他卖了个关子:"有一个领域我觉得非常——抱歉,我不想直接把答案说出来,但这方面确实有一些例子",暗示存在某个"高价值但还没被主流训练覆盖"的可验证领域、当众留白。→ 详细
  • 反过来:什么仍只是"远看可自动化"?结论是"一切"——"几乎所有东西都可以被做成可验证的,只是有些比另一些容易。即便是写作,你也可以想象搞一个'LLM 评审委员会'(council of LLM judges),大概也能得到还算合理的结果。"被追问到底,他一字收尾:"一切(Everything)。"主持人接梗"一切都是可自动化的。太精彩了。"→ 详细
08

vibe coding vs agentic engineering:抬高下限 vs 守住底线

  • vibe coding 抬高"下限":"vibe coding 是关于为每个人抬高'下限'——抬高他们在软件上能做到的事情。下限抬升了,每个人都能 vibe code 出任何东西,这很了不起、很不可思议(amazing, incredible)。"——不会写代码的人现在也能做出能跑的软件,这是地板被抬高了。→ 详细
  • agentic engineering 守住"质量底线":"agentic engineering 是关于守住'质量标准'——守住此前专业软件所具备的那个质量底线。你不能因为 vibe coding 就引入漏洞(vulnerabilities),你仍要像以前一样对你的软件负责,但你能不能做得更快?剧透:你能,但你要怎么正确地做到?"他解释为什么叫它"工程学科"——"你有这些 agent,它们是参差不齐、带尖刺的实体(spiky entities),有点容易犯错、有点随机,但极其强大。问题就是:你要怎么协调它们,让你跑得更快,同时不牺牲你的质量标准?"一句话抓住内核:在不降质的前提下协调一群"强大但易错且随机"的 agent 提速→ 详细
  • 能力上限极高,"10x"被严重低估:"人们以前常说'10 倍工程师'(10x engineer),我觉得现在这个倍数被放大了很多。10 倍并不是你能获得的加速幅度。在我现在看来,那些非常擅长这件事的人,达到的峰值要远远超过 10 倍。"→ 详细
  • 一个引子·Sam Altman 的代际类比:主持人转述去年 Altman 在同场说的——"如果你三十多岁,你会把它当成 Google 搜索的替代品;但如果你是青少年,ChatGPT 就是你通往互联网的入口。"借此问:今天编程里,"用得平庸"和"完全 AI 原生(fully AI native)"的两个人差别在哪?→ 详细
  • Karpathy 的回答其实很朴素:"无非就是努力把手头可用的工具用到极致,把它们的所有功能都利用起来,并且在自己的那套环境配置(setup)上投入精力。就跟以前一样,所有工程师都习惯于把自己用的工具用到极致,不管它是 Vim 还是 VS Code,还是现在的 Claude Code、Codex 之类。"——"AI 原生"不神秘,就是肯花功夫吃透工具、打磨工作流。→ 详细
09

招聘必须重构:不要出谜题,要给大项目

  • 诊断现状:"大多数人其实还没有为'agentic engineer 能力'重构他们的招聘流程。比如你还在出谜题让人解(giving out puzzles to solve),那这还是旧范式。"→ 详细
  • 新招聘范式很具体:"招聘得变成这样:给我一个非常大的项目,看一个人怎么去实现它。比如我们来写一个'给 agent 用的 Twitter 克隆'(a Twitter clone for agents),把它做得非常好、非常安全,再让一些 agent 在上面模拟一些活动。然后我会用 10 个 Codex 5.4 x high 去尝试攻破你部署的这个网站,它们会试图把它攻破,而它们应该攻不破(should not be able to break it)。"——一举两得:既看候选人能不能驾驭 agent 把大项目做出来,又用"10 个高配 agent 来攻击"当作自动化的安全验收。"看人在那种场景下、构建一些更大的项目、并把工具用起来,这大概就是我大部分情况下会去看的东西。"→ 详细
10

人类剩下的价值:品味、判断、监督

  • 现在的答案:人仍要负责审美、判断、品味、监督——"agent 是那种'目录式'的内部实体……很了不起的是,你基本上仍然得负责审美(aesthetics)、判断(judgment)、品味(taste),再加上一点监督(oversight)。"→ 详细
  • 最能体现 agent 古怪的例子·MenuGen 的资金关联 bug(完整版):"你用 Google 账号注册,但用 Stripe 账号购买额度,这两个账号都有邮箱。我的 agent 实际上会——当你购买额度时,用 Stripe 那边的邮箱去把这笔额度关联到 Google 邮箱上。也就是说并没有一个持久的用户 ID(persistent user ID)来标识用户。它试图用邮箱地址做匹配,但你的 Stripe 和 Google 完全可以用不同邮箱,于是它基本没法把这笔钱关联上。"他的吐槽:"你为什么要用邮箱地址去交叉关联资金呢?邮箱可以是任意的(arbitrary)……这种做法太奇怪了。"——这正是"人必须把关设计"的活教材:agent 能写出能跑的代码,却会在"该用唯一用户 ID 绑账"这种架构常识上犯致命错误。→ 详细
  • 人必须掌控 spec/计划,他甚至不太喜欢 plan mode:"人必须负责掌控这个 spec、这个计划——其实我甚至不太喜欢 plan mode(计划模式)。它显然很有用,但我觉得这里有一个更普遍的东西:你必须和你的 agent 一起协作,去设计一份非常详细的 spec,也许它基本上就是文档(basically the docs),然后让 agent 去把它实现出来。你负责监督和那些顶层的分类(top-level categories),而 agent 在底层做大量的活。"→ 详细
  • API 细节交给"实习生",但底层原理仍要懂:以张量(tensor)操作为例——"PyTorch、NumPy、pandas 之间有海量细节……我已经忘了是 keep dims 还是 keep dim、是 dim 还是 axis、是 reshape 还是 permute 还是 transpose,因为你不需要记了。这种细节交给'实习生'(intern,指 agent)去处理,因为它们记忆力非常好(very good recall)。"但他划了条不能越过的线:"你仍然需要知道底层有一个张量、有一个底层的视图(view),你可以创建同一块存储(storage)的不同视图、也可以让它们用不同存储——那样会效率更低。我们仍需理解这些在做什么、理解基本原理,这样你才不会不必要地把内存搬来搬去。"一句话收束人机分工:"你负责的是品味、工程、设计——确保它说得通,确保你提出的是正确的要求(asking for the right things),确保你说清楚'好,这些必须是唯一的用户 ID,我们要把所有东西都绑在它上面'。你做的是一部分设计和开发,而工程师们(agent)做的是'填空'(fill in the blanks)。"→ 详细
11

品味会变得不重要吗?瓶颈在 RL 没覆盖

主持人追问:品味和判断会不会随时间变得没那么重要,还是上限会一直抬高?Karpathy 的诊断——现在审美差,是因为它"不在 RL 里":"我是希望它会变好的。它现在之所以没变好,原因还是同一个:它不是 RL 的一部分。大概没有什么'审美'的代价或者奖励(no aesthetics cost or reward),或者说还不够好。"(接第五节:"可验证性"——审美难以被自动判分,所以训练里没法给奖励、这块就弱。)他看 agent 代码"心脏病发作":"有时候我会有点心脏病发作的感觉(a little bit of a heart attack),因为它并不总是超级惊艳的代码,非常臃肿(very bloated)、有大量复制粘贴、还有一些笨拙脆弱的抽象(awkward abstractions that are brittle),能用,但真的很难看(really gross)。" micro GPT 项目·"像拔牙":那个项目里他想把 LLM 训练简化到尽可能简单,"模型很讨厌这件事(hate this),它们做不到。我一直试图 prompt 它再简化一点,它就是做不到。你会感觉自己处在 RL 的电路之外(outside of the RL circuits)……很明显你是在'拔牙'(pulling teeth)。"但他强调这不是天花板:"没有什么根本性的东西在阻止它变好。几乎就是实验室还没去做这件事而已。"→ 详细

12

动物 vs 幽灵:我们不是在造动物,是在召唤幽灵

框架来源:Karpathy 写过一篇"很发人深省"的文章,核心是"我们不是在构建动物(building animals),我们是在召唤幽灵(summoning ghosts)"——这些是参差不齐形态的智能,"由数据和奖励函数(reward functions)塑造,而不是由内在动机、乐趣、好奇心或掌控感(intrinsic motivation, fun, curiosity, empowerment)塑造,而后面这些某种程度上是通过进化产生的"。为什么这框架重要:"如果你对它们'是什么、不是什么'有一个好的模型,那你在使用它们时就会更有胜任力(more competent)。"他坦诚自己也不确定这框架"是不是真有什么实在的威力",承认"有点哲学思辨的味道"。实操含义:接受它们不是动物智能——"你冲它们吼,它们不会因此干得更好也不会更差,根本没有任何影响。它们其实就是一堆统计性的模拟电路(statistical simulation circuits),底层是预训练(也就是统计),然后在这之上又栓上了 RL(RL bolting on top)。"——一个生动的两层结构:地基是"统计"(预训练),上面"栓"着一层强化学习。这套框架的价值不在于给"五个明显办法",而在于"对它保持一种警惕(being suspicious of it),随着时间慢慢摸索出来"。→ 详细

13

agent native:一切都得为智能体重写

  • 总命题:当 agent 不只是聊天、而是"有真实的权限、有本地上下文(local contacts)、真的会代表你去采取行动"时,世界会变成什么样?Karpathy 答:"所有东西都得重写(everything has to be rewritten)。如今一切从根本上还是为人类写的,都得被重新折腾一遍。我大多数时候用的框架、库,文档从根本上还是写给人类看的。"→ 详细
  • 他"最受不了的一点(favorite pet peeve)":"为什么人们还在告诉我该怎么做?我什么都不想做(I don't want to do anything)。我该把哪段东西复制粘贴给我的智能体?"——把软件 3.0 的心态推到极致:用户的期待已从"教我怎么操作"变成"直接给我一段能丢给 agent 的东西"。具体痛点信号:"每次有人跟我说'去访问这个 URL'之类的,我都只想叹气:唉(ah)。"——任何还要求"人去点一下、跳一下"的流程,在 agent native 视角里都是摩擦。→ 详细
  • 正面思路:把工作负载拆成"传感器"和"执行器",先描述给 agent——"每个人都对这件事兴奋:我们该怎么把那些需要完成的工作负载,从根本上拆解成对世界的传感器(sensors over the world)、对世界的执行器(actuators over the world)。我们怎么让它变成 agent native?基本上就是先把它描述给智能体听。"他还说自己"搭了很多自动化,围绕那些对 LLM 来说非常易读的数据结构(data structures that are very legible to the LLMs)",并希望外面有大量"agent first(智能体优先)的基础设施"。→ 详细
14

agent native 的试金石:MenuGen 的部署之痛

  • 真实痛点:写代码不难,部署才是地狱——"当我写那篇关于 MenuGen 的博客时,大量的工作、大量的麻烦,甚至都不是给 MenuGen 写代码本身。麻烦的是把它部署到 Vercel 上,因为我得跟一堆不同的服务打交道、一个个串起来、进它们的设置页面、进那些菜单、配置我的 DNS(域名解析),整个过程实在太烦人了(so annoying)。"——真正吃时间的往往是这些"胶水活"和配置。→ 详细
  • 一个可操作的"agent native 试金石":"我希望对于 MenuGen,我能给一个 LLM 一句 prompt——'build MenuGen',然后我什么都不用碰(didn't have to touch anything),它就以同样的方式部署到互联网上了。我觉得这会是一个很好的测试,用来检验我们的基础设施是不是正变得越来越 agent native。"——即:一句话从零到上线、全程不用人插手,就是衡量基础设施成熟度的标尺。→ 详细
  • 终局:人和组织都有"agent 代表"——"我们正走向这样一个世界:人和组织都会有自己的智能体代表(agent representation)。我会让我的智能体去和你的智能体对接,去敲定我们会面的一些细节之类的事情。"主持人提的"传感器与执行器"视觉类比让 Karpathy 真心赞了一句——"我真的很喜欢这个形象的类比,之前其实还真没想到过这个比喻(hadn't thought of that),太有意思了。"→ 详细
15

教育的收尾:可以外包思考,但没法外包理解

收尾谈

  • 引子:主持人说 Karpathy"大概是这世界上最擅长把复杂技术概念讲简单的人之一",问他——当智能变廉价、进入 AI 下一个时代,"还有什么东西仍然值得我们去深入学习(worth learning deeply)?"→ 详细
  • 那条让他"大为震撼、几乎每隔一天就想起一次"的推文:"你可以把你的思考外包出去,但你没法把你的理解外包出去(you can outsource your thinking, but you can't outsource your understanding)。我觉得这话说得真好。"——全场的"题眼"金句,也是 TL;DR 第 3 句的出处。→ 详细
  • 他坦承自己正成为"瓶颈":"因为我仍然是这个系统的一部分,信息仍然得以某种方式进到我的大脑里。我感觉自己正在变成一个瓶颈(becoming a bottleneck)——光是搞清楚我们到底想构建什么、为什么这事值得做、我该怎么去引导我的智能体,我就成了瓶颈。归根结底总得有什么东西来引导这个思考和处理的过程,而这个东西从根本上某种程度上还是受限于'理解'。"→ 详细
  • 对知识库兴奋的根因·"导演"比喻:"每当我看到信息被投射出一个不同的视角(a different projection onto information)时,我总会觉得自己获得了某种洞见。对我来说,这其实就是用大量 prompt 针对固定数据做合成数据生成(synthetic data generation)。每当我读一篇文章,我都会用上我自己那个 wiki——它就是从这些文章里一点点搭建起来的。"他把人定位成"导演(director)":"如果你做不到理解,你就没法去引导,你就当不好一个'导演'——毕竟 LLM 在'理解'这件事上肯定不擅长(certainly don't excel at understanding)。所以你仍然是这件事上独一无二的负责人(uniquely in charge)。"→ 详细

本场为单一主题的炉边对话,无独立 lightning round(闪电问答),收尾停在教育话题(见第十五节)。Karpathy 的收尾金句(带着自嘲与好奇):"我很期待过几年再回到这里,看看我们是不是已经被彻底自动化、踢出了这个环路(fully automated out of the loop),而它们真的连'理解'也一并搞定了。"——把全场两条暗线收在一起:一边是"自动化一切"的乐观外推,一边是"理解暂时无法外包"这道人类护城河;他想看的是这道护城河几年后还在不在。→ 详细

  • "我想不起来上一次去纠正它是什么时候了。"——12 月转折的体感临界点。→ 详细

  • "要复制粘贴给你 agent 的那段文本是什么?这才是现在的编程范式。"——软件 3.0 一句话定义。→ 详细

  • "我整个 MenuGen 都是多余的,那个 app 根本就不该存在。"——旧范式被端到端模型抹平。→ 详细

  • "传统计算机自动化你能用代码指定的,这一轮 LLM 自动化你能验证的。"——可验证性总纲。→ 详细

  • "怎么可能 Opus 4.7 一边能重构十万行代码、找 zero-day 漏洞,却告诉我走路去洗车场?这太离谱了。"——jagged intelligence 画面。→ 详细

  • "10 倍并不是你能获得的加速幅度。"——顶尖玩家远超 10x。→ 详细

  • "我们不是在构建动物,我们是在召唤幽灵。"——理解 AI 本性的框架。→ 详细

  • "你可以外包你的思考,但你没法外包你的理解。"——全场题眼。→ 详细

  • vibe coding(凭感觉编程,抬高下限)|agentic engineering(智能体工程,守住质量底线)|软件 1.0/2.0/3.0(人写代码 / 训神经网络 / LLM 当可编程计算机)|context window = 操纵解释器的杠杆

  • 可验证性总纲「传统计算机自动化你能用代码指定的,LLM 自动化你能验证的」|RL 环境 + verification rewardsjagged entities(参差不齐)/ circuits(电路,在 RL 电路里就 fly、否则吃力)/ 国际象棋数据进预训练集受实验室所做之事的摆布

  • Open Claw 安装(复制粘贴给 agent)/ MenuGen(Gemini + Nano Banana 渲进像素,整个 app 多余)/ LLM 知识库·wiki·recompile / 信息处理整体可自动化

  • 神经网络成宿主进程(host process)、CPU 成协处理器(co-processor)/ dominant spend of flops / 工具调用是历史附属物 / diffusion 实时渲 UI

  • 10x 被严重低估、峰值远超 10 倍招聘反转:别出谜题、给大项目 + 10 个 Codex 5.4 x high 攻破当验收 / Twitter clone for agents人负责审美·判断·品味·监督,agent"填空"/ MenuGen 用邮箱交叉关联资金的 bug / 持久用户 ID / 不喜欢 plan mode 但偏执守 spec / 张量·实习生记忆力

  • 审美不在 RL 里所以弱 / 看 agent 代码"心脏病发作"(臃肿·脆弱抽象)/ micro GPT"像拔牙"召唤幽灵 vs 构建动物 / 奖励函数 vs 内在动机 / 统计模拟电路 + RL bolting on top

  • agent native:一切都得重写 / 文档还是写给人 / 传感器·执行器 / legible to LLMs / 一句 prompt'build MenuGen'从零到上线全程不碰 = 试金石 / 人和组织都有 agent 代表外包思考但没法外包理解 / 人是导演(director)/ becoming a bottleneck

  • 人物:Andrej Karpathy(联合创办 OpenAI、让 Tesla autopilot 跑通、造 vibe coding 一词);主持人为 Sequoia 合伙人;提及 Sam Altman。个人项目:MenuGenLLM 知识库/wikimicro GPT

🎯 于你何益 为你定制 · 非通用结论

这期几乎是为你而录的。Karpathy 这一年踩的坑、立的规矩,正好是你两套多-Agent 工厂(Holdwell PRD 工厂、app_incubator)每天在打的仗,连他形容的"看代码像心脏病发作"都和你担心的"碰撞协议纪律会不会走空"是同一种焦虑。下面按项目拆,每条都给你"他怎么做的 + 你这周能动的一件事"。

Holdwell ERP · 多-Agent PRD 工厂

① 招聘的反转,就是你评审的反转:别出谜题,给大项目 + 自动攻破当验收

  • 怎么做的:Karpathy 说现在"大多数人还没为 agent 能力重构招聘——你还在出谜题让人解,那是旧范式"。他的新范式是"给一个非常大的项目,看人怎么实现"——比如做一个"给 agent 用的 Twitter 克隆",做到非常安全,然后"我会用 10 个 Codex 5.4 x high 去尝试攻破你部署的网站,它们应该攻不破(should not be able to break it)"。一举两得:既看驾驭能力,又把"安全验收"做成了一群高配 agent 的自动攻击。
  • 你可以怎么做:你一直担心碰撞协议纪律走空、agent 产出缺闭环证据——本质就是检查容易停在"出谜题"(让 agent 自检一句"我合规吗",软)。把它改成 Karpathy 的"攻破式验收":在碰撞那道关,不是问起草 agent"你自己觉得合格吗",而是让对方角色拿自己的职责当攻击清单(易用性影响漏了没、技术方案对没对着真实代码仓、字段缺不缺、跨线口径一不一致),挑不出洞才算过。这周先拿一个角色(比如 tech-lead 那条线)试一次:让它对一份已定稿的 PRD 反向找茬,看它能不能戳穿——这就是你要的"闭环证据"的第一个样本。

② "强大但易错且随机的一群 agent,如何协调而不降质"——这就是你工厂的学科定义

  • 怎么做的:他给 agentic engineering 下的定义是"守住此前专业软件的质量底线……你有这些参差不齐、带尖刺的实体(spiky entities),有点容易犯错、有点随机,但极其强大。问题就是:你怎么协调它们,让你跑得更快,同时不牺牲质量标准?"注意他把"易错+随机"当成 agent 的固有属性接受下来,不指望靠骂、靠 plan mode 消灭它,而是靠人掌控一份极详细的 spec来收口——"你必须和 agent 一起设计一份非常详细的 spec,也许它基本就是文档,然后让 agent 去实现。你负责监督和顶层分类,agent 在底层填空。"
  • 你可以怎么做:你的痛点"六条产品线强耦合、跨线对齐难",根子正是缺这份"基本就是文档的 spec"当锚。Karpathy 的解法对到你这里 = 给跨线共享的实体立一份不可绕过的 spec,而不是每份 PRD 各写各的。这周做一件最小的事:挑一个高频业务实体(比如订单 / SKU),把它的字段、唯一 ID、跨线口径写成一页"实体 spec",然后规定三驾马车从澄清环节起都必须引用它——先验证"有锚之后跨线是否更容易对齐",再谈铺开。

③ 他不喜欢 plan mode,但偏执地守 spec——这条和你"加流程"的直觉有张力

  • 怎么做的:他说"我甚至不太喜欢 plan mode……它显然有用,但更普遍的是:你必须和 agent 协作设计一份详细 spec"。换句话说,他不信任"让 agent 先出个计划给你点头"这种轻流程,他信任"人和 agent 一起把 spec 抠到能当文档用"的重前置。
  • 和你现在做法冲突:你在 Holdwell 的本能是不断往流程里加环节、加评审(六步碰撞协议本身就是一套不轻的流程)——越严越安心。但 Karpathy 的暗示是:关卡多不等于质量高,真正决定质量的是最前面那份 spec 够不够详细,后面再多的评审也只是在补救一份糊的 spec。这里有张力:你是该继续往流程里加东西,还是把同样的精力前移到"把澄清环节的 spec/实体抠死"?我不替你下结论,但值得你这周自检一次:你最近一次评审没拦住的问题,到底是评审不够,还是澄清一开始就没问清?

app_incubator · 7-Agent 造 App 链路

④ "把该做什么前移到 agent",他给了你一个具体试金石:一句 prompt 从零到上线、全程不碰

  • 怎么做的:他写 MenuGen 那篇博客时,发现"大量的麻烦根本不是写代码,而是部署到 Vercel——配一堆服务、进设置页、配 DNS,整个过程太烦人了"。于是他立了个标尺:"我希望能给 LLM 一句 'build MenuGen',然后我什么都不用碰(didn't have to touch anything),它就部署上线了。这会是检验基础设施是不是越来越 agent native 的好测试。"
  • 你可以怎么做:你 app_incubator 的痛点正是"激活/首屏、把该做什么前移到 agent"。Karpathy 这把尺子直接能用:给你的 7-Agent 链路定一个"一句话从 Figma 设计稿到可访问 demo、中途人不插手"的目标,然后去数——现在从设计稿到上线,人还必须手动点哪几步(连 MCP、填配置、跳 URL)?每一个"还要人点一下"的地方,就是你下一个要前移给 agent 的活。这周列一张"人工插手清单",按出现频率排序,最高频那个就是首屏体验之外你最该消灭的摩擦。

⑤ "为什么还在告诉我该怎么做?我该把哪段复制粘贴给 agent?"——这是你设计稿即契约的灵魂

  • 怎么做的:他最受不了的一点是"为什么人们还在告诉我该怎么做?我什么都不想做(I don't want to do anything)。我该把哪段东西复制粘贴给我的智能体?"配合他对 Open Claw 安装的赞叹——以前要写一个能应付所有平台的臃肿脚本,现在只要写一段说明文本,让 agent"看你的环境、自己执行、在循环里自己调试"。
  • 你可以怎么做:你已经把"设计稿即工程强制契约"立为铁律,这其实就是 Karpathy 说的"那段要复制粘贴给 agent 的文本"——只不过你的文本是 Figma 结构。下一步对到你这里 = 让这份契约更"agent 易读"。他提到自己"围绕对 LLM 非常易读的数据结构(legible to LLMs)搭自动化"。这周挑一个组件,检查你的设计稿交给造 App agent 时,是不是还夹着"需要人脑翻译"的隐含约定(间距靠肉眼、状态靠备注);把这些隐含项显式化成 agent 能直接读的结构,就是在把契约从"给人看"升级到"给 agent 看"。

本人精力 · 你怎么用工具(这是这期对你最直接的一击)

⑥ "AI 原生"不神秘,就是肯花功夫把工具用到极致 + 在自己的 setup 上投入

  • 怎么做的:被问"用得平庸 vs 完全 AI 原生差在哪",Karpathy 的回答朴素到反常:"无非就是努力把手头工具用到极致,把所有功能都利用起来,并且在自己那套环境配置(setup)上投入精力。就跟以前所有工程师把 Vim 或 VS Code 用到极致一样。"——没有秘技,差距全在"愿不愿意吃透工具、打磨工作流"。而他亲历的转折是 12 月那次"质量稳→敢加需求→想不起上次纠正它→彻底信任→一头扎进去",前提是他在休假、有整块时间去和工具磨合。
  • 你可以怎么做:你的元约束是"精力与聚焦最稀缺,单兵推多线"。这条对你既是机会也是警告:你手上 Claude Code / 各种 MCP 的功能你大概只用了一部分,而 Karpathy 说差距就出在这。但你没有他的"休假整块时间"——所以你的版本不是"全面吃透",而是选一个工具、给它一段不被打断的深度时间(你本来就信"每周留一天思考")。这周把那一天的一部分,专门用来把一个工具(比如你最常用的那条 agent 链)的所有功能翻一遍,找出你一直没用上的 2-3 个能力——这比同时浅尝五个新工具的杠杆大得多。

⑦ "可以外包思考,但没法外包理解"——你作为单兵的护城河,和你正在变成的瓶颈

  • 怎么做的:全场题眼。Karpathy 坦承自己正"变成一个瓶颈——光是搞清楚我们到底想构建什么、为什么值得做、我该怎么引导 agent,我就成了瓶颈"。他把人定位成"导演(director)":"如果你做不到理解,你就没法引导,就当不好导演——LLM 在'理解'上肯定不擅长。所以你仍然是这件事上独一无二的负责人。"他对知识库兴奋的根因也在此:每读一篇文章就喂进自己的 wiki、换个视角重新"编译"一遍,因为理解必须发生在他自己脑子里
  • 你可以怎么做:你同时扛 ERP 正职 + StockHelp + 这本第二大脑 + 小红书号,"我成了瓶颈"这句几乎是你的日常写照。对到你这里的不是"少做事",而是认清你不可外包的那部分到底是什么——是"该不该做这个判断""这个 PRD 的业务对不对""这只股票的生意值不值得持有"这类理解,而非具体执行。这周做一次切分:把你手头一件正在亲自做的事,明确标出"哪部分是理解(只能我来)/哪部分是思考与执行(可以丢给 agent)",然后只把后者交出去。你这本第二大脑本身就是 Karpathy 说的那个 wiki——它的真正价值不是存档,而是逼你把读到的东西"重新编译进自己的理解",这正是你作为单兵对抗"被自动化踢出环路"的护城河。

顺带一句 · StockHelp(投资视角,弱关联但有一点)

  • 怎么做的:Karpathy 反复强调模型是"参差不齐的实体(jagged)"——"能重构十万行代码、找 zero-day 漏洞,却告诉你走路去 50 米外的洗车场",原因是它"只在 RL 覆盖的可验证领域有尖峰,边缘地带粗糙",而且"我们受实验室所做之事的摆布"。
  • 你可以怎么做:这对你的价值投资是一面镜子而非操作建议——你在用 LLM 辅助看生意/估值时,要默认它在"有海量训练数据的常见公司/财务比率"上靠谱(在 RL 电路里),但在"冷门标的、非标商业模式、需要常识判断的定性结论"上可能一本正经地胡说(电路之外)。所以 StockHelp 的定性判断、能力圈、安全边际这些,恰恰是"没法外包的理解"——别让一个语气笃定的模型替你下"这是不是卓越生意"的结论。这和你 Phase 1"只看数据、不做信号"的克制是一致的:先让它干"算账"(可验证)的活,"判断生意"的活留给自己。

更深三角度

  • 该反着用:Karpathy 的语境是"资源足、能休假腾出整块时间扎进 vibe coding、单一项目可以反复磨"。你的语境完全相反——精力是元约束、多线并行、没有整块时间。所以他"一头扎进无穷副项目、文件夹塞满"的状态对你是反面教材:你要的不是"我也开 N 个副项目 vibe coding",而是反过来——用同样的工具,去砍掉你已有项目里需要你亲自做的部分,把腾出的精力守在"理解/判断"这唯一不可外包的环节上。他在做加法(无穷探索),你该做减法(聚焦守门)。

  • 和你现在做法冲突:你在 Holdwell 的本能是"加环节、加评审来保质量";Karpathy 的暗示是"质量由最前面那份 spec 决定,后面的关卡只是补救"。你越严的流程,可能越是在掩盖"spec 一开始没抠清"这个真问题。张力留给你自己掂量。

  • 对你的镜子:Karpathy 这个"参与造了现代 AI、又亲手写 MenuGen 还被部署坑到崩溃"的人,公开承认"我正在变成瓶颈"。这面镜子照出来的不是"你不够强",而是——当工具强到能外包思考,瓶颈一定会移到'理解'上,而那恰恰是只有你能站的位置。你不是在和 agent 比谁写得快,你是在抢那个"导演"的椅子;你最近的疲惫,可能不是因为做得太慢,而是因为你还在亲自做太多本可以丢给 agent 的"思考与执行",反而没腾出脑子做"理解与判断"。

One Human Company 新号(2026-07 回填)

① C 类候选:「vibe coding 抬下限 vs agentic engineering 守底线」——一人公司两头都得占,拿实测账验证

  • 怎么做的:Karpathy 给了一对干净的概念:vibe coding 是"为每个人抬高下限——人人都能做出能跑的软件";agentic engineering 是"守住专业软件的质量底线——你不能因为 vibe coding 就引入漏洞,你仍要对软件负责"。他还诚实描述了放任的代价:看 agent 代码"有点心脏病发作——非常臃肿、大量复制粘贴、笨拙脆弱的抽象,能用,但真的很难看"。
  • 你可以怎么做:这是给你第一个 App 量身定做的 C 类选题。候选标题:《Karpathy 说 vibe coding 只是抬下限,我翻了自己 App 的代码库:3 处"心脏病发作"现场和它们花掉的返工钱》——你在 drizzle tech 里验的是:哪些环节放任 vibe(探索/原型),哪些环节必须上工程纪律(支付/数据),两种模式各自的翻车实录和 token 账。可抄物:一张"哪段活能 vibe、哪段活必须守底线"的分诊清单。闸门自检:没有你的翻车现场和账单,这篇只是名词解释——所以必须带实测才发。

② B 支柱:给 AI 员工做绩效,别问它"你行吗",派红队去攻它

  • 怎么做的:Karpathy 说招聘必须重构——"你还在出谜题让人解,那是旧范式",新范式是给大项目,然后"用 10 个 Codex 5.4 x high 去尝试攻破你部署的网站,它们应该攻不破"。把验收从"自我报告"翻转成"对抗攻击"。
  • 你可以怎么做:你 B 支柱(AI 员工管理/绩效,最独占的 25%)的现成体裁:drizzle tech 9+1 角色的"绩效考核"怎么做?照搬人类 KPI 是笑话,Karpathy 给了正解——考核 = 另一个 agent 能不能攻破它的产出。候选标题:《我给 AI 员工发了第一份绩效:不是打分,是派了个"红队同事"专门挑它刺》——写你怎么设攻破式验收、抓到了几个人眼看不出的洞、误报了几个。可抄物:那个红队 agent 的 prompt。这篇的判断和翻车全是你自己的,天然过闸门。

③ 办号的地基:「可以外包思考,但没法外包理解」——这就是你弹药库闸门的理论版

  • 怎么做的:全场题眼,Karpathy 说这条推文让他"几乎每隔一天就想起一次"。他把人定位成"导演":"如果你做不到理解,你就没法引导,就当不好导演——你仍然是这件事上独一无二的负责人。"他自己也坦承"我正在变成瓶颈——光是搞清楚到底想构建什么,我就成了瓶颈"。
  • 你可以怎么做:这句话就是你弹药库闸门("删掉我自己的判断和实测,这篇还成立吗")的底层原理:AI 时代一切可搬运的信息都趋近免费,读者付费(收藏)的只剩"你理解了什么、你怎么判断"。它值得直接做一篇 D 类观点短评,立场句现成且可反驳:"内容行业里所有'外包得出去的思考'都会归零,账号的估值只剩'没法外包的理解'。"——这同时解释了你为什么独占"想清楚/决策"这个词、为什么不做资讯搬运。写的时候带上你自己的镜子(你哪篇存稿其实是"思考搬运"、被闸门毙了)就不空。

所以呢

  • 可迁移思维模型

    • 【耐用】"可以外包思考,但没法外包理解"——这是判断"什么该亲自做、什么该交出去"的总开关,几年内不会过期,对你单兵多线尤其救命。
    • 【耐用】"传感器 / 执行器 + 一句话从零到上线"作为 agent native 试金石——衡量任何流程"前移给 agent 程度"的通用尺子,Holdwell 和 app_incubator 都能直接套。
    • 【会过期】"模型在 X 领域参差不齐(如审美/极简化代码弱)"的具体清单——Karpathy 自己反复说"没有根本性的东西阻止它变好,只是实验室还没做",所以哪块强哪块弱是临时快照,几个月就变,别拿它当长期架构假设(比如别因为"现在审美弱"就永久把 UI 决策锁死在人手里)。
  • 判断更新:如果你之前认为"多-Agent 工厂的质量靠把流程关卡做厚",这期该给你松一颗螺丝——质量的上游在 spec / 实体口径,不在关卡数量;给跨线实体立一页共享 spec,可能比任何一道新评审都更值得这周投入。

  • 这周一个赌注挑 Holdwell 一个高频业务实体(订单或 SKU),把它写成一页跨线共享的"实体 spec",并让一个独立"红队 agent"拿三驾马车各自的职责清单去攻破一份已定稿的 PRD。 一个动作同时验证两件你最缺的东西——"有锚之后跨线是否更好对齐"和"碰撞能不能从提意见升级成攻破式验收、产出第一份闭环证据"。赌注小、可证伪、这周做得完。

接着读