Vibe Coding 与 Agentic Engineering：2026年你该用哪一个？

一年前，你还在敲代码。今天，你只需谈论它。

在 Andrej Karpathy 2025 年 2 月那条关于“vibe coding”的著名推文与 Claude Code、Cursor、Windsurf 等工具爆发之间，开发者构建软件的方式发生了变化。我们不再逐行手写代码，而是开始与 AI 对话。

但问题就出在这里。人们开始把一切都称为“vibe coding”，无论是周六晚上的业余项目，还是 Anthropic 工程师交付生产代码的方式。Karpathy 本人在 2026 年 2 月又出来澄清了。他为严肃的版本提出了一个更好的名称：Agentic Engineering（代理工程）。

那么，你实际做的是哪一种？而你应该做哪一种？

本指南将阐明这两者，展示它们在真实代码中的样子，讲解没人警告过你的安全陷阱，并帮助你判断每种方法何时适用。没有流行词，没有炒作。只有你下一次拉取请求之前需要知道的东西。

什么是 Vibe Coding？

Vibe coding 正如其名。你用日常英语描述你想要的东西，AI 构建它，然后你就在不逐行阅读代码的情况下交付它。

你顺势而为。AI 是工程师。你是那个说“把按钮变成蓝色”并信任结果的产品经理。

它看起来像这样：

你：“给我建一个待办事项应用，用户可以添加任务、标记完成、按状态筛选。”

AI：生成 200 行 React 代码。

你：“不错，交付它。”

这就是 vibe coding。没有代码审查，没有关于架构的问题，不检查拉入了哪些依赖项。只有氛围。

老实说？在很多情况下它都很好用。周末的 hack，一次性的原型，你周五需要的那张落地页，一个只有你会用的工具。

问题从“交付它”意味着“部署到有真实用户和真实数据的服务器”时开始出现。

什么是 Agentic Engineering（代理工程）？

Agentic engineering 保留了相同的 AI 工具，但增加了 vibe coding 抛弃的东西：你的判断力。

你仍然不是逐字敲键盘。你指挥着 AI 代理，它们读取你的代码库、运行测试、修复失败、并打开拉取请求。但你来划定工作范围、审查输出、并对结果负责。

Karpathy 故意把这个术语分成了两半。Agentic（代理的） 意味着由代理驱动，你在编排工作，而不是亲力亲为。Engineering（工程） 意味着仍然涉及工艺、判断力和专业知识。代理是你的合作者，而不是你的替代者。

一个典型的 agentic engineering 工作流程更像是：

1. 编写清晰的规范说明（通常放在像 AGENTS.md 或 CLAUDE.md 这样的文件中）
2. 在编码前要求代理制定计划
3. 让代理进行实现并运行测试套件
4. 像审查任何队友的拉取请求一样审查差异
5. 如果有问题就迭代

少一些“给我做个应用”，多一些“这是架构，这是约束，这是测试，开始吧。”

用一句话说清真正的区别

Vibe coding 优化的是让东西跑起来的速度。Agentic engineering 优化的是对构建出来的东西能持续运行的信心。

就是这样。这就是整个框架。

当你在测试一个想法时，速度很重要。当其他人依赖你所构建的东西时，信心很重要。

真实代码示例

我们来具体看看。下面是同一任务以两种方式处理的结果，这样你就能看到差距到底在哪里。

任务： 构建一个允许用户更新电子邮件地址的 API 端点。

Vibe Coding 方法

你会输入类似这样的内容：“添加一个更新用户电子邮件的端点。”

AI 会给出这个：

app.post('/update-email', async (req, res) => {
  const { userId, newEmail } = req.body;
await db.users.update({
    where: { id: userId },
    data: { email: newEmail }
  });
  res.json({ success: true });
});

它能运行。Postman 返回 200。你继续往下走。

但看看缺少了什么。任何知道 userId 的人都可以更改别人的电子邮件。没有认证检查。没有验证电子邮件是否真的是电子邮件。没有速率限制。没有验证邮件。用户可以输入“哈哈不是邮件”，它也会保存下来。

