大家好，我是陈嘻嘻。

2025年2月，OpenAI联合创始人、前Tesla AI负责人Andrej Karpathy发了一条推文，随手创造了一个词——Vibe Coding。谁也没想到，这条”随手一发”的推文，在一年后成为了Collins词典的2025年度词汇，彻底改变了人们对”写代码”这件事的认知。

今天这篇文章，我综合了10篇国外优质资料（Wikipedia、MIT Technology Review、Zapier、InfoWorld等），帮你系统地搞清楚：Vibe Coding到底是什么、怎么上手、有哪些坑、未来会走向何方。

一、什么是Vibe Coding？

1.1 起源：一条改变行业的推文

2025年2月2日，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. I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”

翻译过来就是：**”完全跟着感觉走，拥抱指数级增长，忘掉代码的存在。我只是看东西、说东西、跑东西、复制粘贴东西，然后它大多数时候就能工作。”**

图：Andrej Karpathy，Vibe Coding概念的提出者，OpenAI联合创始人，前Tesla AI负责人。他那条”随手一发”的推文定义了一个时代。

坦率讲，这条推文的口气有点”凡尔赛”——毕竟Karpathy本人是斯坦福CS231n课程的创始讲师、深度学习领域的顶级研究者。但正因为他精准地捕捉到了行业趋势，这个词一夜爆红。到了2025年11月，Collins词典宣布”Vibe Coding”为年度词汇，Merriam-Webster也将其列为热门俚语。

1.2 定义：到底什么算Vibe Coding？

根据Wikipedia和MIT Technology Review的综合定义，Vibe Coding有三个核心特征：

1. 用自然语言描述需求：你告诉AI”我要一个记账App”，而不是自己写function calculateTotal()
2. 接受AI生成的代码，不逐行审查：关键区别在这里——如果你用AI生成代码但仔细审查了每一行，那叫”用AI当打字助手”，不叫Vibe Coding
3. 通过迭代对话改进：遇到bug就把错误信息丢给AI，让它自己修

程序员Simon Willison说得很到位：

“If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding — that’s using an LLM as a typing assistant.”

如果LLM写了你的每一行代码，但你审查、测试并理解了所有代码，那不叫Vibe Coding——那叫用LLM当打字助手。”

简单来说，Vibe Coding的精髓就是：把方向盘交给AI，你只负责说”往左拐””开快点””停车”。

1.3 它和传统AI辅助编程有什么区别？

二、Vibe Coding的核心工作流

根据vibecoding.app和Zapier的教程，Vibe Coding的工作流程可以概括为7个步骤：

描述想法 → 选择工具 → 写提示词 → 生成初版 → 迭代优化 → 完善功能 → 部署上线

下面是一个更详细的工作流视图：

┌─────────────┐     ┌─────────────┐     ┌─────────────┐│  1. 规划阶段  │────▶│  2. 构建阶段  │────▶│  3. 发布阶段  │└─────────────┘     └─────────────┘     └─────────────┘      │                    │                    │  ┌───┴───┐           ┌───┴───┐           ┌───┴───┐  │写PRD   │           │写提示词 │           │测试    │  │画线框图 │           │生成代码 │           │部署    │  │选工具   │           │迭代修改 │           │收集反馈 │  └───────┘           │频繁测试 │           └───────┘                      └───────┘

2.1 80%法则

这是一个关键认知：AI生成的第一版代码，大约80%是对的，20%需要你来调整。

不要指望一个提示词就能得到完美的应用。第一版是起点，不是终点。真正的魔法发生在迭代过程中。

2.2 小提示词胜过大提示词

这是所有教程都强调的核心原则。不要这样写：

❌ “页头太大了，按钮颜色不对，间距有问题，我想要侧边栏在左边不是右边，还要加搜索栏和响应式设计”

而应该一步一步来：

✅ “把页头高度缩小一半”

✅ “把按钮颜色改成蓝色”

✅ “把侧边栏移到左边”

每个小提示词更容易被AI正确执行，你也更容易发现问题。

2.3 反馈循环

看结果 → 找到一个要改的点 → 写提示词 → 看结果 → 重复

成功的Vibe Coder通常在一个功能上做10-20次迭代。每次迭代只需要几秒钟，这就是效率所在。

三、工具选择：新手该用什么？

根据Zapier对8款工具的深度测评，以下是按使用场景的推荐：

3.1 工具速查表

3.2 10秒决策指南

3.3 进阶组合拳

很多经验丰富的Vibe Coder会用组合工作流：

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐│ Lovable  │───▶│  GitHub  │───▶│  Cursor  │───▶│  部署上线  ││ 构建UI    │    │ 版本控制   │    │ 调试优化   │    │ Vercel等  │└──────────┘    └──────────┘    └──────────┘    └──────────┘

