Vibe Coding之父说：该升级了

2025年初，Andrej Karpathy发了条推文，发明了"Vibe Coding"这个词。

他说：完全沉浸在感觉里，忘掉代码的存在，只告诉AI你想要什么……我甚至不读代码了，直接接受所有改动。

这条推文引爆了整个开发者社区。一年之后，92%的美国开发者每天使用AI编程工具。41%的全球代码由AI生成。Lovable凭Vibe Coding做到单月$1亿ARR。

然后Karpathy又开口了。这次他说：纯Vibe，不够了。

Karpathy说了什么

他的新观点不是否定Vibe Coding，而是说这个方法需要进化。

“感觉导向"适合快速原型、独立项目、探索想法。但当项目规模上去，当代码库开始有真实用户，当你需要保证质量而不只是能跑，Vibe就不够用了。

他提出的方向叫Agentic Engineering：

不是你写代码，不是AI写代码，而是你指挥AI完成一系列有明确目标的任务——你负责架构决策和质量验收，AI负责执行和实现。

区别很微妙，但影响很大。

Vibe Coding是：我有个想法，我跟AI聊，看它给我什么，我接受。

Agentic Engineering是：我知道要做什么，我把任务拆成AI能独立执行的单元，我验证每个单元的输出是否符合预期，再推进下一步。

为什么感觉不够了

Reddit这周的热帖，5755个赞，562条评论：“Why the majority of vibe coded projects fail”。

评论区里的开发者描述了同一种经历：

项目初期非常爽，几天就做出能演示的东西。然后某个时间点之后，AI开始帮你修bug同时引入新bug，代码库变成一团谁都不知道内部逻辑的黑盒，最后要加新功能，AI反而改坏了三个旧功能。

这不是工具问题，是方法论问题。

数据层面：最新研究显示，AI协作代码的安全漏洞数量是人类代码的2.74倍，严重问题多出约1.7倍，逻辑错误和控制流缺陷显著更高。当你的项目规模小、没有真实用户时，这些数字不重要。但规模一旦上去，这些隐患会集中爆发。

Vibe Coding的核心假设是：AI足够聪明，我不需要懂它在做什么。

这个假设在原型阶段成立。在生产代码里不成立。

Agentic Engineering的3个核心特征

1. 任务比对话更重要

Vibe Coding的工作单元是"对话”——你说一句，AI回一句，你接受，继续聊。

Agentic Engineering的工作单元是"任务"——明确的输入、明确的预期输出、明确的验收标准。

实际操作上，这意味着你在让AI干活之前，先想清楚：这个任务完成的标准是什么？我怎么知道它做对了？

不是写一段话描述你的感觉，而是写一个Spec：

1
2
3
4
5
6
7
8
9


任务：实现用户登录功能
输入：邮箱 + 密码
输出：JWT token，有效期24小时
验收标准：
- 正确密码返回200 + token
- 错误密码返回401，不暴露账户是否存在
- token包含userId和过期时间
- 密码用bcrypt hash存储
安全要求：防止暴力破解（单IP 5次/分钟限制）

有了这个，AI的输出就有了可以对照的标准。你不需要读每一行代码，但你需要验证结果是否符合Spec。

2. 你是架构师，AI是工程师

Vibe Coding里，你是产品经理，AI是全能的外包团队，你只管提需求。

Agentic Engineering里，你是架构师，AI是工程师团队。工程师很强，但方向和判断是你的。

这个角色切换意味着：你需要知道你在构建什么，即使不需要知道每行代码怎么写。数据库怎么设计？服务怎么拆分？哪些地方有安全边界？这些判断不能完全外包给AI。

不是说你要会写所有代码，而是你要能做技术判断，哪怕你的技术判断只来自于跟AI深度讨论之后的理解。

3. 验收是流程的一部分，不是可选项

Vibe Coding的流程：提需求 → 接受输出 → 继续。

Agentic Engineering的流程：定任务 → AI执行 → 你验收 → 通过才继续。

验收不是"运行一下看有没有报错"。验收是对照Spec检查：

功能是否符合预期？
边界情况有没有处理？
有没有引入新问题？

Claude Code的Code Review功能这周刚上线，正好对应这个需求——在推进下一步之前，让AI帮你系统性地检查刚完成的任务是否有问题。

Agentic Engineering三大特征：任务>对话、你是架构师、验收是必选项

你的工作流该怎么升级

不是推翻Vibe Coding，是在它的基础上加一层结构。

阶段一：探索期，继续Vibe

新项目、新想法、验证可行性——这里Vibe Coding最爽。随便聊，快速出东西，不用在乎代码质量。这个阶段的目的是验证方向，不是写生产代码。

阶段二：转折点识别

什么时候该切换模式？有几个信号：

项目有了真实用户
改一个功能开始怕影响其他功能
AI建议的方案你已经看不懂逻辑
代码库超过某个你无法整体把握的规模

这个转折点每个项目不一样，但多数人是在出了几次生产事故之后才意识到应该更早切换。

阶段三：Agentic模式

切换到Agentic模式后，每次让AI做一件事之前，先写Spec。Spec不需要很长，但要有：做什么、验收标准是什么。

让AI执行之后，对照Spec验收，而不是直接运行看有没有崩。

Claude Code具体用法：

1
2
3
4
5
6
7
8
9


# 不这么做（Vibe模式）
> 帮我加一个用户登录功能

# 这么做（Agentic模式）
> 实现登录API。
> 规格：POST /auth/login，接受{email, password}
> 返回：成功200+JWT，失败401，密码用bcrypt
> 安全：限制暴力破解，错误信息不暴露账户存在
> 完成后列出你做的每个决策和原因，我来验收

区别不只是提示词更详细，而是你在要求AI解释它做的判断，这样你才能对架构有控制权，而不是只能接受一个黑盒输出。

工作流升级路径：探索期→转折点→Agentic模式

工具层面的Agentic实践

Claude Code

现在的Claude Code不只是"帮你写代码的AI"，它支持多步骤任务、工具调用、代码库范围的上下文理解。Agentic Engineering的工作方式跟它更配：

用 /project 命令让它理解你的整体代码库
用 CLAUDE.md 写清楚你项目的架构约束和代码规范——这就是你的"架构意图"，AI的所有输出都会在这个框架内
每完成一个任务，用刚上线的Code Review功能验收，而不是盲目继续

Cursor

Cursor的Composer模式更适合Agentic工作流。把任务写在Composer里，让它在整个代码库范围内执行，而不是只在当前文件聊。

两者结合

很多人现在用Cursor做日常编辑和补全，Claude Code处理需要深度推理的复杂任务。这个组合在Agentic模式下效果更好——Cursor负责快速迭代，Claude Code负责需要全局视角的架构级任务。

Karpathy没有说Vibe Coding死了

他说的是：工具在进化，方法论也要进化。

2025年Vibe Coding的意义是降低了入门门槛，让更多人能用AI做东西。2026年Agentic Engineering的意义是让这些东西能活得更长、质量更可靠。

这两件事不矛盾。

Vibe Coding让你快速从0到1。Agentic Engineering让你从1到10不崩盘。

你不需要二选一，你需要知道什么时候该切换档位。

大多数Vibe Coding项目的死法不是技术问题，是方法论追不上规模的问题。Karpathy比任何人都清楚这一点，因为这个词就是他发明的。

该升级了。

参考资料

扩展阅读