嗨,我是汤姆,我是YC的合伙人。过去一个月我一直在尝试用vibe coding编写一些副项目,我发现它不仅非常好,而且如果你愿意尝试和学习最佳实践,你还可以显著提高熟练度。在这个视频中,我想分享一些在vibe coding中获得良好结果的方法。这有点像
一两年前的提示工程,人们每周都在发现新东西,并在社交媒体上发布。最好的技术与专业软件工程师可能使用的技术相同。有些人会说,这不是vibe coding,对吧?你现在只是在进行软件工程。我不
我认为这无关紧要。我们试图使用这些工具来获得最佳结果。YC春季批次几周前刚刚开始。在我给你我的vibe coding建议之前,让我们听听创始人们关于他们今天如何充分利用AI工具的技巧。如果你卡在一个AI无法实现或调试某些东西的地方,它只是陷入循环,
有时访问LLM的网站,比如直接访问UI,然后粘贴你的代码并提出同样的问题,就可以得到一个结果,而无论出于何种原因,IDE都无法得到。你可以通过这种方式解决你的问题。所以我会说同时在同一个项目上加载Cursor和Windsurf。Cursor速度更快。所以你可以做很多前端工作,更多全栈方面的工作,将前端链接到后端。Windsurf思考的时间更长一些。我过去常常一边在手机上滚动浏览,一边输入代码,构建这个代理,或者,你知道的,像……
像修改这个提示,我会滚动浏览,修复,滚动,或者,你知道的,粘贴错误。现在,当我等待Windsurf思考时,我可以使用Cursor,你知道的,开始更新前端。有时我会同时加载两者,并使用相同的上下文。也许如果我试图更新前端,我会让它像那个文件一样进行样式设置。然后我会同时按Enter键。然后他们会
两者基本上都会给我提供略微不同的相同前端迭代,我会选择我更喜欢的一个。我的建议是将AI视为一种不同类型的编程语言,将vibe coding视为一种新的编程语言。因此,你不是用代码编程,而是用语言编程。而且,呃,
因此,如果你想获得良好的结果,你必须以非常详细的方式提供许多必要的上下文和信息。我通常从相反的方向开始vibe coding。也就是说,首先从测试用例开始。我手工编写我的测试用例。我不使用任何LLM来编写我的测试用例。
完成后,我就有了LLM可以遵循的强大的防护措施来生成代码。然后他们可以自由地生成他们想要生成的代码。一旦我在测试用例中看到这些绿色的标记,工作就完成了。我不需要微观管理我的代码库。我只是大致了解一下代码的模块化程度。除此之外,一切都很好。是的,我认为首先花不合理的时间
在一个纯粹的LLM中构建你想要构建的内容的范围和实际架构,然后再将其卸载到Cursor或任何其他类型的编码工具中,让它在代码库中自由运行,随意生成实际上不起作用的东西,这一点非常重要。所以请确保你理解你正在构建的实际目标是什么。——我的建议是密切关注LLM在回答你的问题时是否陷入了死胡同。
如果你注意到它一直在重新生成代码,而且看起来有点奇怪,它实际上无法弄清楚。如果你发现自己一直在复制粘贴错误消息,这可能意味着某些地方出了问题,你应该退一步,甚至提示LLM,说,嘿,让我们退一步,尝试检查它失败的原因。是因为你没有提供足够的上下文
让LLM能够弄清楚吗?或者你只是运气不好,它无法完成你的请求?这里最主要的主题是让LLM遵循优秀的专业软件开发人员会使用的流程。所以让我们深入探讨一些我见过的最好的vibe coding建议。
首先,从哪里开始?如果你以前从未编写过任何代码,我可能会选择Replit或Lovable之类的工具。它们为你提供易于使用的可视化界面,并且是直接在代码中尝试新UI的好方法。许多产品经理和设计师实际上直接在代码中实现新想法,而不是在Figma等工具中设计模型。
仅仅因为它太快了。但是当我尝试这样做时,我对UI印象深刻,但是当我想更精确地修改后端逻辑而不是纯粹的UI更改时,像Lovable这样的工具开始出现问题。我会在这里更改一个按钮,后端逻辑会……
奇怪地改变。因此,如果你以前编写过代码,即使你像我一样有点生疏,你也可以直接跳到Windsurf、Cursor或Claudecode等工具。选择好要使用的工具后,第一步不是深入编写代码。相反,我会与LLM一起制定一个全面的计划。
将其放在项目文件夹中的markdown文件中,并不断参考它。这是一个你与AI一起制定的计划,你在实施项目时会逐步执行它,而不是试图一次性完成整个项目。
因此,在我创建了该计划的第一稿之后,我会检查它,删除或移除我不喜欢的部分。我可能会明确地将某些功能标记为“不会做”、“太复杂”。你可能还希望保留一个以后的想法部分,你知道的,告诉LLM,看,我考虑过这个,但现在不在范围内。一旦你有了这个计划,就与LLM一起逐节实施它,并明确地说,让我们现在只做第二节。
然后你检查它是否有效。你运行你的测试并提交到git。然后让AI返回你的计划并将第二节标记为已完成。我可能不会期望模型能够一次性完成整个产品,特别是如果它们很复杂的话。我更喜欢逐个完成,并确保我每个步骤都有一个有效的实现,并且至关重要的是将其提交到git,以便如果下一步出现问题,可以回滚。
但说实话,这个建议在未来两三个月内可能会改变。模型改进得如此之快,很难说我们在不久的将来会走到哪里。我的下一个建议是使用版本控制。版本控制是你的朋友。虔诚地使用Git。我知道这些工具具有这种回滚功能,
我还不太信任它们。因此,我总是确保在开始一个新功能之前,我有一个干净的Git状态,以便如果AI偏离方向,我可以回滚到已知的有效版本。所以不要害怕在它不起作用时使用Git reset head hard,然后再次尝试。我发现如果我多次提示AI来尝试让某些东西工作,我会得到不好的结果。
它往往会积累一层又一层的糟糕代码,而不是真正理解根本原因。你可能会尝试四、五、六个不同的提示,最终得到解决方案。我实际上只会采用该解决方案
Git reset,然后将该解决方案提供给AI,在一个干净的代码库中,以便你可以实现该干净的解决方案,而不会出现层层累积的废料。接下来你应该做的是编写测试。好吧,让你的LLM为你编写测试。他们在这方面做得相当不错,尽管他们通常默认编写非常低级的单元测试。我更喜欢将这些测试保持在非常高的级别。
基本上,你想模拟某人点击网站或应用程序,并确保这些功能端到端地工作,而不是基于单元的基础测试函数。因此,请确保在继续下一个功能之前编写高级集成测试。LLM有一个坏习惯
对不相关的逻辑进行不必要的更改。因此,你告诉它修复那里的东西,它只是毫无理由地更改了这里的一些逻辑。因此,有了这些测试套件,尽早发现这些回归将识别出LLM何时偏离方向并进行了不必要的更改,以便你可以重置并重新开始。请记住,LLM不仅仅用于编码。
在构建这些副项目时,我将它们用于许多非编码工作。例如,我让ClaudeSonic3.7配置我的DNS服务器(这始终是我讨厌的任务)并通过命令行工具设置Heroku托管。它是我的DevOps工程师,并将我的进度提高了10倍。我还使用ChatGPT为我的网站favicon创建图像,即出现在浏览器窗口顶部的那个小图标。
然后Claude获取该图像并编写一个快速的一次性脚本,将其调整为我需要的六种不同大小和格式,以便在所有不同平台上使用favicon。因此,AI现在也是我的设计师。好的,现在让我们看看错误修复。
当我遇到任何错误时,我做的第一件事就是直接将错误消息复制粘贴回LLM。它可能来自你的服务器日志文件或浏览器中的JavaScript控制台。通常,此错误消息足以让AI识别并修复问题。你甚至不需要解释哪里出了问题或你认为哪里出了问题。只需错误消息即可。
就足够了。它非常强大,以至于我很快就会期望所有主要的编码工具都能够摄取这些错误,而无需人工复制粘贴。如果你仔细想想,我们的价值在于复制粘贴机,这有点奇怪,对吧?我们将思考留给了LLM。但我认为复制粘贴将消失,而这些LLM工具将能够跟踪日志或,你知道的,
启动一个无头浏览器并检查JavaScript错误。对于更复杂的错误,你可以要求LLM在编写任何代码之前考虑三个或四个可能的原因。在每次修复错误的尝试失败后,我会重置git并重新开始。同样,你不会积累层层累积的废料。不要在不重置的情况下多次尝试修复错误,因为LLM只会添加更多垃圾。Git reset,重新开始。并添加日志记录。日志记录是你的朋友。
如果怀疑,如果它不起作用,请切换模型。可能是CloredSonic 3.7,可能是OpenAI模型之一,也可能是Gemini。我经常发现不同的模型在其他模型失败的地方取得成功。如果你最终找到了一个棘手错误的根源,我会重置所有更改,然后向LLM提供非常具体的说明,说明如何在干净的代码库中修复该精确的错误,以避免这种情况层层累积的
垃圾代码。下一个技巧是为LLM编写说明。将这些说明放在Cursor规则、Windsurf规则、爪形markdown文件中。每个工具都有略微不同的命名约定。
但是我知道一些创始人为他们的AI编码代理编写了数百行说明。这使得它们变得非常非常有效。网上有很多关于在这些说明文件中放入什么的建议。我会让你自己去寻找。好的,让我们谈谈文档。我仍然发现将这些代理指向在线网络文档仍然有点不稳定。有些人建议使用MCP服务器来访问此文档。
这对某些人有效,对我来说似乎有点过头了。因此,我通常会下载给定一组API的所有文档,并将它们放在我的工作文件夹的子目录中,以便LLM可以本地访问它们。然后在我的说明中,我会说,在你实现这个东西之前,先阅读文档。
它通常更准确。记住一个旁注:你可以使用LLM作为老师,特别是对于不太熟悉编码语言的人。你可能会实现某些东西,然后让AI逐行遍历该实现并向你解释它。这是一种学习新技术的好方法。它比我们过去都喜欢滚动的堆栈溢出要好得多。现在让我们看看更复杂的功能。
如果你正在处理一个新的功能,一个比你通常信任AI实现的更复杂的新功能,我会在一个完全干净的代码库中将其作为一个独立的项目来完成。在没有现有项目复杂性的情况下,获得一个小型参考实现,或者如果有人编写了一个并将其发布在GitHub上,甚至可以下载一个参考实现。然后你将你的LLM指向该实现,
并告诉它在重新实现它到你的更大代码库中的同时遵循它。它实际上非常有效。请记住,小文件和模块化是你的朋友。这对人类编码器也是如此。我认为我们可能会看到向更模块化或基于服务的架构转变
LLM可以在其中工作并保持一致的外部接口,而不是这些具有大量相互依赖关系的大型单体存储库。这些对人和LLM来说都很难。不清楚在一个地方的更改是否会影响代码库的另一部分。
因此,拥有具有稳定外部API的这种模块化架构意味着你可以更改内部结构,只要外部接口和测试仍然通过,你可能就没事了。现在关于选择正确的技术栈的说明。我选择用Ruby on Rails部分构建我的项目,主要是因为我从以前担任专业开发人员时就熟悉它。但是AI的性能让我大吃一惊,尤其是在编写Ruby on Rails代码时。
我认为这是因为Rails是一个拥有20年历史的框架,具有大量完善的约定。许多Rails代码库看起来非常非常相似。对于经验丰富的Ruby on Rails开发人员来说,很明显,特定功能应该位于何处,或者实现特定结果的正确Rails方法是什么。
这意味着在线上有大量非常一致、高质量的Rails代码库训练数据。我的其他朋友在使用Rust或Elixir等语言时不太成功,因为在线上没有那么多训练数据。但谁知道呢?这很快就会改变。
好的,下一个建议。使用屏幕截图。如今,你可以将屏幕截图复制粘贴到大多数编码代理中,这对于演示你看到的UI实现中的错误或从你可能想要在项目中使用的另一个站点中提取设计灵感非常有用。
语音是与这些工具交互的另一种非常酷的方式。我使用YC的一家公司Aqua,基本上我可以对着我的电脑说话,Aqua会将我所说的内容转录到我正在使用的工具中。我目前在Windsurf和Claude Code之间切换了很多,但是使用Aqua,我
我可以以每分钟140个单词的速度输入指令,这大约是我打字速度的两倍。AI对轻微的语法和标点符号错误非常宽容,因此转录不完美实际上并不重要。我实际上是用Aqua写了整个演讲。下一个。
确保经常重构。当你让代码工作并且至关重要的是实现了测试后,你可以随意重构,因为你知道你的测试将捕获任何回归。你甚至可以要求LLM识别代码库中看起来重复的部分或可能是重构的良好候选者。
同样,这只是任何专业软件开发人员都会遵循的一个技巧。你没有数千行长的文件。你将它们保持小巧和模块化。这使得人和LLM更容易理解发生了什么。最后,继续尝试。
这方面最先进的技术似乎每周都在变化。我尝试每个新的模型版本,看看哪个在每个不同的场景中表现更好。有些更擅长调试、长期规划、实现功能或重构。例如,目前Gemini似乎最适合整个代码库索引和提出实施计划。
而Sonnet 3.7,至少对我来说,似乎是实际实施代码更改的主要竞争者。几天前我尝试了GPT 4.1,说实话,我还没有那么印象深刻。它只是向我提出了太多问题,实际上也多次实现了错误的结果。但我下周会再次尝试,我相信情况会再次改变。感谢您的观看,如果您有关于如何充分利用这些模型的技巧或窍门,我很乐意听到。请在下面的评论中分享它们。