2.3 Vibe Coding：跟着 AI 感觉走
小张上个月做了一个原型，产品经理看了说"这不是我想要的"。三天白费了。如果先用 Vibe Coding 做 2 小时原型让产品经理确认，就不会浪费那三天。
"先跑起来再说"——这就是小张的信条。但"轻松"背后，藏着一些你需要知道的陷阱。
❌ 不了解 Vibe Coding vs ✅ 会用 Vibe Coding
❌ 不了解 Vibe Coding 的代价
产品需求不明确时，花 2 周写代码 → 产品经理说"不对" → 全部推翻重来。2 周白费。
✅ 会用 Vibe Coding 的方式
花 2 小时用 AI 出原型 → 产品经理说"不对" → 调整需求 → 只损失 2 小时。
但注意：验证完后需要切换到更严谨的方式，否则 3 个月后会遇到"三月之墙"。
Vibe Coding 的诞生
2025 年 2 月 2 日，Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 总监）在 X 上发了一条推文：
"有一种新的编程方式，我称之为 'vibe coding'，你完全顺从直觉和氛围，拥抱指数级增长，甚至忘记代码的存在。"
Karpathy 自己描述他的工作方式：
"I just write something, run it, check the error, and say 'fix it' to the AI. I barely read the code."
"我只是写点什么，运行它，检查错误，然后对 AI 说'修复它'。我几乎不读代码。"
小张的实际操作
让我们看小张构建一个 Todo 应用的完整 Vibe Coding 过程：
第一步：初始提示
小张: "帮我创建一个 React todo 应用，支持添加、删除、标记完成，用 TypeScript"AI 几秒钟生成了：
├── src/App.tsx (主组件)
├── src/components/TodoItem.tsx
├── src/components/TodoList.tsx
├── src/hooks/useTodos.ts (状态管理)
├── src/types/todo.ts (类型定义)第二步：运行测试
小张: "npm run dev"第三步：发现问题
小张: "删除功能不工作，点击按钮后没有任何反应"AI 检查发现 TodoItem.tsx 的 onClick 缺少 handleDelete 绑定，自动修复。
第四步：继续迭代
小张: "请添加本地存储持久化，刷新后数据不丢失"
小张: "请添加过滤功能（全部/已完成/未完成）"
小张: "请添加编辑功能，双击可以修改内容"全程约 2 小时（传统开发预计需要 2-3 天）。
Vibe Coding 的 80/20 法则
Vibe Coding 有一个著名的陷阱——80/20 法则：
🟡 80-95%：开始遇到困难，边缘情况、集成问题
🔴 95-100%：极其痛苦，AI 能力急剧下降。最后一公里可能花 80% 的时间
最后一公里问题包括：
- 边缘情况处理（时区、特殊字符、并发）
- 安全漏洞修复
- 性能优化
- 复杂系统集成
- 合规性要求
谁在用 Vibe Coding？谁在反对？
支持者：
| 人物 | 背景 | 观点 |
|---|---|---|
| Andrej Karpathy | OpenAI 联合创始人 | 提出 Vibe Coding，认为 AI 编程是未来 |
| 非技术创始人 | 普遍 | 用 Lovable、Bolt 等 48 小时出 MVP |
| 内部工具开发者 | 普遍 | 1 周完成原本 1 月的工作 |
批评者：
| 人物 | 背景 | 观点 |
|---|---|---|
| Linus Torvalds | Linux/Git 创始人 | "从维护角度看可能是个糟糕的主意"（2025 年 11 月） |
| Dave Farley | 软件工程专家 | 称 vibe coding 是"2025 年软件工程中最糟糕的想法之一" |
重要澄清：Linus Torvalds 没有使用过 vibe coding。他是传统 C 程序员，全部代码手动编写。他对 AI 编码工具持怀疑态度，强调代码理解和可维护性。
"三月之墙"现象（社区观察）
Vibe Coding 项目有一个社区中广泛讨论的衰退模式（注：这是开发者社区的实践观察，非学术研究结论。Google 工程总监 Addy Osmani 将类似现象总结为"70% 问题"——AI 能让你快速达到 70%，但最后的 30% 需要真正的工程）：
高速度，高产出
修改开始牵一发动全身
AI 无法理解复杂依赖
自己的系统
这就是为什么 Vibe Coding 适合短期探索，但不适合长期生产系统。
Vibe Coding 的工具
| 工具 | 特点 | 适用 |
|---|---|---|
| Cursor | IDE 深度集成，Tab 补全，多文件编辑 | 专业开发者 |
| Claude Code | CLI 工具，强大的 agent 能力 | 命令行用户 |
| Lovable | 全栈应用构建，一键部署 | 快速原型 |
| Bolt | 端到端开发环境 | 快速 MVP |
| v0 (Vercel) | AI UI 生成 | 前端开发 |
从 Vibe Coding 到 Agentic Engineering
2026 年，Karpathy 在 Sequoia AI Ascent 大会上提出新术语 "Agentic Engineering"（代理工程）：
Vibe Coding 是"让 AI 自由发挥"，Agentic Engineering 是"有结构地编排 AI 代理"。
这标志着 vibe coding 正在从自由探索走向工程化。
📌 本节核心要点
| 概念 | 要点 |
|---|---|
| Vibe Coding 定义 | 用自然语言描述需求，AI 生成代码，几乎不看代码 |
| 提出者 | Andrej Karpathy，2025 年 2 月 |
| 80/20 法则 | 前 80% 极快，后 20%（最后一公里）可能花 80% 的时间（社区观察） |
| "三月之墙" | Vibe Coding 项目约 3 个月后可能遇到维护困境（社区观察，非学术研究） |
| 适合场景 | 原型、MVP、个人项目、学习探索 |
| 绝对不适合 | 安全关键系统、大规模生产系统、合规性行业 |
| 演进方向 | 2026 年 Karpathy 提出 "Agentic Engineering"（代理工程） |
知识检查
问题 1：Vibe Coding 的 80/20 法则是什么？最后一公里通常包含哪些问题？
查看答案
法则：Vibe Coding 可以快速完成 80% 的功能，但最后的 20%（让产品真正可用）可能花费 80% 的时间。
最后一公里问题：边缘情况处理（时区、特殊字符）、安全漏洞修复、性能优化、复杂系统集成、合规性要求。
问题 2：Linus Torvalds 对 Vibe Coding 的真实态度是什么？他有没有使用过 Vibe Coding？
查看答案
- 态度：批评者。他说 vibe coding "may be a horrible, horrible idea from a maintenance standpoint"（从维护角度看可能是个糟糕的主意）。但他也认为 vibe coding 对让更多人接触编程是"fairly positive"的。
- 是否使用：没有使用过。他是传统 C 程序员，Linux 和 Git 全部手动编写。
问题 3：什么是"三月之墙"现象？它的四个阶段分别是什么？
查看答案
这是社区中广泛讨论的现象（非学术研究结论），描述 Vibe Coding 项目的可预测衰退模式：
- 兴奋期（第 1-3 月）：快速功能交付，高速度
- 平台期（第 4-9 月）：集成挑战浮现
- 衰退期（第 10-15 月）：新功能需要大量调试
- 停滞期（第 16-18 月）：团队不再理解自己的系统
问题 4：以下哪些项目适合用 Vibe Coding？哪些绝对不适合？
- A. 创业团队 2 周内做 MVP 给投资人看
- B. 银行支付系统升级
- C. 个人学习项目，探索 React 框架
- D. 医院的患者管理系统
查看答案
- A. 适合 — MVP 验证，速度优先
- B. 绝对不适合 — 金融系统，安全关键
- C. 适合 — 个人学习，风险低
- D. 绝对不适合 — 医疗系统，合规要求严格
下一节预告
单独了解了三种方法论后，是时候放在一起对比了。下一节我们把所有方法论排在一条"光谱"上——从最严格到最灵活。