Vibe Coding 已死：Karpathy 宣布的 Agentic Engineering，到底改变了什么？

Vibe Coding 已死：Karpathy 宣布的 Agentic Engineering，到底改变了什么？

2025 年 2 月 2 日，Andrej Karpathy 在 X 上发了一条帖子。他自己后来说那是”淋浴时的随手一写”。

帖子定义了一种新的编程方式：Vibe Coding——你完全沉浸在 vibes 里，拥抱指数级变化，忘记代码的存在。

这条帖子炸了。一年之内，“Vibe Coding”出现在每一个 Slack 频道、每一场技术会议的 keynote、每一份 VC 的 pitch deck 里。柯林斯词典把它评为年度词汇。搜索量暴涨 6700%。Y Combinator 2025 年春季批次里，25% 的创业公司声称他们 95% 的代码由 AI 生成。

然后，2026 年 2 月 4 日，Karpathy 自己发了另一条帖子。

大意是：Vibe Coding 过时了。

他说，一年过去了，通过 LLM Agent 编程正在成为专业人士的默认工作流，但比起最初”忘记代码存在”的放飞，现在多了更多的监督和审查。他给这种新的工作方式起了个名字——Agentic Engineering。

一个术语从诞生到被创造者亲手”退休”，只花了 365 天。

命名变化的背后，是开发者角色的一次根本性重新定义。

---

一、Vibe Coding 到底出了什么问题

我需要先声明一点：这篇文章不是要否定 Vibe Coding。

直到今天，我在做原型、写周末项目、验证一个新想法的时候，依然会”vibe”。打开 Cursor 或者 Claude Code，用自然语言描述我要什么，AI 生成代码，跑一下看效果，不行就再 prompt 一轮。整个过程不到一小时就能出一个像模像样的 demo。对于那些”结果一眼就能判断对不对”的场景，这个效率是革命性的。

问题出在下一步——当你尝试把 Vibe Coding 的产物推到生产环境的时候。

2025 年下半年开始，行业里陆续出现一些不太好看的案例。Amazon 对代码部署控制进行了一次 90 天重置，至少有一起事故与 AI 编码助手相关。一位 Amazon 高管在内部文件里提到了”高爆炸半径变更”——软件更新因为缺乏控制面的防护措施而大范围传播。

问题不在 Vibe Coding 本身，而在跳过设计思考。

仔细想想，Vibe Coding 本质上解决的是一个”创造问题”——让代码的产生变得极其容易。但它暴露了一个更深的”信心问题”——你对这些代码的质量、安全性、可维护性，心里没底。

这种没底不是你技术差，是因为你根本没看代码。按照 Karpathy 最初的定义，Vibe Coding 的核心特征就是”不读 diff”。你 prompt，你接受，你跑一下，看看行不行。不行就把报错贴回去再来一轮。

这在周末项目里没问题。但当你把同样的工作方式带到一个有真实用户、真实数据、真实安全威胁的系统里时，“不读 diff”就不再是一种风格选择了——它是一种风险敞口。

还有一个更微妙的问题：“Vibe”这个词本身成了负担。

Google 的工程师 Addy Osmani 在一篇广为流传的博客里写了一句话，精准得让人发笑：“当你告诉一个 CTO 你在 vibe engineering 他们的支付系统时，你能看到他脸上的担忧。”

“Vibe”传递的是随性、实验、不较真。这跟专业软件工程追求的可靠、可控、可审计，是两种完全不同的气质。行业需要一个新的词，来描述一种既利用了 AI 的生产力又保留了工程纪律的工作方式。

---

二、Agentic Engineering 到底在说什么

Karpathy 给出的定义很精确，值得逐字拆解。

他说：“agentic”是因为新的默认状态是你 99% 的时间不在直接写代码，你在编排 Agent 来写，然后做监督。“engineering”是为了强调这件事有其艺术、科学和专业性。

翻译成更直白的话：你的角色从”代码的作者”变成了”Agent 的架构师 + 代码的审稿人”。

这不是字面意义上的”不写代码”。你仍然需要理解代码，仍然需要能读懂 Agent 写出来的每一行。区别在于，你的工作重心从”手写实现”迁移到了”设计意图 + 审查产出”。

两种工作流的具体差异，可以用一个对比来说明：

Vibe Coding 的工作流： 想到什么→直接 prompt→接受 AI 输出→跑一下→不行就贴报错重来。整个过程没有规划环节，没有审查环节。速度极快，质量随缘。

Agentic Engineering 的工作流： 先写 Spec 或设计文档（可以让 AI 帮你写，但你要审）→把工作拆成明确定义的任务→把每个任务交给 Agent 执行→像审人类同事的 PR 一样审 Agent 的代码→跑测试，通过了才合并。

两者之间最关键的区别有三处。

规划先行。 在动手之前，你要写清楚你到底要什么。这让我想起自己之前写过的一篇文章——“你以为在写 Spec，其实在绕路写代码”。当时我的观点是，很多开发者觉得写 Spec 是浪费时间。但在 Agentic Engineering 时代，Spec 的消费者从人变成了 Agent。Agent 不懂你的弦外之音、不理解你的产品上下文、不会主动问你”你确定要这么做吗？“。你给它的 Spec 越模糊，它写出来的代码就越随机。Spec 不再是形式主义，它是 Agent 的输入质量。