这就是 vibe coding 的陷阱。代码在狭窄的意义上工作——它不会崩溃。但它也是一个等待发生的安全事件。

Agentic Engineering 方法

你先写一个规范说明。像这样：

## 任务：电子邮件更新端点

### 需求
- 已认证用户只能更新自己的电子邮件
- 新电子邮件必须经过验证（RFC 5322）
- 在提交前向新地址发送验证邮件
- 旧电子邮件应在验证前保持活跃
- 速率限制：每用户每小时 3 次尝试
- 记录更改的审计日志
### 所需测试
- 未授权请求返回 401
- 跨用户更新返回 403
- 无效电子邮件格式返回 400
- 速率限制在 3 次尝试后返回 429

你把这个交给代理。它进行规划、实现、运行测试，并生成更像这样的结果：

import rateLimit from 'express-rate-limit';
import { z } from 'zod';
import { requireAuth } from './middleware/auth.js';
import { sendVerificationEmail } from './services/email.js';
import { auditLog } from './services/audit.js';

const emailSchema = z.object({
  newEmail: z.string().email()
});
const limiter = rateLimit({
  windowMs: 60 * 60 * 1000,
  max: 3,
  message: '邮箱更改尝试次数过多'
});
app.post('/update-email', requireAuth, limiter, async (req, res) => {
  const result = emailSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(400).json({ error: '邮箱格式无效' });
  }
  const { newEmail } = result.data;
  const userId = req.user.id; // 来自认证中间件，而不是请求体
  const token = await createVerificationToken(userId, newEmail);
  await sendVerificationEmail(newEmail, token);
  await auditLog.record({ userId, action: 'email_change_requested', newEmail });
  res.json({
    message: '验证邮件已发送。请确认以完成更改。'
  });
});

相同的功能。你这边付出的精力大致相同。但结果却截然不同。

记得我以便更快登录

代理完成了打字。你完成了关于“更新电子邮件”在真实用户使用的系统中实际含义的思考。

什么时候 Vibe Coding 实际上是正确的选择

Vibe coding 经常被吐槽，但它确实有自己的位置。使用它的场景：

• 你在制作原型。 速度比精雕细琢更重要。反正你会扔掉代码。
• 这是个人工具。 一个整理照片的脚本不需要审计日志。
• 影响范围很小。 没有真实用户，没有真实数据，没有与任何重要系统的集成。
• 你在学习。 有时你只需要看到代码运行起来，才能理解某部分是如何组合在一起的。
• 这是一次性任务。 迁移脚本、数据清理、快速分析。

Vibe coding 是一把锤子。有用，但不适用于所有问题。

什么时候 Agentic Engineering 是正确的选择

几乎所有其他情况。具体包括：

• 生产系统。 任何用户依赖的东西。
• 任何涉及金钱、身份或健康数据的东西。 这里的错误不是 bug，而是事故。
• 多人协作的代码库。 当其他人必须阅读所构建的代码时，一致性很重要。
• 长期存在的项目。 你要维护多年的代码值得投入前期的思考。
• 任何受监管的领域。 医疗、金融、政府、教育。审计人员不在乎“是 AI 做的”。

更深刻的真相：大多数专业代码属于 agentic engineering 的范畴。Vibe coding 是例外，而不是默认。

安全：每个人都轻描淡写的部分

这是 vibe coding 从有风险变得真正危险的地方，也是大多数博客文章一笔带过的部分。我们不会一笔带过。

数据

最近的研究对 AI 生成的代码并不友好。研究发现，大约 45% 的 AI 生成代码包含 OWASP Top 10 中的经典漏洞，而且这个数字在过去两年几乎没有变化。大约 20% 的 vibe-coded 应用在发布时就带有严重的漏洞或配置错误。

佐治亚理工学院网络安全学院的研究人员开发了一个扫描器，用于在公开的安全公告中寻找 AI 引入的漏洞。他们已经确认了数十个案例，严重等级为关键和高风险。

这不是未来的问题。它已经在发生了。

实际出问题的地方

以下是 vibe-coded 应用中反复出现的安全失败：

硬编码的密钥。 API 密钥、数据库密码和 Token 直接出现在源代码中。AI 不知道什么是秘密，所以它只留下占位符，而开发人员忘记删除。

