Karpathy剖析Vibe Coding：未来编程思维的新方向

#能力#

这两年，很多人第一次发现：

原来我不会写代码，也能让 AI 做出一个网页。
原来我不会搭项目，也能让 Agent 帮我跑起来。
原来脑子里那个小工具、小页面、小自动化，不一定只能停在想法里。

这就是Vibe Coding，中文常被翻译成氛围编程。

它最大的意义，是把“开始做东西”的门槛打下来了。

但 Karpathy 最近在 Sequoia AI Ascent 2026 上说了一个更值得琢磨的新判断：

Vibe Coding 抬高了地板，Agentic Engineering 拉高了天花板。

Agentic Engineering，可以先翻成智能体工程，也可以理解成“怎么真正指挥 Agent 干活”。
这句话说白了就是：

会让 AI 帮你做出一个东西，只是第一步。
接下来更重要的问题是：
你能不能让 AI 做得稳、做得对、做得不乱、做得可交付？

这才是下一阶段的门槛。

先说 Karpathy 是谁

Andrej Karpathy 不是普通 AI 博主。

他是 OpenAI 早期创始成员，后来在 Tesla 担任人工智能总监，带过 Autopilot 的计算机视觉团队；他也很擅长把复杂技术讲清楚，很多人认识他，是因为他提出了 “Vibe Coding” 这个说法。

这次红杉资本合伙人 Stephanie Zhan 在 4 月 29 日发帖，说她和 Karpathy 在 2026 年红杉 AI 峰会上再次对谈：去年他提出了 Vibe Coding，今年他说自己作为程序员“从没这么落后过”；她总结这次最大的变化是：Vibe Coding raised the floor，Agentic Engineering raises the ceiling（氛围编程抬高了下限，智能体工程拉高了上限）。

这句话很值得展开。

因为它刚好解释了很多人最近的感受：

AI 确实能干活了。
但你越让它干活，越会发现另一个问题：
它能跑，不代表它一定靠谱。
它能生成，不代表它一定懂你的目标。
它能改文件，不代表它不会改错地方。

1. 氛围编程解决的是“能不能开始”

Vibe Coding，直译叫“氛围编程”，听起来有点轻飘。

它真正表达的是一种新用法：

你不再从语法、框架、目录结构开始。
你先把想法说出来，让 AI 根据你的描述做一个版本。

比如：

“帮我做一个待办清单网页。”
“帮我做一个文件夹整理工具。”
“帮我做一个能上传图片并生成说明的小页面。”
“帮我把这堆资料整理成一个本地知识库。”

以前这些事一听就像程序员的活。

现在你可以先让 AI 开工。

这就是“地板被抬高”的意思。

以前很多人连门口都到不了。
现在至少可以站到门里，看见一个东西被做出来。

Karpathy 在访谈里也提到，他明显感觉到从去年年底开始，模型输出的代码块越来越能直接用，他越来越少去手动纠正，于是开始更信任系统，进入了大量边缘开发的状态。他说得很清楚：他不再只是把 AI 当成 ChatGPT 附近的东西，而是看到了更连贯的 Agent 工作流开始真正运转。

这就是很多人最近上头的原因。

你不一定突然变强了。
是工具把第一步变短了。

2. 智能体工程解决的是“能不能做好”

但 Karpathy 这次想强调的，已经不是“AI 能不能写代码”。

他讲的是Agentic Engineering，中文可以叫智能体工程。

这个词看起来硬，意思其实很简单：

你怎么安排一群会干活、但有时会乱来的 AI，把事情做快，还不把质量做塌。

这和氛围编程不一样。

氛围编程更像：

“我有个想法，你先帮我做出来。”

智能体工程更像：

“我们先定目标、边界、验收标准，再让 Agent 分步骤执行，最后检查结果。”

Karpathy 在访谈里说，Vibe Coding 是抬高下限，让更多人能做软件；Agentic Engineering 要保存专业软件原本的质量线，不能因为用了 AI 就引入漏洞，也不能把责任甩给 AI。你给的识别稿里也提到，他把 Agent 形容成强大但有波动的东西，重点是怎么协调它们，在不牺牲质量的情况下更快完成任务。

这句话特别重要。

很多人用 AI 做东西，最容易掉进一个坑：

只看它有没有做出来。

但真正有价值的问题应该是：

能不能打开？
会不会误删文件？
有没有安全漏洞？
数据有没有绑错？
账号有没有串？
以后还能不能维护？
换个环境还能不能跑？

AI 能让你更快看到结果。
智能体工程决定这个结果能不能拿得出手。

3. 软件 3.0：未来的教程，可能是一段给 Agent 的话

Karpathy 还讲了一个很值得写进收藏夹的概念：

