高级工程师的高级工程课件，往往不是师课讲给新人听的，是高级工程讲给一群同样写了十年代码、早就看腻了花架子的师课人听的。所以，高级工程第一页PPT别放目录，师课放一个你上周刚踩过的高级工程坑，越具体越好。师课

我见过最糟糕的高级工程课件，标题叫《微服务架构最佳实践》，师课打开第一页是高级工程“什么是微服务”。台下坐着的师课人，有三位正在帮公司拆掉两年前自己搭的高级工程微服务。你跟他们讲概念，师课他们只想把笔记本合上。高级工程反过来，有位老哥讲《分布式事务的妥协艺术》，开场直接贴了一段生产环境的异常日志，说“这是周四凌晨三点的事故，我花了七个小时才定位到问题”。全场瞬间安静，所有人都在等下文。

技术课件的第一原则：用事故开场，用代码说话，用数据服人。别铺垫背景，别介绍团队，别感谢主办方。你打开编辑器，贴一段能复现问题的代码，或者一张监控曲线的截图，标注出那个异常的尖峰，然后问一句：“你们猜，这里发生了什么？”——比任何“今天我们来讲讲”都有效。

内容组织上，别按教科书章节来。按“决策点”来。每页只讲一个你必须做的选择，以及选错了会怎样。比如讲缓存，不要从“缓存是什么”讲到“缓存淘汰策略”再讲到“缓存雪崩”。你就讲一个场景：你的接口响应时间从50ms涨到2秒，你第一反应是加缓存，但加了之后发现数据不一致，于是你加了失效时间，结果又遇到缓存穿透。每一步都是真实的纠结，每一步都有对应的代码片段。

页面上的字要少。高级工程师看课件，不是来读文档的。一页PPT上超过五句话，就没人看了。我习惯的做法是：左侧贴关键代码，右侧只留三个词——问题、原因、方案。剩下的全靠嘴讲。有一次我讲连接池调优，整页只有一张曲线图和两行参数对比。底下有人说：“你这页信息量太低了。”我回他：“你听完我讲这十分钟，回去能省三天的排查时间，这页就算值了。”

课件里必须有一个“反例”环节。专门放一段看起来没毛病、但实际会出事的代码。让台下的人先自己找问题，找出来的人会记住这个坑，找不出来的人，你讲完他们会冒冷汗。这个环节的互动效果，比任何提问都强。去年我在内部分享，放了一段用ThreadLocal存用户信息的代码，有个小伙子当场举手说“线程池复用会串数据”。那一刻，我知道这页没白做。

节奏上，每讲15分钟，插一个30秒的“跑题时间”。可以是你上周跟产品经理吵架的细节，也可以是某个开源项目作者在issue里骂人的截图。别小看这30秒，它是让大脑休息的锚点。高级工程师的注意力续航也就20分钟，你要是不给他们喘气的机会，后半场就有人在下面回邮件了。

最后的收尾，别放“谢谢观看”或者“Q&A”。放一张你画的心智图，把今天讲的所有决策点串成一条线。然后说：“这张图我花了两周才画明白，你们现在拿走，省两周。”然后直接下台，别问“大家有什么问题”。有问题的人会追到走廊里问你，没问题的人急着回去改代码。

做课件这件事，本质上是把你自己踩过的坑，压缩成别人能快速吸收的密度。高级工程师的时间贵，你的课件就得配得上这个贵。写代码要重构，做课件要删减。每页PPT问自己一句：这页删了，听众会损失什么？如果答不上来，就删。

(责任编辑：时尚)