当传统编程依然需要大量专业知识时，vibe coding 正悄然改变着软件开发的游戏规则。YC 合伙人 Tom Blomfield 过去一个月使用这种新兴的开发方式进行了深入实验，发现它不仅效果惊人，而且通过适当的技巧和实践，任何人都能显著提高使用效果。

从精心制定计划到严格的版本控制，从自动化测试到模块化设计，这些来自硅谷顶级创业加速器的实战经验，揭示了如何充分利用 AI 工具加速开发流程。

不论你是经验丰富的开发者还是完全的编程新手，这篇文章都将帮助你了解如何在 vibe coding 领域取得最佳成果，以及为什么这种开发方式可能代表着软件工程的未来。

初学者的不同起点：选择合适的工具

如果你之前从未编写过代码，可能最好从 Replit 或 Lovable 等工具开始。它们提供了简单易用的可视界面，是直接用代码尝试新 UI 的绝佳方式。许多产品经理和设计师实际上正在直接用代码实现新想法，而不是在 Figma 等工具中设计模型，因为这样做速度非常快。

但当 Blomfield 尝试这些工具时，他发现虽然对 UI 印象深刻，但当他想要更精确地修改后端逻辑而不仅仅是纯 UI 更改时，像 Lovable 这样的工具开始遇到困难。"我在这边更改一个按钮，后端逻辑会莫名其妙地改变，"他解释道。

如果你之前写过代码，即使像 Blomfield 一样有点生疏，你可能可以直接使用 Windsurf、Cursor 或 Claude Code 等工具。这些更专业的工具提供了更精细的控制，适合有一定技术背景的用户。

不要直接开始编码：制定全面的计划

选择好工具后，第一步不是直接开始编写代码。相反，Blomfield 建议与 LLM 合作编写一份全面的计划。将其放在项目文件夹内的 markdown 文件中，并在开发过程中不断参考。

"这是你与 AI 一起制定的计划，在实施项目时逐步执行，而不是试图一次性完成整个项目，"他解释道。完成计划的第一稿后，你应该仔细检查，删除或移除不喜欢的内容。你可能会明确标记某些功能为"不做——太复杂"，也可能保留一个"供以后参考的想法"部分。

有了计划后，与 LLM 一起逐部分实施，明确表示"现在让我们只做第二部分"。然后检查它是否工作，运行测试并提交。然后让 AI 回到计划中，将第二部分标记为完成。

Blomfield 不建议期望模型能一次性完成整个产品，特别是如果它们很复杂。他更喜欢逐步进行，确保每一步都有一个可行的实施方案，并关键的是提交到 Git，这样如果下一步出现问题，可以回滚。

"但说实话，这个建议可能在接下来的 2-3 个月内发生变化。模型进步如此之快，很难说我们在不久的将来会到达什么程度，"他补充道。

版本控制是你的朋友：严格使用 Git

"版本控制是你的朋友。宗教般地使用 Git，"Blomfield 强调。尽管这些工具有一些内置的恢复功能，但他仍然不完全信任它们。因此，他总是确保在开始一个新功能前有一个"干净的 git 状态"，这样如果 AI 偏离正轨，可以恢复到已知的工作版本。

如果 AI 无法解决问题，不要害怕使用"git reset --hard HEAD"命令重置并重新开始。Blomfield 发现，如果一直提示 AI 尝试解决同一个问题，通常会积累层层不良代码，而不是真正理解根本原因。

"你可能尝试四、五、六个不同的提示，最终得到解决方案。我实际上会采取该解决方案，然后 git reset，然后将该解决方案输入到干净的代码库上的 AI 中，这样你就可以实现干净的解决方案，而不会堆积层层垃圾代码，"他建议道。

编写高级测试：拯救你的项目

下一步是编写测试，或者让 LLM 为你编写测试。它们在这方面相当擅长，尽管它们往往默认编写非常低级的单元测试。Blomfield 更喜欢保持这些测试在超高级别。

"基本上，你希望模拟有人点击浏览网站或应用程序，并确保功能端到端工作，而不是在单元级别测试功能，"他解释道。确保在进入下一个功能前编写高级集成测试。

LLM 有一个不好的习惯，即对不相关的逻辑进行不必要的更改。"所以你告诉它修复那边的这个东西，它只是为了完全没有理由而改变这里的一些逻辑，"Blomfield 指出。拥有这些测试套件可以及早捕捉到这些回归，识别 LLM 何时进行了不必要的更改，以便你可以 git reset 并重新开始。

