现场演示别靠运气：vibe 项目五分钟 live demo 的剧本、备份与救场话术

演示不是展示功能，是让观众在五分钟内相信你

你的 vibe 项目要第一次公开演示了：可能是给投资人、给客户、给黑客松评委，或者只是在团队周会上给同事看。你准备了一大堆功能，打开电脑，从第一个页面开始讲，讲到第三个页面时网络卡了，第四个功能点进去是空白数据，你一边说“这个平时是好的”一边刷新，观众的注意力已经走了。演示失败很少是因为产品不行，而是因为演示的逻辑错了：演示不是把产品的所有功能按顺序过一遍，而是要在五分钟内让观众相信一件事——“这个产品解决了一个真实的问题，而且已经能用了”。功能清单是给文档看的，演示是给人看的；人只能在五分钟里记住一个故事、一个画面、一个“原来可以这样”的瞬间。

先划清边界，因为站内已经有几篇容易混淆的邻近指南。Product Hunt 发布日指南讲的是发布当天的营销节奏——什么时候发帖、怎么回评论、怎么冲榜，解决的是“发布日流量”的问题。私人内测 playbook 讲的是内测流程——怎么招募内测用户、怎么收集反馈、怎么迭代，解决的是“内测期验证”的问题。本篇讲的是现场演示本身——你在台上、镜头前、会议室里，打开产品、操作给人看的那五分钟，解决的是“演示当场不出丑、还能让人记住”的问题。三者的时间点不同：内测在演示之前，演示在发布日当天或之前，发布日营销在演示之后。把演示指南和发布日指南混在一起，就会写出“演示时顺便发个帖子”这种两边都不讨好的内容。

五分钟剧本：一个问题、一条主线、一个高潮

五分钟演示的标准结构是三段：第一分钟讲问题，第二到第四分钟走主线，最后一分钟收在高潮。第一分钟只讲一件事：谁、遇到了什么麻烦、现在是怎么凑合的。不要讲市场规模、不要讲技术架构、不要讲你的愿景——观众在第一分钟里只需要确认“这个问题是真的，而且我听得懂”。举个例子：不要说“我们做了一个基于大模型的智能任务管理平台”，要说“独立开发者每天要在五个工具之间来回复制任务状态，复制错一次，项目进度就乱了”。前者是产品介绍，后者是问题陈述；演示的开场只需要后者。

第二到第四分钟是主线：只走一条用户路径，从问题到解决，一步都不要绕。主线上的每一步都要对应第一分钟里讲的问题：如果问题是“来回复制任务状态”，主线就是“打开产品、导入一次、状态自动同步到五个地方”——观众能清楚地看到问题是怎么被解决的。主线之外的所有功能，哪怕你觉得再酷，都不要在演示里顺带展示。顺带展示的代价是：每多一个分支，观众记住主线的概率就下降一截，而且每个分支都是一个新的故障点——多点一次，就多一次可能卡住、可能空白、可能报错的机会。五分钟演示的纪律是：一条主线走到底，其他功能留到问答环节——如果有人问起，再展示，那叫“应观众要求”，和“顺带展示”完全是两种效果。

最后一分钟是高潮：让观众看到一个“原来可以这样”的瞬间。高潮不是功能最复杂的地方，而是反差最大的地方：以前要做十分钟的事，现在点一下就完成了；以前要五个工具配合的事，现在一个页面就搞定了；以前容易出错的地方，现在自动不出错了。高潮要设计成“看得见”的——数字变化、状态变化、页面变化，而不是你口头说“这样就快多了”。观众记住的永远是画面，不是你的解说词。演示结束前，用一句话收尾：回到第一分钟的问题，说一句“所以，这个问题现在是这样解决的”——首尾呼应，观众离场时脑子里留下的就是这一个完整的故事。

演示账号与演示数据：永远不要用真实数据、永远不要用空数据

演示数据有两条铁律。第一条：永远不要用真实用户数据。真实数据里有真实姓名、真实邮箱、真实业务内容，演示时一旦投屏、录屏、截图，这些信息就公开了；而且真实数据是不可控的——你不知道哪条真实数据里藏着一个会让你当场尴尬的内容（比如一条测试用的脏话、一个客户的内部备注）。第二条：永远不要用空数据。空数据的页面看起来就是“这个产品还没人用”，观众看到空白列表、零条记录，第一反应不是“功能很清晰”，而是“这个产品是空的”。演示数据应该是“精心编造的、看起来像真的、但完全是假的”数据：十到二十条记录，名字是虚构的、业务是典型的、时间是最近的、状态是多样的——有已完成的、有进行中的、有一个正好能触发你高潮环节的。