Software 3.0，软件 3.0。

他把过去的软件分成几个阶段：

Software 1.0，是人写明确规则，也就是传统代码。
Software 2.0，是用数据训练神经网络。
Software 3.0，是把 LLM 当成一种新的“计算机”，你通过上下文、提示词、文件、图片、任务说明来“编程”。这段在你给的识别稿里有完整表述：上下文窗口成了你控制 LLM 的杠杆，LLM 解释上下文并在数字信息空间里执行计算。

听起来抽象，换个例子就懂了。

以前你安装一个工具，教程通常会给你一堆命令：

第一步运行这个。
第二步改那个配置。
第三步如果报错，自己排查。

这种教程像说明书。

但在软件 3.0 里，教程可能变成一段给 Agent 的任务说明：

请帮我安装这个工具。先检查我的系统环境。不要删除已有文件。遇到报错先解释原因，再给两个修复方案。安装完成后，运行一次最小测试。最后告诉我成功标志是什么。

Karpathy 举了 OpenClaw 的例子：传统安装脚本要兼容很多系统，会越来越复杂；但如果安装说明是一段给 Agent 的文字，Agent 可以看你的电脑环境，自己执行、自己调试、自己绕开差异。你给的识别稿里，他直接说“你复制给 Agent 的那段文字，就是现在的编程范式”。

这句话非常关键。

以后好的教程，不一定是“复制这 10 行命令”。

好的教程会越来越像：

一段写给 Agent 的任务单。

任务单里要写清楚：

目标是什么；
哪些地方不能动；
遇到错误怎么处理；
成功以后怎么验证；
最后要交付什么结果。

这也是我们最近写 Hermes、OpenClaw、Claude Code、Skill 时越来越常用的思路。

不是让读者手动解决所有问题。
而是给 Agent 一个足够清楚的任务框架。

4. AI 的强，是锯齿状的强

Karpathy 这次还讲了一个很有意思的词：

Jagged Intelligence，锯齿状智能。

意思是：AI 的能力不是平滑上升的。

它有些地方强得离谱。
有些地方又笨得离谱。

他举了一个例子：

模型可以重构巨大的代码库，可以找安全漏洞，但你问它：“洗车店离我 50 米，我该开车还是走路？”它可能回答你走路，因为 50 米很近。问题是，你是要洗车，车当然也要过去。你给的识别稿里，这个例子非常典型。

这就解释了一个很多人用 AI 时的奇怪体验：

它能帮你做很复杂的东西。
却可能在一个很常识的问题上犯傻。

所以用 Agent 时，别只看它回答得顺不顺。
越像真的，越要留一个验收动作。

比如做网页：

页面能不能打开？
按钮能不能点？
手机上会不会变形？
刷新后数据还在不在？

比如做文件整理：

有没有误删？
有没有覆盖原文件？
有没有保留备份？
能不能生成清单？

比如做自动化：

有没有先小范围测试？
有没有日志？
失败以后能不能回滚？
有没有把账号、金额、用户 ID 这些关键字段处理对？

Karpathy 在访谈里提到过一个很具体的坑：他的 Menu Gen 项目里，Agent 曾经试图用 Stripe 邮箱和 Google 邮箱去关联用户购买的积分，但一个人完全可能用两个不同邮箱，于是资金就可能对不上。这个例子说明，Agent 会写代码，但它未必天然理解产品里的关键约束。

这就是人还要在场的原因。

不是为了和 AI 抢活。
是为了给结果兜底。

5. 真正该练的能力，是“给 Agent 派活”

如果这篇只讲概念，就没太大收藏价值。

所以我更建议把 Karpathy 的观点落到一个很实用的问题上：

以后会不会用 AI，不只看你会不会提问，还要看你会不会派活。

派活和提问不一样。

提问是：

“帮我做一个网页。”

派活是：

目标：帮我做一个本地待办清单网页。限制：只用一个 index.html 文件。不要接数据库。不要联网。不要删除当前文件夹里的其他文件。验收：页面可以打开。可以新增任务。可以勾选完成。可以删除任务。刷新页面后任务还在。执行方式：先给我计划。我确认后再改文件。完成后告诉我改了哪些地方，以及我怎么验证。

你看，这就不只是“会说需求”了。

这里面包含了 4 件事：

目标：我要什么结果。
边界：你不能乱动什么。
验收：做到什么程度算成功。
返工：失败了怎么继续处理。

这就是智能体工程最小版。

不用把词讲得很玄。

它落到日常使用里，就是你每次让 Agent 干活前，先把这四件事说清楚。

6. 未来的差距，不是会不会打开 AI

这次访谈里还有一个判断很扎心。