LLM 不仅仅用于编码：解放你的 DevOps

Blomfield 指出，LLM 不仅仅用于编码。他在构建这些项目时将它们用于许多非编码工作。例如，他让 Claude Sonnet 3.7 配置他的 DNS 服务器（这一直是他讨厌的任务）并通过命令行工具设置 Heroku 托管。

"它是我的 DevOps 工程师，使我的进度加快了 10 倍，"他说。他还使用 ChatGPT 为网站创建 favicon（浏览器窗口顶部显示的小图标），然后 Claude 编写了一个快速脚本，将其调整为跨所有不同平台的 favicon 所需的六种不同大小和格式。

"所以 AI 现在也是我的设计师，"Blomfield 补充道，展示了这些工具的多功能性不仅限于纯代码编写。

错误修复的最佳实践：错误消息是关键

遇到任何错误时，Blomfield 首先做的是将错误消息直接复制粘贴回 LLM。这可能来自服务器日志文件或浏览器中的 JavaScript 控制台。通常，这个错误消息足以让 AI 识别并修复问题。

"你甚至不需要解释出了什么问题或者你认为出了什么问题。仅仅错误消息就足够了，"他说。这种方法如此强大，以至于他预计很快所有主要的编码工具都能够在没有人工复制粘贴的情况下摄取这些错误。

对于更复杂的错误，可以要求 LLM 在编写任何代码之前考虑三四种可能的原因。在每次修复错误失败的尝试后，Blomfield 会重置并重新开始，以避免积累层层垃圾代码。

"不要在不重置的情况下多次尝试修复错误，因为 LLM 只会添加更多层次的垃圾。Git reset，重新开始，并添加日志记录。日志记录是你的朋友，"他建议道。

切换模型：不同的模型有不同的优势

如果出现疑问，如果某个功能不能正常工作，Blomfield 建议切换模型。"可能是 Claude Sonnet 3.7，可能是 OpenAI 的模型之一，可能是 Gemini。我经常发现不同的模型在其他模型失败的地方成功，"他解释道。

如果最终找到了棘手错误的根源，他会重置所有更改，然后给 LLM 非常具体的指示，说明如何在干净的代码库上修复那个精确的错误，以避免积累垃圾代码层。

例如，他发现"目前，Gemini 在整个代码库索引和提出实施计划方面似乎表现最好，而 Sonnet 3.7 对我来说至少看起来是实际实施代码更改的领先竞争者。"他最近尝试了 GPT 4.1，但印象不是很深，"它只是给我带来了太多问题，而且实际上太多次地错误实施。但我下周会再试一次，我确信情况会再次改变。"

为 LLM 编写指导规则：提升效率的关键

Blomfield 的下一个建议是为 LLM 编写指导规则。这些指导可以放在 cursor 规则、windsurf 规则或 claw markdown 文件中，每个工具的命名约定略有不同。

"我认识的一些创始人为他们的 AI 编码代理编写了数百行指令，这使他们的效率大大提高，"他说。关于在这些指令文件中放什么内容的建议在网上有很多，Blomfield 建议自行查找这些资源。

这些指令可以包括项目的上下文、代码风格偏好、特定库的使用指南等信息，帮助 AI 更准确地理解你的期望和项目需求。

处理文档：本地访问更可靠

关于文档，Blomfield 发现让这些代理访问在线网络文档仍然有些不稳定。"我经常会下载一组 API 的所有文档，并将它们放在我工作文件夹的子目录中，这样 LLM 可以本地访问它们，"他解释道。

然后，在他的指导中，他会说"在实施这个功能之前去阅读文档"，这通常会使结果更加准确。相比于依赖 AI 对在线文档的理解，这种方法提供了更可靠的结果。

值得一提的是，你也可以使用 LLM 作为教师，特别是对于不太熟悉编程语言的人。你可能实施某些功能，然后让 AI 逐行解释该实施。"这是学习新技术的好方法，比我们过去滚动浏览 Stack Overflow 要好得多，"Blomfield 指出。

处理复杂功能：独立实现再整合

如果你正在开发一个比通常信任 AI 实施的更复杂的新功能，Blomfield 建议将其作为一个完全干净的代码库中的独立项目。在没有现有项目复杂性的情况下，让小型参考实现工作，或者如果有人编写并在 GitHub 上发布了参考实现，就下载它。

