最近把 YouTube 上讲 Vibe Coding 最火的几部视频全刷了一遍——Tina Huang 的 Fundamentals、Y Combinator 的实践分享、Fireship 的 MCP 教程、DevForge 的警告片，还有几个具体的实操教程。加起来大概有十几万播放量，评论区也翻了翻。

看完之后最深的感受是：Vibe Coding 真的能让人效率翻倍，但它有一套自己的方法论，不是随便 prompt 两句就完事的。

这篇文章没有废话，直接把共同规律整理出来。

先想清楚再动手，别上来就 prompt

几乎每个博主都在强调这个。Tina Huang 专门花了一整段讲 PRD（Product Requirements Document）——哪怕只是一个给 AI 看的备忘录也好，先把"这个 app 是做什么的、目标用户是谁、核心功能是什么"理清楚，再开始构建。

YC 的 Tom Blomfield 说得更直接：在纯 LLM 环境里先花不合理的时间把项目范围和架构定下来，而不是让 Cursor 或 Windsurf 直接在代码库里自由发挥。方向错了，后面全是返工。

小步快跑，一次只做一件事

这是被提到最多的技巧。

prompt 要短、要专注。Naman 在他的 50 条 tips 里说得特别清楚：不要一次列一整张需求清单，而是分次 prompt，每做完一件，commit，再做下一件。AI 处理单任务的时候效果最好，给它太多东西，它要么漏掉细节，要么开始自由发挥。

Tina Huang 总结的那句话挺有意思：你不是在写代码，你是在用自然语言编程。 所以 prompt 的质量直接决定输出质量。

描述结果，不描述实现

这一点反直觉，但特别重要。

比如你想做一个电商网站，不要说"用 React + Node.js + PostgreSQL 搭建"，而是直接说"做一个好看的电商网站，能展示商品、能下单"。让 AI 决定技术栈，它选的工具往往比你自己指定的更合适——前提是你信得过它。

Naman 的原话是：prompt like a designer, not like a coder。 描述你想要的体验，而不是你打算怎么实现。

视觉参考比文字管用

好几个视频都提到了同一个技巧：把截图、Figma 设计图、甚至竞品网站的截图丢给 AI。

Fireship 专门做了整期 MCP 视频，核心就是让 AI 代码编辑器连接 Figma、读取设计文件，自动生成对应的代码。这比用文字描述"我要这个蓝色、这个圆角"精准多了。

版本控制是命

Fireship 那个视频标题就叫"How to make vibe coding not suck"，内容其实就是在讲这个——不要变成那个"两周代码全丢了"的人。

Tina Huang 专门演示了 Git 的完整流程：init、add、commit、push。即便你不会敲命令，直接跟 AI 说"用 git 提交这个修改"也行，但关键是——每一次小改动之后都要 commit。

YC 的 Tom 加了一个更狠的建议：AI 修 bug 失败之后，不要继续反复 prompt 尝试修复。直接 git reset --hard，清空重来，把最终找到的解决方案一次性喂给干净的代码库。他的原话是：“AI 会积累一层又一层的糟糕代码，而不是真正找到根本原因。”

Rollback 用起来

现在主流工具（Replit、Lovable、Bolt.new）都有内置的 rollback 功能。每次大改动之前，系统会自动保存一个快照，发现走偏了就回退。

Tina Huang 讲了一个真实经历：AI 修 bug 把整个组件弄没了，她用 rollback 回到上一个稳定版本，重新来过。省了大量时间。

让 AI 解释它自己写的代码

这是个很多人忽略但特别有价值的技巧。

用 AI 写完一段代码之后，直接问它：“这个 app 的整体逻辑是什么？这些文件之间是怎么配合的？” 它会用自然语言把架构讲清楚，你听完之后对项目的理解会完全不一样。

YC 的 Tom 把这个用得更彻底：把文档下载到本地，让 AI 直接读取，不需要每次都去网上搜。他还会让 AI 把代码一行行解释给他听，当作学习新技术的手段。

MCP 服务器：把 AI 从"写代码"升级到"真正干活"

Fireship 那期视频是整个系列里技术含量最高的。

MCP（Model Context Protocol）是一种标准协议，让你的 AI 代码编辑器连接外部系统。接上 Stripe 的 MCP，AI 就能直接调用真实的支付 API；接上 Figma 的 MCP，它能读取设计文件；接上 Sentry，它能看到真实的报错日志。

这才是让 AI 从"写代码工具"变成"真正的开发助手"的关键。

给 AI 写规则

YC 视频里 Tom 提到，有人给 Cursor 或 Windsurf 写了几百行指令，包括：代码改动要最小化、API 调用要加 rate limit、不要暴露 API key、每次改动之前先检查是否影响其他模块。

Tina Huang 也说，她会在 rules 文件里写明安全规范，让 AI 在生成代码的时候就遵守这些约束，而不是写完再补救。

换一个模型试试

YC 的 Tom 做过一个很系统的对比：Gemini 在整个代码库索引和长期规划上表现最好，Sonnet 3.7 在实际写代码上最靠谱，GPT 4.1 在某些场景反而会出错。

他的建议是：卡住了就换模型，不要在一棵树上吊死。每个模型擅长的事情不太一样。

写在最后

看完这些视频之后，我最深的感受是：Vibe Coding 不是"让 AI 全权负责"，而是你始终保持对系统的理解，用自然语言引导 AI 按你的意图构建。

最核心的一句话是 DevForge 里面那段：

如果你写出的代码超出了你自己的理解范围，那你就根本无法 debug 它。

AI 可以帮你写代码，但它没法帮你理解代码。那部分，始终是你自己的事。

如果你还没试过 Vibe Coding，找一个简单的项目开始——Replit 或 Lovable 对新手最友好；有一定基础的话，直接上 Cursor 或 Windsurf。

边做边学，这是最快的方式。