看视频学不会编程？从讲授式教学到“做中学”的工程化实践

如果你也经历过“看视频全会，一写代码全废”的状态，这篇文章值得耐心读完。很多人把萨尔·汗（Sal Khan）创办的可汗学院当作在线教育标杆，认为只要把课程录成短视频，配上自动练习系统，学习者就能高效掌握知识。这个判断放在数学启蒙、通识科普、概念认知等场景下确实成立，但放到程序员学框架、后端工程师学新中间件、运维学自动化脚本时，往往会碰壁。原因很简单：编程是一项程序性技能，程序性技能的成长高度依赖“做”，而不是“听”。本文会从可汗学院教学模式的底层逻辑讲起，分析为什么纯粹的讲授式教学在技术学习中行不通，然后给出“做中学”（Learning by Doing）的工程化拆解、完整实战案例、常见误区排查和最佳实践建议。

1. 背景与核心概念

1.1 萨尔·汗与可汗学院模式是什么

萨尔·汗（Sal Khan）最早为了给远房的表妹辅导数学，把讲解过程录成视频放到网上，后来逐渐发展成今天知名的可汗学院（Khan Academy）。可汗学院的核心形态是短视频课程：老师在一块电子黑板上一边书写一边讲解，把知识点拆成很短的片段，每个视频通常控制在十分钟以内。配合这套视频，平台还提供了自动批改的练习题、掌握进度追踪和个性化学习路径，让学习者可以按照自己的节奏推进。

这套模式的本质是“讲授式教学”的在线化、碎片化和数据化。它的优势非常明显：可以大规模复制优质内容，降低学习成本，让偏远地区的学生也能接触到系统课程；也能通过后台数据发现大多数学生容易卡在哪个知识点，从而优化讲解方式。可汗学院在 K12 数学、物理、经济等学科上的影响力很大，也推动了“翻转课堂”等教学实践的发展。

但我们要清楚一个边界：可汗学院解决得最好的，是“概念理解”和“公式演练”这类以陈述性知识为主的学习目标。陈述性知识指的是“知道什么”，例如什么是 HTTP 状态码、什么是索引、什么是事务隔离级别。这类知识确实可以通过看视频、做选择题来掌握。可一旦学习目标变成了“能不能写出来”“能不能调通”“能不能排错”，单靠讲授式教学就明显不够了。

1.2 什么是讲授式教学

讲授式教学（Lecture-Based Teaching）是传统课堂最主流的教学方式：教师站在讲台上系统讲解概念、原理、步骤，学生负责听、记、看，然后在课后通过练习巩固。在线教育里，录播课、直播课、图文教程本质上都是讲授式教学的变体。

讲授式教学的效率优势体现在知识传递环节。一个老师面对几十甚至成千上万学生，可以快速把前人总结好的经验讲清楚，避免学生从头踩坑。比如讲“什么是 Docker 镜像”，一段十分钟的视频确实能让人快速建立基本认知。这也是为什么网上有那么多“XX 入门教程”视频，很多人也确实通过视频入了门。

但讲授式教学有一个天然局限：知识传递和技能习得不是一回事。你看完一段“如何用 Flask 写 Hello World”的视频，哪怕每个步骤都记住了，关上视频让你从零写一遍，依然可能卡在虚拟环境激活、依赖安装、端口被占用、路由写法报错这些细节上。这些细节不是“不知道”，而是“没做过”。没有做过，就没有形成身体记忆和问题直觉。

1.3 什么是“做中学”

“做中学”源自教育家杜威提出的“Learning by Doing”，核心理念是：学习不应该先学完理论再实践，而应该在真实或接近真实的任务中，通过动手、试错、解决问题来建构知识。程序员圈子经常说的“Talk is cheap, show me the code”其实也是这个意思。

放到技术学习场景，“做中学”可以拆成三个环节。

第一，任务驱动。你需要有一个明确且可验证的目标，比如“写一个能查询用户订单的接口”，而不是“学完 Spring Boot”。目标越具体，行动越容易开始。

