告别Vibe Coding！为什么Agentic Engineering才是AI编程的正确姿势

导语：Andrej Karpathy 一年后亲手修正了“vibe coding”的说法，转向“agentic engineering”。本文剖析两者差异，并给出可立即落地的实践方法。

一年前，Andrej Karpathy 在推特上扔出了一枚重磅炸弹：“我把一种新的编程方式叫作‘vibe coding’。你完全交给感觉，拥抱指数级效率，甚至忘掉代码本身的存在。”这条推文像野火一样烧遍了开发者社区。一夜之间，人人都在谈 vibe coding，教程、工具、方法论铺天盖地。然而，整整一年后，2026 年 2 月 4 日，Karpathy 亲手修正了自己的说法：“如今，借助 LLM 代理进行编程，正在越来越多地变成专业人士的默认工作流，只不过它伴随着更多监督与审查。就我个人而言，我现在最喜欢的说法是：‘agentic engineering’（代理式工程）。”

这不仅是措辞的转变，更是一次对 AI 编程模式的彻底反思。本文将深入分析：vibe coding 为什么注定失败？agentic engineering 究竟是什么？以及它如何重塑我们构建软件的方式。

Vibe Coding 与 Agentic Engineering：差别不在工具，而在纪律

大多数人对 agentic engineering 的误解是：它只是用了更强的 AI 模型，或者自动化程度更高。但真相远比这深刻。Vibe coding 的本质并不是“使用 AI 编程”，而是在缺乏严格审查的情况下，盲目信任 AI 产出的代码。它的典型路径是：提需求 → 复制 AI 给出的代码 → 运行一下 → 能用就过，报错就把错误信息喂回去再来一轮。人不再对代码的质量、安全性和架构负责。

而 agentic engineering 则确立了一种全新分工：AI 负责实现细节，人类负责架构、约束和质量把关。开发者依然可能只写少量核心代码，但所有由 agent 生成的代码都在明确的边界、规范与审查之下运作。同样的工具，不同的工程纪律——这正是两者之间的分水岭。用一句话概括：Vibe coding = YOLO；Agentic engineering = AI 制造，人类担责。

为什么 Vibe Coding 一经放大就会崩塌？

在没有工程治理的团队中，vibe coding 几乎注定会产出“AI 垃圾”（AI slop）——那些看起来像模像样，实际却脆弱不堪、隐藏无数地雷的代码。它不仅制造小 bug，更会系统性推高技术债务，把工程师的时间消耗在无尽的排查、理解和重构上。Vibe coding 在生产环境中会以三种典型方式走向失败。

1. 安全漏洞被高效批量制造

Agent 写得快不等于写得安全。假如一个代理每周能生成 1000 个 pull request，即便漏洞率只有 1%，也意味着每周新增 10 个漏洞。而 vibe coding 最致命之处，正是没有安全检查这道闸门。开发者往往直接采纳 AI 代码，从未认真检查权限控制、输入校验或加密逻辑。漏洞就这样悄无声息地流入生产环境。

2. 架构逐渐腐烂到无人能懂

Vibe coding 天然跳过设计阶段。你扔给 agent 一个需求，它产出实现，你觉得“能跑就行”，然后开始堆下一个功能。短期来看爽感十足，但三个月后，整个代码库就变成了一个没人能解释的黑洞——甚至连生成它的 agent 自己也无法说清当初的设计逻辑。因为没有架构决策记录，没有约束条件，自然也就没有可追溯性。

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

长时间会话是 vibe coding 的又一软肋。Agent 会逐渐忘记之前的决定、限制和接口约定，导致新代码与旧代码互相矛盾。更糟糕的是，由于开发者没有认真读取 diff，这些问题往往很难被及时发现。到 2026 年，一个日益严峻的挑战浮出水面——认知债（cognitive debt）：由于 AI 交互管理混乱、上下文丢失、代理行为不稳定而积累的理解成本和决策成本。而 vibe coding 恰恰是制造认知债最快的途径之一。

真正的 Agentic Engineering 长什么样？

Agentic engineering 的流程并不神秘，但它要求一种 vibe coding 明确放弃的东西：工程纪律。下面就是它的核心实践步骤。

第一步：先写 Spec，再让 Agent 动手

在给任何指令之前，先写出清晰的设计说明：这个功能要做什么？边界条件是什么？数据模型如何设计？潜在风险有哪些？哪些区域最容易出错？这一步正是 vibe coder 最爱省略的，却也是决定 agent 产出质量的关键。你可以用 AI 辅助写 spec，但必须由你来主导，并且必须在 agent 修改代码前完成。

第二步：将任务拆解为小而明确的模块

“帮我做一个用户认证系统”——这就是典型的 vibe coding prompt，笼统、模糊，最终 agent 会替你做出一系列你从未同意过的架构决策。而 agentic engineering 则会说：“基于我们现有的 Resend 集成，实现密码重置邮件流程。Token 存 Redis，TTL 为 15 分钟。这里是 spec。”这样的 prompt 有边界、有约束、可审查、可拆解，产出的代码可控性不在一个量级。

第三步：像审查同事 PR 一样审查 AI 代码

这是最难坚持但也最关键的一步。你必须用审查人类同事代码的标准去审视每一个 AI 提交的 PR。不是“差不多能跑就行”，而是若你自己都解释不清模块逻辑，它就不该进入主干。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 才能真正从玩具变成生产力。不是规模让一切安全，而是结构让规模变得安全。

开发者的新角色：从创作者到架构师

Vibe coding 抓住了生成式工具初现时那种令人兴奋的情绪：快，爽，仿佛一切都可以一句话搞定。但 agentic engineering 代表的是一种更沉静、更务实的现实。开发者的价值重心正在发生转移：你不再只是那个“亲手写代码的人”，而是决定构建什么、定义架构边界、审查产出结果、最终拍板上线的人。决定你价值的，不再是手速或记住多少 API 参数，而是定义问题的清晰度和判断结果的准确度。未来属于最擅长架构、最会想清楚问题、最不肯在审查上放水的人。