审查代码。 这一点我也在之前的文章里聊过——AI 时代开发者的核心能力正在从”写代码”迁移到”审代码”。Agentic Engineering 把这个趋势固化成了流程。你不是在做可选的 code review，你是在做类似于编辑审稿的工作：Agent 是初级写手，你是高级编辑。如果你不能解释某个模块在干什么，它就不应该被合并。

测试为王。 Osmani 在他的博客里说得很直接：测试是 Agentic Engineering 和 Vibe Coding 之间最大的区分点。Vibe Coding 的测试方式是”跑一下看看行不行”。Agentic Engineering 要求你有系统化的自动测试，因为当 Agent 每天帮你写几十个 PR 的时候，你不可能用肉眼逐行审查所有代码——你需要测试来帮你兜底。

---

三、这在实际工作中长什么样

讲完概念，说说真实场景。

现在主流的 Agentic Engineering 工作流已经沉淀出一个核心循环：PEV——Plan → Execute → Verify。

Plan 阶段： 你写设计文档、定义架构、拆解任务。这个阶段可以让 AI 辅助（比如让 Claude 帮你基于需求生成一个初版架构方案），但最终的架构决策必须是你做的。Agent 擅长在给定约束条件下解决局部问题，但不擅长做涉及多个模块的全局权衡。

Execute 阶段： 把拆好的任务交给 Agent。你可以用 Claude Code 在终端里跑，用 Cursor 在 IDE 里跑——工具选择不是重点，任务拆解的颗粒度才是重点。一个好的任务应该是”给用户设置页面加一个修改邮箱的功能，验证规则是 xxx，完成后跑一遍现有测试”，而不是”帮我把用户系统做完”。

Verify 阶段： 审代码、跑测试、安全扫描。这个阶段的严格程度直接决定了你能不能把 Agent 的产出推到生产环境。Stripe 有一个叫 Minions 的内部系统，Agent 每周产出超过 1000 个被合并的 PR。这个规模如果没有系统化的自动化验证流程撑着，是不可能安全运作的。

PEV 不是某个公司的专利，它更像是一种正在行业里自然形成的共识。不同公司的具体实现不同，但核心逻辑是一致的：先想清楚，再让 Agent 干，然后严格验收。

---

四、这对你我意味着什么

好，概念讲完了，落回到个体。

如果你是每天写代码的人

Agentic Engineering 时代，你需要投资的技能方向正在迁移。

以前，你花大量时间练的是”写代码的手速”——熟悉 API、背诵设计模式、在键盘上快速实现功能。这些技能仍然有价值（你得能读懂 Agent 写的代码才能审），但它们不再是决定性的差异化能力了。

新的差异化能力包括：

写清楚意图的能力。 这就是 Spec、PRD、设计文档。很多人觉得这是”产品经理的事”，但在 Agent 作为执行者的世界里，你给 Agent 的指令越精确，产出质量越高。这本质上是一种技术写作能力。

快速判断代码质量的能力。 你不需要逐行读完每一行，但你需要在 30 秒内扫完一个 diff，判断”这个改动会不会炸”。这种直觉来自经验积累，来自你见过足够多的好代码和坏代码。

系统设计的全局观。 Agent 很擅长局部实现——你告诉它做一个函数、一个组件、一个端点，它能做得不错。但涉及到”这个数据该存在缓存还是数据库”、“这两个服务之间是同步调用还是异步消息”这类跨模块的架构决策，Agent 几乎无法替你做。这些决策需要你理解业务上下文、理解性能约束、理解团队的运维能力。AI 越强，架构师越值钱。

如果你是技术管理者

有一个新概念值得关注：认知债务（Cognitive Debt）。

我们都熟悉技术债务——代码里的权宜之计累积成未来的维护成本。认知债务是类似的东西，但发生在 AI 交互层面：管理不善的 Agent 调用、丢失的上下文、不可靠的 Agent 行为，这些东西也会累积。

举个例子：你的团队开始用 Agent 写代码了，但没有统一的 Spec 模板、没有 Agent 使用规范、没有自动化的审查流程。三个月后你会发现代码库里有大量”能跑但没人能解释为什么这么写”的代码。这就是认知债务。

2025 年技术债务是工程团队最头疼的问题。2026 年，认知债务可能会取而代之。

---

结尾

回到 Karpathy 的时间线。

2025 年 2 月，他在淋浴的时候想出了 Vibe Coding。2026 年 2 月，他在 X 上亲手”退休”了它。

这 365 天里，AI 编码工具的市场规模达到了 128 亿美元，Claude Code 上线不到一年就贡献了 Anthropic 超过 25 亿美元的年化收入，Cursor 的年化收入突破了 20 亿美元。

但我觉得最重要的变化不是这些数字，而是一个行业心态的成熟：从”AI 好酷，让它帮我写代码”到”AI 好强，我怎么管好它帮我写的代码”。

Karpathy 最后说了一句话，我觉得是对 Agentic Engineering 最好的注解：

未来表现最好的开发者，不是 prompt 最快的人，而是对”要构建什么以及为什么”想得最清楚的人。

AI 在以指数级的速度变强。但”想清楚”这件事——目前来看——还没有被任何模型解决。这可能是我们这代开发者最持久的护城河。

---

你现在的日常工作流，更接近 Vibe Coding 还是 Agentic Engineering？或者说你还在两者之间纠结？评论区聊聊。

如果觉得有收获，点个「喜欢」让更多技术人看到。