第二，动手试错。你必须在真实环境里写代码、跑命令、看报错。报错不是失败，而是系统给你的即时反馈。每解决一个报错，你就建立了一个新的“问题-对策”连接。

第三，复盘迭代。做完一个小功能后，回过头看哪里卡住、为什么卡住、能不能换一种写法。这个环节决定了你是在“重复劳动”还是在“刻意练习”。

用一句话概括：讲授式教学把知识装进脑子，做中学把知识长在手上。

1.4 两种模式的核心差异

2. 为什么纯粹的讲授式教学行不通

2.1 知识迁移不会自动发生

我们经常产生一种错觉：自己看懂了老师的代码，就等于会写代码。这种“看懂”其实只是理解了代码的语法和逻辑，并没有经历从需求到设计的完整决策过程。老师为什么在这个位置加判空？为什么选择列表而不是字典？为什么用递归而不是循环？这些决策背景在视频里往往一带而过，或者压根不会讲。

这就是知识迁移问题。课堂上学到的知识，能不能在新场景下被正确调用，取决于你之前有没有在类似场景下主动调用过。只看视频的学习者，建立的是“这条语法见过”的熟悉感，而不是“遇到这类问题应该用这个工具”的处理能力。所以很多人刷完几十集教程后，遇到一个稍微变形的需求，依然无从下手。

写代码最核心的能力是“把模糊需求翻译成结构化逻辑”，这个过程没有任何视频能代替你完成。你只有在一遍遍从需求到代码的转换中，才能真正提升这种翻译能力。

2.2 缺乏反馈闭环

技能学习非常依赖反馈。没有反馈的学习，就像在黑屋子里投篮，你投了再多次，也不知道该往左还是往右调整。

讲授式教学里，反馈通常是滞后的：视频讲完，你做练习，等老师批改，可能已经过了好几天。而编程恰恰是反馈最密集的领域之一。运行代码的瞬间，编译器会告诉你语法哪里错了，测试用例会告诉你逻辑哪里不满足预期，浏览器的报错面板会告诉你变量为什么未定义。这些反馈如果能被充分利用，学习效率会非常高。

但只看视频的学习者无法获得这种直接反馈。他们看到的是一段已经调通的代码，而不是代码背后的调试过程。真正有价值的，不是最终那几行正确答案，而是“我写了 A 版本，报错，我推测是 B 原因，修改后通过了”这条完整的反馈链路。没有亲手走完这条链路，技能就没办法稳固。

2.3 学习是主动建构，不是被动接收

认知科学里有一个基本共识：学习者在接收新信息时，不是一张白纸，而是会基于已有的知识结构对信息进行过滤、解释和重组。同样的讲解，基础不同的人理解出来的东西完全不同。

讲授式教学默认所有学生都在同一个认知起点，通过统一的讲解向大脑“写入”知识。但写代码是一件高度依赖上下文的活动：同一个函数，有人理解的是“怎么用”，有人理解的是“为什么这么设计”，还有人能联想到“生产环境可能有什么坑”。这些差异不是靠多讲几遍就能抹平的，而是需要学习者在真实的上下文里自己构建。

做中学天然支持这种主动建构。当你在自己的项目里需要实现一个功能时，你会带着问题去找资料：为什么这样写不行？文档里为什么推荐那个方式？试错的过程就是在不断修正和丰富自己的知识结构。而且这个过程中遇到的问题是你自己发现的，你解决问题的动机也更强。

2.4 学习动机难以维持

讲授式教学的内容组织方式是“由易到难”，这个顺序对系统性知识是合理的，但它的驱动力是外在的逻辑，而不是学习者的内在需求。很多人在看视频教程时都有这样的体验：前半部分还能跟上，越到后面越觉得不知道学这些有什么用，于是慢慢放弃。

做中学的任务驱动方式可以有效缓解这个问题。你不必先完成漫长的“基础铺垫”才动手，而是从第一节课就开始做一个虽然简单但完整的小项目。每完成一个小功能，你都能看到自己创造了新的东西。这种即时成就感提供的反馈强度远超“听完一节课”的满足感。