演示账号也要单独准备：一个专门用于演示的账号，密码简单好记、登录状态提前保持、权限是“能走主线、不能误删数据”的级别。不要用你自己的日常账号演示——你的日常账号里有真实项目、真实设置、真实通知，演示时弹一条真实通知出来，整个节奏就断了。也不要在演示前一分钟才注册新账号——新账号是空的，违反了上一条铁律。正确的做法是：提前一天建好演示账号、填好演示数据、走一遍主线、确认每一步的画面都是你想要的，然后把这个账号和这份数据冻结起来——演示当天不再改数据、不再加功能、不再“顺手优化一下”。冻结，是演示准备里最难执行、也最重要的一条纪律。

备份方案：每一处可能失败的地方，都要有一条不用现场修的退路

演示失败的常见原因其实就那么几种，每一种都可以提前准备退路。网络问题：准备离线版本或本地运行版本，主线全程不依赖现场网络；如果实在必须联网，提前测试现场网络，准备手机热点作为备用。登录问题：提前保持登录状态，准备好演示账号的密码写在手边（不要现场找回密码、不要现场收验证码——验证码收不到是演示现场最常见的翻车之一）。数据问题：准备一份演示数据的截图或录屏作为最后的退路——如果现场操作真的卡住了，你可以说“现场网络有点问题，我直接给大家看一下录好的效果”，然后播放录屏；录屏不是作弊，它是专业演示的标准配置，好莱坞发布会都这么干。

操作失误：准备一份“演示检查清单”，按顺序列出每一步要点的按钮、要说的话、要注意的画面，演示时放在手边（不要背诵、不要即兴发挥——紧张时即兴发挥最容易说错、点错）。设备问题：提前一天到现场测试投屏、分辨率、字体大小——你的笔记本上看着清楚的字体，投到大屏上可能小得看不见；演示用的浏览器要提前关掉所有无关标签页、关掉通知、开勿扰模式。时间超了：准备两个版本——完整版五分钟、压缩版三分钟，如果前面超时，直接切压缩版，砍掉中间的非关键步骤，但高潮一定要保留。砍高潮的演示等于没有演示。

救场话术：卡住的时候，说什么比修什么更重要

演示现场卡住时，观众其实不在乎你修得多快，他们在乎的是你慌不慌。救场话术的核心是“承认、转移、继续”，不要辩解、不要假装没卡住、不要说“这个平时是好的”。承认的说法是：“这里现场有点问题，我先跳过这一步”——一句话，不解释原因、不追究责任。转移的说法是：“我们直接看结果”——切到录屏、切到截图、切到下一个已经准备好的画面。继续的说法是：“刚才那一步的结果是这样的”——用一句话把跳过的步骤交代清楚，然后回到主线上。整个救场过程应该控制在三十秒以内：承认五秒、转移十秒、继续十五秒。超过三十秒还在修，观众的注意力就回不来了。

还有几种常见场面的现成说法。观众问了一个你没准备的功能：“好问题，这个功能我们目前是这样处理的”——然后展示你准备好的最接近的功能，或者诚实地说“这个还在开发中，目前的替代做法是这样”——诚实比硬编一个不存在的功能更可信。观众指出一个明显的 bug：“谢谢指出，这个我们记下来了”——不要当场争辩“这不是 bug”、不要当场修 bug（现场修 bug 是演示自杀行为，修好一次的概率远低于搞砸的概率）。演示超时被提醒：“好，我直接跳到最后的结果”——切到高潮画面，用一句话收尾，不要试图“加快速度讲完”——加快速度只会让后半段变成含糊的噪音。所有这些话术的共同点是：演示者的镇定本身就是产品可信度的一部分。你慌，观众就觉得产品也不稳；你稳，观众就觉得“这点小问题不算什么”。

演示前 24 小时的检查清单

