从 idea 到 demo：vibe coding 收敛策略与最小闭环实践

1. 为什么“从 idea 到 demo”这一步，比你想的要难得多

很多人对 vibe coding 的理解停留在“对着 AI 说几句话，代码就自己长出来了”。我一开始也这么想，直到真正拿一个模糊的念头去跑完整流程，才发现最卡人的根本不是写代码，而是从一团感觉里提炼出一个能被验证的最小闭环。idea 在你脑子里的时候是完美的，一旦要落成 demo，所有没想清楚的地方都会暴露出来：输入是什么、输出长什么样、哪一步先跑通、哪些东西可以暂时假装不存在。

这篇内容适合两类人：一类是脑子里攒了一堆想法但从没动手落地过的，另一类是已经会写点代码、但每次做 demo 都半途而废的。我会把“从 idea 到 demo”拆成一条可复现的路径，重点讲清楚每个环节为什么这么设计，而不是丢给你一堆工具名让你自己猜。vibe coding 的核心不是让 AI 替你思考，而是让你把思考的颗粒度降到 AI 能接住的水平，然后你负责判断和收敛。

先说一个反直觉的结论：demo 阶段最该砍掉的，恰恰是你最得意的那个功能。因为 demo 的唯一使命是证明“这条路走得通”，不是证明“这个产品很完整”。我见过太多人卡在第一步，就是因为想把 idea 的全部野心塞进第一个 demo，结果每个模块都只做了三成，拼起来跑不动，最后连“到底哪里不行”都说不清。所以下面这套流程，本质是一套收敛策略，帮你把 idea 削到只剩一根主干，再用 vibe coding 的方式快速把它立起来。

2. 把脑子里的感觉翻译成一句话：idea 收敛的三个动作

2.1 先写“用户做完这件事之后得到了什么”，而不是“我要做什么”

大部分人描述 idea 的方式是功能视角：“我想做一个能自动整理笔记的工具”。这句话对开发没用，因为它没有定义“整理”是什么、输入从哪来、输出给谁看。正确的起点是结果视角：用户把一堆散乱的笔记丢进来，五分钟之后拿到一份按主题分好组、每条都带一句话摘要的清单。你看，同样一件事，第二种描述里已经藏了输入、输出、时间预期和验收标准。

我自己的习惯是拿一张纸，逼自己用“谁 + 在什么场景下 + 做了什么 + 得到什么”这四段式写一句话。写不出来，说明 idea 还没收敛到能开工的程度。这一步不需要任何工具，但它决定了后面 vibe coding 的效率——因为你对 AI 的描述质量，直接取决于你对自己的描述质量。

2.2 找出那个“没有它就不成立”的核心动作

一句话描述完之后，接着问自己：这件事里哪一个动作是缺了就整个不成立的？还是拿笔记工具举例，核心动作不是“分组”，也不是“摘要”，而是“把非结构化的文本变成结构化的条目”。分组和摘要都是在这个动作之上叠加的。demo 阶段你只需要把这个核心动作跑通，哪怕分组是写死的规则、摘要是固定模板，都无所谓。

这里有个很实用的判断标准：如果这个动作可以用一句“输入 X，经过 Y，输出 Z”说清楚，它就是核心动作。说不清楚的，要么是还没想明白，要么它其实是好几个动作粘在一起，需要继续拆。我踩过的坑就是一次性想做三个核心动作，结果每个都只做了一半，调试的时候根本分不清是哪个环节出的问题。

2.3 给 demo 划一条“到此为止”的线

收敛的最后一步是明确这个 demo 不做什么。这一步最容易被忽略，但它恰恰是 demo 能做完的保障。不做的清单可以很长：不做登录、不做持久化、不做错误处理、不做移动端适配、不做性能优化。每一条“不做”都是在给自己省时间，也是在给 AI 减少需要理解的上下文。