图：Cursor是基于VS Code的AI原生代码编辑器，支持Agent模式、多模型切换，是Vibe Coding调试优化的最佳选择。

Zapier的测评者说得好：

“All vibe coding tools try to make you forget the code. Cursor is when you remember that it’s actually there.“

“所有Vibe Coding工具都试图让你忘掉代码。Cursor是你想起来代码其实还在那儿的时候用的。”

四、11条最佳实践：从菜鸟到靠谱

综合Zapier和iBuildWith.ai的最佳实践指南，以下是让你的Vibe Coding更靠谱的11条建议：

第一阶段：动手之前

1. 别指望魔法

“Solve small problems. Don’t try to go build it all with one prompt.”（解决小问题，别想着一个提示词搞定一切。）

2. 写PRD（产品需求文档）

在开始Vibe Coding之前，用ChatGPT或Claude先写一份PRD，包括：

• App做什么、给谁用、怎么工作
• 底层技术选型
• 开发里程碑

3. 先画线框图

在脑子里或纸上把用户流程走一遍：用户从哪里进来？点什么按钮？看到什么结果？

4. 像系统架构师一样思考

在iBuildWith.ai的建议中，最重要的一条是：别急着写提示词，先退一步看全局。

示例：做一个习惯追踪器，先画清楚流程——用户认证 → 数据存储 → 习惯追踪逻辑 → 报告UI

第二阶段：搭建基础

5. 设置GitHub版本控制

在东西能工作的时候，马上push到GitHub！ 这是最重要的习惯之一。

6. 配置全局规则

在Cursor中创建.cursorrules文件，给AI设定角色：

“You are a Senior Front-End Developer specializing in React and TypeScript…”

7. 先建数据库

如果你的App需要存数据或用户登录，先把Supabase或Firebase搭好。后面再加数据库功能，体验会非常痛苦。

第三阶段：构建与迭代

8. 分步构建，一次一个功能

三个”不要”：

• 不要同时构建多个功能
• 不要在一个提示词里修多个不相关的bug
• 不要跳步（比如还没写支付组件就先装Stripe）

9. 审查后再接受，频繁测试

“The robots lie, but it’s not on purpose — they just want to make you happy.”

“AI会说谎，但不是故意的——它只是想让你开心。”

预期：每加一个新功能，至少会在另外两个地方引入问题。

10. 给AI提供角色和约束

来自iBuildWith.ai的高级技巧：

• 给AI指定身份：”你是一个专注于安全代码的高级Python后端工程师”
• 设定验收标准：”这个API响应时间要在200ms以内，支持10000 QPS”
• 问”还缺什么？”：”这是我的数据库schema，我可能遗漏了哪些索引或关系？”

11. 知道何时停手，知道何时放弃

“Don’t be afraid to throw work away if you hit a wall and it feels like it’s spiraling.” — Andy Keil

“如果撞墙了、感觉在打转，别怕扔掉重来。”

五、争议与反思：Vibe Coding是骗局吗？

5.1 来自企业界的警告

在Medium的一篇引发广泛讨论的文章《Was Vibe Coding a Ruse?》（Vibe Coding是不是一场骗局？）中，一位金融科技公司的CTO说了这样一段话：

“Vibe coding is a nightmare and I’m getting ready to ban it. We opened more security holes in 2025 than we did in all of 2020 to 2024. It’s a miracle we haven’t been breached yet.”

“Vibe Coding是一场噩梦，我准备禁止它了。2025年我们制造的安全漏洞比2020到2024年加起来都多。没被黑客攻破简直是个奇迹。”

文章作者Joe Procopio指出一个犀利的观点：Vibe Coding的热炒背后，可能夹带着一个商业叙事——

“如果AI能让任何人写代码，那我们到底还需要多少昂贵的程序员？”

5.2 数据说话：AI代码质量堪忧

图：安全问题是Vibe Coding面临的最大挑战。多项研究显示AI生成的代码在安全漏洞和逻辑错误方面显著高于人类代码。

来自Wikipedia词条引用的多项研究数据：

5.3 一个真实的翻车故事

MIT Technology Review讲了一个典型案例：一个叫Leo的用户在X上炫耀自己完全用Cursor构建了一个SaaS应用。结果帖子一发，就被一群黑客盯上了，两天后他发帖求助：

“Guys, I’m under attack. I’m not technical, so this is taking me longer than usual to figure out.”

“各位，我被攻击了。我不懂技术，所以解决起来比平常慢得多。”

5.4 Andrew Ng的不满

