1. 为什么“从 idea 到 demo”这一步卡住了绝大多数人我做了十多年开发带过不少新人也跟很多独立开发者聊过。一个特别普遍的现象是脑子里冒出一个想法兴奋了半小时打开编辑器然后……就没有然后了。不是不会写代码而是从“一个模糊的念头”到“一个能跑起来、能给别人看的东西”之间横着一条很宽的沟。这条沟里埋着需求拆解、技术选型、环境搭建、最小闭环设计、调试排错每一块单独拎出来都不难但合在一起就足以让人在第一个晚上就放弃。“vibe coding”这个词最近被聊得很多但很多人把它理解成“让 AI 帮我写代码”。这个理解太窄了。我自己的体会是vibe coding 的核心不是“谁来敲键盘”而是保持创作节奏不被打断——你脑子里那个“感觉”还在的时候别让环境配置、依赖冲突、脚手架选择这些琐事把你从心流里拽出来。从 idea 到 demo 的第一阶段目标根本不是写出生产级代码而是用最短路径验证“这个想法到底成不成立”。所以这篇东西不是教你某个框架怎么用而是把我自己从零把一个想法推到可运行 demo 的完整思路摊开讲。适合谁看适合那些有想法但总在起步阶段卡住的人适合想用 AI 辅助但发现“越帮越乱”的人也适合单纯想看看别人怎么组织这类工作流的老手。我会把每一步的“为什么这么选”讲清楚因为选型逻辑比具体命令重要得多——命令会过时判断力不会。2. 把脑子里的“感觉”翻译成一句话需求2.1 先写“不做什么”比写“做什么”更重要大部分人拿到一个 idea第一反应是列功能清单要有登录、要有列表、要有搜索、要能分享……列完一看二十条当场泄气。我的做法反过来先写清楚这个 demo不做什么。比如我想做一个“本地优先的读书笔记工具”第一版我明确不做的包括不做账号系统、不做云同步、不做多人协作、不做移动端。这四条一划掉剩下的核心就只剩一件事——能快速记一条笔记并检索到它。为什么这一步这么关键因为 demo 的本质是验证假设不是交付产品。你脑子里那个“感觉”背后其实藏着一个假设比如“我觉得大家需要一个不用登录就能记笔记的东西”。demo 要验证的就是这个假设其他功能都是噪音。把“不做什么”写下来等于给后面的所有决策设了一道闸门任何超出这个范围的想法一律记到“第二版清单”里现在不碰。2.2 用“一句话 一个动作”锁定最小闭环我习惯把需求压缩成两个东西一句话描述加一个核心动作。还是读书笔记那个例子一句话是“一个打开就能写、关掉不丢的本地笔记工具”核心动作是“输入文字 → 保存 → 下次打开能看到”。就这三步。任何 demo 只要能跑通这三步就算成功。这里有个经验核心动作最好能在 30 秒内被一个外行看懂。如果你跟朋友说“我这个 demo 能干嘛”需要解释超过 30 秒说明闭环还没锁死。我见过太多人把 demo 做成“半成品产品”功能一堆但每个都半吊子最后自己都不知道该演示什么。锁定一个动作你的演示脚本就自然出来了连录屏都不用写稿。2.3 给 idea 标一个“验证成本”不是所有想法都值得马上动手。我一般会给每个 idea 估一个“验证成本”从零到能跑大概要花几个晚上。如果一个想法验证成本超过三个晚上我会先把它拆小或者干脆先放着。因为超过三个晚上还没看到东西热情基本就凉了。这个估算怎么做的看它依赖多少“外部不确定性”。比如纯前端的小工具一个晚上能出东西涉及本地文件读写加半个晚上涉及调用某个第三方服务再加一个晚上因为你要处理密钥、限流、返回格式这些破事。把不确定性列出来成本自然就估出来了。这一步不需要精确只需要帮你判断“现在做还是以后做”。3. 技术选型别选“最好的”选“最不容易打断你的”3.1 选型的唯一标准是“减少决策次数”新手选型最容易犯的错是去搜“2025 年最流行的 XX 框架”然后在一堆对比文章里迷失。我的标准特别朴素哪个方案需要我做的决策最少就选哪个。因为每一个决策点都是一次心流中断的机会。举个例子做那个笔记工具前端我直接用一个带热重载的轻量框架不纠结状态管理库因为第一版根本不需要全局状态。后端我干脆不要数据存本地文件。数据库不存在的。这样我全程只需要做三个决策用什么写界面、数据存哪、怎么读出来。决策少了动手就快了。3.2 环境准备里那些“看起来很小”的坑环境这块我踩过的坑能写一本书。说几个最典型的。第一版本管理一定要在动手前搞定。我见过太多人代码写到一半发现运行时版本不对回头折腾环境一折腾就是一晚上第二天就不想继续了。动手前花十分钟确认版本比事后花两小时救火划算得多。第二依赖安装尽量用官方推荐的默认方式。有些人喜欢手动配一堆东西觉得“可控”结果一个路径写错就卡住。默认方式虽然看起来“不够专业”但它经过了最多人的验证出问题的概率最低。demo 阶段稳定压倒一切。第三把启动命令写在一个地方。我习惯在项目根目录放一个说明文件就写三行怎么装依赖、怎么启动、怎么访问。别小看这个隔两天再回来你自己都会忘。3.3 什么时候该用 AI 辅助什么时候别用AI 辅助写代码确实能提速但用错地方反而拖慢。我的经验是样板代码、格式转换、报错解释交给 AI核心逻辑、架构决策、调试判断自己来。因为 AI 生成的东西你需要读懂才能改如果核心逻辑你都不熟改起来比从头写还慢。还有一个坑AI 给的方案经常“过度完整”。你问它怎么读一个文件它给你一套带异常处理、日志、配置管理的完整类。对 demo 来说这是负担。我的做法是明确告诉它“给我最小可运行版本不要异常处理不要日志”这样出来的东西才贴合 demo 的节奏。4. 搭骨架先让“空壳”跑起来再往里填肉4.1 空壳跑通的那一刻心态就稳了这是我强烈推荐的一个习惯先搭一个什么都不做、但能启动、能访问的空壳。界面上就一行字“Hello”或者一个空白页面。别觉得这没意义它的价值在于把“环境是否正常”“启动流程是否通”这两个最大的不确定性提前消灭掉。我自己的流程是新建项目 → 用脚手架生成默认结构 → 直接启动 → 看到默认页面 → 关掉。整个过程不超过十五分钟。这十五分钟买来的是后面几个小时的心安——你知道基础设施是好的接下来写的每一行代码出问题都是逻辑问题不是环境问题。这个区分太重要了它能把你的排查范围缩小一大半。4.2 数据流先于界面空壳跑通后下一步不是画界面而是把数据流打通。还是笔记工具的例子我先写一个最丑的输入框和一个最丑的按钮点按钮把文字存到一个本地文件再写一个最丑的列表把文件内容读出来显示。界面丑到不能看但数据从输入到存储到读取的整条链路是通的。为什么先做数据流因为界面是“表现”数据流是“本质”。表现可以慢慢调本质不通整个 demo 就是假的。而且数据流打通后你会有一种“它真的活了”的感觉这种正反馈对保持节奏特别重要。界面美化放到最后那时候你已经有成就感了调样式也不觉得累。4.3 用“假数据”先把界面撑起来如果数据流一时半会打不通还有个技巧先用写死的假数据把界面撑起来。比如列表页先塞三条硬编码的笔记看看布局、间距、交互顺不顺。这样你能在没有后端的情况下先把前端体验调好等后端通了直接替换数据源就行。这个技巧的好处是解耦。前端和后端可以并行推进谁先好谁先上。我经常这么干尤其是当某个第三方接口还没申请下来的时候先用假数据把整个流程走一遍接口一到直接换几乎不用改结构。5. 调试阶段把“它为什么不工作”变成一道选择题5.1 报错信息要“从下往上”读调试是 demo 阶段最耗时的部分也是最容易让人崩溃的部分。我总结的第一个技巧是报错信息从最下面一行开始读。大部分运行时和框架的报错最底下那行才是真正的错误上面一堆是调用栈。新手容易从第一行开始读读半天被一堆路径和函数名绕晕其实关键信息就在最后。第二个技巧先看错误类型再看错误内容。是“找不到文件”还是“类型不匹配”还是“连接超时”类型决定了你往哪个方向查。方向对了内容只是细节方向错了读再多内容也是白搭。5.2 二分法定位把范围一刀一刀切小当错误不明显的时候我用得最多的方法是二分法。比如页面白屏我不知道是哪段代码的问题就在中间打个日志看执行到哪一步停了。停在前半段就查前半段停在后半段就查后半段一次砍一半几次就定位到了。这个方法听起来笨但它是最可靠的。因为 demo 阶段代码量不大二分几次就到底了。比“盯着代码猜”快得多也比“到处加日志”干净。关键是它给你一个确定的推进节奏不会让你陷入“改一下试试、再改一下试试”的随机状态。5.3 那些“改了但没生效”的情况有个特别气人的情况你改了代码重启发现行为没变。这时候先别怀疑人生按顺序查三件事。第一改的文件是不是正在运行的那个。有时候项目里有两份同名文件你改的那份根本没被加载。第二缓存有没有清。前端尤其常见浏览器缓存、构建缓存清一下往往就好了。第三进程有没有真的重启。有时候旧进程没退干净新进程起不来你看到的还是旧的。这三件事查完九成的“改了没生效”都能解决。剩下的那一成通常是配置文件的路径写错了或者环境变量没加载。总之先怀疑“我改的东西有没有被用上”再怀疑“我改得对不对”。6. 从“能跑”到“能演示”demo 的最后一百米6.1 演示路径要提前走三遍demo 能跑不等于能演示。我见过太多人自己电脑上跑得好好的一演示就翻车。原因很简单演示路径和你平时的操作路径不一样。平时你可能随手点演示时你要按顺序点中间任何一步卡住都尴尬。我的做法是把演示要走的每一步写下来然后照着走三遍。第一遍看流程通不通第二遍看有没有多余步骤可以砍第三遍计时。三遍走完你会发现好几个“平时没注意但演示时会暴露”的问题比如某个按钮位置太偏、某个加载太慢、某个提示文案看不懂。提前修掉演示就稳了。6.2 准备一个“兜底方案”再稳的 demo 也可能出意外。我的习惯是准备一个兜底方案要么录一段屏要么准备一份静态截图万一现场跑不起来直接放录屏嘴上说“我这边网络有点问题先看录屏”。这不是作弊这是专业。观众要看的是你的想法不是你的环境。兜底方案还有个好处它逼你把 demo 的“最佳状态”固定下来。录屏的时候你会不自觉地优化流程、调整节奏这个过程本身就在帮你打磨 demo。6.3 演示时只讲“一个点”最后说个心态问题。demo 演示最容易犯的错是想讲太多。你做了五个功能恨不得全讲一遍结果每个都讲不透观众也记不住。我的建议是只讲一个点讲透。就讲那个核心动作讲它解决了什么问题讲你为什么这么设计。其他的功能一句带过甚至不提。因为 demo 的目的是让人记住“你在做什么”不是让人记住“你做了多少”。一个点讲清楚了别人自然会问“那其他方面呢”这时候你再展开效果比你自己一股脑倒出来好得多。7. 我踩过的几个典型坑你可以直接绕开第一个坑过早优化。demo 阶段看到代码有点乱就想重构一重构就停不下来最后功能没做完代码倒是很“优雅”。我的教训是demo 阶段允许丑陋允许重复允许硬编码。只要它能跑、能演示就是好代码。重构是第二版的事。第二个坑追求“完整”。总想着“这个功能不做完就不算 demo”结果每个功能都做到一半。正确的做法是每个功能都做到“能演示”的程度就停哪怕它背后是写死的。先让整个流程完整再让每个环节完整。第三个坑不记录。做到一半去干别的回来忘了做到哪了。我的习惯是每次停下来之前在说明文件里写一行“下次从这里继续”。就一行字能省掉半小时的回忆时间。第四个坑一个人闷头做太久。demo 阶段最怕闭门造车做了三天发现方向错了。我的做法是每完成一个核心动作就找个朋友看一眼哪怕只是发个截图。外人的一句话经常能点醒你。8. 关于节奏为什么“快”比“好”更重要最后聊点虚的但我觉得是最重要的。从 idea 到 demo最大的敌人不是技术难度是热情衰减。一个想法在你脑子里最鲜活的时候就是刚冒出来的那几天。这几天你不动手它就慢慢凉了最后变成一个“我以前想过”的遗憾。所以 demo 阶段的一切决策都应该服务于“快”。快出东西快看到反馈快验证。技术选型选快的功能范围砍到最快能验证的界面丑一点没关系代码乱一点没关系。你要的不是一个完美的作品是一个能证明“这个方向值得继续”的证据。等 demo 跑起来了你有了证据有了反馈有了继续投入的理由那时候再谈优化、谈架构、谈体验都来得及。反过来如果一开始就追求“好”大概率是东西没出来热情先没了。我自己这些年做过的 demo 里真正变成产品的没几个但每一个 demo 都让我学到了东西也让我更清楚什么方向不值得投入。从这个角度说demo 的价值不在于它本身而在于它帮你用最小的代价换到了最真实的判断。这个买卖怎么算都划算。