看完了 10 集 Python 基础教程把视频里的示例代码一行行跟着敲完甚至还在笔记里抄了一遍然后关掉播放器面对一个空白文件突然不知道第一行该写什么。这是我在技术社区和自学群里见过最多的求助帖也是“讲授式教学”在编程学习中最典型的失败现场。萨尔·汗创办可汗学院让全球数亿人免费获得了高质量的教学视频这件事的教育价值不需要质疑。但如果把“把课讲清楚”当成教学的全部尤其是在编程学习这个领域一定会遇到一个扎心的瓶颈学习者看得懂却做不到。真正的原因不是视频不够清晰不是老师不够幽默而是讲授式教学天然缺少一个结构性的东西——反馈回路feedback loop。学习编程不是“听懂一个概念”而是“在反复试错中建立行为习惯”。本文就从“为什么萨尔·汗式教学行不通”这个问题切入拆解“讲授式教学”与“做中学”在原理层面的差别并给出一套更符合编程学习规律的自学或团队培训路径。如果你正在学编程却总觉得“眼睛会了、手不会”或者你负责带新人、做技术培训但发现传统“讲师讲、学生听”的模式效率很低这篇文章值得你读完并收藏。1. 为什么一个教育理念会在编程学习中失效可汗学院最初的成功建立在数学教学上。萨尔·汗早期给表妹录数学辅导视频每段视频控制在十分钟左右把一道题的解法一步步讲清楚。学生可以暂停、回放、按自己的节奏看。这个模式在教育资源不均衡的场景下价值巨大它用极低的成本把“名师讲解”复制到了全世界。但如果只看“讲解”这一环很容易忽略一个事实可汗学院真正的教学模式是“视频讲授 在线练习系统”。学生在看完视频后会被引导去做一组练习题系统当场判断对错并给出解析。这套设计比单纯看视频要先进得多因为它增加了一个基础的反馈环节。问题在于这类练习系统里的题目大多数是“点选型”“填空型”的客观题。学习者面对的是一道已经被定义好边界的问题输入答案后立刻得到对错判断。而编程学习中的真实任务完全不是这样。真实编程任务里没有人告诉你“这里该用 for 循环还是 while 循环”没有人在你做错时立刻弹出解析甚至没有人告诉你“这个程序对不对”。你面对的是编译器的报错、运行时异常、奇怪的空指针、莫名不匹配的数据类型。你需要自己发现问题、定位问题、假设原因、修改代码、再次运行验证。这个过程是一个完整的“假设-检验-修正”循环。讲授式教学擅长传递“已知的、结构化的知识”但它不擅长训练“面对未知问题的应对能力”。把可汗学院的方法直接搬到编程学习里就会出现文章开头那个场景视频看完了练习也做了但真正上手写项目时仍然手足无措。从更底层的角度看萨尔·汗的教育理念延续了“知识传递”这一传统教学隐喻老师拥有知识学生缺少知识老师的任务是把知识从自己的头脑搬运到学生的头脑中。只要讲解足够清晰、练习安排足够合理学生就能学会。这个隐喻对公式推导、历史事件、语法规则这些“陈述性知识”有一定效果但对编程这种“程序性知识”占比极高的技能来说有一个致命缺陷技能不是被传递过去的而是在操作、反馈、修正的循环中长出来的。这也是本文的核心判断萨尔·汗式教学之所以在编程学习中行不通不是因为他讲得不好而是因为它把教学系统的重心放在了“传播知识”上而不是“构建反馈”上。而做中学恰恰是围绕反馈回路来设计学习体验的。2. 讲授式教学的核心假设与适用范围2.1 讲授式教学的基本逻辑讲授式教学简单说就是由老师或视频课程把概念、原理、案例系统性地讲解给学生听学生通过听讲、记录、理解再通过课后练习巩固。它的基本逻辑是知识可以被分解成清晰的单元。优秀教师能把每个单元讲得通俗易懂。学生只要理解了每个单元就能组合出完整的知识体系。作业与考试用来验证理解程度。这个逻辑在教育史上根深蒂固。它适合信息密度高、结构严谨、答案明确的科目。比如数学公式的推导、物理定律的证明、编程语言的基本语法这些内容确实需要有人先做系统的讲述否则学生自己摸索效率极低。2.2 可汗学院到底解决了什么问题可汗学院解决的问题是“优质讲解的规模化分发”。在没有互联网教育的年代同一个教室里五十个学生听同一个老师讲课学得快的人被拖慢学得慢的人跟不上。视频课程出现后学生可以暂停、回放、倍速理论上可以按自己的节奏学习。同时练习系统提供了即时对错反馈并让学生可以反复练习直到掌握。这套设计显著改善了“教师资源不足”和“学生水平参差”的问题。在数学、物理、经济学等基础学科中它的有效性已经被大规模用户验证。这是萨尔·汗值得尊敬的地方。2.3 它做得好的领域与做不好的领域一种教学方式的有效性高度依赖学科的性质。我们可以把学习内容粗略分成两类内容类型特征典型例子讲授式教学的效果陈述性知识事实、概念、公式、规则变量是什么、HTTP 状态码含义效果好适合系统讲解程序性知识技能、流程、操作、判断写函数、调 bug、设计接口效果差必须动手训练策略性知识在复杂情境中做决策架构选型、性能优化、需求拆解讲授只能提供启发必须靠实践积累讲授式教学在陈述性知识的传授上效率极高。但在程序性知识和策略性知识上它只能完成“铺垫”的功能。你不可能通过看游泳教学视频学会游泳不可能通过看拳击比赛录像学会出拳。编程也是一样你能通过视频理解“什么是函数”但“什么时候应该拆函数、怎么拆、拆到什么粒度”这种判断力只能在持续写代码和改代码的过程中形成。3. 讲授式教学的三个结构性局限3.1 局限一学生只接收信息没有构建知识教育学里有一个广泛被接受的理念学习不是“接收信息”而是“构建意义”。同一段关于 Python 字典的讲解有经验的人听到的是“键值对在哈希表中的组织方式”新手听到的只是“字典就是大括号加冒号”。差异为什么这么大因为理解不是把老师的话原样复制到大脑而是把新信息和自己已有的经验、模型、知识结构连接起来。如果没有相关的经验基础信息就只是悬浮在记忆表层的“死知识”。讲授式教学默认“讲清楚就等于学明白”但实际情况是讲解只能确保学生“听见了”不能确保学生“构建了”。只有当学生尝试用自己的语言解释这个概念或者用这个概念去解决一个具体问题时知识结构才算真正建立。这就是“生成效应”学习者在主动生成答案、解释或解决方案时记忆和理解效果远好于被动接收。3.2 局限二反馈回路缺失或严重延迟这是讲授式教学在编程学习中最致命的短板。人能学会复杂技能依赖一个核心机制尝试行动 → 获得结果 → 对比预期 → 调整行动。这个循环循环得越快学习效率越高。孩子学走路跌倒了爬起来再试每一步都有即时反馈学骑自行车车身倾斜不稳定的感觉就是即时反馈学编程写完代码运行后的报错和输出就是即时反馈。但传统的讲授式课堂里一节课四十五分钟学生没有机会尝试课后作业要等到第二天甚至下周才有批改结果。反馈周期太长学习者在“尝试-反馈”的循环中无法形成有效的自我校正。更糟的是当反馈最终来临时学习者往往已经忘记了自己当时的思考过程。讲授式教学弱化了反馈环节相当于在训练运动员时只让他看录像不让他上场。看录像当然有用但永远替代不了上场后的真实触球感。3.3 局限三教学节奏由讲授者决定而不是由学生决定视频课程提供了一种“伪个性化”学生可以暂停、回放、倍速。但本质上课程的推进节奏仍然由讲师决定。讲师觉得“列表推导式很简单”可能只花两分钟而你可能需要在这里停留一小时。讲师觉得“递归很难”用了二十分钟讲解而你可能在五分钟内已经理解了核心剩下的十五分钟只是陪跑。学习效率最高的状态发生在学生刚好处于自己的能力边界附近也就是所谓“最近发展区”。在这个区域里任务有挑战性但又够得着学生最投入、进步最快。讲授式教学假设同一个班级里的学生处于近似水平这在现实里几乎不成立。做中学则不一样当学习者在真实任务中前进时他会自然地在自己的卡点停留、反复调试、尝试不同方案直到突破。学习节奏真正由学习者自身的认知状态决定而不是由课程大纲决定。4. 编程学习为什么依赖“反馈回路”4.1 编程首先是一种技能而不是一门知识如果把编程学习比作学开车那语法就是油门和刹车的位置API 是交通标志但不真正上路这些信息毫无意义。编程的核心能力是在面对一个模糊需求时能够把问题拆解成可执行的步骤用代码表达并在出错时快速定位和修复。这些能力全部依赖大量实际操作来养成。4.2 反馈回路是技能习得的发动机我们来拆解一次完整的错误处理过程你写了一段代码想实现“读取文件并统计单词数”。运行后程序抛出异常FileNotFoundError。你查看报错信息发现路径不对。你修改路径再次运行。这次程序跑通了但输出结果比预期的少。你意识到自己只统计了小写单词问题出在大小写没有统一。你加上.lower()再次运行。输出正确。这一步一步的过程就是你真正学到东西的瞬间。编译器、运行时和调试器共同构成了一套极其强大的即时反馈系统。每一次报错都是在告诉你“你的心智模型和现实世界之间存在偏差。”而修正偏差的过程就是学习发生的过程。4.3 如何快速得到反馈回路对于编程学习者来说建立反馈回路的最短路径是不断制造“可以运行的最小程序”。比如你现在想学习 Python 的列表推导式不要只看教程而是立刻打开一个 Python 文件写一小段代码# 文件路径squares.py squares [x * x for x in range(10)] print(squares)运行它python squares.py观察输出。然后修改条件、修改表达式看看结果会怎样变化。再故意制造一个错误看看会得到什么报错信息。这就是一个完整的反馈循环五分钟之内就能完成。4.4 最小反馈示例用错误信息驱动理解# 文件路径broken_squares.py squares [x * x for x in range(10) print(squares)运行后会看到SyntaxError报错。这是Python在告诉你方括号少了一个。你的任务不是“背住正确的写法”而是“理解这个报错为什么出现”。当你亲手写出这个错误并成功修复后你对面这条代码的记忆深度会远超只看十遍正确代码。5. 同一个知识点两种教法对比以“列表推导式”为例前面讲了理论这一章用一个具体的编程知识点来做对比。这个知识点是 Python 的列表推导式。5.1 讲授式路径讲授式教学会这样设计讲解列表推导式的语法结构[表达式 for 变量 in 可迭代对象 if 条件]。给出几个例子逐步演示推导式如何展开成普通 for 循环。强调它比普通循环更简洁、更 Pythonic。布置几道练习题比如“生成 0 到 9 的平方数列表”。你跟着看下来每一步都听得懂示例代码也都能复现。但这不保证你下次遇到“要把列表里的偶数筛选出来并乘以 3”时能第一时间想到用列表推导式。5.2 做中学路径做中学路径会这样设计第一步给你一个真实问题“我有一个整数列表想把每个数平方以后生成新列表请写代码实现。”第二步你可以先用笨办法写numbers [1, 2, 3, 4, 5] squares [] for n in numbers: squares.append(n * n) print(squares)这段代码能跑通。这时再问自己一个问题这段代码能不能更简洁第三步带着“更简洁”这个动机去查阅资料或看教程中关于列表推导式的章节你找到了答案numbers [1, 2, 3, 4, 5] squares [n * n for n in numbers] print(squares)运行后结果一致你亲身体验到了列表推导式带来的简洁感。第四步做一个挑战任务如果只想保留平方后大于 10 的数字怎么写你尝试加上 if 条件numbers [1, 2, 3, 4, 5, 6] squares [n * n for n in numbers if n * n 10] print(squares)运行、验证、调整。整个过程大约二十分钟但你经历了“发现问题-寻找方案-应用方案-验证结果”的完整闭环。5.3 两种路径的关键差异维度讲授式路径做中学路径动机来源外部课程安排内在需求驱动概念接触时机先听概念后做练习先遇到问题再引入概念反馈来源练习题对错判断代码运行结果与报错信息记忆深度浅层理解情景化记忆更持久能力迁移依赖题目相似度更容易迁移到真实项目做中学不是一种“少了讲解”的学习方式而是一种“讲解出现在正确时机”的学习方式。概念仍然要学语法仍然要记但它们出现在学习者已经产生困惑、主动想要答案的时刻。这时的讲解价值远远大于课程开头五分钟的铺垫。6. 做中学不是不要讲解而是重新安排讲解的位置6.1 讲解要放到“困惑之后”很多人在理解“做中学”时会把它简化成“只做不学”。这是误解。讲解本身没有错错的是把它放在学习旅程的最前面。当学习者还没有产生困惑时大量讲解只会变成低效的信息输入。更合理的顺序是先让学习者尝试一个有一定挑战性的任务在尝试中暴露问题然后针对暴露的问题做简短讲解最后让学习者带着新理解继续修改。这个过程可以概括为尝试 → 困惑 → 讲解 → 再尝试。6.2 一个可复用的学习流程模板这套流程不只适用于个人自学也适用于团队培训和技术训练营。推荐一个通用的五个步骤定义任务选择一个合适难度的真实任务比如“写一个命令行版待办事项管理程序”。自主尝试不急着看教程先凭已有知识尽量完成记录卡住的地方。针对性讲解只讲卡点不从头讲。把卡壳的语法、API、设计思路讲清楚。二次实现在听完讲解后重新实现或优化代码争取独立完成。复盘总结把“我一开始是怎样想的”“错在哪里”“最终如何解决”记录下来。这五步中讲解的比例不超过三分之一其余时间都在做、在错、在改。6.3 时间配比三分之一讲解三分之二动手给团队做过技术培训的工程师应该都有体会讲两小时不如让新人自己折腾半小时来得有效。一个比较稳妥的时间配比是如果总共要学 10 个小时那讲解类内容控制在 3 小时以内动手编码不少于 6 小时最后再用 1 小时做总结复盘。当然这不是一个绝对公式而是一种倾向性引导。不同基础的学习者可以调整比例但始终要记得编码时间的占比不应该低于观看或阅读时间的占比。6.4 如何验证自己的学习效果做中学的验证方式不是再做一道课后题而是看你能否独立完成一个从未见过的小任务。建议每学完一个阶段给自己布置一个“综合挑战任务”。比如学完 Python 基础语法后不急着看爬虫教程先尝试独立写一个简单的文件批量重命名脚本学完 Flask 后不急着看项目实战视频先尝试把官方文档里的最小示例改造成自己的博客后端。如果全程不打开任何教程也能完成说明知识已经内化。如果中途卡住卡住的地方就是下一次学习的最佳起点。7. 自学者与团队培训中最容易踩的四个坑问题现象可能原因排查方式解决方案看完视频就忘写代码时大脑空白学习时间基本花在被动接收上主动产出太少统计一周内“观看时长”和“编码时长”的比值把编码时长提升到观看时长的两倍以上能看懂报错但找不到自己代码的问题缺少分解问题的训练遇到错误就全局乱猜问问自己这个报错发生在哪一行变量当时的值是什么学会分段注释代码用二分定位法缩小错误范围练习题都能做对但做小项目时无从下手练习题目有明确的边界真实任务没有边界观察卡壳位置是不是在“拆解需求”这一步多练习把需求拆成小的子任务逐步完成团队培训效果差新人上手慢培训以讲师宣讲为主新人缺少真实代码任务的反馈统计培训期间每个新人写了多少行有效代码、修了多少个 bug设计“小任务闯关”机制让新人第一天就接触真实代码这四个坑有一个共同点问题的根源不是“讲得不够清楚”而是“学生练得不够多、反馈不够快”。8. 用工程化思维设计“做中学”体系对于个人自学者这里的“工程化”体现在把学习当成项目来管理对于团队培训则体现在制度建设。8.1 用任务清单替代课程表与其列一个“学习计划第 1 周学变量第 2 周学函数”不如列一个“任务清单”# Python 学习项目命令行待办事项管理工具 ## 阶段一最小可用版 - [ ] 创建一个 Python 文件用列表存储待办事项 - [ ] 实现添加待办的功能 - [ ] 实现查看所有待办的功能 - [ ] 实现标记完成的待办功能 ## 阶段二持久化 - [ ] 将待办事项保存到本地文本文件 - [ ] 程序启动时从文件读取已有数据 - [ ] 处理文件不存在的异常情况 ## 阶段三增强 - [ ] 支持删除待办事项 - [ ] 支持按优先级排序 - [ ] 增加命令行参数支持 add、list、done 等子命令每完成一个勾就获得一次正反馈。任务清单比课程表更符合做中学的逻辑因为它是按“能完成什么”来组织的不是按“看了什么”来组织的。8.2 用测试代码替代“课后作业”传统的练习题是给一个固定输入期望一个固定输出。而测试代码的逻辑是先定义程序应该满足的行为再写实现。这在做中学中是一个极好的反馈工具。# 文件路径test_calculator.py import calculator def test_add(): assert calculator.add(2, 3) 5 def test_subtract(): assert calculator.subtract(5, 2) 3当你运行pytest时所有未通过测试的用例会清晰告诉你“程序目前不满足哪些行为”。你不用等老师批改就能立刻进入修复循环。pytest test_calculator.py -v看到绿色通过的一刻就是一次完整正反馈。团队培训中这个机制比“出题-判卷”高效得多。8.3 用代码评审制造人工反馈对初学者而言最大问题往往是“不知道自己哪里写得不够好”。一种有效的做法是引入“人工反馈”把代码给有经验的人看请对方指出三个可以改进的点。不需要一次给十条意见每次给最重要的两三条即可。对于团队培训可以设计固定节奏的代码评审每周抽一次让新人讲解自己本周写的代码由导师和 peer 提出改进建议。评审不是打分而是“反馈系统”的一种人工扩展。8.4 一个最小项目训练模板如果要为一名新入职的 Python 工程师设计一周的培训计划可以这样天数训练任务关键反馈第 1 天跑通项目本地环境修复 3 个故意制造的 bug错误信息与运行结果第 2 天为现有模块补充单元测试pytest 测试结果第 3-4 天独立实现一个小需求评审后修改代码评审意见第 5 天复盘一周解决过的问题写一篇技术笔记输出倒逼总结这个模板的核心不是“教学大纲”而是“真实任务 即时/短期反馈”。新人不是在“准备做项目”而是“在项目中学习”。9. 结论讲课没有错错在把它当成学习系统的全部回到最初的问题为什么萨尔·汗行不通因为可汗学院式的讲授教学本质上是一个“知识分发系统”。它擅长把结构良好的知识以最低成本、最好体验送到学习者面前。在一个信息稀缺的时代这价值连城。但在编程这个需要高度动手、持续反馈的领域它的结构性短板非常明显学生接收了大量输入却缺少足够的输出机会也缺少高密度的“试错-修正”循环。做中学并不是要否定讲解。恰恰相反做中学为讲解找到了更合适的位置它把讲解从学习的起点移到学习者产生困惑之后。这个位置上的讲解才会被真正消化。对于正在自学编程的人最实际的建议是下一次准备打开一个新教程之前先给自己找一个“卡住你的问题”。带着问题去学用代码去验证用错误去推动理解。这比刷完十集视频更能让你接近一个真正的程序员。对于正在设计技术培训体系的团队最值得思考的一件事是你的课程里学生每天真正动手写代码的时间有多少他们写完代码后能不能在一天内得到有效的反馈如果这两个数字不够高那再多再精彩的课程视频也很难带来技术能力的真实增长。