演示前一天：走一遍完整流程并计时，确认五分钟版本和三分钟版本都走得通；演示账号、演示数据已冻结；录屏已录好、已测试能播放；现场网络、投屏、分辨率已测试；演示检查清单已打印或放在手边。演示当天提前一小时到场：再走一遍主线（不要改任何东西，只确认）；关通知、开勿扰、关无关标签页；确认手机热点可用；把演示账号密码写在手边；深呼吸一次，提醒自己：演示的目标不是“展示所有功能”，而是“让观众记住一个故事”。演示结束后 24 小时内：把观众的问题记下来——这些问题是你下一轮产品迭代最真实的反馈，比任何问卷都准；把演示中卡住的地方记下来——下次演示的备份方案就从这里开始补。演示不是一次性的表演，它是你产品故事的一次排练——排练得越多，故事讲得越好，产品本身也会在这个过程中变得更清晰。

远程演示的特殊准备：镜头前的一切都会被放大

远程演示（视频会议、直播、录播）和现场演示的准备有一半是相同的，另一半完全不同。相同的是剧本、演示账号、演示数据、备份方案——这些不分场合。不同的是：远程演示里，观众看不到你的肢体语言，只能看到你的屏幕和听到你的声音，所以屏幕上的每一个细节都会被放大。字体要比平时大一号——你笔记本上看着刚好的字体，分享屏幕后经过视频压缩，观众那边可能已经糊了。鼠标移动要慢、要稳——快速晃动的鼠标在视频里会变成残影，观众根本看不清你点了哪里。说话要比平时慢半拍——网络延迟会让你的解说和画面错位，语速慢一点，错位的影响就小一点。演示前，一定要和一个人做一次完整的远程彩排，让对方告诉你：哪些字看不清、哪些步骤跟不上、哪段解说和画面对不上——你自己是发现不了这些问题的，因为你对自己的产品太熟了，熟到会自动脑补画面。

远程演示还有两个现场演示没有的风险。第一个是“你以为在分享屏幕，其实没有”——演示开始前，先确认屏幕分享已经开启、分享的是正确的窗口（不是整个桌面——整个桌面会暴露你的通知、你的其他标签页、你的私人文件；分享单个应用窗口是最安全的）。第二个是“你的声音”——提前测试麦克风、关掉可能突然响起的提示音、准备好备用耳机。很多远程演示翻车不是产品问题，而是“观众听不清你在说什么”——听不清，故事就讲不下去。还有一个小技巧：远程演示时，在屏幕角落放一个小小的“进度提示”——比如“第一步：导入数据”这样的字幕式提示，观众即使中途走神回来，也能立刻知道你讲到哪里了。现场演示里观众走神了还能看你的肢体语言找回来，远程演示里没有这个线索，进度提示就是他们的锚点。

问答环节的准备：演示结束才是真正的考试

演示的五分钟只是开场，问答环节才是观众真正检验产品的时候。准备问答的方法不是“预测所有问题”，而是准备三类答案。第一类是“已经准备好的演示”：把主线之外的、观众最可能问起的两个功能，各准备一分钟的快速演示——有人问起时，你不是口头解释，而是直接操作给他们看，这种“应要求展示”的效果远胜于主线里的“顺带展示”。第二类是“诚实承认的边界”：列出你的产品目前明确做不到的三件事，以及各自的替代做法——观众问起时，诚实承认比硬编功能更可信，而且“知道自己做不到什么”本身就是专业度的证明。第三类是“记下来的问题”：准备一个本子（或文档），问答时把每个问题原样记下来——记下来这个动作本身就在告诉观众“我重视你的问题”，而且这些问题是你下一轮迭代最真实的反馈来源。

问答环节还有三个纪律。第一，不要在问答环节现场改代码、现场修 bug——问答环节的修 bug 和演示环节一样危险，而且问答时修 bug 会让所有观众都等着你，时间成本更高。第二，遇到不知道答案的问题，不要猜——说“这个问题我需要确认一下，演示结束后我把答案发给你”，然后真的在 24 小时内把答案发过去——“演示后补答案”不是失分项，言而有信反而是加分项。第三，控制问答时间：如果问答时间快到了，还有问题没答完，不要 rushed 地赶完所有问题——挑最关键的一个认真回答，剩下的说“我们演示后继续聊”，然后真的留下来继续聊。演示的目标从来不是“回答所有问题”，而是“让观众带着一个清晰的故事离开，并且愿意继续聊下去”。