2025 年 2 月 2 日，Andrej Karpathy 发了一条推文。不到一个月，Merriam-Webster 词典收录了这个新词。不到一年，71% 的开发者尝试过，58% 的团队将其纳入日常工作流。
这场 AI 编程革命到底在说什么？本文从起源出发，系统拆解 Vibe Coding 的底层原理。
一、一个词，改变编程的定义
2025 年 2 月 2 日，OpenAI 联合创始人、前 Tesla AI 负责人 Andrej Karpathy 在 X（Twitter）上写道：
"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."
"有一种新的编程方式，我称之为 vibe coding------你完全交给感觉，拥抱指数增长，甚至忘记代码的存在。"
他描述了自己的工作流：用 Cursor Composer + SuperWhisper 语音输入，用自然语言描述需求，AI 生成代码。他说："我只是看、说、运行、复制粘贴，大部分时候它能跑。"他坦诚代码长得"超出了自己的理解范围"，修 bug 的方式是"把报错丢回去，或者做些随机的改动直到问题消失"。
这条推文引爆了整个技术圈。 27,000+ 点赞。一周之内，"15 条 Vibe Coding 规则"的帖子又收到 10,000+ 点赞。2 月 13 日，《Business Insider》首次主流媒体报道。2 月 27 日，《纽约时报》跟进。3 月 1 日------距离那条推文不到一个月------Merriam-Webster 词典正式收录 "vibe coding" 为俚语。 年底，Collins 词典将其列为年度词汇候选。
这在语言史上是极罕见的：一个技术术语，从被创造到进词典，不到 30 天。
为什么这么快？
因为 Karpathy 命名了一个已经广泛存在但尚未被定义的行为 。Replit CEO Amjad Masad 在数小时内回应：Replit 上约 75% 的用户已经在这样编程 。2025 年 3 月，Y Combinator 报告其 Winter 2025 批次中 25% 的创业公司代码库 95% 由 AI 生成。
Karpathy 不是在发明新东西，他是在给一场已经在发生的革命命名。
二、三层理解：Vibe Coding 到底是什么？
Vibe Coding 在不同语境下有不同的含义。理解这三层，才能真正把握它的全貌。
第一层：字面理解（新手视角）
"用自然语言描述需求，AI 生成代码，不深究代码细节，能跑就行。"
这是 Karpathy 原始推文最直接的含义，也是最常被人误解的层面。他强调这适合**"扔掉的周末项目"**（throwaway weekend projects）------不是生产级代码。
这一层的核心转变是：从"人写代码"到"人描述意图，AI 实现细节"。编程的门槛从"掌握编程语言"降到了"能用自然语言清晰表达需求"。
第二层：工程实践（专业视角）
"Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行"
这是 Vibe Coding 从"玩具"走向"工具"的关键演化。在这一层，Vibe Coding 不再意味着"放弃对代码的理解"，而是重新定义人与 AI 的分工：
- 人的角色：意图架构师 + 审查者。你负责定义"做什么"、"为什么做"、"做到什么标准"。
- AI 的角色：执行者。负责"怎么做"------生成代码、运行测试、格式化输出。
这一层的核心方法论包括 胶水编程、[Spec-Driven Development](#Spec-Driven Development "#")、[Context Engineering](#Context Engineering "#") 等，将在中篇和下篇详细展开。
第三层：范式转移（行业视角）
"AI 原生研发范式：从'代码中心'到'文档驱动'的演进"
在这一层，Vibe Coding 代表的不仅仅是"让 AI 写代码"，而是软件工程 "真相来源"的迁移：
- 传统范式 ：需求文档 → 人写代码 → 代码即真相（代码是最终的事实来源）
- AI 原生范式 ：需求文档 → 规范（Spec）→ AI 生成代码 → 规范才是真相，代码只是规范的产物
这意味着 .md 文件（Markdown 规范文档）的地位被提升到了前所未有的高度。圈内有一个精妙的说法：.md 不再是 "Markdown Document"，而是 "Machine Done" --- Human Designed, Machine Done。
这三个层次不是互斥的，而是递进的。你可以停留在第一层做原型探索，也可以在第三层用 SDD 管理生产级项目。
三、五条核心命题：Vibe Coding 的底层原理
这些命题来自 tradecatlabs/vibe-coding-cn 指南。它们构成了 Vibe Coding 的"第一性原理"。
命题 1：生成域
LLM 的能力边界，是其生成物能够直接或间接实现、驱动、约束、修改、验证或影响的范围。生成物可达，即模型能力可达。
白话：AI 能稳定生成什么、不能稳定生成什么------这是你的"技能范围"。在这个范围内，你是超人；超出这个范围，你需要自己填补。
实例：AI 能稳定生成一段对话、纠正语法错误、出填空题------这些在生成域内。但你不能指望 AI "设计一个符合教学大纲的完整课程体系"------那超出了单个生成的能力边界，需要人类做架构层面的拆解。
命题 2：模型吞噬
模型能力会持续吞噬一切可被吞噬的中间层。凡是因模型能力不足而存在、且可被吞噬的工程补丁，都会被更强模型吞噬。
白话：今天你辛辛苦苦设计的 Prompt Chain、Agent 编排框架、多步推理工作流------明天可能就是模型的一个内置能力。不要在这些"补丁"上过度投资。
实例 ：2023 年需要 Chain-of-Thought prompting 才能让模型做多步推理。2024 年模型自己就会了。2025 年需要手写 Function Calling 编排。2026 年可能就是模型的标准能力。把你的精力放在模型吞不掉的东西上：业务理解、架构设计、质量审查。
命题 3：隔离审查
AI 生成结果只是候选解，不是已验证事实；必须新开隔离会话独立审查，用事实、测试和可追溯证据裁决。
白话 ：产生代码的上下文，绝不能是审查代码的上下文。 让同一个 AI 在同一个会话里审查自己刚生成的代码，等于让嫌犯当自己的法官。
实例 ：AI 生成的代码通过了。你应该用另一个会话 （甚至另一个模型）来审查它。这个审查者只看到代码和 Spec，看不到生成过程，它的判断更客观。更理想的做法是：测试、类型检查、lint 作为硬门禁------这些都是确定性的，AI 无法绕过。
命题 4：能力编排
AI 编程的高阶形态不是从零生成代码，而是反向搜索成熟工具链与仓库，把已有能力编排成可验证的业务系统。能复用时不重造，能编排时不发明。
白话：你不是在造零件，你是在拼乐高。你的工作是找到最好的零件（成熟的开源组件），然后写"胶水代码"把它们粘起来。
实例：做语音输入功能------
- ❌ "帮我写一个语音识别模块"（造轮子）
- ✅ "调研 Web Speech API 的兼容性和最佳实践，用
useSpeechhook 封装，接入现有 ChatArea 组件"（胶水编程）
命题 5：上下文质量 > Prompt 质量
在 9,649 次对照实验中，上下文质量对输出质量的预测力强于 Prompt 质量。在 20 步的 Agent 会话中，坏的上下文会复利式恶化。
白话 ：给 AI 看什么，比怎么问更重要。 一个精心设计的 CLAUDE.md，比十个精妙的 Prompt 都管用------因为 CLAUDE.md 在每个会话中都存在，Prompt 只在一次对话中有效。
四、道·法·术·器：Vibe Coding 的四层框架
tradecatlabs 的指南用中国传统哲学的"道法术器"框架来组织 Vibe Coding 的知识体系，这是一个很有启发性的视角。
| 层次 | 含义 | 核心问题 | 你的实践 |
|---|---|---|---|
| 道 | 人与 AI 的协作关系、责任边界、可靠性来源 | 谁对最终质量负责？ | 你是架构师 + 审查者，AI 是执行者。最终责任在你，不在 AI。 |
| 法 | 把问题抽象成目标、对象、约束、路径和验证标准 | 怎么把模糊需求变成清晰指令？ | 写 Spec 文档，定义数据契约（Zod/TypeScript），设定质量门禁。 |
| 术 | 把抽象方法落成流程、文档、门禁和迭代动作 | 具体按什么步骤操作？ | RIPER 工作流、ISPI 四层模型、能力编排七步法。 |
| 器 | 用工具承载读写文件、执行命令、运行测试和交付结果 | 用什么工具落地？ | Claude Code / Cursor、CLAUDE.md、Skills、Hooks、GitHub Spec Kit。 |
这个框架的美妙之处在于它的层次性：上层决定方向，下层决定效率。
- 道错了，再好的工具也是南辕北辙（比如让 AI 做最终决策，人只负责"提出需求"）
- 法缺了，AI 就会自由发挥，代码变成不可控的"屎山"（没有 Spec 约束的生成 = 无限膨胀）
- 术乱了，效率急剧下降（没有工作流 = 每次都从零开始）
- 器不配，好的方法无法落地（用错了工具，事半功倍）
五、适用边界：什么能做，什么不能做
Karpathy 的原话就说这是"扔掉的周末项目"的工具。但随着方法论和工具链的成熟，Vibe Coding 的边界在不断扩展。2026 年的共识是：
✅ 高 ROI 场景
| 场景 | 效率提升 | 为什么 |
|---|---|---|
| MVP 原型 | 天 → 小时 | 原型核心是"能跑"，不是"完美" |
| 内部工具 / 管理后台 | 周 → 天 | 用户规模小，出错影响可控 |
| 前端组件、表单、布局 | 小时 → 分钟 | 模式固定，AI 生成质量高 |
| 重构、脚手架、迁移 | 显著加速 | 重复性高，AI 比人快得多 |
| 个人项目、一次性脚本 | 极高效率 | 维护周期短或不存在 |
⛔ 需要谨慎 / 避免的场景
| 场景 | 原因 |
|---|---|
| 支付/交易核心系统 | 一个 bug 的代价是真实的金钱 |
| 用户认证/权限边界 | AI 最容易忽略安全漏洞 |
| 性能优化（找瓶颈） | 需要测量 + 人类判断，不是写代码 |
| 分布式系统架构 | "You can't vibe code scale" |
| 合规/监管系统 | 需要完整审计链，AI 无法提供 |
| AI 生成代码的长期维护 | GitClear 预计 2027 年全球 AI 代码累积 $1.5 万亿技术债务 |
黄金法则
AI 生成你的产品差异化代码（你最独特的部分）； 用久经考验的基础设施（Supabase、Auth0、Appwrite 等）处理认证、数据库、存储------ 这些地方的错误成本由用户承担。
六、2025-2026 关键数据
- Stack Overflow 2025 调查：71% 开发者尝试过 Vibe Coding，58% 团队已纳入日常
- Y Combinator W25：25% 创业公司代码库 95%+ AI 生成
- GitHub Octoverse 2025：有结构化 Vibe Coding 规则的团队交付速度快 57%
- 原型开发时间：从 2-3 天降至 4-6 小时
- 新框架上手时间：从 ~1 周降至 一个下午
- Veracode 2025：AI 生成代码中 45% 包含安全漏洞
- 15 个测试应用中发现了 69 个安全漏洞
- GitClear 预测：到 2027 年全球 AI 生成代码累积 $1.5T 技术债务
总结
Vibe Coding 不是魔法，也不是骗局。它是 AI 能力发展到一定阶段后，软件工程自然演化出的新范式：
- Karpathy 定义了起点：用自然语言编程，拥抱 AI 的生成能力
- 社区构建了体系：五条命题给出底层原理，"道法术器"给出组织框架
- 边界决定了成败：知道什么能做、什么不能做，比掌握任何技巧都重要