从零到英雄：毁掉你首次构建会话的 5 个错误

你有了提示词，也有了想法。以下是阻碍你前进的事物，以及如何彻底避开它们的方法。

所以，你已经完成了第一次构建会话。屏幕上出现了一些东西。也许它看起来很棒。也许它接近了目标但还差一点。也许你发现自己陷入了循环，不确定为什么事情没有按照预期运作。

这完全正常。“Vibe coding”（氛围编程）是一种新的工作方式，和任何新技能一样，有少数几种模式几乎每次都会让人们绊倒——尤其是在最初的几次会话中。好消息是：它们始终是那五种相同的模式。一旦你知道了它们，你就能预见到它们的到来。

本文旨在为你提供这条捷径。

我们写这篇文章的目标很简单：

• 指出导致大多数首次构建会话草草收场的五个错误

• 解释每个错误发生的原因（这从来都不是 AI 的问题）

• 向你展示如何在它浪费你另一个小时之前准确修复每一个错误

错误 1 —— 模糊的循环

它的表现形式

你生成了某样东西，但它不太对劲。于是你输入*“让它看起来更好”或“改善设计”。AI 生成了不同的东西。仍然不对劲。你再次输入“让它看起来更好”。*它又变了。三十分钟过去了，你经历了四个版本，但没有一个是你想的那样。

这就是模糊循环。它是迄今为止最常见的首次会话错误。

为什么会发生

AI 并不是在故意刁难你。它真的不知道对你来说*“更好”*意味着什么。它没有参考你的品味、你的受众或让你感到困扰的具体细节。所以它只能猜测——而在模糊的简报下进行的猜测几乎永远是不对的。

解决方法：停止评价，开始提供指引

评价告诉 AI 有什么地方不对劲。指引则告诉它该做什么来替代。

模糊 → “让它看起来更好。” 具体 → “标题字体太细，很难阅读——把它加粗，并加大字号，使它在页面顶部显得醒目。”

在你输入优化提示词之前，问自己：究竟是什么地方不对，又具体应该用什么来替换它？先回答这个问题，然后再输入提示词。

如果你还无法说出哪里不对劲，那就使用 Enter 的可视化编辑器。点击让你困扰的元素，直接调整它；一旦感觉对了，就把你刚才所做的改动描述出来作为下一个提示词。这种点击与描述相结合的方式比单纯靠反复尝试提示词要快得多。

错误 2 —— 全盘重写的陷阱

它的表现形式

某些地方行不通，于是你让 AI 从头开始。新版本出现了不同的问题。你又让它重来。一小时后，你已经看过五个完全不同的版本了——而且你也丢失了之前那些版本中运行良好的部分。

为什么会发生

重新开始感觉很果断。这感觉像是进展。但其实两者都不是。

每一次全盘重写不仅丢弃了错误的部分，也丢弃了所有正确的部分。你差点喜欢的布局，感觉还不错的标题，基本成型的结构。你又回到了零点，面对着一堆全新的问题需要解决。

解决方法：外科手术式而非核武器式

在你要求重写之前，问自己这个问题：是整体都坏了，还是某个特定元素坏了？

几乎总是某个特定元素。找到它。指名道姓。只修复那一个地方。

模糊 → “重来，我不喜欢这个。” 具体 → “导航栏在顶部占用了太多空间——减小它的高度并将链接调小。其他部分保持不变。”

第二个提示词解决了问题，第一个却制造了新的问题。当事情不对劲时，抵制那种推倒重来的冲动。修复那个特定的地方，保留行之有效的内容。

错误 3 —— 功能蔓延（Feature Creep）

它的表现形式

你的产品核心正在运作——虽然不完美，但能运作。于是你添加了一些功能。用户个人资料页面。入职流程。分享功能。现在，你是在一个尚未完全完成的基础之上进行构建。新功能在其他地方引入了一个 Bug。你正在调试一个你本不该还没到那一步就构建的东西。

为什么会发生