AI领域的另一位大佬Andrew Ng对”Vibe Coding”这个名字本身就很不满意：

它误导人们以为软件工程师在用AI工具时只是”跟着感觉走”，而实际上这是一项非常累的工作。

5.5 对开源生态的冲击

2026年1月，一篇题为**”Vibe Coding Kills Open Source”**的学术论文引发关注。核心论点：

• LLM倾向于推荐大型、主流的库，挤压了新生开源项目的生存空间
• Vibe Coder不会提交bug报告，不会参与社区互动
• 开源维护者的回报机制（声誉、工作机会、社区认同）被削弱

连Linux之父Linus Torvalds也在2026年1月承认自己用了Vibe Coding来写一个音频工具的Python可视化组件——但注意，他只是用来写一个小工具，而非Linux内核。

5.6 公允的评价

说了这么多问题，坦率讲，Vibe Coding确实有它的价值：

• 原型开发：几小时做出过去需要几周的原型
• 降低门槛：让非程序员也能把想法变成可运行的软件
• 创意探索：快速验证一个idea是否值得投入

关键在于认清边界：Vibe Coding ≈ 快速原型工具 ≠ 生产级软件开发方案。

六、未来展望：进化而非革命

6.1 专家怎么看？

InfoWorld采访了大量技术领袖，观点汇总如下：

乐观派：

“I don’t think vibe coding is the end of software development any more than the compiler, high-level languages, or the virtual machine were.”

“我不认为Vibe Coding是软件开发的终结，就像编译器、高级语言、虚拟机都不是一样。”— Nic Benders, New Relic首席技术策略师

“Vibe coding is just another abstraction to a higher order… the volume of development work did not go down; it increased significantly, but the nature of the job changed.”

“Vibe Coding只是又一层更高阶的抽象……开发工作量不会减少，只会增加，但工作的性质会改变。”— Bharat Guruprakash, Algolia首席产品官

谨慎派：

“Treat vibe coding like working with a junior developer, with code reviews, scoped permissions, and tight loops.”

“把Vibe Coding当作跟初级开发者合作——需要代码审查、权限控制和紧密的反馈循环。”— Rob Whiteley, Coder CEO

6.2 未来的方向：混合模式

The Conversation的科学家视角提供了一个有意思的类比：Vibe Coding就像当年的WYSIWYG编辑器和拖拽式网站构建器——它们没有取代专业的Web开发，但确实让更多人能够创建自己的网站。

最可能的未来是一种混合开发模式，两者各司其职：

Zapier文章中提到的Sutro创始人Tomas Halgas有一个特别好的思路：

未来可能是将应用拆解为隔离的模块，在每个模块内部Vibe Code，模块之间用安全的连接方式对接。 如果某个API有问题，直接拆掉换一个，不会影响你的前端页面。

这种”模块化Vibe Coding”的思路，个人以为是最有可能落地的方向。

七、30天学习路线图

如果你认真想学Vibe Coding，这是一个务实的30天计划（来自vibecoding.app）：

第1周：入门

重点：熟悉提示词写法和迭代节奏。

第2周：进阶

• 尝试Cursor（如果还没试过）
• 查看AI生成的代码，理解它做了什么
• 用文件引用（@filename）来精确控制提示词
• 把第1周的项目用更精确的方式重做一遍

重点：开始理解代码，建立直觉。

第3周：发布

• 选择你最好的项目
• 打磨到你觉得拿得出手
• 部署上线（Replit一键部署或Vercel）
• 分享给真实用户，收集反馈

重点：完成、部署、获取反馈。

第4周：实战

• 做一个解决真实问题的工具
• 考虑加入用户认证
• 尝试连接API或数据库
• 根据实际使用情况添加功能

重点：真实场景、复杂度管理、技能成长。

30天后，大多数人可以做出看起来和用起来都像真实产品的应用。你不会成为专家，但你会变得有能力。

五个关键要点总结

1. Vibe Coding是真实的趋势：不是噱头，但也不是魔法。它是AI辅助编程的自然演化。

2. 80%法则：第一版80%能用，剩下20%靠迭代。小步快跑，一次只改一件事。

3. 工具选择很重要：零基础用Lovable，有编程基础用Cursor，想最快上线用Bolt.new。

4. 安全是最大软肋：约45%的AI生成代码包含安全漏洞。个人项目随便玩，涉及用户数据务必人工审查。

5. 混合模式是未来：Vibe Coding做原型和探索，传统工程做生产和安全。两者结合，而非替代。

参考资料

我是陈嘻嘻，一只职场海洋里摸爬滚打的牛马。

如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。

有问题欢迎在评论区交流。

下篇见！