Karpathy：10x 工程师已经不够看了

Pengfei Ni — Sat, 02 May 2026 10:00:00 +0800

Claude Code 和 Codex 出来这一年多，我几乎每天都在用。刚上手那阵非常兴奋，写代码确实快了不少。但用的时间越长，反而越经常冒出一种说不清的无力感。

模型变强的速度比预想中快得多。以前觉得花了几年才练出来的本事，让 Agent 跑一下，输出经常比自己手写还干净。重构一个陌生模块也好，读懂别人的老代码也好，定位一个偶发的 bug 也好，Agent 默认就能做对。

慢慢就有种感觉：自己能干的事 AI 都能干，那作为工程师我的价值到底还剩什么？

这两天看 Karpathy 在 Sequoia AI Ascent 2026 上的对谈，发现他也是同样的感觉：他从来没有像现在这样，觉得自己作为程序员落伍了。

去年 2 月他造了 Vibe Coding 这个词，意思是凭感觉写代码，不纠结细节，让 AI 替你搞定。这词火了一整年，几乎成了 AI 编程的代名词。结果发明这词的人，自己觉得落伍了。

一开始我以为他只是谦虚。看完半小时完整对谈，才发现他是认真的，而且把这种感觉拆得挺清楚。内容密度很高，我把最有价值的部分整理了分享给你。

为什么感觉落伍了

Karpathy 的落伍感不是凭空来的，转折发生在去年 12 月。

他用 Agent 写代码已经有一段时间了，之前体验时好时坏，模型输出经常要手动改。但到了 12 月，他发现代码直接拿来就能用，追加需求继续改，输出还是对的。到后来他都记不清上一次手动修正是什么时候了。

这不是慢慢变好，是一个突然的台阶。从“有时候能用”到“默认能用”，中间没有过渡。

这跟我开头说的感受其实是一回事。当 AI 默认就能搞定那些以前需要费劲做的事，无力感自然就来了。

所以 Karpathy 也提醒了一件事：如果你 12 月之后没有重新认真试一次，可能还在用一个已经过期的心智模型判断这些工具。

下限和上限是两回事

既然能力有了质变，这对不同的人意味着什么？Karpathy 在这里有个挺重要的区分：Vibe Coding 和 Agentic Engineering 不是一回事。

Vibe Coding 抬的是下限。非程序员也能用自然语言描述需求，跑起来一个东西。

但 Agentic Engineering 抬的是上限。它面向的是专业工程师，解决的问题是：怎么用 Agent 工具更快地交付，同时不牺牲安全性、可靠性和代码质量。

这是两条完全不同的路。Vibe Coding 让不会写代码的人做出能跑的原型；Agentic Engineering 让一个工程师在生产级质量的前提下，把效率拉到之前不敢想的水平。

之前大家说 10x 工程师，现在擅长 Agentic Engineering 的人远超 10x。个人产出的上限比以前高得太多。

这才是他觉得落伍的真正原因。不是 AI 太强，而是不同人用 AI 的能力差距正在急剧拉大。好工程师和普通工程师之间的杠杆倍数，比以前任何时候都大。

同一个模型，同时天才和白痴

不过，能力差距拉大的前提是，你得知道模型到底擅长什么。对谈里我觉得最有意思的就是这一段：LLM 的锯齿形智能。

Karpathy 举了个例子：最先进的 Opus 4.7 可以连贯地重构一个 10 万行的代码库，或者发现零日漏洞。但你问它“洗车店离我 50 米，我应该开车还是走路”，它会告诉你走路去，因为距离很近。

一个能发现零日漏洞的系统，怎么可能不知道你不能走路去洗车？

Karpathy 给了两个解释。

第一个是可验证性。LLM 的训练靠强化学习，强化学习需要验证信号。代码有编译器和测试，数学有证明，这些领域天然可验证，RL 在这上面效果拉满。但日常常识很难构造验证环境，落不到轨道上。

第二个更有意思，是经济学。前沿实验室选什么数据进训练集，取决于商业价值和 TAM。代码能力值钱，所以有人花大力气做了。Karpathy 还举了个例子：从 GPT-3.5 到 GPT-4，棋力大幅提升，很多人以为是通用能力进步，实际上是因为有人决定往预训练数据里加了大量棋谱。能力的提升不是均匀发生的，是跟着数据分布走的。

