这篇文章内容来自于 Y Combinator 的视频《How To Get The Most Out Of Vibe Coding》的启发。

📚 系列文章导航

本系列文章基于 Y Combinator 的《How To Get The Most Out Of Vibe Coding》视频，深入探讨与 AI 协同编程的最佳实践：

  1. ✨ 如何更好的 Vibe Coding？—来自 YC Startup Founders 的实践建议 - 深入分析 Vibe Coding 的核心原则和进阶技巧（本文）

  2. 🤝 在 Coding 的时候，我们应该和 AI 如何进行有效的协同 - 分析与 AI 协同的核心思维模型和工作原则

  3. 🔄 Vibe Coding 的开发工作流 - 详细介绍标准化的 Vibe Coding 开发流程和调试方法

我最近通过 Vibe Coding 的方式，构建了好几个产品，也确实感受到了 Vibe Coding 的强大，但是并不意味着，使用 AI 构建产品就没有门槛；这并不意味着我可以使用一句话就可以轻易构建出一个可用的产品。

当我真正在使用 AI 去构建产品的时候，我发现了很多问题，也发现了很多局限。但是这些并不意味着我们应该回归传统的人工编码的方式。恰恰因为如此，我觉得 Vibe Coding 或者更准确的说，和 AI 进行协同编程的领域，有很多值得学习的地方，需要不断通过练习而可以获得显著精进的技能。

就像这个视频中 YC 的合伙人 Tom Blomfield 说的那样：“We’re trying to use these tools to get the best results. ”（我们的目标是利用这些工具获得最佳结果，而不是纠结于定义）。这个视频更新时间是 比较久远了，但是里面的实践建议，放到今天，依然非常有用。

最高效的 Vibe Coding 技巧，其实就是专业软件工程师一直以来遵循的最佳实践

视频信息

Vibe Coding

  • Title: How To Get The Most Out Of Vibe Coding | Startup School (如何通过“Vibe Coding”获得最大收益)
  • Author: Y Combinator (主讲人: Tom Blomfield, YC Partner)
  • URL: https://www.youtube.com/watch?v=BJjsfNO5JTo
  • Overview: 视频探讨了如何将“Vibe Coding”（利用 AI 工具辅助编程的直觉式开发）转化为一种专业、高效的工程实践。核心论点在于，最好的 AI 编程技巧本质上就是优秀的软件工程原则。Tom 强调，不要把 AI 仅仅当作代码生成器，而应将其视为需要明确指令、详尽规划和严格代码审查的“初级开发人员”。结论是，通过建立结构化的工作流（如编写 Markdown 计划、从测试出发、频繁重置上下文、保持模块化），开发者可以利用 Cursor、Windsurf 等工具极大幅度地提升构建速度，同时避免生成不可维护的“垃圾代码”。

内容主题

第一节：Vibe Coding 的本质与起步策略

Vibe Coding 的定义与心态转变 “Vibe Coding” 这个术语最近在技术圈非常流行，许多人认为它只是随意地向 AI 描述想法并生成代码。但 YC 合伙人 Tom 在过去一个月通过构建多个副业项目（Side Projects）的实验后发现，这不仅仅是一种新奇的玩法，更是一项可以通过练习显著精进的技能。这就好比一两年前的“提示词工程”（Prompt Engineering），当时人们每周都在发现新技巧。Tom 指出，最高效的 Vibe Coding 技巧，其实就是专业软件工程师一直以来遵循的最佳实践。即使有人质疑这不再是“凭感觉（Vibe）”而是传统的“软件工程”，但这正是问题的关键——我们的目标是利用这些工具获得最佳结果，而不是纠结于定义。

YC 创业者的实战经验 在正式建议之前，视频展示了 YC Spring Batch 创业者们的真实心得，这些经验非常宝贵且具体：

  • 多工具并用策略：一位创始人建议同时运行 Cursor 和 Windsurf。Cursor 速度较快，适合前端修改或全栈连接；而 Windsurf 思考时间更长，适合深层逻辑。利用一个工具“思考”的时间，可以在另一个工具中处理前端样式，甚至可以让两个工具针对同一需求生成不同版本，以此择优。
  • 自然语言编程：另一位创始人提出将 AI 视为一种新的编程语言。你不再是用代码语法编程，而是用自然语言编程。这意味着你需要像写代码一样，提供极高密度的上下文（Context）和详细信息，才能得到好结果。
  • 逆向开发（Test-First Approach）：一种非常稳健的方法是“逆向 Vibe Coding”。先手工编写测试用例（不使用 LLM），建立严格的护栏（Guardrails）。只有当测试用例准备好后，才让 LLM 自由生成代码。只要看到测试通过的“绿灯”，任务即算完成，无需微观管理代码细节。
  • 纯 LLM 规划先行：在进入代码编辑器之前，先在纯 LLM（如 ChatGPT 或 Claude 的网页版）中花费“不合理”多的时间来构建范围和架构。这能避免直接在代码库中胡乱生成行不通的方案。

