Vibe Coding 到底怎么玩？这5个技巧你绝对用得上

[音乐] 大家好，我是汤姆，YC的合伙人。过去一个月，我一直在尝试用"氛围编程"做几个小项目，发现它不仅效果惊人，而且如果你愿意不断调试并学习最佳实践，还能明显提升这项技能。本期视频中，我想分享一些通过氛围编程获得出色成果的方法。这有点像一两年前的提示工程——当时人们每周都能发现新技巧，并在社交媒体上分享。最有效的技巧其实与专业软件工程师使用的如出一辙。有人可能会说："这还算氛围编程吗？这不就是软件工程吗？"我觉得这种争论毫无意义。

我们正尝试利用这些工具来获得最佳效果。YC春季批次几周前刚刚启动。在我分享关于Vibe Coding的建议之前，先听听创始人们如何运用技巧从当前AI工具中获取最大价值。当你陷入AI IDE无法实现或调试某个功能、反复陷入死循环的困境时，有时直接访问LLM的网站——也就是直接打开用户界面，粘贴代码并询问相同的问题——可能会得到IDE因某种原因无法给出的解决方案。所以我建议，不妨在同一个项目中同时加载cursor和Windsurf。

嗯 cursor 速度更快一些，所以你可以做很多前端工作，更像全栈开发那样把前端和后端连接起来。Windsurf 思考的时间会更长一些。以前我经常一边刷手机一边打字说"构建这个代理"或者"修改这个提示"，然后我就继续刷手机或者粘贴错误信息。现在等 Windsurf 思考的时候，我可以切换到 cursor 开始更新前端。有时候我会同时打开两个工具，保持相同的上下文。

如果我要更新前端界面，我会让它参照那个文件的风格进行样式设计，然后直接按回车键确认两个选项，这样它们会给我呈现同一前端界面的略微不同版本，我再从中挑选更中意的一个。我的建议是，把AI视为一种新型编程语言，而"氛围编程"则是一种全新的编程范式。也就是说，你不再用代码编程，而是用语言编程。正因如此，若想获得理想效果，就必须事无巨细地提供大量必要的上下文和信息。我通常采用逆向方式开始氛围编程——先从测试用例入手，亲手编写测试用例。

我写测试用例时不会使用任何LLMs，一旦完成，我就有严格的防护规则，让我的LLMs可以遵循这些规则来生成代码。对吧？然后它们就能自由生成想要的代码。只要看到测试用例上出现绿色标记，工作就完成了。我不需要微观管理我的代码库，只需大致检查代码的模块化程度，其他方面都没问题。是的，我认为在把任务交给cursor或任何其他编码工具之前，先花大量时间用纯LLM构建出你要实现的范围和实际架构非常重要，而不是让工具在代码库里随意生成一堆根本行不通的东西。

嗯，所以一定要明确你正在构建的东西的实际目标是什么。我的建议是，真正留意一下LLM在回答你的问题时是否陷入了钻牛角尖的状态。如果你发现它一直在重复生成代码，而且看起来有点不对劲，实际上无法解决问题。如果你发现自己不得不一直复制粘贴错误信息，那可能意味着出了岔子，你应该退一步思考，甚至直接对LLM说：“嘿，我们退一步，试着从根本上分析一下为什么失败了。是因为你没有提供足够的上下文让语言模型能够理解，还是只是运气不好，它无法完成你的请求？”

这里的核心理念是让LLM遵循优秀专业软件开发者的工作流程。现在让我们深入探讨一些我见过的最佳"氛围编程"建议。首先从起点说起。如果你从未写过代码，我建议先尝试Replet或Lovable这类工具。它们提供直观的可视化界面，能让你直接在代码中体验新UI的乐趣。许多产品经理和设计师现在都直接通过代码实现新创意，而非在Figma这类工具中设计原型——因为代码实现的速度实在太快了。当我尝试这种方法时，确实被生成的UI效果惊艳到了。不过当我需要更精确地修改后端逻辑而非单纯调整UI时，像Lovable这样的工具就开始显得力不从心了。

我在这里改个按钮，后端逻辑就会莫名其妙地变化。所以如果你以前写过代码，哪怕像我一样有点生疏，也可以直接上手使用像Windsurf Cursor或Claude Code这样的工具。选定工具后，第一步不是急着写代码，而是先和LLM一起制定一份全面的计划。把计划放在项目文件夹里的Markdown文件中，并不断回顾参考。这份计划是你与AI共同制定的，在实施项目时逐步推进，而不是试图一次性完成所有工作。因此，在完成计划初稿后，我会通读一遍，删除或去掉你不喜欢的内容。

