如何最大化 Vibe Coding 的效果 | 创业学校

cover

摘要

本篇是 YC 合伙人 Tom 关于 Vibe Coding（即用自然语言指挥 AI 编写代码的实践）的实用指南。Tom 在过去一个月用 Vibe Coding 做了多个副项目，发现这不仅效果惊人，而且是一项可以通过学习和实践显著提升的技能——就像一两年前的提示工程 (Prompt Engineering)，每周都有新技巧涌现。核心理念是：让 LLM 遵循专业软件工程师的工作流程。YC Spring 批次的多位创始人也分享了他们的实战经验，包括同时使用 Cursor 和 Windsurf、先在纯 LLM 中做架构设计再交给编码工具、从测试用例反向驱动、以及警惕 LLM 陷入"兔子洞"。Tom 系统性地介绍了从工具选择、项目规划、版本控制、测试编写、Bug 修复、指令文件、文档管理到技术栈选择、截图与语音输入、代码重构等一整套最佳实践，并强调持续实验——因为最前沿的技术几乎每周都在变。

正文

YC 创始人的 Vibe Coding 实战技巧

在正式给出建议之前，Tom 先分享了 YC Spring 批次创始人们的实战心得：

  1. 换工具破局：当 AI IDE 陷入循环无法调试时，直接把代码粘贴到 LLM 网页端（如 Claude.ai 或 ChatGPT），同样的提问往往能得到 IDE 无法给出的答案。
  2. 双 IDE 并行：同时加载 Cursor 和 Windsurf。Cursor 更快，适合前端和全栈快速迭代；Windsurf 思考更久，适合复杂逻辑。等待 Windsurf 思考时可以在 Cursor 上推进前端，甚至让两者基于相同上下文同时给出同一功能的不同实现，择优选用。
  3. 把 AI 当新编程语言：Vibe Coding 本质上是用自然语言编程，因此必须像给编程语言提供上下文一样，给出极其详细和完整的信息。
  4. 测试驱动：先手写测试用例（不依赖 LLM），然后让 LLM 在测试的护栏下自由生成代码，绿灯亮了就完成——无需微管代码库。
  5. 先做架构再编码：在纯 LLM 中花"不合理的时间"梳理范围和架构，再交给 Cursor 等工具，否则 AI 会在代码库中胡乱编造。
  6. 警惕兔子洞：如果 LLM 反复生成看似诡异的代码、你不断粘贴错误信息——说明已经走偏了，应该后退一步，让 LLM 自省失败原因：是上下文不足，还是运气不好？

选择合适的工具

从未写过代码的人，推荐从 Replit 或 Lovable 入手——它们提供可视界面，适合快速试验 UI，许多产品经理和设计师已直接跳过 Figma 原型、用代码实现新想法。但当需要精确修改后端逻辑时，这类工具容易失控（改一个按钮，后端逻辑莫名其妙跟着变）。有编程经验的人可以直接上手 Windsurf、Cursor 或 Claude Code。

第一步：写计划，而非写代码

选定工具后，第一步不是写代码，而是与 LLM 协作撰写一份详尽的项目计划，保存为 Markdown 文件放在项目目录中，持续参照执行。审核计划初稿时：删除不想要的、标记"不做"的过于复杂的功能、把后续想法归入"待定"区。然后按章节逐步实施——明确告诉 AI"现在只做第二节"，完成后检查、测试、提交，再让 AI 回到计划标记完成。不要指望模型一次性产出完整产品，尤其是复杂项目；逐步推进、每步提交到 Git，出问题时可以回退。

版本控制：Git 是你最可靠的朋友

版本控制 (Version Control) 至关重要。虽然工具有自带的回退功能，Tom 表示还不信任它们——每次开始新功能前，确保 Git 处于干净状态，这样 AI "跑偏"时可以回退到已知可工作的版本。不要犹豫使用 git reset --hard：如果不对就重掷骰子。反复用多个 Prompt 修补会让 LLM 积累层层垃圾代码 (Crap)，而非真正理解根因。更好的做法是：经过多轮尝试找到解决方案后，git reset 回到干净代码库，把该方案作为清晰的指令重新喂给 AI，这样实现干净、无多余层级。

编写测试

让 LLM 写测试——它们在这方面相当擅长，但默认倾向写低层级的单元测试 (Unit Tests)。Tom 更推荐高层级的集成测试 (Integration Tests)：模拟用户在网站或 App 中的点击流程，端到端验证功能是否正常。在进入下一个功能之前，确保测试就位。测试套件的价值在于捕获 LLM 的"副作用"——它经常在修复 A 的时候毫无理由地改动 B 的逻辑，有了测试就能尽早发现回归 (Regression)，果断 git reset 重新来过。

LLM 不只用于编码

