Vibe Coding很爽,但别把文档扔了

Vibe Coding火了。

一句话描述需求，龙虾刷刷刷就给你做出一个能跑的Demo。

于是很多人开始说：文档是上个时代的产物，以后直接用Demo沟通就行了。

听起来很对。

但实践下来，我发现这话只对了一半。

Demo的魔力

先说Demo好在哪。

以前产品经理写完PRD，拉个评审会，讲了一小时，技术说”没听懂”，业务说”不是我要的”。

现在呢？

跟龙虾聊几轮，十分钟出一个可交互的Demo，往群里一丢。

所见即所得，谁都看得懂。

不用脑补了，不用猜了，点一点就知道是不是自己要的。

达成共识的效率，直接翻了几倍。

而且Demo还有一个隐藏好处——你能像用户一样去体验。

文字写得再好，你也很难感受到”这个按钮放在这里到底顺不顺手”。

Demo可以。

但Demo有个致命盲区

Demo让你看见了”做出来是什么样”。

但它藏起了一个更重要的问题：为什么要做？

我见过太多这样的场景——

Demo做出来了，大家一看，“挺好的，上吧”。

上了之后，数据不动。

回头一想才发现：

·这个功能到底解决用户什么问题？没想清楚

·目标用户是谁？没定义

·成功指标是什么？没定

·竞品怎么做的？没看

·过往数据什么表现？没拉

·这个策略的逻辑是什么？没梳理

·怎么验证和迭代？没规划

Demo太直观了，直观到让你跳过了所有”为什么”，直接冲向”是什么”。

大家围着Demo讨论的全是交互细节——按钮颜色、弹窗位置、文案措辞。

没人问一句：这件事该不该做？

文档的真正价值

很多人觉得写文档是形式主义。

不是。

写文档的过程，就是逼自己想清楚的过程。

你写目标的时候，会问自己：这个目标合理吗？能量化吗？

你写背景的时候，会问自己：数据支撑在哪？用户真的有这个痛点吗？

你写策略的时候，会问自己：为什么是这个方案？有没有更好的？

你写验收标准的时候，会问自己：怎么算做成了？做不成怎么办？

每写一行字，都是一次自我质疑。

这些质疑，在看Demo的时候不会发生。

因为Demo给你的是一个”已经完成”的东西，你的大脑会自动切换到评价模式——好不好看、顺不顺手。

而文档给你的是一个”还在思考”的过程，你的大脑会保持在分析模式——对不对、该不该、够不够。

一个让你评价答案，一个让你审视问题。

两者不是替代，是组合拳

所以最好的方式是什么？

先写文档，想清楚为什么做、做什么、怎么衡量。

再出Demo，让所有人看见做出来什么样。

文档解决”想得清”的问题。

Demo解决”看得见”的问题。

想得清 + 看得见 = 真正的共识。

而且龙虾时代，两者都更容易了

以前写文档要半天，做Demo要几天。

现在呢？

让龙虾帮你写文档，你来审视和补充，一小时搞定。

让龙虾帮你做Demo，你来体验和调整，半小时能看。

两件事加起来，可能还没以前单写一份PRD花的时间长。

成本这么低，为什么要二选一？

Vibe Coding真正该有的姿势

不是”用Demo替代文档”。

而是——

第一步：跟龙虾聊清楚为什么做。

目标、用户、数据、策略、验证方案，用文档沉淀下来。

这一步用上篇讲的反问式协作，效果最好。

第二步：让龙虾快速出Demo。

基于想清楚的方案，做出可交互的原型。

第三步：带着文档和Demo一起评审。

文档告诉大家”为什么做”，Demo告诉大家”做出来什么样”。

有理有据，有图有真相。

这才是VibeCoding最该有的样子。

最后一句话

Demo能让你看见答案，文档能让你看见问题。

光有答案没有问题，你都不知道自己在解什么题。