然后，指向你的 LLM 参考实现，并告诉它在将其重新实施到你的更大代码库中时遵循该实现。"这实际上效果出奇地好，"他表示。

小文件和模块化是你的朋友。这对人类编码者和 AI 都适用。"我认为我们可能会看到向更模块化或基于服务的架构转变，LLM 有明确的 API 边界，可以在其中工作，同时保持一致的外部接口，而不是这些具有大量相互依存关系的巨大单一代码库，"Blomfield 预测。

选择合适的技术栈：框架约定性越强越好

在选择合适的技术栈时，Blomfield 选择部分使用 Ruby on Rails 构建他的项目，主要是因为他从过去的专业开发经验中熟悉它。"但我对 AI 的表现感到震惊，特别是在编写 Ruby on Rails 代码时，"他说。

他认为这是因为 Rails 是一个有 20 年历史的框架，有大量成熟的约定。许多 Rails 代码库看起来非常相似，对有经验的 Ruby on Rails 开发人员来说，特定功能应该位于何处或实现某个结果的正确"Rails 方式"是显而易见的。

"这意味着在线上有大量相当一致的高质量 Rails 代码库训练数据，"Blomfield 解释道。相比之下，他的一些朋友在使用像 Rust 或 Elixir 这样的语言时成功较少，因为这些语言在线上的训练数据不那么多，"但谁知道，这可能很快就会改变。"

利用视觉和语音：提高交互效率

另一个技巧是使用截图。现在可以将截图复制粘贴到大多数编码代理中，这在演示 UI 实现中的错误或引入来自其他网站的设计灵感时非常有用。

语音是与这些工具交互的另一种非常酷的方式。Blomfield 使用 YC 公司 Aqua，"基本上我可以对着电脑说话，Aqua 将我所说的内容转录到我正在使用的工具中。"使用 Aqua，他可以有效地以每分钟 140 字的速度输入指令，这大约是他打字速度的两倍。

"AI 对微小的语法和标点错误如此宽容，以至于转录不完美实际上并不重要，"他指出，强调了这些工具在处理自然语言输入方面的灵活性。

频繁重构：保持代码质量

当代码正常工作并且测试完成后，你可以放心地重构，因为你知道测试会捕捉任何回归。你甚至可以要求 LLM 识别代码库中看起来重复或可能是重构好候选对象的部分。

"这只是任何专业软件开发人员都会遵循的建议，"Blomfield 说。"你不会有成千上万行的文件。你保持它们小而模块化。这使得人类和 LLM 都更容易理解发生了什么。"

保持代码库整洁和模块化不仅使开发更加高效，还减少了错误和意外行为的风险，特别是在使用 AI 工具时，这些工具可能容易受到代码库复杂性的影响。

持续实验：紧跟技术发展

最后一个建议是保持实验精神。"这些东西的最新技术似乎每周都在变化，"Blomfield 指出。他尝试每个新模型发布，看看哪个在不同场景中表现更好。

有些模型在调试、长期规划、实施功能或重构方面表现更好。例如，正如前面提到的，他发现 Gemini 在整个代码库索引和制定实施计划方面表现最好，而 Claude Sonnet 3.7 在实际实施代码更改方面似乎是领先者。

"我几天前刚试了 GPT 4.1，老实说，我还不太满意。它给我带来了太多问题，而且实际上错误实施的次数太多。但我下周会再试一次，我确信情况会再次改变，"Blomfield 表示，强调了跟踪这一快速发展领域的重要性。

总结：未来的软件开发方向

随着 vibe coding 工具的不断发展，Blomfield 的经验提供了一个宝贵的窗口，让我们了解软件开发的未来可能是什么样子。他的建议不仅适用于当前的工具和模型，还揭示了一种更广泛的方法，即将传统软件工程最佳实践与新兴 AI 功能相结合。

从适当的计划和版本控制到测试和模块化，许多传统软件开发的原则在 AI 辅助编程环境中仍然适用。然而，新工具也开辟了新的工作方式，允许更快的迭代、更广泛的实验和前所未有的生产力。

随着这些模型和工具的持续改进，我们可能会看到软件开发变得更加民主化，使更广泛的人能够创建复杂的应用程序，同时也改变专业开发人员工作的性质和重点。在这个快速发展的领域中，保持开放的态度、愿意实验和适应新方法将是成功的关键。