他打了个比方：如果你的应用恰好在 RL 训练覆盖的轨道上，你会觉得在飞；如果不在，你就是在丛林里拿砍刀开路。

这个判断对做产品的人特别有参考价值。开始一个 Agent 项目之前，先问自己：我的任务在不在模型训练的轨道上？在的话就能直接用；不在的话，要么准备 fine-tuning，要么换个思路。

你写的代码可能不该存在

说完模型能力的边界，Karpathy 抛出了一个更激进的观点：就算在模型擅长的轨道上，很多现有的软件其实也不应该存在。

他用自己做的 MenuGen 举例。这个应用拍一张餐厅菜单的照片，用 OCR 识别菜名，调用图像生成器给每道菜生成图片，然后重新渲染菜单。他用 Vibe Coding 写出来，部署在 Vercel 上，效果挺好。

然后他看到了另一种做法：直接把菜单照片发给 Gemini，让它用 Nanobanana 在原图上渲染菜品图片。输入一张图，输出一张图。没有 OCR，没有后端，没有数据库。

他说自己的整个 MenuGen 应用都是多余的。它还停在 Software 1.0 的范式里，而 Software 3.0 的做法是让大模型直接完成端到端的任务。

另一个例子是 OpenClaw 的安装方式。传统做法是写一个 Shell 脚本处理各种平台差异。OpenClaw 的做法是写一段自然语言的安装说明，让用户复制给自己的 Agent。Agent 读你的环境，适配你的系统，中间出问题自己调试。

这等于是用.md 替代了.sh。

第三个例子是 LLM 知识库。以前没有任何代码能把一堆非结构化的文章变成一个有组织的 Wiki。这不是做得快了，而是以前根本做不了。

Karpathy 说，每次范式转换，人们最先做的总是把新工具用来加速旧工作流。但真正有意思的不是加速，是那些以前根本不可能的新东西。

能外包思考，不能外包理解

前面说的都是工具和能力层面。Karpathy 在对谈快结束时，聊到了一个更根本的问题。

他引用了一条推文：你可以外包你的思考，但你不能外包你的理解。

他说这句话几乎每隔一天就会在他脑子里冒出来。

他现在觉得自己是系统里的瓶颈。Agent 可以执行、搜索、写代码、迭代，但“我们到底在做什么”“为什么值得做”“方向对不对”，这些问题 Agent 回答不了。

他甚至不太喜欢 Plan Mode 这个概念。在他看来更准确的说法是：人负责写 Spec，Agent 负责实现。Spec 是你的设计意图，是你对系统不变量的理解，是你对用户场景的判断。Agent 负责的是 API 细节、代码实现、格式规范这些可以查手册的事。

他举了自己的例子：PyTorch 和 NumPy 的 API 细节他已经记不住了，keep_dims 还是keepdim，dim 还是axis，reshape 还是permute。这些交给 Agent 就行。但底层 Tensor 的存储模型、View 和 Copy 的区别，这些你必须懂，不然你都不知道自己在让 Agent 做什么。

招聘还没跟上来

如果理解力和判断力才是核心竞争力，现在的招聘方式就有点尴尬了。Karpathy 也聊到了这个问题。

大部分公司面试还在考察八股文。但 Agentic Engineering 的核心能力不是能不能解一道算法题，而是能不能交付一个经得住考验的系统。

他给了一个挺有意思的面试思路：让候选人做一个真实项目，比如一个 Twitter 克隆，要求部署上线、功能完整、安全合格。然后用 10 个 Codex 实例去攻击这个系统，看它能不能扛住。

这种面试考的不是算法能力，而是你在有 Agent 工具辅助的情况下，能不能做出一个可靠的、上线后不会出事的产品。

回到开头那个问题

回到开头那个问题：自己能干的事 AI 都能干，那作为工程师我的价值还剩什么？

看完这个对谈，答案大概清楚了：工具可以外包，理解不能。你仍然是系统的掌控者，信息仍然要进入你的大脑，你仍然需要搞清楚正在发生什么才能给出正确的方向。

所以与其焦虑被 AI 替代，不如把这种无力感当作一个校准信号。工程师的能力上限在快速上移，之前的 10x 工程师，可能只是新标尺下的 2x。真正值得关注的不是 AI 能做什么，而是你能不能把理解力跟上这个新的杠杆倍数。

Agentic Engineering | Feisky