当然，这不是说完全不需要系统学习。我们只是要意识到：人是被短期反馈驱动的动物，学习设计必须不断创造短期反馈，才能支撑长期的成长曲线。

2.5 萨尔·汗模式的合理使用范围

讲到这里，需要给萨尔·汗模式一个公正的评价。可汗学院模式并不是“错”，而是它适用的学习目标有限。它可以用来理解概念、熟悉术语、建立整体认知框架，也可以作为做中学过程中的“按需参考资料”。

比如你想学习 Redis，完全可以先看一个入门视频，了解 Redis 是什么、能解决什么问题，这个过程大概一小时。但从一小时之后开始，你就应该打开命令行，把 Redis 装起来，写几个 key，练习设置过期时间，然后尝试用 Java、Python 或者 Go 把 Redis 集成到项目里。视频的作用是帮你建立初始心理地图，而不是替你完成学习。把视频当成“说明书”而不是“老师”，会更容易接近做中学的状态。

3. 环境准备：把“做中学”当成一个工程来设计

做中学听起来简单，但很多人在落地时同样会翻车。最常见的问题是“每天忙忙碌碌地写代码，回头一看啥都没沉淀下来”。要避免这种状态，建议你把学习本身当成一个工程来做：有目标、有仓库、有日志、有复盘。

3.1 学习环境清单

在开始一个学习项目前，先确认下面几项环境是否准备好。

这套清单的作用是防止做中学变成无头苍蝇式地瞎折腾。技术学习要动手，但不是蛮干，而是要像做项目一样有序推进。

3.2 初始化一个学习项目

假设你要花一个月学习一个新的技术栈，可以先用命令行建好项目骨架。

mkdir learn-by-doing cd learn-by-doing git init mkdir -p docs code notes echo "# Learn By Doing" > README.md git add . git commit -m "初始化学习项目"

建议把项目拆成三个目录：docs 存放需求文档和复盘文档，code 存放自己写的代码，notes 存放每天的学习记录。这样做的好处是，一个月后你可以清晰地看到自己写了多少内容，而不是只留下一句“我学了挺多”。

3.3 用脚本记录学习日志

每天记录学习日志非常有用，但很多人坚持不下来。可以写一个简单的命令行脚本，把当天的学习内容快速追加到一个 Markdown 文件里。

# 文件路径：notes/learning_log.py import sys from datetime import date def add_log(today_work, problem, solution): with open("learning_log.md", "a", encoding="utf-8") as f: f.write(f"\n## {date.today()}\n") f.write(f"- 今日任务：{today_work}\n") f.write(f"- 遇到的问题：{problem}\n") f.write(f"- 解决思路：{solution}\n") if __name__ == "__main__": work = input("今天做了什么：") problem = input("遇到什么问题：") solution = input("怎么解决的：") add_log(work, problem, solution) print("日志已记录到 learning_log.md")

运行方式：

python notes/learning_log.py

这段脚本虽然简单，但符合“记录-复盘-沉淀”的最小闭环。每天花五分钟记录，比学两小时不记录更有长期价值。技术写作和知识沉淀，最忌讳的就是做过就忘。

4. “做中学”的核心拆解

4.1 目标拆解：从一个可验证的成果开始

做中学的第一步，是把“学会一个技术”这种模糊目标，拆成一个个“可验证的成果”。什么叫可验证？就是有一个客观的判定标准：代码能跑通、接口能返回正确数据、点击按钮后页面出现预期结果。

我建议用“功能清单”代替“知识清单”。知识清单是“我要学完 Spring Boot 的自动配置、拦截器、AOP”，功能清单是“我要做一个能注册、登录、发布文章的小网站”。前者让你陷入无休止的学习，后者让你有明确的完成节点。

