现场演示前如何设计可靠的演示方案（含降级、检查点与彩排门槛）

当你要在演讲、工作坊、网络研讨会或直播中做现场演示（live demo / live coding），需要一套能在网络中断、命令报错或投屏失败时仍然成立的演示运行手册时使用。

适用场景

解决思路

1. 先做访谈式提问，一次只问一个问题，尽量用选择题，能构建运行手册就停止：演示要证明什么（一句话主张）、在哪里运行（大会舞台/聚会/工作坊/网络研讨会/录制视频/销售电话/展位/内部全员会）、给多少分钟以及超时一倍会怎样、会触及什么（本地代码/本地服务/托管产品/第三方 API/云账号/真实客户数据）、是否控制场地网络还是访客、观众是谁、以前出过什么错、已有什么现成资产（仓库/脚本/预置环境/录像/沙箱租户）、硬性约束（公司笔记本策略/禁止录屏/未发布功能/不能上屏的数据）、活动日期、是一次性还是全年复用的演示套件、有多少彩排小时以及谁负责后续维护。
2. 用一句话写下演示的**主张**（claim）。凡是不服务于这个主张的内容都列为删除候选——展示六个功能的演示等于什么都没证明。
3. 把演示切成**段落**（segments），每个段落对应主张的一步，每段控制在约 90 秒以内（本技能设定的默认值，按实际时长缩放）。段落按“它证明了什么”命名，而不是按“它敲了什么”命名。
4. 构建风险登记表：对照 references/demo-risk-register.md 逐条走查这个具体演示，只保留真正可能触发的风险，按（发生概率 × 破坏的可见程度）排序。
5. 选择保真度层级（fidelity tier）：先过滤出能证明该主张的层级，按效率顺序呈现其中前 2-3 个及其取舍，推荐第一个，等用户选定后再继续设计——这个决定影响所有下游设计。
6. 设计检查点架构：每个段落都要有一个命名的恢复点（git tag、目录快照、数据库 dump、预构建镜像、预填充租户、demo-runner 脚本中的一步）；**任何段落都不得依赖前一段落的实时输出**；至少保留三个检查点；在运行手册中标注哪些段落时间不够时可丢弃；写明每段的前置条件和预期屏幕状态，以及一行“如果不是这样”的分支。
7. 设计环境加固：把场地网络当作额外奖励而非依赖，拔掉网线也能跑完；本地栈 + 种子数据 + 录制的第三方响应；热点只作为真正远程部分的备份，并且要在真实场地测试过。屏幕方面：终端字号 ≥24pt、编辑器 ≥20pt、高对比度或浅色主题、块状光标、约 80-100 列、关闭通知、退出聊天和邮件、使用全新浏览器 profile、清空 shell 历史。
8. 为每个段落写降级方案：用什么替代、该资产放在哪里、切换到它的按键是什么。
9. 写恢复台词——切换时口播的那两三句话。彩排切换本身，而不只是彩排演示。
10. 按 references/demo-runbook-template.md 组装运行手册（头部含主张/层级/预算/网络/数据/负责人/最后验证日期，段落表含每段恢复点和降级方案，降级资产清单，一条命令重置，写好的恢复台词，起飞前检查清单和彩排日志）。逐节呈现并逐节获得确认，不要一次性丢出整份手册。
11. 把重置做成**一条命令**、幂等，并从冷机器上彩排过（不是已经跑过两遍演示的机器）。绑定到快捷键或写在便签上。
12. 上台前预置所有慢操作：安装、构建、镜像拉取、模型下载、索引构建、DNS 传播、账号验证、冷启动。如果命令是故事的一部分可以展示，但绝不在观众面前等待。
13. 如果演示材料在 git 仓库中，用 scripts/demo-checkpoints.sh 创建、列出、跳转和重置带标签的检查点（save/list/goto/reset）；否则用材料本身的快照机制套用同样模式。
14. 恢复计划：**只尝试修复一次，然后切换**，修复时间约 20 秒（本技能自设预算，按形式调整）；切换脚本和时间要在活动**之前**写好并演练，就像混沌工程要求实验开始前先脚本化并测试中止路径；预写切换台词并把切换当作独立演练；口述本应发生什么再展示降级；只道歉一次且简短；只有当真实错误能一句话解释且支持论点时才当作内容；为任何层级都救不了的失败（笔记本死机、投屏失败）安排人工冗余——前排同事持有仓库、幻灯片和录像的克隆。
15. 彩排与通过门槛：先逐段彩排（暴露实际耗时是预期的两倍，修法是砍低价值步骤或预填样板，而不是说快一点）；数结果而不是数遍数。迭代设计直到全部满足：连续三次冷启动运行（全新机器状态、只用重置命令、无手动修复）在预算分钟内完成；每个段落至少从自己的恢复点直接进入过一次；风险表前三项各演练过（触发、切降级、继续讲，20 秒内）；完整跑过一次断网；完整跑过一次在场地分辨率和宽高比下、从房间后排可读；实测总演示时间不到允许时间的一半。任何一项不达标就改设计（降层级、砍段落、把依赖移到离线），不要靠增加练习次数补偿。
16. 事后按以下维度评估：是否按设计运行、恢复损失秒数、观众提问是否引用演示内容而非是否成功、录像中演示段的观看完成率。这些只作方向性参考。
17. 按观众类型调整演示数据和账号：B2B/企业用真实感域名数据（foo、test1、asdf 会显得从没用过），绝不碰生产或展示其他客户数据，先用沙箱租户和只读凭证；销售/客户电话先问对方来看什么并从那里开场，失败段落直接恢复成下一段的主张；展位以最直观的段落开场、每几分钟会被打断重启、环境噪音排除依赖音频的内容、先问一个问题筛选兴趣；B2C/独立开发者展示真实安装或注册路径和真实耗时；内部/全员会数据风险不降低，未发布功能、客户名和营收数字会通过录像泄露。
18. 如果运行环境有持久记忆，存储主张、选定层级、段落列表和重置命令——同一个演示下次活动换个时长会重跑，重新推导会产生一个不同且更少测试的版本。
19. 在运行手册中给每次干净的冷启动运行标注日期，并在每次活动前重新验证命令与产品是否匹配。

适用边界 · 注意事项

• 演示的叙事结构、在演讲中的位置和时长分配不属于本技能——用 samber/developer-relations-skills@tech-talk-outline。
• 录制版演示的脚本撰写不属于本技能——用 samber/developer-relations-skills@technical-video-script。
• 把演示路径转化为文档化的首次成功路径不属于本技能——用 samber/developer-relations-skills@developer-quickstart-guide。