目录
2025 年 2 月，OpenAI 联合创始人、前 Tesla AI 负责人 Andrej Karpathy 在 X 上发的一句话，让一个新词在世界范围内扩散开来——vibe coding。
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
一年后的 2026 年，这个词正处于 褒贬两极的争论中心。Karpathy 本人提议改名，企业端的安全事故急剧上升，而在个人开发者、创业团队和内部工具领域，它已经作为 一种标准化的编码风格 落地下来。本文将基于官方信息源与行业数据，从定义到最新争论，对 vibe coding 做一次完整梳理。
Vibe coding ＝"不读代码，全交给 AI"的风格
— 介于传统编码与 agentic engineering 之间的位置
用来 快速试做一次性原型，vibe coding 无可替代。
但若要投入生产，就必须向 agentic engineering 一侧 靠拢。
1. 什么是 vibe coding
Vibe coding 是一种以 "谈论代码该做什么，而不是去写或读代码本身" 为核心的编程风格。你用自然语言把想要的东西告诉 AI（Claude、GPT、Cursor Composer 等），然后不读生成出来的代码，反复运行并继续要它修复。
核心思想有三条：
- 放下对代码的执着：丢掉"这是我写的代码"那种所有权感。
- 能跑就行：跑通之后，内部实现的理解可以稍后再说——或者永远不说。
- 用对话推进：出 bug 或报错时，直接告诉 AI"修一下"。把堆栈信息粘贴给它就够了。
典型例子：个人开发者输入"用 Pygame 写个俄罗斯方块" → Claude 返回 500 行代码 → 跑起来 → 方块不会下落，于是说"方块不旋转" → 拿到修复后的版本。整个过程自己一行都没写。
2. Karpathy 的发明与一年后的改名
"vibe coding"这个词由 Andrej Karpathy 于 2025 年 2 月 在 X（原 Twitter）上首次提出。他用它来形容自己将 Cursor Composer（当时使用 Sonnet）和 SuperWhisper（语音输入）组合起来、几乎只靠"说话"就完成应用开发的体验。
之后一年里发生的事：
- 2025 年 8 月：主流 LLM 在 SWE-bench 上突破 60%，vibe coding 开始具备现实可行性。
- 2025 年 12 月：Karpathy 本人报告自己的工作流出现戏剧性反转——11 月手写比例 80%，12 月 AI 生成比例 80%。
- 2026 年 2 月：Karpathy 提议放弃"vibe coding"这一名称，改称 "agentic engineering"。区别在于：vibe = 说出想要什么，然后接受 AI 给的东西；agentic engineering = 设计系统、明确约束，并用 AI 加速一个你已经想清楚的实现。
所以 vibe coding 处于一个微妙位置——"普及了概念的词，但创造它的人已经不再推荐"。市场上仍在继续使用，因为没有别的词能传达出 "轻松随性"和"摆脱读代码束缚" 的同样意味。
3. 典型的工作流
抽象论到此为止，下面看实际的循环过程。
Describe → Generate → Run → Talk back
这 4 步循环要 跑几十到几百次，才能拼出一个功能。
它和传统的"设计 → 实现 → 测试"线性流程是两种不同的东西。
4. 主流工具
截至 2026 年 5 月，下面这些工具特别适合 vibe coding 风格。
| 工具 | 提供方 | 优势 | 典型用途 |
|---|---|---|---|
| Claude Code | Anthropic | 长时自主任务、MCP 集成、narrate-then-code 帮你真正理解代码 | 对既有仓库做大规模改动、新项目启动 |
| Cursor Composer | Cursor | IDE 一体化、多文件编辑，因 Karpathy 使用而声名大噪 | 个人开发、创业公司 MVP |
| Codex CLI | OpenAI | 集成 GPT-5.5，终端自动化能力强 | CLI 工具、脚本、运维自动化 |
| Lovable | 独立创业公司 | 专为"用对话造应用"设计的 UI，连部署也帮你做 | 非工程师的 SaaS 原型 |
| v0 | Vercel | 专注 UI 组件，从生成到部署一气呵成 | 落地页、纯前端工作 |
| Bolt.new | StackBlitz | 完全在浏览器中运行，从模板生成全栈 Web 应用 | 学习、演示、内部工具 |
| Devin | Cognition | 自主智能体。给它一张工单，它就交出一个 PR | 团队中"额外的一名工程师"位 |
如果你是非工程师，用于学习或原型开发，看 Lovable、v0 与 Bolt.new。如果你是面向已有代码工作的职业工程师，目前的主流选择是 Claude Code、Cursor 与 Codex CLI。
5. 阴暗面——安全与质量的现实
"Vibe coding 写起来很爽，但放到生产又是另一回事。"这个温差在 2026 年再也藏不住了，第三方调查的数字一点都不留情。
用数字看 vibe coding 的阴暗面
— "好玩"不等于"安全"
对比 2026 年 1 月：约 6 倍
Georgia Tech Vibe Security Radar
行业调查中位数
100% 引入了同类 SSRF 漏洞
Tenzai 12 月调查
安全漏洞：2.74 倍
CodeRabbit 470 PR 分析
人类提交：1.5%——约 2 倍
CSA 2026
86% 含有 XSS 漏洞
Georgetown CSET
Escape.tech 扫描了 5,600 个公开部署的 vibe coding 应用，发现 2,000 个严重漏洞、400 个 API 密钥外泄、175 起 PII（医疗与支付数据）泄露。"能跑"和"安全"是两件事。
这并不是"AI 不行"的故事，而是 "把没读过的代码推上生产"这种开发风格本身的结构性问题。同样的 AI，配上人工评审和验证，事故率会大幅下降。
6. Vibe vs Agentic Engineering
理解 Karpathy 在 2026 年提出的改名建议是值得的——它能让运营层面的判断更清晰。
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 起点 | "我想做这个" | "我想这样设计" |
| 约束 | 隐式，交给 AI 去解读 | 显式，明确告诉 AI |
| 代码理解 | 不需要，确认结果即可 | 必须，AI 是加速工具 |
| 评审 | 只看"能不能跑" | 看 diff、设计判断、安全 |
| 适用范围 | 个人实验、学习、一次性代码 | 生产系统、长期运行、共享资产 |
| 失败模式 | 安全事故、不可维护 | 速度变慢、被 AI 绑住手脚 |
| 谁是主角 | AI | 人（AI 是放大器） |
用同样的工具（Claude Code、Cursor），会因为使用者的姿态不同而变成 vibe coding 或 agentic engineering。重要的是有意识地知道"我现在在哪种模式"，并主动切换。
7. "Vibe & Verify"——落地的铁律
2026 年正在标准化的最佳实践叫 "Vibe & Verify"：保留让 AI 来写带来的轻盈感，但在后段一定加上验证。
(1) 按风险等级切换模式
- 低风险（个人工具、学习、脚本）：full vibe 完全没问题。
- 中风险（内部工具、MVP、一次性原型）：vibe + 冒烟测试 + 简易安全扫描。
- 高风险（生产、客户数据、对外公开）：必须用 agentic engineering 模式。即便是用 vibe 写出来的，也要先经过 人工评审 + 自动化安全扫描 + 补充测试 再 push。
(2) 对 AI 生成代码必做的三件事
- 看 diff：一次性代码可以一行不读。共享代码至少把 diff 用眼睛扫一遍。
- 跑安全 linter：
semgrep、bandit、truffleHog等。对 secrets、SSRF 与 XSS 的机器化检查不可省略。 - 让 AI 写测试：对同一个 AI 一定再追加一句"现在给它写测试"。没有测试的代码连 vibe coding 都算不上。
(3) 不要丢掉"读代码"的能力
太习惯 vibe coding 之后，一旦 AI 出错——或者你不得不接手别人的代码——你会发现自己 读不懂了。Karpathy 本人也反复强调，能在细节层面理解 AI 生成的代码的能力很重要。就算 vibe，也要养成偶尔停下来真正读一遍代码的习惯；从长期看，差距正是在这里拉开的。
(4) 不要 vibe 你的 secrets
API 密钥、数据库密码、生产环境访问令牌——绝不交给 AI、绝不让它写进代码里。.env + .gitignore + 环境变量这套规范，不论 vibe 不 vibe 都不能破例。Escape.tech 发现的那 400 起外泄，正是这层基本卫生崩塌的案例。
8. 谁应该 vibe coding，做什么、做到什么程度
| 身份 | vibe coding 适合用在哪 | 需要注意什么 |
|---|---|---|
| 非工程师（PM、设计师、创业者） | 原型、内部工具、自动化脚本 | 涉及真实客户数据的部分——把工程师拉进来 |
| 初级工程师（0〜2 年） | 学习、个人项目、工作辅助 | vibe 太多基本功练不出来。要刻意留出"读代码"的时间 |
| 中级工程师 | 常规任务提速、生成文档、补测试 | 生产代码重构要往 agentic engineering 一侧靠 |
| 资深工程师 | 规格设计的对练、多方案高速原型、阅读遗留代码 | 真正的价值在于把 vibe 当作 思考的加速器 |
| 安全 / SRE | 运维工具、监控脚本、看板 | 触及生产的部分要严格执行 Vibe & Verify |
总结
- Vibe coding 是 Karpathy 于 2025 年 2 月提出的"不读代码、全交给 AI"的编码风格。
- Karpathy 本人随后于 2026 年提议改名为 "agentic engineering"——生产工作需要设计、约束与人的判断。
- 主流工具：Claude Code、Cursor Composer、Codex CLI、Lovable、v0、Bolt.new、Devin。
- 安全现实：AI 代码 40〜62% 含有漏洞，5 家主流代理全部被发现 SSRF，CVE 三个月内增长 6 倍。
- Vibe & Verify：按风险切换模式、看 diff、跑安全扫描、让 AI 写测试、绝不 vibe 你的 secrets。
- 不要丢掉"读代码的能力"——越是常 vibe 的人，偶尔停下来去理解一下，越会成为长期的差距来源。
FAQ
Q1. 既然 Karpathy 已经改名，"vibe coding"是不是已经是个过时词？
市场上仍然广泛使用，因为没有别的词能传达"轻松地交给 AI"那种语感。比较务实的做法是把两者视为互补："轻松探索模式 = vibe coding"，"生产模式 = agentic engineering"。
Q2. 编程新手从 vibe coding 上手可以吗？
可以——但 一定也要读代码。如果只 vibe，AI 出错时你完全没有判断依据。比较现实的路径是：先用"我手上有能跑的代码"这种成就感作为前期动力，再逐步提高真正理解代码的时间占比。
Q3. 在公司里用 vibe coding 时，怎么说服上司？
带三样东西去：(1) Vibe & Verify 的运营规则、(2) 集成进 CI 的安全扫描、(3) 代码评审依旧严格保持。只要能明确说出"我们在提速度，但没有降低防线"，多数组织都会放行。
Q4. Vibe coding 与传统的"AI 辅助编码"（Copilot 等）有什么不同？
区别在于 谁在驾驶座。Copilot 是"结对编程"模式——人在写，AI 在补全。vibe coding 是 AI 主导，人类只负责对话与确认。边界本身比较模糊，现实中很多开发者会在两者之间反复切换。
Q5. 应该从哪个工具开始？
个人开发或学习，试试 Lovable、Bolt.new 或 v0（只用浏览器就行，无需安装）。认真做软件开发，则试试 Claude Code 或 Cursor——Claude Code 是 CLI，Cursor 是 IDE 一体化，按喜好选。Karpathy 本人偏爱 Cursor Composer。
Q6. AI 写出来的代码，著作权归属如何？
截至 2026 年 5 月，美国和日本的基本立场都是 "完全由 AI 生成的代码不受著作权保护"。经过人工实质性修改或挑选的代码可以成为可保护对象。商用层面更容易出问题的其实是 许可证污染——AI 把 GPL 等带许可的代码再次输出到你的代码库里——所以建议在 CI 里加一个许可证检查器。
Q7. Vibe coding 会"抢走工程师的工作"吗？
"只会写代码的工程师"的市场单价在向下走。另一方面，规格设计、架构决策、安全与生产运维这些技能的价值，反而 因为 vibe coding 的普及而上升。能"读懂、判断、修复"AI 大量产出的代码的人，截至 2026 年正处于供不应求的状态。