每完成一个功能，哪怕只是“通过浏览器访问到页面”，都要给自己一个确认：这个功能已经可验证，我离目标又近了一步。这种确认本身就是一种正反馈，比打勾式地看完一章节课程有用得多。

4.2 先跑通，再优化

很多学习者在做中学时会犯另一个错误：过度设计。一开始就想把项目架构搭得特别完美，依赖注入、设计模式、组件划分一步到位，结果还没写完第一个功能，就被复杂度劝退了。

正确的做法是先跑通一个最简版本。无论是代码实现、流程编码、还是数据处理，先找到一个能产生结果的最小路径。比如学消息队列，不要一上来就研究集群和高可用策略，先想办法在本地启动一个单机实例，写一个生产者和消费者，把一条消息从 A 送到 B。这个最小路径跑通之后，你再慢慢往里面加功能、做优化、引入更复杂的场景。

工程领域有个词叫“最小可行产品”（MVP），做中学同样需要 MVP。先把整个链路打通，才能建立全局观，后续的优化也才有着力点。

4.3 建立反馈回路：测试、日志、评审、复盘

做中学的“做”只是手段，真正的成长来自反馈回路。一条完整的反馈回路包含四个环节。

第一，测试。写代码时顺手补充测试用例，不一定要覆盖所有分支，至少要覆盖主流程。测试能告诉你功能是不是真的符合预期，而不是“看起来没报错就行”。

第二，日志。在关键节点打日志，观察程序运行时到底走了哪条路径。日志是排错的第一手段，也是理解程序行为的最直接途径。

第三，评审。如果项目有同事或者朋友能帮忙 review，那要珍惜这个机会。别人眼中的盲区往往就是你的盲区。没有团队条件，可以隔几天回看自己写的代码，这相当于“时间的评审”。

第四，复盘。每周抽出半小时，把本周的卡点列出来，找共性。如果连续三次都卡在同一个知识点上，说明这个知识点不是运气问题，而是你的薄弱点，需要专门补强。

4.4 间隔重复与刻意练习

做中学不能只停留在舒适区里反复做已经会的事情。如果你已经能用 Flask 写增删改查，就不要为了成就感再做十个增删改查项目。这时候应该刻意增加难度，让自己刚好跳一跳够得着。

这里可以结合“间隔重复”（Spaced Repetition）的思路：每隔一段时间，主动回头解决之前卡住的问题。不是简单地把旧代码复制一遍，而是关掉旧代码，凭记忆重写一遍，看自己能还原多少。这个“提取练习”的过程，对长期记忆的帮助非常大。

5. 完整实战案例：用“做中学”学一个新的 Web 框架

下面用一个具体的案例，把做中学的完整流程走一遍。假设你是后端开发者，想学习 FastAPI 这个现代 Python Web 框架。按照传统的讲授式学习，你可能会先翻几十集视频；按照做中学的思路，你应该从一个可运行的小项目开始。

5.1 场景设定

学习目标：用 FastAPI 做一个待办事项接口服务，支持新增任务、查看任务列表、删除任务。不需要数据库，先用内存列表存储，跑通之后再考虑数据持久化。

这个目标足够小，一个周末可以完成；也足够完整，包含路由、请求参数、响应模型和基本的增删改查逻辑。

5.2 第一阶段：准备环境

先创建项目目录并安装依赖。

mkdir fastapi-todo cd fastapi-todo python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install fastapi uvicorn

版本说明：FastAPI 和 Uvicorn 的版本迭代较快，具体版本号以 pip 安装时的最新稳定版为准。本文示例不依赖特定新特性，在常见稳定版本上均可运行。

5.3 第二阶段：编写最简接口

在项目根目录创建main.py，写第一个最简版本的 FastAPI 应用。

# 文件路径：fastapi-todo/main.py from fastapi import FastAPI app = FastAPI() @app.get("/") def read_root(): return {"message": "Hello FastAPI"}

启动服务：

uvicorn main:app --reload

浏览器访问 http://127.0.0.1:8000/，如果能看到{"message":"Hello FastAPI"}，说明你的第一个最简版本已经跑通。这个环节很重要，它确认了环境、依赖和基本语法都没问题。

