vibe design 与 vibe coding：分岔点在哪，为什么重要

关于 vibe design vs vibe coding 的大多数解释都止步于一个定义：一个生成设计，一个生成代码，完。这话没错，但毫无用处。我在 Open Design 做的正是这两者之间的接缝——也就是一份生成出来的设计本该变成可运行界面的那一段——我可以告诉你，钱不在定义里。钱在它们之间的那道缝隙：一份漂亮的原型永远没能上线的地方，以及生成出来的代码悄悄偏离了任何一套连贯设计的地方。把这道分岔搞错，你每一次都得用这两种货币之一来付账。

所以这不是又一篇术语表。它讲的是真正的区别、那两个没人会写进功能页的失败模式，以及该在什么时候伸手去抓哪一个的判断框架。如果你想先从最底层的定义看起，什么是 vibe design 这篇入门里有。

真正的区别：同一种本能，不同的产物

两者都源自同一种本能——描述出那个vibe（一种感觉、一个方向、一份参照），让 AI 产出点东西，而不是手动摆放每一个矩形、手动敲下每一个 div。它们的分岔在于：你最后手里握着的是什么：

• vibe design 产出的是一份设计——一屏画面、一个布局、一份你看着它、对它做出反应的原型。这个产物是一个决定：「对，就这个方向。」
• vibe coding 产出的是代码——一个你能点击的、可运行的前端。这个产物是一份交付物：「这个能跑。」

其余的一切，都从这一处分岔衍生而来。设计改起来便宜，却根本没法上线。代码能上线，但重新调整样式很贵。这意味着这两种工具的失败方式恰好相反——而这一点，而不是那个定义，才是真正应该左右你选择的东西。

	vibe design	vibe coding
你得到的	一份可编辑的设计 / 原型	可运行的前端代码
为什么而优化	探索方向	产出能跑的东西
改动的代价	便宜——它只是一张图	昂贵——它是一次构建
能照原样上线吗？	不能——还需要被构建出来	能——但样式全凭模型猜
典型工具	Visily、Uizard、Figma AI	v0、Lovable、Bolt
败在	原型悬崖	设计漂移

两个没人提醒你的失败模式

原型悬崖（vibe design 的失败）。你在 30 秒里生成出某个美得不行的东西，满屋子人点头，然后它就这么搁在那儿——因为原型是对一个应用的描述，不是一个应用。总得有人把它造出来，而原型越漂亮，等构建出来变了样时的沉没成本就越大。同一屏「完成了」的画面，我用代码重做的次数，多到我都不太好意思承认。原型感觉像是进展；其实它是一张欠条。

设计漂移（vibe coding 的失败）。这一个会让团队措手不及。让一个代码生成工具一屏接一屏地生成，每一屏都看似合理却又微妙地不对劲——这里按钮圆角不一样，那里一抹偏离色板的灰，间距也几乎对上了。Reddit 上有个帖子就一句话：「vibe coding 造成的设计漂移简直离谱」，整个问题被这一行说尽了。代码能跑，所以它看上去像是上线了——但你已经攒下了十几个差一点点的近似品，它们加在一起并不构成一套系统。没人定下过这套设计；模型猜了十二遍。

下面这点才是要害：这两种失败的根因是同一个。原型悬崖和设计漂移之所以都会发生，是因为设计和代码不共享同一个事实源。原型不知道自己会被怎么造出来；代码不知道设计系统规定了什么。把这一件事修好，两种失败模式就基本都消失了。

什么时候该伸手抓哪一个

跳过那句「看情况」。下面是我会做的判断：

当产物是一个决定时，伸手去抓 vibe design。你在探索方向，你需要在任何人写代码之前先拿到干系人的认可，房间里还没有工程师，或者你正处在那种乱糟糟的从零到一阶段——在这个阶段，扔掉十个方向正是重点所在。你要的是用最便宜的方式看到选项、再否掉它们。别拿它上线——拿它来做决定。

当产物必须能跑时，伸手去抓 vibe coding。原型需要真实的交互，你已经过了选方向、进到了「让它跑起来」，或者通往认知的最快路径就是点击一个活的东西。只是进场时要心里有数：你已经签下了管理漂移的责任——这意味着你需要一套生成过程真能遵循的设计系统，光靠 vibe 不行。

判断你处在哪一边的信号：问一句「下一个决定是这东西应该是什么，还是这东西能不能用？」前者是 vibe design。后者是 vibe coding。多数团队伸手去抓的是自己喜欢的工具，而不是自己其实正在回答的那个问题——错就错在这儿。

真正的答案：让它们成为同一个闭环

「设计对编码」这种框定本身就是陷阱。一旦把它们当成两个分开的步骤，你就得到一次交接——而交接正是这两种失败模式栖身的地方。那些不失血的团队把它们当作同一个闭环，而闭合这个环的东西平淡无奇：一套两半都得遵循的、真实而共享的设计系统产物。

这正是 Open Design 押注的赌注。这套设计系统不是代码读不到的 Figma 库，也不是模型会无视的样式指南——它是一份可移植的 DESIGN.md 文件，设计这一步和代码生成那一步都消费它。从它出发生成设计，对照它生成代码，于是原型没法掉下悬崖（它早已指向真实的代码），代码也没法漂移（它被钉死在系统上）。vibe design 和 vibe coding 不再是一场对决，而成为从意图到上线的同一套动作。至于今天分立于这条线两侧的那些工具，我在 vibe design 工具一文里把这一片都过了一遍。

FAQ

vibe design 和 vibe coding 有什么区别？vibe design 生成一份你对它做出反应的设计；vibe coding 生成你可以使用的、可运行的代码。同样是意图优先的本能，产物不同——一个是决定，一个是交付物。

vibe design 是不是就是给设计师用的 vibe coding？不是。vibe coding 产出代码（除非有一套系统约束它，否则设计会漂移）；vibe design 产出设计（除非有人把它造出来，否则它永远不会上线）。它们是互补的两半，而不是同一样东西换个受众。

我该先学哪个？哪个对得上你的下一个决定就学哪个：这东西应该是什么（vibe design）还是这东西能不能用（vibe coding）。长远来看，杠杆在于把它们连起来，让任何一个都不会单独失败。

vibe coding 会取代设计师吗？它取代的是手动摆放矩形，不是决定什么才对。关于什么应该存在的判断——以及那套让它保持连贯的系统——恰恰是自动化不了的那部分。漂移就是证据。

结论

vibe design 和 vibe coding 不是竞争对手；它们是同一套动作的两端，而每一个把它们当成分开步骤的团队，都在中间那段交了过路费——要么是一份永远没上线的原型，要么是一个不断漂移的 UI。按你面前的那个问题来选：是在决定它应该是什么，还是在让它跑起来。然后做那件几乎没人做的事——给两半同一套设计系统去遵循，让那个 vibe 一路从意图存活到你自己拥有的、已上线的代码。