Vibe Coding：与AI共舞的编程新范式
本章要点
走过了前面四章，你已经能熟练地让 AI 帮你写代码、解释代码、调试代码，也理解了它背后的基本原理。这时你可能会发现，自己写代码的姿势悄悄发生了变化——你不再像从前那样，一行一行地敲下每个字符，而是越来越多地用自然语言"指挥"AI 完成任务，再凭着感觉判断结果是否合用。
这种新的编程姿势，在 2025 年初被一位重量级人物正式命名为 Vibe Coding。它不只是一个流行词，而是一种正在重塑整个软件开发行业的范式。这一节，我们就来认真聊聊：什么是 Vibe Coding？它从何而来？我们这些初学者，又该如何看待和使用它？
读完这一节，你会获得：
- 理解 Vibe Coding 的来历，以及它为什么会在 2025 年突然席卷整个行业
- 看清 Vibe Coding 与传统编程的根本差异，知道两者的"心智模型"分别是什么
- 学会判断哪些场景适合 Vibe Coding，哪些场景应当谨慎使用
- 认识 Vibe Coding 的甜蜜与陷阱，为后面学习 SDD、TDD 等更严谨的方法论铺垫
一切从 Karpathy 的一条推文说起
2025 年 2 月，前 OpenAI 创始团队成员、特斯拉前 AI 总监 Andrej Karpathy 在社交平台上发了一条不长的帖子，大意是这样的：
"有一种全新的编程方式正在兴起，我管它叫 Vibe Coding。你完全沉浸在'氛围'里，拥抱指数级增长的能力，甚至忘记代码本身的存在。"
他描述的场景非常生活化——他打开一个 AI 编程工具，对着语音输入说出自己的想法，让 AI 把代码写出来。如果跑不起来，他不去读错误信息，而是把错误原封不动地丢回给 AI，让 AI 自己想办法解决。如果还不行，再换个说法。整个过程中，他几乎不看代码本身，而是看 AI 跑出来的结果对不对。
这段描述当时引起了轩然大波。一部分人欢呼："这就是未来！"另一部分人则忧心忡忡："这就是未来吗？"
无论你站在哪一边，有一件事是确凿的：Vibe Coding 这个词，从那天起，就成了整个 AI 编程时代最具代表性的标签。
Vibe Coding 到底是什么意思
"Vibe" 这个词在英文里有点难翻译。它不是"氛围"那么客观，也不只是"感觉"那么个人，更像是某种你和环境之间共同营造出来的、说不清道不明却又真实存在的"调子"。当我们说一家咖啡馆 vibe 不错时，意思是它的灯光、音乐、椅子的高度、店员的语气，恰好凑成了让你想坐下来的那种感觉。
把这个词放到编程里，意思就变得有趣起来。Vibe Coding 不再强调"我精确地告诉计算机做什么"，而是强调"我和 AI 共同维持一种创作的氛围"。你说一个想法，AI 给一段代码；你看一眼结果，再说下一个想法；AI 又改一改。你们之间的对话，就像两个音乐人在即兴 jam——没有完整的乐谱，全凭感觉推进，但最后真的能合奏出一首曲子。
更形象一点说，传统的编程像是写论文：你要先想清楚论点、列好提纲、推敲每一句话。而 Vibe Coding 更像是聊天：你抛出一个念头，让对方接住，再根据对方的回应继续往下聊。
Vibe Coding 与传统编程的根本差异
要理解 Vibe Coding 为什么会被视为一种"新范式"，我们得把它和传统编程方式认真比一比。这种比较不是为了分高下，而是帮你看清楚：当你在 Vibe Coding 的时候，你的"心智模型"已经悄悄从一种切换到了另一种。
控制粒度的差异
传统编程时，你的控制粒度细到每一个字符。变量该叫什么名字、循环该用 for 还是 while、判断条件该写在哪一行——这些都是你亲手做出的决定。代码是你思维的直接产物，每一行都对应着你脑子里的某个想法。
而 Vibe Coding 的控制粒度，是"意图"。你告诉 AI："给我写一个能从 CSV 文件读取数据，按某一列分组求平均值，然后画成柱状图的脚本"。至于这个脚本里用了哪个库、变量怎么命名、循环怎么写，你可能根本不关心。你关心的是结果对不对，图好不好看。
这种粒度上的转变，意味着你和代码的关系发生了根本变化。从前你是代码的"作者"，现在你更像是代码的"导演"——你不亲自演每一个角色，但你决定整部戏要怎么走。
容错方式的差异
传统编程对错误的态度是"立即修复"。一行报错，你停下来，读错误信息，定位问题，修改代码，再次运行。这是一种线性的、基于理解的纠错方式。
Vibe Coding 对错误的态度则要宽容得多——更准确地说，是"懒"得多。错了就让 AI 再试一次。再错了就换个说法。再不行就重新生成一遍。Karpathy 在那条帖子里有一个很有意思的描述："我有时候根本看不懂代码做了什么，但只要它能跑、跑出来对，我就接受它。"
这种"试错驱动"的方式听起来不太严谨，但你会发现它在很多场景下意外地高效——尤其是当任务本身规模不大、你只是想快速验证某个想法的时候。
知识结构的差异
传统编程要求你建立完整的知识体系。要写 React，你得理解组件、状态、生命周期、虚拟 DOM。要写后端，你得理解 HTTP、数据库、并发、缓存。这些知识就像建房子的砖，少一块都可能塌。
Vibe Coding 不要求你掌握所有的砖，它要求你拥有"感觉"。你不一定要懂 React 的内部原理，但你要能看出"这个按钮的位置怪怪的"；你不一定要懂数据库的索引机制，但你要能察觉"怎么查个数据要等这么久"。Vibe Coding 时代的开发者，需要的是更敏锐的产品感、审美感、用户感，而不是更厚的技术手册。
这并不意味着技术知识不再重要——恰恰相反，等到 Vibe Coding 出问题的那一刻，技术知识就成了你的救命稻草。但在很多日常场景中，知识的角色确实从"必备品"变成了"备用品"。
蜜月期与回归理性：Vibe Coding 的两面
Vibe Coding 在 2025 年上半年掀起了巨大的热潮。无数人晒出自己用 AI"几个小时做出一个 SaaS 产品"的截图，独立开发者们感叹"过去要一周的活儿现在一个下午就搞定了"。一时间，仿佛人人都能成为程序员，软件开发的门槛被前所未有地拉低。
但很快，质疑的声音也来了。
到了 2025 年下半年，连 Karpathy 自己都开始在公开访谈中重新审视这个由他命名的范式。他直言："Vibe Coding 的蜜月期已经过去了。"他注意到，越来越多用 Vibe Coding 写出来的代码库，在规模稍大之后就变得难以维护——AI 在不同时间生成的代码风格不一致，潜藏的 bug 在用户量上来后集中爆发，而最棘手的是：没有人真正理解代码做了什么。
这其实是 Vibe Coding 的固有悖论：你越是依赖"感觉"，就越容易在感觉失灵的那一刻无所适从。当一个 bug 藏在 AI 生成的几千行代码里，而你从未仔细读过其中任何一行时，你怎么调试？当一个性能问题需要重构整套架构时，你连架构是什么样都说不清，又如何重构？
哪些场景适合 Vibe Coding
理解了它的两面性，我们就能更清醒地判断 Vibe Coding 的适用边界。它特别适合那些"小而快"的场景：
写一个一次性使用的脚本，比如把某个文件夹里的图片批量改名；做一个周末玩具项目，自己用用就好，不需要长期维护；快速搭一个原型给团队看效果，证明某个想法可行；在学习某个新技术时探索性地试一试，看看它大概是怎么用的。在这些场景里，代码的"寿命"很短，"感觉对"远比"代码完美"重要。Vibe Coding 让你能用最小的心力，达成最快的产出。
哪些场景需要谨慎使用
而当代码需要长期存在、被多人协作、承担真实业务责任时，纯粹的 Vibe Coding 就开始显露出它的局限：
如果你在做一个会被真实用户使用的产品，每一个隐藏的 bug 都可能变成客诉；如果你在和团队协作开发，没人能读懂的"vibe 代码"会变成同事的噩梦；如果你在写需要保证安全性的代码，凭感觉可能漏掉关键的边界检查；如果你在做一个会运行很多年的系统，今天的"快"会变成明天的"债"。
在这些场景下，光靠 vibe 是不够的。你需要更严谨的方法论——这正是我们后面两节要讲的 SDD（规范驱动开发） 和 TDD（测试驱动开发） 的用武之地。它们不是要你放弃和 AI 协作，而是要你在协作中加入更多的"约束"和"验证"，让 AI 不只是"猜对你的意思"，而是"按图施工、有据可查"。
给初学者的 Vibe Coding 建议
读到这里，你可能会有点犹豫：作为一个 AI 编程的初学者，我到底该不该 Vibe Coding？
我的建议是——该，但要带着自觉地 vibe。
你应当大方地享受 Vibe Coding 带来的乐趣和效率。它是降低编程门槛、让更多人参与创造的伟大力量。当你想到一个点子，能在一两个小时内做出可运行的东西，这种正反馈对学习者来说太宝贵了。不要因为它"不严谨"就拒绝它，那等于把入门的台阶又抬高了。
但与此同时，你要时常停下来问自己几个问题：
- 这段代码我大概理解它在做什么吗？ 不需要每行都懂，但起码要能说出"它从哪里读数据，做了什么处理，输出到哪里去"。
- 如果它出问题了，我有头绪从哪开始查吗？ 如果完全没有，说明你对这段代码的依赖度已经超出了 Vibe Coding 的安全边界。
- 这段代码是会被丢掉的，还是会一直跑下去？ 前者尽情 vibe，后者要补上规范和测试。
带着这些问题去 Vibe Coding，你就不会迷失在"感觉"里。你会发现自己慢慢形成了一种节奏：在轻量场景里 vibe 得飞起，在严肃场景里切换到更严谨的模式。这种"节奏感"，正是我们整个第五章想要帮你建立的能力。
小结
这一节，我们认识了 2025 年由 Karpathy 提出、并迅速席卷整个行业的新范式——Vibe Coding。
它的核心是一种心智模型的转变：从"亲手书写每一行代码"转变为"与 AI 共同维持创作的氛围"。在这种模式下，你的控制粒度从字符变成了意图，你的容错方式从理解修复变成了试错迭代，你需要的能力从扎实的技术细节变成了敏锐的产品感觉。
它带来了真实的好处：极大地降低了编程门槛，加速了原型与小工具的开发，让"想到就能做到"变得前所未有地容易。
它也带来了真实的代价：当代码规模变大、生命周期变长时，"vibe 代码"很容易变成无法理解、无法维护、无法信任的技术债。
理解这种甜蜜与陷阱并存的两面性，是这一章最重要的认知。我们既不该把 Vibe Coding 神化，也不该一味贬低它，而是要学会因地制宜地使用它——在合适的场景里大胆 vibe，在不合适的场景里换上更严谨的方法论。
下一节，我们就来认识其中最重要的一种严谨方法论：SDD（规范驱动开发）。它会告诉你，当你不能仅仅依赖"感觉"时，怎样让 AI 按图施工、把代码做得既准确又可控。
练习
思考题 1：复盘你最近的一次 AI 编程经历
回想最近一次你让 AI 帮你写代码的经历，问自己几个问题：
- 你给 AI 的"指令"是清晰的需求，还是一种模糊的"感觉"？
- 你有没有仔细阅读 AI 生成的代码？还是直接复制运行？
- 如果代码出错了，你是去理解代码，还是直接把错误丢回给 AI？
把答案对照本节内容，看看你当时究竟在哪种"模式"里。
思考题 2：判断场景适用性
下面几个场景，你认为哪些适合纯粹的 Vibe Coding，哪些应当更谨慎？为什么？
- 给老板做一个数据可视化的 demo，下周开会用一次就丢
- 重构公司核心订单系统的支付模块
- 给自己写一个监控钓鱼邮件的小工具，自用
- 给一个已有 5000 用户的 SaaS 产品加新功能
- 学习一个新框架时，照着官方教程改改示例代码
实践题 3：体验心智切换
挑一个小任务（比如"写一个能统计某个文件夹下所有 Markdown 文件字数的脚本"），用两种方式各做一遍：
- Vibe 模式：直接对 AI 描述需求，不看生成的代码细节，只验证结果
- 传统模式：自己一行一行写，遇到不会的查文档
记录下两种方式的耗时、心情、最终代码的质量，体会它们的差异。
讨论题 4：AI 时代，"会编程"意味着什么
如果 Vibe Coding 真的能让任何人通过自然语言写出能跑的代码，那么"会编程"这个能力还重要吗？我们这些学习者，应当把精力投在哪里？
不必急着回答。带着这个问题继续读后面的章节，看看你的答案会不会发生变化。