Vibe Coding 项目总烂尾？三个动手前的思考技巧

你是不是也遇到过这样的情况：用 Vibe Coding 做项目，想到哪做到哪，做着做着，自己都不知道下一步该干嘛了；跟 AI 你一句、我一句地聊，改着改着它把前面做的全忘了，越改越乱；好不容易东西做出来，一看根本不是你想要的，最后只能推翻重写，或者干脆烂尾。

其实很多人对 Vibe Coding 有误解。Vibe Coding 里这个「Vibe」的过程才是最重要的——你的思考决定了 AI 怎么动手。对 AI 来说写代码非常简单，但前提是它得知道要写什么。

所以真正决定一个项目成不成的关键，根本不在写代码，而在你动手之前的思考。

这篇教程给你三个动手之前必须做好的技巧：优先找对标、文档驱动、前端先行。整个过程不用写任何代码，都是 AI 编程中的思考技巧，跟着思路走就行。

下面是本期提到的三个网站，都是动手前「找对标」会用到的，先放在这里方便你随时查。

动手写代码之前的第一步，是找对标。

先给你一个最重要的观念：新手做 Vibe Coding，千万别一上来就想着「我要原创一个东西」。说句实话，你现在能想到的绝大多数产品，早就有人做出来、而且做得很好了。你要做的不是从零发明，而是找到那个做得好的，站在它的肩膀上去改。

最省事的一种做法——直接去 GitHub 上找开源项目。

Vibe Coding 圈里已经被新手做烂的那几样：记账、笔记、todo 待办，你打开 GitHub 一搜一大把，而且人家功能比你做得全得多。你想做个笔记软件？早就有项目做得非常成熟。你想做个看板？有的项目都迭代好多年了。很可能你脑子里那个需求，早就被某个开源项目完整满足了——这种时候还自己从头写，就是纯纯重复造轮子。

开源最大的好处是你能直接拿来用、直接改：

1. 找到合适的项目，克隆到本地
2. 让 AI 在它的基础上接着帮你迭代
3. 不光快得多，最后得到的还是一个更成熟、更完整的产品

那如果你想做的东西没有现成开源能直接套用呢？比如你开了个卖饰品的小店，或者做定制，想给店做一个展示用的门店网站——网上不一定有现成的能直接拿来用。这种时候，就去找参考。

给你两个网站：

• One Page Love：里面全是各种各样的单页落地页，特别适合个人做 Vibe Coding 拿来参考
• reallygooddesigns：大量成熟的设计方案，而且按不同分类做了评选，直接找它总结出来的优质对标

不过找参考不是看个热闹。尤其如果你没什么产品设计经验，看这些页面的时候一定要带着问题去想：

• 我这个店的网站，到底需要哪些功能？
• 这些功能该怎么摆、放在哪儿？
• 哪些是必须有的，哪些其实我根本用不上？

把这几个问题想清楚，一个属于你自己门店网站的框架，心里就有谱了，剩下的就是让 AI 照着搭出来。

不管是找开源还是找同类，意义都一样：省下从零思考的时间，并且一开始就有一个完整、成熟的框架，不至于想到哪做到哪，做着做着结构全乱、最后烂尾。所以记住，Vibe Coding 动手之前，先去找对标。

找完对标，第二个技巧是文档驱动。我们先看看一个真实项目的目录长什么样。

这是我自己的个人站「搞定空间站」项目。里面有一个专门的文件夹叫 PRDs，按一个一个版本、一个一个功能分好了子文件夹——初始版本、登录功能、许愿墙……每加一个新功能，就开一个新文件夹。

点开其中一个，比如「许愿墙」，里面装的就是这个功能的全套文档：

PRDs/
  初始版本/
  登录功能/
  许愿墙/
    产品 PRD
    UI 设计文档
    开发计划

这一个功能从想法到上线，全程都有文档记着。等这一版做完，就整体提交一次、存个档，再开始下一版。

