技术分享最怕的不是内容难，而是讲的人很累、听的人犯困。当一块块文字幻灯片翻过去，观众的大脑很容易离线。真正能让人抬起头的，往往是讲者突然打开终端敲下命令，屏幕立刻给出结果，或者是讲者自嘲一句“我上周就栽在这了”。这种即时可见的真实感和失败经验，比任何架构图都更能建立信任。
为什么Live Demo能打破枯燥感
Live Demo的核心价值在于把“他说是对的”变成“你看它真的跑起来了”。在传统的幻灯片分享中，代码和结果被静态截图固定，观众没有参与感，也很难判断讲者是否省略了关键步骤。而现场运行一段程序，输入和输出之间只隔着一个回车键，这种低延迟的反馈会持续刺激观众的注意力。哪怕演示中出现了小意外，只要处理得当，反而能证明讲者真的理解这套系统。
从认知负荷角度看，人脑处理动态过程比记忆静态结论更轻松。当我们展示一个排序算法时，直接跑一遍并打印每一步的数组状态，观众可以自己“看会”，而不必强行理解讲者的语言描述。下面这段Python示例在分享时现场运行，能直观看到冒泡排序的中间过程：
def bubble_sort(arr):
n = len(arr)
for i in range(n):
for j in range(0, n - i - 1):
if arr[j] > arr[j + 1]:
arr[j], arr[j + 1] = arr[j + 1], arr[j]
print(f'第{i+1}轮后: {arr}')
data = [5, 2, 9, 1, 5, 6]
bubble_sort(data)
当然，Live Demo也有明显缺点：环境依赖、网络波动、权限问题都可能导致翻车。因此演示代码应尽量精简，去掉无关业务逻辑，只保留能说明问题的核心路径。同时建议准备一段录屏作为兜底，一旦现场环境出问题就切到录屏，保证节奏不中断。
踩坑故事怎么讲才不像是凑时间
很多人以为踩坑故事就是“我错了大家笑一笑”，其实好的事故复盘必须包含三个要素：错误的上下文、当时的判断依据、以及事后的根因。如果只说“我不小心删了库”，观众只会觉得你马虎；但如果你讲清楚当时是为了快速发布跳过了备份脚本，而监控系统又因为权限问题没有报警，听众就能把自己的项目对号入座，反思类似风险。
在筛选故事时，优先选那些“看起来合理但结果荒谬”的案例。比如某次接口超时，大家本能地加机器，后来发现是序列化工具在循环里反复建连接。这类故事既有技术深度，又打破了直觉，容易引发讨论。下面的Java片段展示了一个典型的资源未释放陷阱，分享时可以现场改一行代码来对比性能：
// 错误写法：在循环内创建连接
for (String id : idList) {
Connection conn = DriverManager.getConnection(url);
// 查询操作
conn.close(); // 容易遗漏或异常未关
}
// 正确写法：使用try-with-resources
for (String id : idList) {
try (Connection conn = DriverManager.getConnection(url)) {
// 查询操作
}
}
讲坑的时候语气要平和，不要把自己塑造成受害者，也不要过度自黑。重点放在“我们如何从这次事件里改了流程”，比如引入了连接池巡检、增加了慢查询告警。这样故事就不再是八卦，而是可复用的方法论。
把Demo和故事缝进分享节奏里
单独放Demo或单独讲故事都不够，最佳结构是“抛问题—跑Demo—讲踩坑—给方案”。例如在讲缓存击穿时，先问大家“半夜告警被叫醒是什么体验”，然后现场用压测工具打一波未预热缓存，接着讲某次生产事故就是因为热点key失效，最后给出布隆过滤器和互斥锁的代码模板。这种起伏的节奏让观众的情绪跟着走。
时间分配上，一场四十分钟的分享，Live Demo控制在十分钟以内，踩坑故事占八分钟左右，其余留给原理和总结。演示前务必在分享用的笔记本上完整跑通一遍，关闭无关通知，把终端字体调大。故事部分可以准备一两张简单的时间线草图，不需要精美，但能帮观众理清前后因果。
最后，讲完之后留五分钟开放提问，往往观众会基于你刚跑的Demo提出边界情况，这时候顺着问题再敲几行代码，是最自然的高光时刻。整场分享从无聊的单向播报，变成了一次共同调试，参与感也就立住了。