How To Get The Most Out Of Vibe Coding | Startup School

在过去的几个月里，Tom深入探索了“Vibe Coding”这一编程实践，并将其应用于多个个人项目。他发现这种方法不仅效率惊人，而且通过不断尝试和采纳最佳实践，可以显著提升其效果。本视频旨在分享如何利用Vibe Coding取得卓越成果的策略。Vibe Coding类似于一两年前的提示工程，当时人们每周都会发现新方法并在社交媒体上分享。最有效的技术往往与专业软件工程师所采用的实践不谋而合。尽管有人可能认为这已经超出了Vibe Coding的范畴，更像是传统的软件工程，但Tom认为，关键在于利用这些工具来实现最佳结果，而非拘泥于定义。

YC Spring批次刚刚启动，在分享Vibe Coding的建议之前，让我们先听听各位创始人是如何利用AI工具发挥最大效用的。创始人分享了许多实用的技巧，例如，当AI集成开发环境（IDE）陷入无法解决或调试的循环时，直接将代码和问题粘贴到大型语言模型（LLM）的网页界面，往往能获得意想不到的解决方案。这表明在某些情况下，LLM的原始界面可能比集成工具更有效。

一位创始人建议同时使用Cursor和Windsurf来处理同一个项目。Cursor速度更快，适合前端和全栈开发，可以快速连接前后端。Windsurf则思考时间较长，这期间可以切换到Cursor更新前端，从而实现并行开发，提高效率。同时向两个工具输入相同上下文，比较它们略有不同的输出，然后选择最佳方案，也是一种有效策略。

另一位创始人提出，应将AI视为一种新型编程语言，将Vibe Coding视为一种全新的编程方式。在这种模式下，不再是使用代码进行编程，而是使用“语言”进行编程。因此，为了获得良好结果，必须以非常详细的方式提供所有必要的上下文和信息。

“把AI想象成一种不同的编程语言，Vibe Coding是一种新的编程语言。与其用代码编程，不如用语言编程。”

有创始人建议采用逆向编码，即从手工编写测试用例开始，而不是依赖LLM生成测试。一旦测试用例完成，就可以为LLM设置严格的生成代码规则。当测试通过时，就意味着任务完成，无需对代码库进行微管理，只需关注代码的模块化。这确保了LLM在既定的高质量标准下自由生成代码。

在将任务交给Cursor或其他编码工具之前，投入大量时间在纯LLM环境中构建项目范围和实际架构至关重要。避免让AI在代码库中随意生成不工作的内容，确保在编码之前清晰理解构建的目标，这样可以防止AI陷入“兔子洞”。

密切监控LLM在回答问题时是否陷入死循环非常重要。如果发现它不断重新生成代码，看起来很奇怪，或者需要频繁复制粘贴错误信息，这可能意味着出现了问题。此时应该退一步，甚至提示LLM反思为什么会失败，是因为缺乏足够的上下文，还是只是运气不佳。核心思想是让LLM遵循专业软件开发人员所使用的流程。接下来，我们将深入探讨一些Tom认为最有效的Vibe Coding建议。

对于从未编写过代码的初学者，建议选择诸如Replit或Lovable之类的工具。这些工具提供易于使用的可视化界面，是直接在代码中尝试新用户界面（UI）的绝佳方式。许多产品经理和设计师现在倾向于直接在代码中实现新想法，而不是在Figma等工具中设计模型，因为这样速度更快。然而，在Tom的实验中，他发现这些工具在UI方面表现出色，但在需要精确修改后端逻辑时，它们开始显得力不从心。例如，修改一个按钮可能会导致后端逻辑发生意想不到的改变。如果您有编码经验，即使有些生疏，也可以直接使用Windsurf、Cursor或Claude Code等高级工具。

在选择好工具后，第一步并非立即开始编写代码。相反，应该与LLM合作制定一个全面的计划。将此计划保存为项目文件夹中的Markdown文件，并持续参考。这是一个与AI共同开发的计划，在项目实施过程中逐步执行，而不是试图一次性完成整个项目。制定好初稿后，审阅并删除不喜欢或认为过于复杂的功能，并将其明确标记为“不做”。还可以保留一个“留待以后”的想法部分，告知LLM这些想法已考虑，但目前超出范围。有了计划后，与LLM合作，逐节实现，明确指定“现在只做第二节”。