这里每一份文件，都是用来指挥 AI 干活的：

把这三份文档先写好，再让 AI 动手，它干起活来又准又稳。

为什么一定要这么做？因为很多新手的习惯正好相反。

问题： 工具一装好，就直接跟 AI 聊：「帮我做个什么东西」。AI 开始胡写一通，写一段你看一眼，再说「加个功能」「改个设计」，你一句、它一句地往下做。

这个习惯是从我们平时跟 AI 聊天带过来的，但做 Vibe Coding，这种工作方式就是错的。

原因： Vibe Coding 要写大量代码，功能一多，很容易就把 AI 的上下文吃满了。你别以为换个一百万上下文的大模型就没事——该满还是满，写不了几个功能它就扛不住了。一旦满了，AI 就开始忘事：前面做过啥记不全，于是越改越乱。这就是你项目崩掉的根源之一。

所以 Vibe Coding 不能靠对话驱动，要靠文档驱动：在开始实施之前，把想法完整、有结构地写下来，让 AI 先有一个整体概念，再逐步推进。

那想长期迭代、不断加新功能呢？答案还是文档：像前面一样，新建一个文件夹，写新的 PRD，描述清楚要新增的功能和它具体该怎么设计，再让 AI 建立开发计划去实现它。

说到底就一句话：用你的文档版本，去驱动你的开发版本。规划在前，代码在后，你的项目才稳得住。

学会用文档驱动之后，实际开发时还有一个顺序上的技巧，能帮你省下大量返工时间：前端先行，先做 demo。

Demo 长得跟最终产品差不多，但背后是空的，不具备任何实际功能：按钮点了没反应，列表数据是假的。它的意义在于——让你在还没真正开发功能之前，就提前看到这个产品大概长什么样、能干些什么。

为什么这一步这么关键？因为成本结构。

虽然现在 AI 编程能帮我们很快实现很多功能，但这个成本结构是不变的：一旦产品开始进入正式开发，你消耗的 token 资源会是设计阶段的几十上百倍。

• 一个 demo 几乎不怎么费资源，你在这个阶段发现问题、改方向，成本极低
• 反过来，如果你跳过这一步，花几个小时把整个产品全开发完，结果一看某个核心功能根本不是你要的——这时候想改就牵一发动全身，不光要改代码，可能连前面的设计文档都得跟着推翻重写

所以你要做的，就是把可能出问题的地方，尽量在最靠前、最便宜的阶段就暴露出来、解决掉。

具体怎么做？举个例子：我想做一个数据分析产品，已经有了对应的产品文档和设计稿。在这个基础上，就可以先让 AI 写一个 demo 页面，这样我就能直观看到产品大概有哪些功能、怎么布局。

对 AI 说：

请基于现有的产品文档和设计文档，帮我做一个 demo 页面：
1. 展示 PRD 中要求的核心功能板块
2. 展示主要页面和最核心的状态
3. 呈现产品的设计配色以及功能模块
4. 不用做具体的逻辑

看到 demo 之后，你对照一下是不是和你预期一致，把可能出问题的地方，尽量在最靠前、最便宜的阶段就暴露出来、解决掉。

记住一句话：能在前面用一个 demo 解决的问题，千万别拖到全部开发完之后。先做个能看的，确认没问题，再往里填功能。

以上就是做好 Vibe Coding 的三个核心技巧。最后快速回顾一下：

这三步其实都在干同一件事：先把方向找对，先把框架想清楚，先看到东西大概长什么样，然后再让 AI 去动手。

做到这三点，你就不会再像以前那样做着做着就乱了、崩了，而是能稳稳当当地把一个项目从头做到尾。

Vibe Coding 真正的门槛，从来都不是 coding，而是 vibe——你动手之前那点思考。把思考做在前面，普通人也能用 AI，把脑子里的想法稳稳地变成一个真正能用的东西。