杂谈| 告别Vibe Coding：一文读懂其继任者Agentic Engineering

整整一年前，Andrej Karpathy 发过一条推文。

他说：“我把一种新的编程方式叫作‘vibe coding’。你完全交给感觉，拥抱指数级效率，甚至忘掉代码本身的存在。”

当时，开发者一下子就上头了。

这个词迅速传开。一夜之间，教程满天飞。“这怎么做？”“直接 vibe code 啊。”它甚至一度成了很多人面对“如何快速做出一个东西”时的万能回答。

然后，越来越多人开始把这些 vibe-coded 应用往生产环境里推。

结果呢？并不漂亮。

2026 年 2 月 4 日——也就是那条原始推文发出整整一年后——Karpathy 又发了一条新动态。还是同一个话题。但结论，已经完全变了。

他说：

“如今，借助 LLM 代理进行编程，正在越来越多地变成专业人士的默认工作流，只不过它伴随着更多监督与审查。就我个人而言，我现在最喜欢的说法是：‘agentic engineering’（代理式工程）。”

也就是说，那个提出 “vibe coding” 的人，自己已经往前走了。

这篇文章就来聊清楚三件事：

到底是什么变了；
到底是什么替代了 vibe coding；
以及，它为什么会直接影响你今天到底该怎么构建软件。

真正的区别，不在工具，在纪律

这一部分，恰恰是大多数解释文章最容易讲偏的地方。

很多人会把 agentic engineering 理解成：“用了更好的 AI 工具”；或者“自动化更多了”；再或者“代理能力更强了”。

但说实话，这些都没有抓到核心。

vibe coding 的本质，不是用了 AI。而是你在不认真审代码的前提下，把事情交给 AI 去糊。

它最典型的路径是什么？

你提个 prompt。AI 给你一段实现。你直接收下。跑一跑。能跑就算赢。跑不通，就把报错原样贴回去，再来一轮。

问题从来不只是 AI。真正的问题，是人没有对 AI 产出的代码承担起审查责任。

而 agentic engineering 不一样。

它的逻辑是：AI 负责具体实现，人类负责架构、质量和正确性。

你也许手写的代码只占很小一部分。剩下的大量代码，确实可能来自各种 agent。但它们是在你的边界、你的约束、你的审查之下工作的。这才叫“agentic”。

同样的工具。但工程纪律，完全不是一回事。

如果只用一句话概括两者区别，那就是：

Vibe coding = YOLO。Agentic engineering = AI 来造，人类来负责。

为什么 vibe coding 一旦放大，就一定会出事

如果一个团队并不真正懂得如何把 LLM 用在软件工程里，那么 vibe coding 最终大概率只会产出一种东西：

AI slop。

也就是那种乍一看像那么回事，实际要么没用、要么一碰就碎、甚至还会顺手把旧代码一起带崩的代码。

更糟的是，这类代码并不会只制造小 bug。它会持续地推高团队的技术债。工程师大量的时间，最后不是花在推进新功能上，而是花在“理解它、排查它、重构它”上。

真正让 vibe coding 在生产环境里失败的，主要有三种典型死法。

1. 安全漏洞会被批量制造出来

代理写得快，不等于它写得安全。

它完全可能以极高效率，把漏洞也一并高效生成出来。假设一个 agent 每周能产出 1000 个 PR，哪怕漏洞率只有 1%，那也意味着——你每周都在新增 10 个漏洞。

而 vibe coding 最大的问题，就在于它根本没有这道安全闸门。AI 写了，你就交付了。至于里面有没有危险代码、有没有权限绕过、有没有输入校验问题，很多人根本没真正看过。

2. 架构会慢慢烂到没人看得懂

vibe coding 的致命伤之一，是它天然跳过设计阶段。

你想要一个功能。你把需求甩给 agent。它给你实现。你觉得“能跑就行”，然后继续下一项。

短期看，这很爽。三个月后，这种爽就会变成报应。

因为那时候，整个代码库会慢慢变成一种非常熟悉的状态：没人说得清它为什么会长成今天这样。

不是你说不清。是连当初生成它的 agent，也说不清。

因为一开始就没有真正的设计推导。没有架构决策记录。没有明确约束。也没有稳定的理由链条。所以后面自然也就没有可追溯性。

3. 上下文一长，系统就开始“失忆”

vibe coding 还有一个非常现实的问题：会话越长，结果往往越差。

agent 会逐渐忘记前面做过的决定。忘记先前的限制。忘记你们已经确认过的接口。然后它写出来的新代码，开始和旧代码自相矛盾。

更可怕的是，开发者常常根本没发现。因为他们没有认真读 diff。

到了 2026 年，一个越来越被重视的问题已经浮上来了——认知债（cognitive debt）。

它指的是：因为 AI 交互管理不善、上下文丢失、代理行为不稳定，而不断累积起来的理解成本和决策成本。

而 vibe coding，本质上就是一种制造认知债最快的开发方式之一。

真正的 agentic engineering，到底长什么样

它的流程其实并不神秘。也不复杂。但它要求一种 vibe coding 明确放弃掉的东西：工程纪律。

第一步：先写 spec，再碰代码

在你给 agent 下任何指令之前，先写设计说明。

这个功能到底做什么？边界条件有哪些？数据模型怎么设计？可能会出什么问题？哪些地方最容易踩坑？

这一步，正是大多数 vibe coder 最爱省略的。

偏偏也正是这一环，决定了 agent 最终给你的，到底是靠谱实现，还是“看起来像对的垃圾”。