你可以明确标记某些功能为“暂不实现”，避免过于复杂。也可以保留一个“后续想法”的板块。比如告诉LLM：“我考虑过这个，但目前不在范围内。” 制定好计划后，与LLM协作逐步实施，明确说“我们先做第二部分”。接着验证功能是否正常，运行测试并提交mit。然后让AI返回计划，将第二部分标记为已完成。我目前不指望模型能一次性完成整个产品，尤其是复杂项目。更倾向于分步推进，确保每一步都能正常运行，关键是要提交mit到Git，这样如果下一步出问题还能回退。

但说实话，这个建议可能两三个月后就会过时。模型迭代速度太快，很难预测短期内的走向。我的下一个建议是使用版本控制。版本控制是你的好帮手。要虔诚地使用Git。我知道有些工具自带类似回退的功能，但我目前还不太信任它们。所以每次开发新功能前，我都会确保从干净的Git状态开始，这样万一AI突然天马行空，我还能回退到已知的稳定版本。如果效果不好，别怕用硬重置，大不了重新开始。我发现如果反复提示AI试图修正问题，结果往往更糟糕。

它往往会在代码中层层叠加劣质代码，而不是真正理解根本原因。你可能会尝试四、五、六次不同的提示，最终才得到解决方案。我通常会直接采用那个解决方案，重置代码库，然后将该方案输入到AI中，以便在干净的代码基础上实现这个干净的方案，避免层层叠加的拼凑代码。接下来你应该做的是编写测试，或者让你的LLM为你编写测试。它们在这方面相当擅长。尽管它们通常默认编写非常底层的单元测试，但我更倾向于让这些测试保持极高的抽象层级。

嗯，你实际上是想模拟用户点击网站或应用的操作，确保功能端到端运行正常，而不是在单元层面测试函数。所以一定要在进入下一个功能之前，先编写高级集成测试。LLMs有个坏习惯，就是会对无关逻辑做不必要的修改。你让它修复这里的问题，它却毫无理由地改动那边的逻辑。因此，建立这些测试套件能及早发现回归问题，当LLM偏离正轨做出无谓修改时，就能及时重置并重新开始。记住，LLMs不仅用于编码。我在做这类副项目时，也会大量用于非编码工作。

例如，我曾需要配置DNS服务器（这始终是我讨厌的任务），并通过命令行工具设置Heroku托管。这对我来说就像一位DevOps工程师，将我的效率提升了大约10倍。我还用聊天工具为网站图标生成了一张图片——就是浏览器窗口顶部那个小图标。随后，又用该工具将这张图片快速编写了一个一次性脚本，将其调整为跨平台所需的六种不同尺寸和格式。现在，AI也成了我的设计师。好了，接下来我们看看Bug修复。遇到任何Bug时，我做的第一件事就是直接将错误信息复制粘贴到工具中。这些信息可能来自服务器日志文件或浏览器的JavaScript控制台。

通常，仅凭这条错误信息就足以让AI识别并解决问题。你甚至不需要解释哪里出错了，或者你认为哪里出了问题。仅仅错误信息本身就已经足够。它的能力如此强大，以至于我很快预计所有主流编程工具都能直接读取这些错误，而无需人类手动复制粘贴。仔细想想，我们作为“复制粘贴机器”的价值其实有点奇怪，对吧？我们似乎把思考留给了LLM。但我认为复制粘贴这种方式即将被淘汰，这些LLM工具将能够直接追踪日志，或者启动无头浏览器来检查JavaScript错误。

面对更复杂的漏洞，你可以让LLM在编写代码前先思考三到四种可能的原因。每次修复失败后，我会重置状态重新开始，这样就不会积累层层叠叠的"硬壳"。不要在不重置的情况下反复尝试修复，因为LLM只会不断叠加更多"垃圾层"。重置后重新开始，并添加日志记录。日志是你的好帮手。如果遇到问题且修复无效，就切换模型。可能是Claude嗯Sonic 3.7版本，也可能是某个OpenAI系列模型，或是Gemini。我经常发现，不同模型会在其他模型失败时成功解决问题。

如果你最终找到了一个棘手错误的根源，我会重置所有修改，然后给出非常具体的指示，告诉它在干净的代码库上如何修复那个确切的错误，以避免垃圾代码层层堆积。下一个技巧是为AI编写指令。把这些指令放在哪里呢？无论是放在规则文件、Windsurf规则文件还是Claw Markdown文件中都可以。每个工具的命名规范略有不同。但我认识一些创始人，他们为AI编码助手编写了数百行指令，这让他们的效率大大提高。网上有很多关于在这些指令文件中写什么内容的建议，我会让你自己去查找。好了，我们来谈谈文档。