Tom 把 LLM 当作全栈助手：Claude Sonnet 3.7 帮他配置 DNS 服务器（他最讨厌的任务）和通过命令行设置 Heroku 托管——相当于一个 DevOps 工程师，效率提升 10 倍；ChatGPT 为网站生成 Favicon 图标，Claude 再写一个一次性脚本把图标裁剪成六个不同尺寸和格式。AI 成了他的设计师和运维工程师。

Bug 修复策略

遇到 Bug 的第一反应：直接把错误信息粘贴回 LLM——无论是服务器日志还是浏览器 JavaScript 控制台的报错。很多时候，仅凭错误信息 AI 就能定位并修复问题，你甚至不需要解释哪里出了错。Tom 预测，未来所有主流编码工具都会自动摄取这些错误信息，人类充当"复制粘贴机器"的角色终将消失——LLM 将直接追踪日志 (Tail Logs) 或启动无头浏览器 (Headless Browser) 检查 JS 错误。

更复杂的 Bug：让 LLM 在写代码前先思考三四种可能原因。每次修复尝试失败后，先 git reset 再重新开始，不要在失败基础上累积层级。如果还是搞不定，添加日志 (Logging)——日志是你的朋友。如果依然不行，换模型：Claude Sonnet 3.7、OpenAI 系列或 Gemini，不同模型各有强项，往往一个失败的地方另一个能成功。找到根源后，先 git reset 清除所有尝试，再在干净代码库上给出极其精确的修复指令。

为 LLM 编写指令文件

无论是 Cursor Rules、Windsurf Rules 还是 Claude 的 CLAUDE.md，每种工具有自己的指令文件命名规范。Tom 认识的创始人中，有人写了数百行指令给 AI 编码代理，效果显著提升。网上有大量关于指令文件内容的最佳实践，建议自行搜索。

文档管理

让 AI 代理读取在线文档仍然不太稳定。有人建议用 MCP 服务器 (MCP Server) 访问文档，对某些人有效但 Tom 觉得太重了。他的做法是：把相关 API 文档全部下载到项目目录的子文件夹中，然后在指令里告诉 LLM "实现这个之前先去读文档"——准确度高得多。另外，可以把 LLM 当老师：实现一个功能后，让 AI 逐行解释代码，这是学习新技术的高效方式，比刷 Stack Overflow 好得多。

复杂功能的实现策略

当新功能复杂到不敢完全信任 AI 一次搞定时：在一个完全干净的独立代码库中做参考实现 (Reference Implementation)，或者从 GitHub 下载别人已写好的参考实现，然后让 LLM 参照它在你主项目中重新实现——效果出奇地好。

小文件与模块化架构

这是专业开发者的常识，同样适用于 LLM：保持文件小而模块化 (Modular)。Tom 预测未来会更多转向服务化架构 (Service-based Architecture)，让 LLM 在清晰的 API 边界内工作——只要外部接口 (External Interface) 不变、测试通过，内部实现可以自由调整。相比之下，巨大的单体仓库 (Monorepo) 布满相互依赖，人和 LLM 都难以判断某处改动是否会波及另一部分。

选择合适的技术栈

Tom 用 Ruby on Rails 做项目部分代码，因为他有专业开发经验。但他被 AI 写 Rails 代码的表现惊艳到——Rails 是一个 20 年历史的框架，有大量成熟的约定 (Conventions)，绝大多数 Rails 代码库看起来非常相似，经验丰富的开发者一眼就知道某段功能应该放在哪里、"Rails 之道 (The Rails Way)" 是什么。这意味着网上有大量一致、高质量的 Rails 训练数据。相比之下，Rust 或 Elixir 等语言因在线训练数据较少，AI 表现就不那么好——不过这可能很快改变。

截图与语音输入

截图：大多数编码代理现在支持粘贴截图，对于展示 UI Bug 或从其他网站引入设计灵感都非常有用。语音：Tom 使用 Aqua（一家 YC 公司），对着电脑说话即可转录为指令输入到 Cursor 或 Claude Code 中，输入速度约每分钟 140 词，是打字速度的两倍。AI 对语法和标点错误极其宽容，转录不必完美。Tom 本篇演讲稿就是用 Aqua 完成的。

频繁重构

当代码跑通、测试就位后，可以放心重构 (Refactor)——测试会捕获回归。可以请 LLM 识别代码库中重复或适合重构的部分。同样，这是专业开发者的标准做法：不要让文件长达数千行，保持小而模块化，人和 LLM 都更容易理解。

持续实验

最前沿的变化几乎以周为单位。Tom 每个新模型发布都会试用：在调试、长期规划、功能实现、重构等不同场景下比较表现。例如，目前 Gemini 在全代码库索引 (Codebase Indexing) 和制定实施计划方面领先，而 Sonnet 3.7 在实际编写代码变更上最强。GPT-4.1 他刚试过，问太多问题、实现出错次数太多——但下周再试可能又不一样了。Tom 欢迎观众在评论区分享自己的 Vibe Coding 技巧。