ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

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

看视频学不会编程?从讲授式教学到“做中学”的工程化实践 如果你也经历过“看视频全会一写代码全废”的状态这篇文章值得耐心读完。很多人把萨尔·汗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 学习环境清单在开始一个学习项目前先确认下面几项环境是否准备好。项目说明明确目标用一句话写清楚“我要在一个月内完成一个什么样的项目”项目仓库用 Git 管理代码方便回溯和复盘运行环境本机装好语言环境、数据库、容器环境能跑通最小样例学习日志每天记录“做了什么、遇到什么问题、怎么解决的”复盘机制每周回顾一次卡点找出共性薄弱点这套清单的作用是防止做中学变成无头苍蝇式地瞎折腾。技术学习要动手但不是蛮干而是要像做项目一样有序推进。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, encodingutf-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_modellist[TaskOut]) def list_tasks(): return tasks app.post(/tasks, response_modelTaskOut) 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_modelTaskOut) def delete_task(task_id: int): for task in tasks: if task[id] task_id: tasks.remove(task) return task raise HTTPException(status_code404, detail任务不存在)代码说明tasks是一个内存列表服务重启后数据会丢失这是刻意选择的简化方案。Task和TaskOut都是 Pydantic 模型前者负责接收请求体后者负责格式化响应。response_modellist[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 同一主题讲授式与做中学的差异环节讲授式学习路径做中学学习路径第一天看视频了解 FastAPI 是什么安装依赖写出 Hello World第二天继续学路由参数实现新增任务接口第三天学 Pydantic 模型用法实现列表和删除接口第四天学习依赖注入用 curl 完整验证接口第五天开始看实战项目视频加入 SQLite 持久化并写测试结果能看懂代码但不确定能否独立实现已经拥有一个能运行的完整小项目对比中可以看到讲授式学习的大量时间花在“理解”上但缺少“产出”。做中学虽然前期慢一点但每一步都有可累积的成果这些成果会成为后续学习的脚手架。6. 常见误区与排查思路做中学听起来简单但执行中会遇到很多具体问题。下面整理几个高频误区。问题现象常见原因解决思路收藏了无数教程还是不会写只看不练知识没有内化每看一节必须写一个对应的小程序一开始就设计复杂架构项目半途而废完美主义跳过了最小可行路径先跑通一个最小版本再做优化遇到报错第一反应是回看视频缺少独立排查能力先读报错信息搜索关键词再对照文档做了很多练习但感觉没成长停留在舒适区重复刻意增加难度挑战薄弱点项目做完就忘无法面试讲清楚缺少复盘和总结写 README、画流程图、梳理技术决策6.1 只看不练想“攒够基础再动手”很多人的学习节奏是这样的先花很长时间看视频、记笔记等到觉得“基础够了”再动手写项目。问题在于这个“基础够了”的临界点永远等不来。技术栈是无限扩张的每一层都有新的概念如果不动手你根本不知道自己缺什么。正确做法是尽早动手让需求倒逼你补基础。遇到不会的语法再查、再学这样的学习更有针对性也更牢固。6.2 遇到报错就回到视频教程遇到报错后直接回看视频是一种低效的排错方式。视频里并不会包含你当前遇到的具体报错尤其是版本差异导致的问题。更有效的排错顺序是完整读一遍报错信息重点关注 Error 后面的第一行。把报错关键词复制到搜索引擎搜索优先看官方文档和 Stack Overflow。尝试在最小复现环境里排除干扰因素。修复后再想一下这个报错的根因是什么以后怎么避免这套流程会训练你独立的排错能力。编程学习中的大部分成长恰恰来自这些调不通又调通了的时刻。6.3 没有沉淀和复盘做中学如果只做不复盘会陷入“越学越散”的状态。你可能做了很多小项目但每个项目之间没有知识连接遇到新问题还是从零开始。建议每个项目都写一份简短的 README至少包含项目目标我想解决什么问题。技术选型我用了哪些技术为什么选它。核心难点哪部分最花时间最终怎么解决。可改进点如果重做一遍我会在哪里改。写 README 的过程就是你在把隐性经验转化为显性知识的过程。这一步是区分“有经验”和“有经验但说不出来”的关键。6.4 拿生产环境练手做中学鼓励动手但必须限定在安全可控的环境里。千万不要为了“实战”就直接在生产环境执行危险命令比如没有备份的批量删除、没有灰度策略的配置变更、没有授权的数据库操作。技术学习要有边界感任何操作都要先确认环境隔离情况。本地开发环境、测试环境、专用的沙箱虚拟机都是不错的选择。涉及到公司业务数据时即使是在测试库也要遵循最小权限原则不做超出授权范围的操作。7. 最佳实践与工程建议7.1 用任务清单管理学习粒度做中学需要一个可以持续追踪的目标。这里推荐把学习计划拆成周任务和日任务两个级别。周任务描述的是本周要交付的成果例如“完成用户登录接口并支持 token 校验”。日任务则是可以当天完成的行动例如“研究 JWT 的签发和验证流程”。每天下班前检查日任务是否完成如果连续三天都没完成就说明任务拆分得太大或太难需要进一步调整。7.2 把学习成果代码化、文档化尽量把每一次实验、每一个问题都沉淀成代码和文档。代码是给别人看的文档是给未来的自己看的。这个习惯本身的技术含量不比写业务代码低。尤其是当你学习一个新技术时可以尝试把学习过程写成一篇技术博客。不需要写得多深只要把“我遇到了什么问题、为什么这么解决、关键代码是什么”讲清楚就足够有价值。写博客的过程会逼你把模糊的理解变成清晰的表达这是做中学的最后一环。7.3 建立最小反馈周期反馈周期越短学习效果越好。做中学里最小的反馈周期就是“改一行代码 - 立刻看到结果”。为了缩短反馈周期建议把学习环境配置得好用一点能自动化测试就自动化测试能热重载就热重载能写脚本验证就写脚本。比如开发接口时不要每次手工打开浏览器去点页面而是写好自动化测试脚本一条命令跑完所有接口验证。脚本虽然多花了一点时间但它在整个学习周期里会持续为你提供快速反馈。7.4 从“看教程”过渡到“写教程”当你学完一个技术点之后试着写一篇教程教给别人。这一步用到的能力远超“看懂”你需要组织逻辑、选择例子、预判读者可能的困惑。写不出来说明你没真懂写出来的过程就是在查漏补缺。这也是为什么很多技术博主技术成长快的原因。他们不是天生会写而是通过输出来倒逼输入。你不需要写得完美甚至可以先写给自己看但一定要写。7.5 安全与合规意识最后强调一遍安全边界。做中学过程中你会接触数据库连接、用户数据、服务器权限等内容即使是在练习项目里也要养成安全意识密码不能明文存储、API 密钥不能提交到公开仓库、涉及删除的操作要谨慎。这些意识和编程技能一样需要日常积累。不要让你的学习项目成为安全事故的源头。8. 写在最后回到标题的问题为什么萨尔·汗模式行不通准确地说是“只靠讲授式教学不够用”。可汗学院让我们看到了在线知识传递的效率但技术学习里最硬核的部分——动手写代码、排错、调试、架构设计——永远需要学习者亲手去实践。看一百节视频不如亲手跑通一个接口收藏一百篇教程不如提交第一行 commit。真正的技术成长发生在你感到困惑、查询资料、动手验证、最终解决问题的那个闭环里。下一次想学一个新框架时试着关掉视频收藏夹打开编辑器写下你的第一个最小可运行版本。哪怕只有三行代码那也是属于你的进步。如果这篇文章对你有帮助欢迎收藏备用如果你有更好的做中学实践方法也欢迎在评论区分享交流。
返回列表