当某样东西能工作时，本能就会想去扩展它。核心部分感觉解决了，所以你的注意力跳到了缺失的部分。但核心从未像你决定跳过它时感觉的那样稳固。

解决方法：完成一件事，再进行下一项

在添加任何功能之前，问自己：核心部分是否运作得足够好，以至于添加这个功能会让它更好——还是我添加这个只是为了逃避完成核心部分？

在第一次构建会话中，答案几乎总是后者。

定义什么是核心部分的“完成”。这个产品对于一个真实用户来说，最有用的最小版本是什么？不是令人惊叹，而是有用。先构建那个版本。确保它从头到尾都能运行。然后，仅仅是然后，再添加下一项。

最好的构建不是功能最多的。而是每一个存在的功能都能真正运作的构建。

错误 4 —— 完美主义者的停顿

它的表现形式

你有了能运行的东西。但按钮颜色不太对，所以你花了二十分钟调整。然后标题间距稍微不对劲。又二十分钟。字体粗细。内边距。两小时过去了。产品看起来比开始时稍好一点点，但你还没有展示给任何人看。

为什么会发生

追求完美感觉比发布更安全。当你还在进行完善时，它就还没算错。而一旦别人看到它，他们可能看不懂——面对这种可能比面对一个颜色稍微不对的按钮要困难得多。

解决方法：目标是“好到可以展示”

从他人使用你的产品中获得的 30 秒反馈，比你独自钻研两小时要有价值得多。他们在前 10 秒表现出的困惑——他们点击哪里、在哪里停顿、错过了什么——能确切地告诉你接下来该修复什么。你自己的眼睛，在盯着同一个屏幕几小时后，是无法发现这些的。

为你的会话设定一个规则：当它足够好到可以展示给一个真实的人看时，就停止完善并展示它。而不是等到完美。达到“好到可以展示”就是里程碑。

发布不完美的东西。从中学习。然后改进。

错误 5 —— 独自孤立（The Solo Silo）

它的表现形式

你独自构建，独自完善，独自迭代。你知道每一件东西的用途，为什么每个按钮都在那里，每个部分是干什么的。产品对你来说完全说得通。当你最终展示给别人看时，他们在前 10 秒内就感到困惑了。

你本来三小时前就能知道这些的。

为什么会发生

构建感觉是非常个人的事，尤其是当你第一次这样做时。展示尚未完成的作品会让你感到脆弱。如果他们看不懂怎么办？如果他们认为它设计得很烂怎么办？

这些是真实的恐惧。但它们也是你需要发现的问题。

解决方法：尽早发布，分享链接，观察会发生什么

Enter 会立即将你的项目部署到实时 URL。那个链接是你拥有的最快反馈机制。把它发给一个人——不是为了寻求赞同，而是为了观察。观察他们如何浏览它。留意他们在哪里暂停。留意他们点击了你没预料到的什么地方。留意他们错过了你以为显而易见的地方。

你不需要一百个用户。一个人作为陌生人浏览你的产品 60 秒，比你一周的独自完善更能教会你东西。他们在前 10 秒感到的困惑就是重要信号。根据它采取行动。

尽早发布不是脆弱——这是了解下一步该构建什么的最高效途径。

这五个错误背后的模式

把它们放在一起看，你会发现它们以五种不同的形式表现出同样的东西：留在自己的脑袋里，而不是在现实中进行测试的本能。

模糊循环：描述感觉而不是指引。全盘重写：替换一切而不是修复特定的地方。功能蔓延：在基础稳固前就进行扩展。完美主义者的停顿：完善而不是发布。独自孤立：构建而不是学习。

其中的每一个都是在逃避让构建变得快速有效的反馈循环。而在每种情况下，解决方法都是一样的：保持具体，进行手术式的操作，并尽可能快地将你的工作呈现给现实世界。

现在你知道该留意什么了。你的下一次会话将大不相同。

系列文章的后续内容

你了解了错误。你知道如何避免它们。基础正在变得更加牢固。

再见！