5.4 第三阶段：实现待办事项功能

在第一个版本的基础上，加入待办事项的增删查逻辑。此时先不引入复杂的数据校验，用 Python 列表和字典完成任务。

# 文件路径：fastapi-todo/main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI() tasks = [] next_id = 1 class Task(BaseModel): title: str class TaskOut(BaseModel): id: int title: str @app.get("/tasks", response_model=list[TaskOut]) def list_tasks(): return tasks @app.post("/tasks", response_model=TaskOut) def create_task(task: Task): global next_id new_task = {"id": next_id, "title": task.title} tasks.append(new_task) next_id += 1 return new_task @app.delete("/tasks/{task_id}", response_model=TaskOut) def delete_task(task_id: int): for task in tasks: if task["id"] == task_id: tasks.remove(task) return task raise HTTPException(status_code=404, detail="任务不存在")

代码说明：

• tasks是一个内存列表，服务重启后数据会丢失，这是刻意选择的简化方案。
• Task和TaskOut都是 Pydantic 模型，前者负责接收请求体，后者负责格式化响应。
• response_model=list[TaskOut]表示接口返回一个TaskOut对象组成的列表。这里用到了 Python 3.9+ 的泛型语法，如果你的 Python 版本较低，需要改成List[TaskOut]并导入List。

5.5 第四阶段：验证接口

启动服务后，用 curl 命令验证接口是否按预期工作。

# 新增一个任务 curl -X POST http://127.0.0.1:8000/tasks \ -H "Content-Type: application/json" \ -d '{"title": "学习 FastAPI"}' # 查看任务列表 curl http://127.0.0.1:8000/tasks # 删除一个任务 curl -X DELETE http://127.0.0.1:8000/tasks/1

预期输出：新增任务后返回{"id":1,"title":"学习 FastAPI"}；查看列表返回包含刚才任务的数组；删除后再查看列表，数组为空。如果你能通过这三条命令走通全部流程，说明这个最小项目已经完成。

5.6 同一主题，讲授式与做中学的差异

对比中可以看到，讲授式学习的大量时间花在“理解”上，但缺少“产出”。做中学虽然前期慢一点，但每一步都有可累积的成果，这些成果会成为后续学习的脚手架。

6. 常见误区与排查思路

做中学听起来简单，但执行中会遇到很多具体问题。下面整理几个高频误区。

6.1 只看不练，想“攒够基础再动手”

很多人的学习节奏是这样的：先花很长时间看视频、记笔记，等到觉得“基础够了”再动手写项目。问题在于，这个“基础够了”的临界点永远等不来。技术栈是无限扩张的，每一层都有新的概念，如果不动手，你根本不知道自己缺什么。

正确做法是尽早动手，让需求倒逼你补基础。遇到不会的语法再查、再学，这样的学习更有针对性，也更牢固。

6.2 遇到报错就回到视频教程

遇到报错后直接回看视频，是一种低效的排错方式。视频里并不会包含你当前遇到的具体报错，尤其是版本差异导致的问题。

更有效的排错顺序是：

1. 完整读一遍报错信息，重点关注 Error 后面的第一行。
2. 把报错关键词复制到搜索引擎搜索，优先看官方文档和 Stack Overflow。
3. 尝试在最小复现环境里排除干扰因素。
4. 修复后再想一下：这个报错的根因是什么？以后怎么避免？

这套流程会训练你独立的排错能力。编程学习中的大部分成长，恰恰来自这些调不通又调通了的时刻。

6.3 没有沉淀和复盘

做中学如果只做不复盘，会陷入“越学越散”的状态。你可能做了很多小项目，但每个项目之间没有知识连接，遇到新问题还是从零开始。

建议每个项目都写一份简短的 README，至少包含：

• 项目目标：我想解决什么问题。
• 技术选型：我用了哪些技术，为什么选它。
• 核心难点：哪部分最花时间，最终怎么解决。
• 可改进点：如果重做一遍，我会在哪里改。