工具选择指南 对于不同背景的开发者，工具的选择至关重要：

  • 零基础新手：如果你从未写过代码，推荐使用 Replit 或 Lovable。这些工具提供直观的视觉界面，非常适合直接在代码中尝试新的 UI 想法。许多产品经理和设计师现在直接用代码实现想法，而不是画 Figma 原型，因为这样更快。但要注意，像 Lovable 这类工具在修改后端逻辑时可能会遇到瓶颈，有时修改一个按钮会导致后端逻辑发生奇怪的变化。
  • 有经验的开发者：即使你生疏了（Rusty），也建议直接跳过新手工具，使用 Windsurf、Cursor 或 Claude Code。这些工具提供了更强的控制力，适合处理复杂的全栈逻辑。

第二节：黄金工艺流–从规划到提交

“不写代码”的起手式 选定工具后的第一步，绝对不是直接开始写代码。Tom 强烈建议先与 LLM 合作编写一份综合计划（Comprehensive Plan）。

  • Markdown 计划书：将这份计划保存为项目文件夹中的 Markdown 文件。这份文件是你与 AI 的“契约”，在整个开发过程中要不断回看。
  • 迭代与修剪：在生成计划初稿后，要人工介入进行审查。删除你不喜欢的部分，明确标记某些功能为“不做”（Won’t do）或“过于复杂”。可以将一些稍后考虑的想法移入“Ideas for later”章节，明确告诉 LLM 这些当前在范围之外（Out of scope）。

分块执行与 Git 提交 一旦计划确立，执行过程必须是**逐节进行（Section by section）**的。

  • 指令明确：明确告诉 AI，“现在我们只做第二部分”。
  • 验证与锁定：每完成一部分，立即运行测试并检查功能。确认无误后，进行 Git Commit。这是一个关键的“存档点”。
  • 更新计划：让 AI 回到 Markdown 计划文件中，将该部分标记为“已完成”。
  • 避免“一步登天”（One-shot）：目前的模型虽然强大，但还没好到能一次性生成整个复杂产品。试图让模型一次性完成所有工作通常会导致混乱。分步执行不仅稳健，还能让你在出错时有路可退。

版本控制的铁律 版本控制（Version Control）是 Vibe Coding 中最重要的安全网。

  • 宗教般地使用 Git：尽管现在的 AI 编辑器都有内置的“Revert”（回滚）功能，但 Tom 坦言还不敢完全信任它们。他坚持使用 Git，确保在开始新功能前，代码库是干净的（Clean Git Slate）。
  • 重置的勇气（Git Reset Hard）：这是很多新手容易忽略的一点。如果 AI 在实现某个功能时“走火入魔”（Vision Quest），搞得一团糟，不要试图修补。直接执行 git reset --hard，回到上一个已知的良好状态。
  • 避免“代码淤泥”：如果你发现自己为了一个功能尝试了 4、5、6 个不同的 Prompt，代码库往往会堆积层层叠叠的错误逻辑（Layers of bad code/craft）。正确的做法是：在脏代码中找到解决方案后，记录下来，然后 Reset 代码库，在干净的状态下一次性输入最终的解决方案。这样能保证代码的整洁，避免未知的副作用。

第三节：质量防线–测试策略与高级调试

高层次集成测试（High-Level Integration Tests） 测试在 Vibe Coding 中扮演着守门员的角色。LLM 擅长写测试，但往往倾向于写底层的单元测试（Unit Tests）。

  • 模拟用户行为：Tom 建议指导 LLM 编写“超高层次”的测试。例如，模拟用户点击网站、浏览应用，确保端到端（End-to-End）的功能正常。
  • 防止回归（Catching Regressions）：LLM 有一个坏习惯，就是会在修改 A 处代码时，莫名其妙地改动 B 处无关的逻辑。拥有这套高层次测试套件，能让你在这种情况发生时立即察觉。一旦发现 AI 做了不必要的修改，立即 Reset 并重新开始。

调试（Debugging）的艺术 当 Bug 出现时，处理方式决定了效率。

  • 复制粘贴错误信息：遇到 Bug，第一反应应该是直接将服务器日志或浏览器控制台的错误信息 Copy & Paste 给 LLM。通常这不仅能定位问题，甚至不需要你解释发生了什么，AI 就能修复。Tom 预测未来这些工具将能自动读取日志或通过无头浏览器（Headless Browser）自行排查，无需人类充当“复制粘贴机器”。
  • 让 AI 先思考：对于复杂的 Bug，不要让 AI 马上写代码。要求它“列出 3 到 4 个可能的原因”，先进行推理。
  • 失败即重置（Reset on Failure）：这是反复强调的原则。如果 AI 尝试修复 Bug 失败了，不要让它在失败的代码基础上继续尝试。Reset 回去，重新开始。因为每一次失败的尝试都在代码中增加了无用的复杂度和垃圾代码（Crust/Crap）。
  • 切换模型：如果你在一个模型上卡住了（比如 Claude Sonnet 3.7），试试 OpenAI 的模型或 Google 的 Gemini。不同模型在不同场景下有不同的“直觉”，往往能解决彼此解决不了的问题。
  • 干净重现：如果你在调试过程中最终找到了复杂的根源，建议 Reset 所有更改，然后在干净的代码库上给 AI 一个极其精确的指令来修复这个特定的 Bug，以保持代码库的纯净。

