演示驱动开发：先做出能播的 demo，再回头补功能

vibe coding 有个甜蜜的陷阱：AI 写代码太顺了，顺到你会不自觉地把 80% 的时间花在用户永远看不见的地方——完美的数据库 schema、可扩展的抽象层、 exhaustive 的错误处理。然后你兴冲冲地发出去，发现根本没人关心，因为你连"这东西到底解决什么问题"都没机会讲清楚。

演示驱动开发（Demo-Driven Development）就是治这个的。它的规则只有一条：先做出一个 3 分钟能讲清楚、能录屏、能发给别人看的 demo，再回头补功能。demo 不需要是完整的产品，它只需要回答一个问题："如果这东西存在了，用户的一天会有什么不一样？"

demo 的三条硬标准

第一，3 分钟讲完。打开录屏，从"我有个问题"讲到"看，它解决了"，3 分钟内必须闭环。讲不完说明你的 demo 想表达的东西太多，砍。

第二， happy path 必须丝滑。demo 可以没有错误处理、没有边界情况、数据可以是写死的——但主流程必须一次跑通，卡顿和报错是 demo 的死刑。记住：demo 是广告片，不是纪录片。

第三，24 小时内可发出。从想法到第一版 demo，超过 24 小时你就已经在"过度建设"了。AI 时代的 demo 应该按小时计，而不是按周计。今晚有想法，明晚就该有链接可以发给朋友看。

demo 先行改变了什么

最大的改变是反馈的质量。用文字描述想法，别人只能给礼貌性评价；丢一个可点的 demo 过去，对方会立刻开始挑刺——"这个按钮我找不到""要是我是用户我希望先看到 X"。挑刺是最好的反馈，它意味着对方在认真地把自己代入用户。

其次是它逼你做减法。3 分钟的 demo 容不下 10 个功能，你会被迫回答"如果只能留一个功能，是哪个"。这个问题的答案，往往就是你产品的真正核心——很多人在做了三个月后才想明白的事，demo 第一周就逼你想明白了。

第三是心理账户。有一个能播的 demo 在手里，你和别人聊起项目时底气完全不一样；更重要的是，你自己每天打开它，看到的是"已经做出来的东西"，而不是待办清单。这种正反馈是独立开发者最稀缺的燃料。

demo 之后：体面的"回填"

demo 先行不等于永远糙快猛。它的完整循环是：demo → 反馈 → 验证方向 → 回填工程。回填阶段要补的，按优先级排序：数据持久化（demo 的写死数据换成真数据库）、错误处理（happy path 之外的世界）、认证和权限（多用户之前必须有）、测试和监控（准备给陌生人用之前）。

注意这个顺序本身就是判断题：如果 demo 发出去没人感兴趣，回填就不用做了——你省下了三个月的无用功。这才是演示驱动开发真正的经济学价值：用 24 小时的 demo 成本，去证伪一个可能浪费 3 个月的方向。

一句话：先让世界看到它，再让它变得正确。顺序错了，正确毫无意义。