我一般会把“不做清单”和“要做清单”并排写，做完一项划掉一项。当“要做清单”全部划完，demo 就算成了，哪怕它丑得不行、只能跑一次、数据是硬编码的。记住，demo 是证据，不是产品。它的价值在于让你和任何看到它的人相信“这个方向可行”，而不是让人夸它做得好。

3. 选对 vibe coding 的起手式：从哪一层开始让 AI 介入

3.1 三种介入时机，对应三种完全不同的体验

vibe coding 不是只有一种玩法。根据你让 AI 介入的时机，体验差别巨大。我把它分成三种：

第一种最稳，但慢；第三种最快，但容易跑偏。我实测下来，从 idea 到 demo 这个阶段，第二种“边想边写”性价比最高。因为 demo 的本质是探索，你不可能在动手前把所有细节想清楚，但也不能完全放手让 AI 乱跑。边想边写的意思是：你定一个方向，让 AI 给你两三个实现方案，你选一个，再让它往下做一层，你再判断。如此往复。

3.2 为什么我不建议一上来就让 AI 写整个项目

很多人第一次用 vibe coding 的方式做 demo，会直接甩一句“帮我做一个笔记整理工具”，然后期待 AI 吐出一个能跑的东西。结果通常是：AI 给了一个看起来完整但跑不起来的骨架，你花在修它的时间比从零写还多。原因很简单——AI 不知道你的验收标准，也不知道你心里的“整理”到底长什么样。

正确的起手式是先让 AI 帮你把核心动作写成一段伪代码或者流程描述，你确认这段描述符合你的预期之后，再让它逐段翻译成真实代码。这个“先对齐再生成”的动作，能省掉后面大量的返工。我现在的习惯是：任何超过五十行的生成，都先要一段自然语言的方案描述，确认无误再动手。

3.3 给 AI 的上下文里，必须包含的三样东西

不管你用哪种介入方式，想让 AI 的输出靠谱，上下文里至少要有这三样：

• 输入输出的具体样例：不要只说“输入是文本”，要给一段真实的文本，再说“输出应该是这样的结构”，附一个真实的结构示例。
• 技术栈的明确约束：用什么语言、什么框架、什么运行环境，越具体越好。模糊的约束会让 AI 自由发挥，而自由发挥在 demo 阶段往往是灾难。
• 验收标准：什么情况下算跑通。比如“给定这段输入，运行后能在终端打印出按主题分组的列表”，这就是一个可验证的标准。

这三样东西准备起来不超过十分钟，但能让 AI 的输出质量提升一个档次。我踩过的坑就是上下文给得太随意，AI 生成了一堆看起来对但根本跑不通的代码，回头排查发现是它默认用了某个我没装的库。

4. 搭一个能跑的最小骨架：环境与依赖的取舍逻辑

4.1 demo 阶段的环境原则：能少装就少装

demo 的环境搭建有一个铁律：每多一个依赖，就多一个跑不起来的理由。我见过太多 demo 死在环境问题上，而不是死在逻辑上。所以我的做法是，能用标准库解决的绝不上第三方库，能用单文件解决的绝不拆多文件，能本地跑的绝不碰服务端。

具体到操作上，我会先问自己三个问题：这个功能标准库能不能做？如果不能，有没有零依赖的替代方案？如果一定要装库，它会不会引入额外的系统级依赖？这三个问题过一遍，大部分不必要的依赖就被砍掉了。比如做文本处理，很多语言的标准库已经够用，没必要一上来就上重型框架。

4.2 依赖装不上时的排查顺序

即便再克制，有时候还是得装东西。装不上是常态，关键是排查要有顺序，不要瞎试。我的一般顺序是：

1. 确认版本：先看你要装的库支持哪些版本，和你当前环境是否匹配。版本不匹配是最常见的原因。
2. 确认网络与源：包管理器的源是否可达，是否需要换源。这一步经常被忽略，但国内环境下换源能解决一大半问题。
3. 确认权限：是不是因为权限不足导致装到了错误的位置，或者根本没写进去。
4. 看完整报错：不要只看最后一行，往上翻，真正的错误原因往往在中间。