完成一节后，检查其功能是否正常，运行测试，然后提交到Git。接着，让AI回到计划中，将该节标记为完成。Tom不建议期望模型一次性完成整个产品，尤其是复杂的项目。他倾向于分段进行，确保每一步都有一个可工作的实现，并且关键是将其提交到Git，以便在下一步出错时可以回滚。然而，他也承认，鉴于模型的快速发展，这一建议在未来两三个月内可能会有所改变。这些模型进步如此之快，以至于很难预测近期会发生什么。下一个建议是使用版本控制。

版本控制是开发者最好的朋友，请虔诚地使用Git。尽管许多AI工具声称提供某种形式的恢复功能，但Tom对此持谨慎态度，因为他尚不完全信任它们。因此，在开始开发新功能之前，他总是确保从一个干净的Git版本开始，以便在AI出现问题时可以回滚到已知的工作版本。因此，如果代码无法正常工作，不要害怕使用git reset --hard HEAD，然后重新尝试。Tom发现，如果他多次提示AI尝试修复同一问题，结果往往很糟糕。AI倾向于累积一层又一层的糟糕代码，而不是真正理解问题的根本原因。你可能需要尝试四、五、六个不同的提示才能最终得到解决方案。实际上，更好的做法是采纳这个解决方案，然后git reset，在一个干净的代码库上将该解决方案输入给AI，这样就可以实现一个干净的解决方案，避免累积不必要的“垃圾”。下一个重要的实践是编写测试。

编写测试，或者让LLM为你编写测试。LLM在这方面表现相当出色，尽管它们通常默认编写非常低级的单元测试。Tom更倾向于保持测试在非常高的层次，基本上是模拟用户点击网站或应用程序的过程，并确保功能端到端正常工作，而不是仅仅进行单元级别的函数测试。因此，在进入下一个功能之前，请务必编写高层次的集成测试。LLM有一个不好的习惯，那就是对不相关的逻辑进行不必要的修改。例如，你让它修复某个问题，它却莫名其妙地改变了其他地方的逻辑。因此，建立这些测试套件可以尽早捕捉到这些回归，识别出LLM何时进行了不必要的修改，以便你可以回滚并重新开始。请记住，LLM不仅仅用于编码。

LLM不仅仅用于编码。Tom在构建这些个人项目时，也将它们用于大量的非编码工作。例如，他使用Claude Sonnet 3.7配置了DNS服务器，这是一项他一直讨厌的任务，并通过命令行工具设置了Heroku托管。LLM扮演了他的DevOps工程师，将他的进度加速了十倍。他还使用ChatGPT为网站的收藏夹图标（favicon）创建了一个图像，这个小图标会出现在浏览器窗口的顶部。然后，Claude又利用这个图像，编写了一个快速的临时脚本，将其调整成不同平台所需的六种不同大小和格式。因此，AI现在也成为了他的设计师。接下来，让我们看看错误修复。

当遇到任何bug时，Tom做的第一件事就是将错误信息直接复制粘贴回LLM。这些错误信息可能来自服务器日志文件，也可能来自浏览器中的JavaScript控制台。通常情况下，这些错误信息足以让AI识别并修复问题，甚至不需要你解释具体出了什么问题或你认为出了什么问题。仅仅是错误信息就足够了，这非常强大。Tom预计，很快所有主要的编码工具都将能够自动摄取这些错误，而无需人类手动复制粘贴。我们作为“复制粘贴机器”的角色似乎有些奇怪，因为我们把思考工作留给了LLM。但他认为，这种复制粘贴的做法将会过时，LLM工具将能够直接跟踪日志或启动无头浏览器来检查JavaScript错误。对于更复杂的bug，你可以要求LLM在编写任何代码之前，先思考三到四种可能的病因。每次尝试修复bug失败后，Tom都会进行git reset并重新开始，以免累积一层又一层的“垃圾代码”。不要在不重置的情况下多次尝试修复bug，因为LLM只会添加更多的“垃圾”。git reset，重新开始，并添加日志记录。日志记录是你的好朋友。如果怀疑，如果不起作用，切换模型。也许是Claude Sonnet 3.7，也许是OpenAI的模型，也许是Gemini。Tom经常发现，不同的模型在其他模型失败的地方会成功。如果你最终找到了一个棘手bug的根源，Tom会重置所有更改，然后在一个干净的代码库上向LLM提供非常具体的指令，说明如何修复那个精确的bug，以避免这种一层又一层的垃圾代码累积。下一个建议是为LLM编写指令。

“如果我们发现自己一直在复制粘贴错误信息，很可能意味着出问题了，应该退一步，甚至提示LLM思考失败的原因。”