第四节：进阶技巧–上下文管理与复杂结构

指令文件与文档管理 为了让 AI 长期保持高效，你需要管理好它所拥有的上下文。

  • 指令文件（Rules/Instructions）：无论是 Cursor Rules, Windsurf Rules 还是 Claude 的 Markdown 文件，你应该编写一份核心指令集。有些创始人写了几百行指令，这能让 AI Agent 的效率成倍提升。这包括你的编码风格偏好、项目结构约定等。

  • 本地文档库：虽然 AI 可以联网，但直接读取在线文档的效果有时不稳定（Patchy）。Tom 建议将项目依赖的 API 文档全部下载下来，放在项目的一个子文件夹中。在指令中明确告诉 LLM：“在实现这个功能前，先去阅读那个文件夹里的文档。”这比依赖模型训练数据或联网搜索要准确得多。

    当然如果觉得下载 API 文档麻烦的情况下， 我觉得可以使用 Context 7 的 MCP 服务，也可以解决大部分信息准确性的问题。

处理复杂功能与独立开发 当你需要开发一个超出常规复杂度的功能，或者你不敢信任 AI 直接在现有代码库中操作时：

  • 独立项目（Standalone Project）策略：在一个完全空白的新代码库中开发这个功能。建立一个极简的参考实现（Reference Implementation），或者从 GitHub 下载一个现成的参考。
  • 移植逻辑：一旦在这个独立环境中跑通了，再指示 LLM 参考这个实现，将其“移植”到你的主代码库中。这种方法能有效隔离复杂性，避免搞坏主项目。

架构设计与技术栈选择

  • 模块化与 API 边界：适合 AI 的架构也是适合人类的架构。Tom 预测未来会更多地转向模块化或基于服务的架构。清晰的 API 边界让 AI 可以在不影响系统其他部分的情况下，自由修改内部实现。相比之下，巨型单体仓库（Monorepos）及其复杂的相互依赖关系，对 AI 和人类来说都是噩梦。
  • 选择“AI 友好”的技术栈：Tom 选择了 Ruby on Rails。尽管这是个 20 年的老框架，但 AI 写 Rails 代码的能力令人震惊。原因在于 Rails 有极其强大的“惯例优于配置”（Convention over Configuration）原则，且互联网上有海量的、结构高度一致的 Rails 代码作为训练数据。相比之下，像 Rust 或 Elixir 这样变体较多或数据较少的语言，AI 的表现可能较差。选择成熟、规范统一的框架是 Vibe Coding 的一个隐藏秘籍。

第五节：交互升级——多模态与持续实验

利用多模态能力

  • 截图（Screenshots）：现在的编码 Agent 都支持图片输入。遇到 UI Bug，直接截图丢给它；想要模仿某个网站的设计，截图给它作为灵感。这比用语言描述 UI 问题要高效得多。
  • 语音编码（Voice Coding）：Tom 推荐使用 Aqua（一家 YC 公司产品）或其他语音工具。人类说话的速度（约 140 词/分钟）是打字速度的两倍。而且现在的模型对语音转写的语法错误容忍度极高，即使转写不完美，AI 也能理解你的意图。Tom 甚至透露整个演讲稿都是用 Aqua 写成的。

非编码任务的自动化 LLM 的用途不仅限于写代码：

  • DevOps 工程师：配置 DNS、设置 Heroku 托管、编写命令行脚本等繁琐任务，AI 可以以 10 倍的速度完成。
  • 设计师：Tom 使用 ChatGPT 生成网站图标（Favicon），然后让 Claude 写一个一次性脚本将图片调整为 6 种不同的尺寸格式。这些“一次性脚本”是 AI 极佳的用武之地。

持续实验与重构

  • 频繁重构（Refactor Frequently）：有了测试的保护，你可以大胆重构。甚至可以主动问 LLM：“代码库里哪些部分是重复的？哪些适合重构？”保持代码文件的短小精悍，对人类和 LLM 阅读都有好处。
  • 紧跟模型更新：这个领域的变化是以“周”为单位的。Gemini 目前在全库索引（Context Window）和规划方面表现出色；Claude Sonnet 3.7 在代码实现上似乎处于领先地位；GPT-4 系列也有其优势。建议在不同场景下尝试最新模型，不要死守一个工具。