这个顺序能覆盖九成以上的依赖问题。我自己的经验是，报错信息里出现频率最高的那个词，往往就是根因，比如反复出现某个路径，那大概率是路径配置的问题。

4.3 骨架跑通的第一条命令应该是什么

环境准备好之后，不要急着写业务逻辑。先写一条能证明环境是通的最小命令，比如打印一行字、读一个本地文件、发一个最简单的请求。这条命令跑通，你才有资格往下走。很多人跳过这一步，直接写业务，结果业务跑不起来的时候，分不清是环境问题还是逻辑问题。

我的习惯是把这条命令单独存成一个文件，跑通之后再往里加东西。这样任何时候出问题，我都能退回到这个已知可用的状态，逐步定位是哪一步引入的故障。这个习惯看起来笨，但它救过我无数次。

5. 核心动作的落地：把一句话需求拆成可执行的生成步骤

5.1 从“一句话需求”到“一段可运行代码”的中间层

前面说的核心动作，比如“把非结构化文本变成结构化条目”，直接丢给 AI 生成代码，效果往往不好。因为这句话里缺了太多中间信息。我一般会在需求和代码之间加一个中间层，用自然语言把核心动作拆成三到五步，每一步都明确输入和输出。

还是拿笔记整理举例，中间层可能是这样：

1. 读入一段多行文本，按空行切成若干块。
2. 对每一块，提取第一行作为标题，剩下的作为正文。
3. 根据标题里的关键词，给每一块打一个主题标签。
4. 把所有块按主题标签分组，输出成列表。

这四步每一步都足够简单，简单到 AI 几乎不会理解错。然后我逐步让 AI 把每一步翻译成代码，每翻译一步就跑一次，确认输出符合预期再往下。这个“拆步 + 逐步验证”的节奏，是 demo 阶段最稳的推进方式。

5.2 每一步都要有可观察的输出

拆步之后，关键是要让每一步都有可观察的输出。什么叫可观察？就是你能看到它到底处理了什么、得到了什么。打印日志、输出中间文件、在终端显示结果，都算。最怕的是写了一大段代码，运行之后什么都没发生，你也不知道它到底跑没跑。

我的做法是，每完成一步，就在终端打印这一步的输入和输出。比如第一步切块之后，打印“切成了 N 块，第一块内容是……”。这样一旦后面出问题，我能立刻定位是哪一步的输入不对。这个习惯在 demo 阶段尤其重要，因为 demo 的逻辑往往是一次性的，没有测试覆盖，全靠肉眼观察。

5.3 遇到 AI 生成结果不对时的三种处理方式

即便拆得很细，AI 还是可能生成不对的结果。这时候不要急着改代码，先判断是哪一类问题：

• 理解偏差：AI 理解错了你的意图。处理方式是重新描述，换一种说法，或者给一个更具体的例子。
• 能力边界：这个任务超出了 AI 当前能稳定处理的范围。处理方式是继续拆，拆到它能处理为止。
• 随机波动：同样的描述，多试几次结果不一样。处理方式是固定一个能用的版本，不要反复重生成。

我自己的经验是，大部分“不对”其实是理解偏差，重新描述一遍就好了。真正遇到能力边界的情况不多，但一旦遇到，硬刚是没用的，只能拆。至于随机波动，接受它，选一个能跑的版本继续往下，不要在 demo 阶段追求完美。

6. 从“能跑”到“能演示”：demo 收尾的取舍与包装

6.1 能跑不等于能演示，中间差了什么

代码能跑通，和你能拿它给别人演示，中间还有一段距离。这段距离不是功能上的，而是体验上的。能跑的代码可能输出一堆乱糟糟的日志，可能每次都要手动改输入，可能跑完就没了。能演示的 demo 需要：一个明确的入口、一段固定的示例输入、一个清晰的输出展示。

我一般会在收尾阶段做三件事：把示例输入固化到代码里或者一个固定文件里，让任何人拿到都能一键跑；把输出整理成人类能看懂的格式，而不是原始的数据结构；写一段三句话的说明，讲清楚这个 demo 做了什么、怎么跑、看到什么算成功。这三件事加起来不超过半小时，但它决定了你的 demo 是“我自己知道它能跑”还是“别人也能看懂它能跑”。