将这些指令放入Cursor规则、Windsurf规则或Claude markdown文件中。每个工具都有略微不同的命名约定。但Tom知道有些创始人为他们的AI编码代理编写了数百行指令，这使得他们的效率大大提高。网上有大量关于这些指令文件中应包含什么内容的建议，Tom建议自行查找。

Tom发现，目前让这些AI代理直接处理在线网络文档仍然有些不稳定。虽然有人建议使用MCP服务器来访问文档，这对一些人有效，但对Tom来说似乎有些过度。因此，他通常会下载给定API集的所有文档，并将其放入工作文件夹的子目录中，以便LLM可以本地访问。然后，在指令中，他会告诉LLM“在实现此功能之前先阅读文档”。这种方法通常会更准确。一个值得注意的附带提示是，你可以将LLM用作教师，尤其是对于那些不太熟悉编码语言的人。你可以实现一些功能，然后让AI逐行解释该实现。这是学习新技术的好方法，比我们以前经常做的滚动Stack Overflow要好得多。现在，让我们看看更复杂的功能。

如果你正在开发一项比你通常信任AI实现更复杂的新功能，Tom建议将其作为一个独立的、完全干净代码库中的项目来完成。先在一个小型参考实现中使其工作，避免现有项目的复杂性，甚至可以从GitHub下载一个已有的参考实现。然后，将LLM指向该实现，并告诉它在你的大型代码库中重新实现时遵循该参考。这种方法的效果出奇地好。记住，小文件和模块化是你的朋友，这对于人类程序员也同样适用。Tom认为，我们可能会看到向更模块化或基于服务的架构转变，其中LLM可以在清晰的API边界内工作，同时保持一致的外部接口，而不是那些包含大量内部依赖的庞大单体仓库。这些对于人类和LLM都很难处理，因为不清楚一个地方的更改是否会影响代码库的另一个部分。因此，采用这种具有一致外部API的现代架构意味着你可以修改内部实现，只要外部接口和测试仍然通过，通常就没有问题。接下来是关于选择正确技术栈的说明。

Tom选择部分使用Ruby on Rails来构建他的项目，主要是因为他作为专业开发者时熟悉这个框架。但AI在编写Ruby on Rails代码时的表现令他震惊。他认为这可能是因为Rails是一个拥有20年历史的框架，拥有大量成熟的约定。许多Rails代码库看起来非常相似，有经验的Ruby on Rails开发者能够轻易判断特定功能应该放在哪里，或者实现某个结果的正确Rails方式。这意味着网上有大量相当一致且高质量的Rails代码库作为训练数据。Tom的其他朋友在使用Rust或Elixir等语言时获得的成功较少，因为这些语言的在线训练数据较少，但谁知道这可能很快就会改变。下一个建议是使用截图。

现在大多数编码代理都支持复制粘贴截图，这对于演示UI中的bug或从其他网站获取设计灵感非常有用。语音是另一种与这些工具交互的酷炫方式。Tom使用了Aqua，一个YC孵化的公司，他可以直接对电脑说话，Aqua会把他说的内容转录到他正在使用的工具中。目前，他频繁切换于Windsurf和Claude Code之间，但有了Aqua，他能有效地以每分钟140字的速度输入指令，这大约是他打字速度的两倍。而且AI对细微的语法和标点错误非常宽容，即使转录不完美也无关紧要。Tom甚至用Aqua完成了这次演讲的整个撰写。接下来，请务必经常重构。

当代码正常工作并且关键的测试已经实现时，你可以随意重构，因为你知道测试会捕捉到任何回归。你甚至可以要求LLM识别代码库中看起来重复或适合重构的部分。这同样是任何专业软件开发人员都会遵循的建议。避免编写数千行长的文件，保持它们小巧和模块化。这使得人类和LLM都能更容易理解代码的运作。最后，持续实验！

这个领域的最新技术似乎每周都在变化。Tom会尝试每一个新发布的模型，看看它们在不同场景下的表现如何。有些模型更擅长调试，有些擅长长期规划，有些擅长实现功能，还有些擅长重构。例如，目前Gemini似乎最适合进行整个代码库的索引和制定实现计划，而Sonnet 3.7（至少对他而言）似乎是实际实现代码更改的领先竞争者。几天前，Tom尝试了GPT-4.1，但说实话，他并不太满意。它提出了太多问题，而且实际实现也多次出错。但他下周会再次尝试，相信情况又会发生变化。感谢观看！如果你有任何关于如何充分利用这些模型的技巧或窍门，请在评论区分享。

“这个领域的最新技术似乎每周都在变化。我尝试每一个新发布的模型，看看它们在不同场景下的表现如何。”