写 README 的过程，就是你在把隐性经验转化为显性知识的过程。这一步是区分“有经验”和“有经验但说不出来”的关键。

6.4 拿生产环境练手

做中学鼓励动手，但必须限定在安全可控的环境里。千万不要为了“实战”就直接在生产环境执行危险命令，比如没有备份的批量删除、没有灰度策略的配置变更、没有授权的数据库操作。技术学习要有边界感，任何操作都要先确认环境隔离情况。

本地开发环境、测试环境、专用的沙箱虚拟机都是不错的选择。涉及到公司业务数据时，即使是在测试库，也要遵循最小权限原则，不做超出授权范围的操作。

7. 最佳实践与工程建议

7.1 用任务清单管理学习粒度

做中学需要一个可以持续追踪的目标。这里推荐把学习计划拆成周任务和日任务两个级别。

周任务描述的是本周要交付的成果，例如“完成用户登录接口，并支持 token 校验”。日任务则是可以当天完成的行动，例如“研究 JWT 的签发和验证流程”。每天下班前检查日任务是否完成，如果连续三天都没完成，就说明任务拆分得太大或太难，需要进一步调整。

7.2 把学习成果代码化、文档化

尽量把每一次实验、每一个问题都沉淀成代码和文档。代码是给别人看的，文档是给未来的自己看的。这个习惯本身的技术含量不比写业务代码低。

尤其是当你学习一个新技术时，可以尝试把学习过程写成一篇技术博客。不需要写得多深，只要把“我遇到了什么问题、为什么这么解决、关键代码是什么”讲清楚，就足够有价值。写博客的过程会逼你把模糊的理解变成清晰的表达，这是做中学的最后一环。

7.3 建立最小反馈周期

反馈周期越短，学习效果越好。做中学里，最小的反馈周期就是“改一行代码 -> 立刻看到结果”。为了缩短反馈周期，建议把学习环境配置得好用一点：能自动化测试就自动化测试，能热重载就热重载，能写脚本验证就写脚本。

比如开发接口时，不要每次手工打开浏览器去点页面，而是写好自动化测试脚本，一条命令跑完所有接口验证。脚本虽然多花了一点时间，但它在整个学习周期里会持续为你提供快速反馈。

7.4 从“看教程”过渡到“写教程”

当你学完一个技术点之后，试着写一篇教程教给别人。这一步用到的能力远超“看懂”：你需要组织逻辑、选择例子、预判读者可能的困惑。写不出来，说明你没真懂；写出来的过程，就是在查漏补缺。

这也是为什么很多技术博主技术成长快的原因。他们不是天生会写，而是通过输出来倒逼输入。你不需要写得完美，甚至可以先写给自己看，但一定要写。

7.5 安全与合规意识

最后强调一遍安全边界。做中学过程中，你会接触数据库连接、用户数据、服务器权限等内容，即使是在练习项目里，也要养成安全意识：密码不能明文存储、API 密钥不能提交到公开仓库、涉及删除的操作要谨慎。这些意识和编程技能一样，需要日常积累。不要让你的学习项目成为安全事故的源头。

8. 写在最后

回到标题的问题：为什么萨尔·汗模式行不通？准确地说，是“只靠讲授式教学不够用”。可汗学院让我们看到了在线知识传递的效率，但技术学习里最硬核的部分——动手写代码、排错、调试、架构设计——永远需要学习者亲手去实践。看一百节视频不如亲手跑通一个接口，收藏一百篇教程不如提交第一行 commit。

真正的技术成长，发生在你感到困惑、查询资料、动手验证、最终解决问题的那个闭环里。下一次想学一个新框架时，试着关掉视频收藏夹，打开编辑器，写下你的第一个最小可运行版本。哪怕只有三行代码，那也是属于你的进步。如果这篇文章对你有帮助，欢迎收藏备用；如果你有更好的做中学实践方法，也欢迎在评论区分享交流。