6.2 哪些“不完美”可以留着，哪些必须修

demo 收尾时，你会面对一堆不完美的地方。我的判断标准是：影响演示流程的必须修，不影响的一律留着。比如输出格式难看，不影响演示，留着；但每次跑都要手动改一个路径，影响演示，必须修。再比如处理速度慢，只要在可接受范围内，留着；但偶尔会崩溃，必须修，因为演示时崩溃是致命的。

这个标准能帮你把收尾时间控制在合理范围内。我见过有人为了把 demo 打磨得完美，结果拖了好几周，最后热情耗尽，demo 也没演示成。记住，demo 是拿来证明方向的，不是拿来交付的。它的不完美是正常的，甚至是必要的，因为它提醒你后面还有很长的路要走。

6.3 演示时最该讲的三句话

最后说演示。很多人演示 demo 的时候，花大量时间讲技术细节，结果听众一脸茫然。其实演示只需要讲清楚三句话：这个 demo 解决什么问题、它是怎么解决的、它证明了什么。第一句让人知道你在干嘛，第二句让人知道你怎么干的，第三句让人知道这件事值不值得继续。

技术细节留到别人问的时候再讲。演示的目的是让人相信这个方向可行，而不是让人佩服你的技术。我自己的习惯是，演示前把这三句话写下来，练两遍，确保能在两分钟内讲完。剩下的时间留给提问和讨论，那才是真正有价值的部分。

7. 我在多次“从 idea 到 demo”里踩出来的几条经验

第一条经验是：demo 的代码不值得复用，但 demo 的流程值得复用。我早期总想着把 demo 写成能长期维护的样子，结果每次都在架构上纠结，反而拖慢了验证速度。后来我想通了，demo 就是一次性的，它的价值在于验证方向，不在于代码质量。但“收敛 idea、拆核心动作、逐步验证、收尾演示”这套流程，是可以反复用的，而且越用越顺。

第二条经验是：卡住的时候，往回退一步，而不是往前硬冲。demo 阶段遇到卡点，八成是因为当前这一步的输入不对，或者当前这一步拆得还不够细。这时候正确的做法是退回到上一个能跑通的状态，重新审视这一步的输入和描述，而不是在错误的输入上继续加代码。我踩过的最大的坑就是硬冲，结果越写越乱，最后只能全部推倒重来。

第三条经验是：记录每一步的输入输出，比记录代码本身更重要。demo 是一次性的，代码很快就没用了，但每一步的输入输出样例，是你后面做正式版本时的宝贵参考。我现在做 demo 会单独存一个文件，记录每一步的示例输入和期望输出，这个文件在后续开发里比代码本身还有用。

第四条经验是：别在 demo 阶段追求“优雅”。优雅是正式版本的事，demo 阶段追求的是“能跑”和“能看懂”。硬编码、重复代码、丑陋的输出，在 demo 里都是可以接受的。我见过太多人因为受不了自己写的“脏代码”而反复重构，最后 demo 没做完，热情也没了。忍住，先让它跑起来，优雅的事以后再说。

第五条经验是：给 demo 设一个硬性时间盒。我一般给自己设一天到三天，超过这个时间还没跑通核心动作，就说明这个 idea 要么需要重新收敛，要么当前不适合做 demo。时间盒的作用是防止你无限投入，也逼你在有限时间里做取舍。这个习惯让我避免了很多“看起来能做但实际做不完”的坑。

最后分享一个我一直在用的小技巧：把 demo 的每一步都写成一句“如果……那么……”的断言。比如“如果输入是这段文本，那么输出应该包含三个主题分组”。这些断言就是你验证每一步是否正确的标准，也是你演示时最有说服力的证据。写断言花不了几分钟，但它能让你的 demo 从“我觉得它能跑”变成“我能证明它能跑”。