★ FEATURED ARTICLE 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 介入的时机体验差别巨大。我把它分成三种介入时机你负责的部分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 依赖装不上时的排查顺序即便再克制有时候还是得装东西。装不上是常态关键是排查要有顺序不要瞎试。我的一般顺序是确认版本先看你要装的库支持哪些版本和你当前环境是否匹配。版本不匹配是最常见的原因。确认网络与源包管理器的源是否可达是否需要换源。这一步经常被忽略但国内环境下换源能解决一大半问题。确认权限是不是因为权限不足导致装到了错误的位置或者根本没写进去。看完整报错不要只看最后一行往上翻真正的错误原因往往在中间。这个顺序能覆盖九成以上的依赖问题。我自己的经验是报错信息里出现频率最高的那个词往往就是根因比如反复出现某个路径那大概率是路径配置的问题。4.3 骨架跑通的第一条命令应该是什么环境准备好之后不要急着写业务逻辑。先写一条能证明环境是通的最小命令比如打印一行字、读一个本地文件、发一个最简单的请求。这条命令跑通你才有资格往下走。很多人跳过这一步直接写业务结果业务跑不起来的时候分不清是环境问题还是逻辑问题。我的习惯是把这条命令单独存成一个文件跑通之后再往里加东西。这样任何时候出问题我都能退回到这个已知可用的状态逐步定位是哪一步引入的故障。这个习惯看起来笨但它救过我无数次。5. 核心动作的落地把一句话需求拆成可执行的生成步骤5.1 从“一句话需求”到“一段可运行代码”的中间层前面说的核心动作比如“把非结构化文本变成结构化条目”直接丢给 AI 生成代码效果往往不好。因为这句话里缺了太多中间信息。我一般会在需求和代码之间加一个中间层用自然语言把核心动作拆成三到五步每一步都明确输入和输出。还是拿笔记整理举例中间层可能是这样读入一段多行文本按空行切成若干块。对每一块提取第一行作为标题剩下的作为正文。根据标题里的关键词给每一块打一个主题标签。把所有块按主题标签分组输出成列表。这四步每一步都足够简单简单到 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 从“我觉得它能跑”变成“我能证明它能跑”。
阅读完成 · 觉得有帮助？
