第1982篇：做AI讲师的经验——技术培训课程的设计与交付方法论

老张2026/4/30大约 12 分钟

第1982篇：做AI讲师的经验——技术培训课程的设计与交付方法论

我不是天生会教书的人。

第一次站上讲台讲Java课，下面坐了三十几个人，我手里捏着PPT遥控器，说了第一句话就发现声音有点颤。那次课讲得一塌糊涂，课后有个学员私下问我："老师，你说的那个Spring AOP，能不能用人话再讲一遍？"

那是我第一次意识到：你懂一个东西和你能把它讲明白，是完全不同的两种能力。

这几年断断续续做了不少技术培训，有线下的企业内训，有线上的录播课程，也有知识星球里的直播分享。踩了很多坑，也摸出了一些规律。今天想把这些东西完整写下来。

讲师和工程师，是两种不同的动物

先说一个认知误区：技术水平高不等于能教好课。

这个误区害了很多人。我见过有人Java写得炉火纯青，一开口讲课学员全懵。为什么？因为专家知道太多了，专家的大脑已经无法模拟一个初学者的状态。专家看到一行代码，脑子里自动补全了背后的上下文、历史演进、设计取舍；但学员看到的只是那一行代码，不知道前因后果。

这个现象有个名字叫"知识诅咒"（The Curse of Knowledge）。你一旦知道了某件事，就很难想象不知道它是什么感觉。

所以，成为一个好讲师的第一步，不是把技术学得更深，而是学会忘掉你的专家视角，重新用初学者的眼睛看这些内容。

我的具体做法是：每次备课，先强迫自己写下"一个完全不懂这个知识点的人，他最可能的困惑是什么"。把这个困惑列成清单，然后围绕着解答这些困惑来设计课程。

课程设计的底层逻辑

我见过很多技术课程是这样设计的：按照文档的顺序讲，从第一章讲到最后一章，每个API都讲一遍。这是最烂的课程设计。

好的课程设计有一个核心原则：先建立"为什么"，再建立"是什么"，最后才是"怎么做"。

以Spring Boot入门课为例：

烂的顺序：

Spring Boot是什么
搭建第一个项目
application.yml配置
Controller、Service、Repository层
数据库连接
...

好的顺序：

你现在用原生Servlet写一个接口有多痛苦？（演示一遍）
这些痛苦是从哪里来的？（讲原理层面的问题）
Spring Framework是怎么解决这些问题的？
Spring Boot在Spring的基础上又省掉了哪些麻烦？
好，现在我们来搭一个项目，看它到底省在哪里

两种顺序的差距，不在于知识点的多少，而在于有没有给学员建立"动机"。

学员要先感受到痛苦，才会珍视解决方案。你直接把解决方案塞给他，他不会产生"原来如此"的感觉，只会觉得"这有什么用？"。

课程结构：我用的三层架构

经过几年摸索，我现在设计技术课程会用一个三层架构：

每个知识点都要经历这五层。以"Redis缓存穿透"为例：

概念层：什么是缓存穿透？用一个生活类比讲清楚——就像你去图书馆借一本不存在的书，每次都要劳驾工作人员去书库找一圈，找不到才告诉你"没有"。如果有一万个人来借同一本不存在的书，图书馆就被搞瘫了。

机制层：缓存穿透在系统层面发生了什么？请求先打缓存，缓存没有，再打数据库，数据库也没有，返回空值，但空值不写缓存，下次同样的请求继续穿透数据库。画一张请求链路图：

实战层：两种主要解决方案——缓存空值法和布隆过滤器。代码实现：

@Service
public class UserService {

    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    @Autowired
    private UserRepository userRepository;

    // 方案一：缓存空值，设置短TTL
    public User getUserById(Long id) {
        String key = "user:" + id;
        Object cached = redisTemplate.opsForValue().get(key);
        
        if (cached != null) {
            // 注意：这里需要区分"缓存了null"和"key不存在"
            return cached instanceof NullValue ? null : (User) cached;
        }
        
        User user = userRepository.findById(id).orElse(null);
        
        if (user == null) {
            // 缓存空值，TTL设短一点，避免占用太多内存
            redisTemplate.opsForValue().set(key, new NullValue(), 60, TimeUnit.SECONDS);
        } else {
            redisTemplate.opsForValue().set(key, user, 30, TimeUnit.MINUTES);
        }
        
        return user;
    }
}

踩坑层：缓存空值法的问题是什么？如果攻击者用随机ID轮番打，你会缓存大量垃圾空值，内存被撑爆。布隆过滤器的问题是什么？有一定的误判率，合法ID可能被拦截，适合对误判容忍度高的场景。怎么选？

拓展层：这个问题和缓存击穿、缓存雪崩有什么关系？如果面试官问你这三个的区别，你能不能一句话说清楚？

这五层走完，一个知识点就真正立起来了，不是浮在空中的概念。

交付方式：线下、线上、直播的不同打法

线下课程的优势是即时反馈，你能看到学员的眼神，知道他们在哪里卡住了。但线下课程对讲师的要求更高，你需要能够实时调整节奏，因为不同人的吸收速度差异很大。

我在线下课上用的一个技巧叫"举手反馈法"：每讲完一个知识点，问一个简单问题，请听懂的举手。如果举手的不到60%，说明这个点讲得不清楚，需要换个角度再讲一遍。这个办法很管用，但前提是你要把自尊心放下——它会实时告诉你你讲得有多糟糕。