主持人问，如果看两个人使用 OpenClaw、Claude Code、Codex 这些工具，一个用得一般，一个很用的很地道，差别在哪里？

Karpathy 的回答大意是：会不会充分利用工具、会不会投资自己的配置、会不会把工具链用到位。他说这有点像过去工程师会打磨 Vim、VS Code，现在则是打磨 Claude Code、Codex 这类 Agent 工具。

这句话很现实。

未来的差距可能不再是：

你有没有 AI。

而是：

你有没有自己的任务模板；
有没有自己的项目规则；
有没有常用 Skill；
有没有验收清单；
有没有让 Agent 读懂你偏好的文件；
有没有把成功经验沉淀下来。

比如你经常让 AI 做小工具，就应该有一份固定规则：

做任何小工具前，先确认：1. 工具解决什么问题2. 输入是什么3. 输出是什么4. 是否需要保存数据5. 是否需要联网6. 是否要支持手机7. 完成后如何测试

比如你经常让 AI 改网页，就应该有一份验收清单：

改完页面后，请检查：1. 桌面端是否正常2. 手机端是否正常3. 按钮是否能点击4. 表单是否有提示5. 是否有明显溢出或遮挡6. 是否改动了无关文件

比如你经常让 AI 整理资料，就应该有一份输出规范：

整理资料时，请输出：1. 一句话结论2. 关键事实3. 可执行建议4. 不确定点5. 后续需要我确认的问题

这些东西一开始看起来很小。

用久了以后，它们会变成你的个人工作流。

AI native 可能是你开始有自己的 AI 工作台开始。

7. “理解”不能外包

访谈最后，Karpathy 提到一句很值得记的话：

You can outsource your thinking, but you can't outsource your understanding.

可以翻成：

你可以外包一部分思考，但不能外包你的理解。

他解释说，人仍然是系统的一部分。你要知道自己到底想建什么，为什么值得做，怎么指挥 Agent；如果理解没有进入你的脑子，你就没法当好导演。他提出知识库、Wiki、不同的信息投射方式，本质上都是帮助自己增强理解。

很多人现在用 AI，会有一种错觉：

既然 AI 会写、会改、会查、会总结，那我是不是只要等结果就行？

短期可以。

长期不行。

因为你如果不理解目标，AI 做偏了你也看不出来。
你如果不理解边界，AI 改错文件你也不知道。
你如果不理解好坏，AI 给你一个能跑但很烂的东西，你会误以为完成了。
你如果不理解用户，AI 会把一个技术上正确、体验上很怪的东西交给你。

所以，越是 Agent 变强，越要保留自己的判断。

AI 可以替你跑腿。
AI 可以替你试错。
AI 可以替你生成第一版。
AI 可以替你整理大量信息。

但你得知道：

我要解决什么问题。 哪些地方不能错。 做到什么程度可以交付。 哪里看起来不舒服。 哪里需要重新来过。 这就是 Karpathy 这次访谈最值得带走的地方。

最后给一套可以直接收藏的模板。

以后你让 Hermes、OpenClaw、Claude Code、Codex、Cursor 这类 Agent 做事，可以先用这个：

请你帮我完成这个任务：【目标】我要得到什么结果：【背景】你需要知道的信息：【限制】这些事情不要做：- 不要删除文件- 不要改动无关文件- 不要擅自安装大型依赖- 不确定时先问我【执行方式】请先给计划，不要立刻动手。计划里写清楚：1. 你准备改哪些文件2. 每一步要做什么3. 可能的风险是什么【验收标准】完成后必须满足：1.2.3.【交付结果】完成后请告诉我：1. 你改了什么2. 我怎么验证3. 还有哪些风险4. 如果失败，下一步怎么排查

如果你想更短一点，就记这个四句版：

目标：我要你做什么，最后交付什么。边界：哪些文件不能动，哪些方式不要用。验收：做到什么样算成功，怎么检查。返工：如果失败，先定位原因，再给两个修正方案。

这四句话，就是你从氛围编程走向智能体工程的起点。

最后说一句

Vibe Coding 很爽。

它让很多想法第一次有机会出现在屏幕上。

但 Karpathy 这次真正提醒我们的，是下一个阶段已经来了：

会让 AI 动手，不稀奇。
会让 AI 稳稳地把事做完，才开始拉开差距。

以后真正值得练的，不一定是背多少代码语法。

更值得练的是：

怎么描述目标；
怎么设置边界；
怎么拆任务；
怎么验收结果；
怎么让 Agent 返工；
怎么把一次成功沉淀成下次可复用的流程。

这就是我对 “Agentic Engineering” 的理解。

氛围编程让你开始。
智能体工程让你走远。

如果你觉得有点用，烦请点赞关注收藏，谢谢！