我仍然觉得将这些智能体指向在线网页文档的做法效果参差不齐。有些人建议用MCP服务器来获取文档，这对部分人有效，但在我看来有点小题大做。所以我通常会下载某个API系列的全部文档，把它们放在工作文件夹的子目录中，这样LLM就能在本地读取。然后在指令中我会明确要求：在实现功能前先阅读文档。这样做往往准确得多。另外要记住一个技巧：你可以把LLM当作老师，特别是对编程语言不太熟悉的人。你可以先实现某个功能，然后让AI逐行解析代码并为你讲解。

这是学习新技术的好方法。比我们过去那样在Stack Overflow上翻来翻去强多了。现在来看更复杂的功能。如果你要开发一个比平时更复杂的全新功能模块，我建议把它做成独立项目，放在完全干净的代码库里。先做一个简单的参考实现，避免现有项目的复杂性干扰，或者如果有人在GitHub上发布了参考实现，直接下载下来也行。然后把你LLM里的实现指给它看，让它参照这个实现，在你的大代码库里重新编写。这个方法效果出奇地好。记住，小文件和模块化是你的好朋友。

这对人类程序员同样适用。我认为我们可能会看到向更模块化或基于服务的架构转变，其中LLM具有清晰的API边界，可以在保持一致外部接口的同时运作，而不是那些依赖关系错综复杂的庞大单体仓库。这种架构对人类和LLMs都颇具挑战性——因为很难判断某处的修改是否会影响代码库的其他部分。而采用这种具有一致外部API的现代架构意味着：只要测试中的外部接口仍然通过，你就可以放心修改内部实现。现在需要留意的是选择合适的技术栈。

我选择部分使用Ruby on Rails构建项目，主要是因为以前做专业开发者时对它比较熟悉。但AI的表现让我惊叹不已，尤其是在编写Ruby on Rails代码时。我认为这是因为Rails是一个拥有20年历史的框架，有着大量成熟的约定规范。许多Rails代码库看起来非常相似，对于经验丰富的Ruby on Rails开发者来说，某个功能应该放在哪里，或者实现特定结果的正确Rails方式都一目了然。这意味着网上有大量高度一致且高质量的Rails代码库训练数据。

我有其他朋友在学习Rust或Elixir这类语言时就没那么顺利，因为网上相关的训练数据不够多，但谁知道呢，这种情况可能很快就会改变。好了，下一条建议：善用截图。现在大多数编程助手都支持直接粘贴截图，这非常实用——无论是展示你发现的UI实现漏洞，还是从其他网站获取设计灵感用于自己的项目。语音交互也是与这些工具互动的酷炫方式。我使用一家YC公司开发的Aqua，基本上我对着电脑说话，Aqua就能把我说的内容转录到正在使用的工具中。

我目前频繁在Windinsurf和Clawude Code之间切换，但使用Aqua时，我每分钟能有效输入140个单词的指令，这大约是我打字速度的两倍。而且AI对细微的语法和标点错误非常宽容，即使转录不够完美也完全不影响使用。实际上，整篇演讲稿都是用Aqua完成的。接下来请务必频繁重构代码。当代码正常运行且关键测试用例通过后，你就可以放心重构——测试用例会捕捉所有回归错误。你甚至可以要求LLM识别代码库中重复或适合重构的部分。再次强调，这是每位专业软件开发人员都会遵循的基本准则。

你不会拥有数千行长的文件。你会保持它们小而模块化。这样能让人类和机器都更容易理解发生了什么。最后，不断尝试。这类技术的前沿似乎每周都在变化。我会尝试每个新发布的模型，看看它们在各种不同场景中的表现。有些模型在调试、长期规划、实现功能或重构方面更出色。例如，目前，Gemini似乎最适合整个代码库的索引和制定实现计划，而Sonet 3.7，至少在我看来，似乎是实际实现代码变更的主要竞争者。我几天前刚试过GPT4.1，老实说，我并没有那么印象深刻。

它带回了太多问题，而且实际上多次搞错了实现方式。但我下周会再试一次，我相信情况又会有所变化。感谢观看，如果你有关于如何充分利用这些模型的技巧或窍门，我很乐意看到。请在下方评论区分享。[音乐]