录播课程完全不同。没有即时反馈，你只能靠课程结构本身来引导学习。我在录播课上最重视的是节奏控制：每15-20分钟必须有一个小总结，每30分钟必须有一个练习题或思考题，否则学员的注意力会在第25分钟彻底涣散。

另一个录播课的关键是提前预测困惑点。我录课之前会把每节课的脚本写出来，然后逐句检查：这句话，一个初学者读到这里会有什么疑问？如果有疑问，要么改写这句话让它自解释，要么在下一句主动解答这个疑问。

直播课是另一个维度。直播最大的特点是互动性，但也是它最难控制的地方。聊天区涌来的问题往往是四面八方的，你要学会识别：哪个问题值得当场回答，哪个问题是离题的，哪个问题等讲完这个部分自然就解答了。

我在直播上吃过一次很大的亏：课讲到一半，聊天区出现了一个关于Kafka分区策略的问题，我觉得这个问题很好，一时兴起展开讲了20分钟。结果原本的主题没讲完，学员投诉说"今天课没讲完"。从那以后，我会在直播开始前明确告诉学员：聊天区的问题我会在课程结束后统一回答。

最难的事：如何处理"我已经会了"的学员

技术培训课里最让讲师头大的一类学员是"我已经会了"型——他们坐在台下，表情写着"你讲的这些我都知道"。

这类学员分两种情况：

第一种是真的会了，这没问题。你需要给这类人准备深度内容，在课程里设置一些进阶层次，让他们有东西挖。我的做法是在每个知识点后面加一个"扩展阅读"环节，把更深层的东西抛出来，会的人可以和我对话，不会的人听个大概不影响主线学习。

第二种是以为自己会了，但其实是"浅层会了"。这种情况更常见，也更微妙。我处理这种情况的方式是问深入问题。

比如学员说"AOP我会，就是动态代理嘛"，我会问："那Spring AOP在什么情况下用JDK动态代理，什么情况下用CGLIB？这个选择是在哪里决定的？如果强制用CGLIB而目标类是final的，会发生什么？"

大多数"我已经会了"的学员，三个问题之后就会安静下来，开始认真听课。不是打脸，是帮他们发现自己真正的边界在哪里。

课程材料的制作：PPT是最低效的学习媒介

我越来越不喜欢PPT驱动的技术课程。PPT适合演示，不适合学习。

PPT的问题是它太"完整"了——每一页都是精炼的结论，没有推导过程。学员看完PPT，感觉学到了什么，但一周后全忘了，因为大脑没有经历过"理解"的过程，只是视觉扫描了一遍。

我现在倾向于用代码驱动教学：打开IDE，从一个空项目开始，一步一步写出来，每写一行都讲为什么这样写，哪里会出问题，怎么避免。

这有一个副作用——你的课程内容没法提前全部做好，因为你要实时演示。这对讲师的要求很高，你必须对这些代码足够熟悉，不能在台上手忙脚乱。

我的备课方式是：把整个课程的代码提前写一遍，然后再把它删掉，重新写一遍，直到我能流畅地写出来，不需要看任何参考资料。只有到这种程度，才敢上台现场演示。

课后跟进：这是大多数讲师最忽视的环节

课讲完了，学员拿到了材料，这是大多数讲师认为"交付完成"的时间点。

但真正的学习往往发生在课后：学员回去试图实现课上的代码，遇到了问题；学员在实际工作中碰到了相关场景，想起了课上的内容；学员思考之后有了新的疑问。

如果这个阶段没有支持，学习效果会大打折扣。

我的做法是课后设置一个"48小时答疑窗口"——课程结束后48小时内提出的问题，我保证回答。这对学员的吸收效果影响很大。很多人在课上没听懂但不好意思问，回家想了一晚上之后，会在答疑窗口里提出质量很高的问题。

另外，我会给每门课设计一个课后作业，而且是真实的项目练习，不是选择题和填空题。比如讲完Redis集群，作业是：在本地搭建一个三主三从的Redis Cluster，并且写一个程序模拟缓存雪崩，然后加上保护机制，测试前后的差异。

能做完这个作业的学员，知识是真正消化了的。做不完的，会在尝试的过程中发现自己哪里没听懂，下次学习会更有针对性。

关于"有趣"这件事

技术课程很难有趣，这是大家的共识。我一直不太认同这个观点。

任何知识，只要你讲清楚了它的来历、讲清楚了它解决的问题有多痛、讲清楚了它的发明者是怎么一步一步想到这个方案的，它就会变得有趣。

我讲分布式锁的时候，会先讲这样一个故事：电商双十一，库存还剩1件，两个用户同时下单，两个请求几乎同时到达服务器，都读到了库存=1，都认为可以下单，都把库存减1……结果库存变成了-1。这不是一个假设的问题，这是真实发生过的生产事故。

然后我问：你作为一个工程师，第一反应是怎么解决这个问题？

让学员先思考，先提方案，即使方案不完整甚至是错的，也没关系。因为他们提出了方案，就有了"这个方案行得通吗"的好奇心，后面讲正确方案的时候，他们会主动对比、主动发现差异。

好奇心一旦被激发，知识就不难了。

总结：讲师这件事没有捷径

讲好一门技术课程，需要：

对知识的深度理解（不只是会用，还要懂原理）
对学员认知状态的准确模拟（知识诅咒的对抗）
清晰的课程结构设计（五层递进）
大量的练习（代码演示必须非常熟练）
完善的课后支持

没有任何捷径。但这件事带来的回报也是独特的——当一个学员跑来告诉你"我昨天用你讲的方案解决了一个困扰了我们团队三个月的问题"，那种满足感，是你把功能写进代码里体会不到的。