vibe coding能跑不等于有人需要：AI泡沫的认知陷阱

vibe coding能跑不等于有人需要：AI泡沫的认知陷阱 | 前端进阶之旅

Full translation

完整中文译文

工具链的故事现在已经很熟悉了。创始人 prompting，迭代，交付。应用跑起来了。Demo 演示正常。也许 README 也很干净。周末两天，或者两周，一个真实可用的东西就存在了——这东西以前要花好几个月才能做出来。

常见的解读是分发失败。发到 Product Hunt。提交到各种目录。写一条发布动态。试试 TikTok。逻辑是：构建很快，分发也应该跟上。

有时候确实如此。但有一个更前置的层面，是快速构建让人更难看清、而不是更容易看清的。

构建速度是一个供给信号。它说明创始人现在可以快速产出可运行的软件。但它不说明任何关于是否有人在软件所做的事情上本来就处于困境。

在 vibe coding 之前，开发的缓慢实际上强制进行了一种意外的需求测试。如果花六个月构建一个东西，创始人通常会去和人交流，寻找问题真实存在的证据，然后在投入之前会犹豫。摩擦让承诺变得昂贵，从而过滤掉了弱需求。

Vibe coding 去掉了这种摩擦。它让承诺几乎变成免费的。创始人可以用以前做第一次客户访谈的时间，构建出一个完整的、可运行的应用。

这是构建层面的真正胜利。也是为什么这么多 vibe-coded 应用撞上了一面看似意外的墙。那面墙一直都在。只是慢速构建把它藏起来了。

有用的测试不是"这个应用能被构建出来吗？"构建已经回答了这个问题。测试是：在这个应用存在之前，是否已经有人在这个问题上花费时间、金钱，或者在使用 workaround。

有几个信号可以区分两者：

嵌入现有工作流的产品，会遇到那些本来就把任务做得很差的人。他们认得这个工具，因为它去掉了一个他们讨厌的步骤。第一次对话不是"这是干什么的？"而是"这东西怎么没有早点出来？"

先于任何工作流构建的产品，会遇到需要被说服"这个任务值得做"的人。第一次对话是教育。即使产品很好，采用也很慢，因为买家没有当前的理由去改变。

Vibe coding 让第二种情况看起来像第一种。应用能跑，所以感觉上工作流一定存在。但能跑的软件和已经存在的痛苦工作流是两回事。

更难的问题，在构建完成、沉默开始之后，不是"我怎样才能更快地分发这个？"而是：这个方向是否还有生命力——或者说，正确的做法是不是收窄 offerings，重新定位到已经让人痛苦的工作流上，或者在继续构建之前停止，先把需求证据重建好。

这些都不好玩。但它们才是能节省几个月时间的选择，因为构建从来都不是瓶颈。需求证据才是。

我持续记录的几个相关案例：

这些案例里产品都跑起来了。关注也来了。购买时刻没有来。

如果你的 vibe-coded 应用已经上线好几周，沉默仍然是最响亮的信号，下一步可能不是再来一次发布。而是检查方向在构建开始之前是否被验证过。