一、一个词，改变编程的定义

2025 年 2 月 2 日，OpenAI 联合创始人、前 Tesla AI 负责人 Andrej Karpathy 在 X（Twitter）上写道：

他描述了自己的工作流：用 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 在不同语境下有不同的含义。理解这三层，才能真正把握它的全貌。

第一层：字面理解（新手视角）

这是 Karpathy 原始推文最直接的含义，也是最常被人误解的层面。他强调这适合**"扔掉的周末项目"**（throwaway weekend projects）——不是生产级代码。

这一层的核心转变是：从"人写代码"到"人描述意图，AI 实现细节"。编程的门槛从"掌握编程语言"降到了"能用自然语言清晰表达需求"。

第二层：工程实践（专业视角）

这是 Vibe Coding 从"玩具"走向"工具"的关键演化。在这一层，Vibe Coding 不再意味着"放弃对代码的理解"，而是重新定义人与 AI 的分工：

• 人的角色：意图架构师 + 审查者。你负责定义"做什么"、"为什么做"、"做到什么标准"。
• AI 的角色：执行者。负责"怎么做"——生成代码、运行测试、格式化输出。

这一层的核心方法论包括 胶水编程、Spec-Driven Development、Context Engineering 等，将在中篇和下篇详细展开。

第三层：范式转移（行业视角）

在这一层，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：生成域

白话：AI 能稳定生成什么、不能稳定生成什么——这是你的"技能范围"。在这个范围内，你是超人；超出这个范围，你需要自己填补。

实例：AI 能稳定生成一段对话、纠正语法错误、出填空题——这些在生成域内。但你不能指望 AI "设计一个符合教学大纲的完整课程体系"——那超出了单个生成的能力边界，需要人类做架构层面的拆解。

命题 2：模型吞噬

白话：今天你辛辛苦苦设计的 Prompt Chain、Agent 编排框架、多步推理工作流——明天可能就是模型的一个内置能力。不要在这些"补丁"上过度投资。

实例：2023 年需要 Chain-of-Thought prompting 才能让模型做多步推理。2024 年模型自己就会了。2025 年需要手写 Function Calling 编排。2026 年可能就是模型的标准能力。把你的精力放在模型吞不掉的东西上：业务理解、架构设计、质量审查。

命题 3：隔离审查

白话：产生代码的上下文，绝不能是审查代码的上下文。 让同一个 AI 在同一个会话里审查自己刚生成的代码，等于让嫌犯当自己的法官。

实例：AI 生成的代码通过了。你应该用另一个会话（甚至另一个模型）来审查它。这个审查者只看到代码和 Spec，看不到生成过程，它的判断更客观。更理想的做法是：测试、类型检查、lint 作为硬门禁——这些都是确定性的，AI 无法绕过。

命题 4：能力编排

白话：你不是在造零件，你是在拼乐高。你的工作是找到最好的零件（成熟的开源组件），然后写"胶水代码"把它们粘起来。

实例：做语音输入功能——

• "帮我写一个语音识别模块"（造轮子）
• "调研 Web Speech API 的兼容性和最佳实践，用 useSpeech hook 封装，接入现有 ChatArea 组件"（胶水编程）

命题 5：上下文质量 > Prompt 质量

白话：给 AI 看什么，比怎么问更重要。 一个精心设计的 CLAUDE.md，比十个精妙的 Prompt 都管用——因为 CLAUDE.md 在每个会话中都存在，Prompt 只在一次对话中有效。

四、道·法·术·器：Vibe Coding 的四层框架

tradecatlabs 的指南用中国传统哲学的"道法术器"框架来组织 Vibe Coding 的知识体系，这是一个很有启发性的视角。

这个框架的美妙之处在于它的层次性：上层决定方向，下层决定效率。

• 道错了，再好的工具也是南辕北辙（比如让 AI 做最终决策，人只负责"提出需求"）
• 法缺了，AI 就会自由发挥，代码变成不可控的"屎山"（没有 Spec 约束的生成 = 无限膨胀）
• 术乱了，效率急剧下降（没有工作流 = 每次都从零开始）
• 器不配，好的方法无法落地（用错了工具，事半功倍）

五、适用边界：什么能做，什么不能做

Karpathy 的原话就说这是"扔掉的周末项目"的工具。但随着方法论和工具链的成熟，Vibe Coding 的边界在不断扩展。2026 年的共识是：

高 ROI 场景

需要谨慎 / 避免的场景

黄金法则

六、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 的生成能力
• 社区构建了体系：五条命题给出底层原理，"道法术器"给出组织框架
• 边界决定了成败：知道什么能做、什么不能做，比掌握任何技巧都重要