你当然可以借助 AI 来一起写 spec。但请注意：是你来写。 而且，必须在 agent 动手改文件之前写。

第二步：把任务切成小而清晰的块

设计良好的 agentic 系统，不会把所有任务一锅端给 AI。它会把事情拆成更小的模块，让 agent 在明确范围内生成相对独立的组件，再把它们稳稳接进现有代码库，而不是顺手再制造一层技术债。

比如：

“帮我做一个用户认证系统。”

这就是非常典型的 vibe coding prompt。它太大。太模糊。太空泛。最后 agent 一定会替你做出一堆你从来没同意过的架构决策。

而如果你这样说：

“基于我们现有的 Resend 集成，实现密码重置邮件流程。Token 存 Redis，TTL 为 15 分钟。这里是 spec。”

这就是 agentic engineering 任务。

它有边界。有约束。可审查。也可拆解。

同样是让 AI 写代码，两者最后产出的可控性，根本不是一个量级。

第三步：像审人类 PR 一样审 AI 代码

这一条，是最难坚持的。但也是最关键的。

你必须用审查同事 PR 的标准，去审 AI 提交的代码。不是“差不多能跑就行”，而是——如果你自己都解释不清这个模块在干什么，它就不应该进主干。

真正困难的地方在于：AI 生成很快。审查很慢。

于是人就很容易动歪心思：“先过吧。”“看起来没问题。”“等出事再说。”

而恰恰是这种“略过审查”的瞬间，制造出了后来所有人都在抱怨的那种无法维护的代码库。

所以要怎么做？

读 diff。真的读。每个函数都要看懂。哪里不明确，就让 agent 先解释清楚。解释不清楚，就别 merge。

第四步：测试要狠，不能装样子

如果一定要说，agentic engineering 和 vibe coding 最大的分水岭是什么，那我会选两个字：

测试。

vibe coding 的交付标准通常是：“看起来像能用。”

agentic engineering 的交付标准则是：测试通过。

而且要强调一点：不是“agent 自动生成了一堆测试，然后你扫一眼就点头”。而是那些测试，要么是你自己写的，要么是你认真审过、确认能真正兜底的。

测试不是最后的附属品。它是整个流程里，判断“这玩意到底能不能上线”的最后一层现实过滤器。想要了解更多关于 软件测试 的最佳实践，可以参考相关的专业内容。

当这套方法被认真执行时，结果并不是空谈

这不是纸上谈兵。也不是某种只适合理论派的流程洁癖。

真正把 agentic engineering 做对的公司，已经在给出非常具体的结果。

TELUS 用 13，000 个 AI 解决方案，累计节省了 50 万小时以上。 Zapier 在整个组织里实现了 89% 的 AI 采用率。 Stripe 的 agents 每周能产出 1000+ 个已经合并的 PR。

这不是 vibe coding 能交出来的结果。这也不是“模型突然聪明了一百倍”导致的奇迹。

它真正说明的是：当你把治理、审查流程、代理编排全部搭好之后，再让 agents 在这个结构里规模化执行，AI 才会从玩具变成生产力。

不是规模让一切变安全。恰恰相反——是结构，才让规模变得安全。 这与专业的 运维/DevOps/SRE 理念不谋而合，都强调通过流程和工具来保证质量和效率。

全新思维模式 —— 架构师，而非创作者

开发者的角色，正在发生变化。

vibe coding 抓住的，是生成式工具刚冒头时那种令人兴奋的情绪：快。爽。仿佛一切都可以一句话搞定。

而 agentic engineering 代表的，则是一种更沉下来、更接地气的现实。

对于工程师而言，这意味着技能重心的转移。

你不再只是那个“亲手写代码的人”。你更像是那个：

• 决定到底要构建什么，以及为什么要这么构建的人
• 设计 agent 必须遵守的架构边界的人
• 审查 agent 产出结果的人
• 决定哪些东西可以上线、哪些绝对不能上线的人

在这个新阶段里，一个开发者真正的价值，越来越不取决于你的手速有多快，或者你能不能背出一堆 API 参数。

真正决定你价值的，是两件事：

你定义问题的清晰度。以及你判断结果的准确度。

未来真正会过得好的开发者，不会是“提示词打得最快”的那批人。而会是：

最会做架构的人，最会想清楚问题的人，也是最不肯在审查上放水的人。

这和 vibe coding 要求的能力，已经不是同一个方向了。但说实话，它也确实更值钱。

这周你就该改掉的 3 件事

你不需要换新工具。你需要换习惯。

1. 每次让 agent 干活前，先写 spec

哪怕只有一段话。哪怕只是几个 bullet points。也要逼自己在下 prompt 之前，把问题先想清楚。

这一条习惯，比任何工具，都更能把你从 vibe coding 拉到 agentic engineering。

2. 把每一个 diff 真正读完

不是扫一眼。不是看个大概。是逐行读。

agent 改了 200 行？那你就读 200 行。

哪里不懂，就问。解释不清，就不能进。你自己都说不清的东西，没资格被合并。

3. 测试跑完之前，别说“做完了”

如果现成没有测试，那就先写测试。再让 agent 去实现，直到测试通过。

先有测试，再有实现。这个顺序，尽量不要倒。

同样的三件工具，同样的 AI，同样的代码编辑器。只是换了三条习惯，最后的结果就会完全不同。

最后

真正取代 vibe coding 的，从来不是某个更强的新模型。而是“AI 在干活，人类在负责”的工程秩序。

欢迎在 云栈社区 分享你的实践与思考。