认证悄悄地变弱。 在迭代提示（“先让它工作，暂时不要登录”）期间，认证检查被移除且从未恢复。端点保持暴露状态。

SQL 注入和类似攻击。 AI 生成的代码通常直接将用户输入拼接到查询中，而不是使用参数化语句。代码能编译。能运行。但它也门户大开。

Slopsquatting。 这个很疯狂。AI 有时会幻觉出不存在的包名。攻击者注册了完全相同的名称，并在其中植入恶意代码，知道 AI 会继续推荐它们。你的应用在 npm install 时安装了恶意软件。

授权漏洞。 AI 构建了愉快路径（happy path）。它很少检查“这个用户应该被允许这样做吗？”上面的端点（你可以通过传入任何人的 userId 来更改其电子邮件）就是一个教科书式的例子。

依赖膨胀。 AI 会拉入任何能使代码最快运行的库。你最终会得到数百个从未审查过的传递依赖，每个都是一个潜在的入口点。

什么真正有帮助

AI 辅助开发中的安全不是禁止工具。而是建立能够捕捉 AI 遗漏内容的习惯：

对 AI 生成的代码进行静态分析。 使用 Semgrep、Snyk 或你现有的 SAST 扫描器。把 AI 输出当作来自初级承包商的代码：不要假设任何事，验证一切。

使用提示级别的防护栏。 将安全需求添加到你的规范说明文件中。比如“所有端点都需要认证”、“所有用户输入必须通过 schema 验证”、“永远不要记录秘密”。现代的编码代理会尊重 CLAUDE.md 或 AGENTS.md 中的这些要求。

锁定依赖并审查安装的内容。 不要让代理自由地添加包。要求对新依赖进行审批，即使这会拖慢你的速度。

测试运行中的应用，而不仅仅是代码。 动态应用安全测试（DAST）工具会探测你的实际部署应用以发现漏洞。它们能捕捉那些在代码中看起来没问题但在运行时可以被利用的东西。

让人类保持在审查循环中。 特别是任何涉及认证、支付或个人数据的内容。代理可以实现，但人类仍然需要批准。

底线：AI 不知道你的威胁模型。你知道。不要外包这部分。

如何进行切换（如果你需要的话）

如果你一直在 vibe coding 并想升级到 agentic engineering，你不必明天就彻底改革一切。一个合理的路径：

1. 开始编写规范说明。 即使只有一个段落也好。告诉代理你想要什么、约束条件以及如何知道它有效。
2. 在你的仓库中添加 AGENTS.md 或 CLAUDE.md。 描述你的技术栈、你的约定、你的安全要求。每个接触仓库的代理都会读取它。
3. 让测试成为非可选项。 如果代理不能为更改编写一个通过的测试，那么更改就还没完成。
4. 在合并前审查差异。 即使只是五分钟的扫描也能捕捉到很多问题。
5. 在 CI 中运行安全扫描。 设置一次，永远受益。

你会慢一周。然后会在项目的其余部分跑得更快。

结论

Vibe coding 和 agentic engineering 不是敌人。它们是用于不同工作的工具。

如果你在素描、探索或构建只有你会用的东西，vibe coding 没问题。享受乐趣，快速行动。

如果你在交付其他人会运行、依赖或用他们的数据信任的软件，agentic engineering 是标准。AI 仍然完成大部分打字工作。你仍然完成工程工作。

2026 年正在发生的转变，其实不是关于 AI 取代开发者。而是关于“成为开发者”现在意味着什么。更少时间写 for 循环，更多时间写规范说明。更少时间调试语法错误，更多时间审查来自代理的拉取请求。更少打字，更多思考。

为眼前的工作选择正确的方法。不管你做什么，请在部署之抢跑一次安全扫描。

快速参考

觉得有用吗？ Agentic engineering 领域发展迅速；今天正确的事情可能在三个月后发生变化。将此页面加入书签稍后回来，或者在下一个副业项目中同时尝试这两种方法，以便亲身感受差异。

• 原文链接： medium.com/@ancilartech/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～