这周四五六三天学校没有安排课程，终于完整地有了自己的时间。前段时间因为总是在忙项目和比赛备赛，上课的时候很多时候也在顾自己的事情。回过头来才发现，自己对老师讲的内容已经有点“不知所云”了，于是就打算趁着这三天时间，好好复习一下这个月学的 JavaEE 以及微信小程序开发课程。

但是当我真正拿起 PPT 开始啃上面的知识时，我很快就发现了一个问题：如果只是单看 PPT，脑子里确实会留下一个印象，可这种“看过了”的感觉并不等于真正学会了。

最先让我意识到“看 PPT 不等于学会了”的，是补 MyBatis 第一章的时候。表面上看，那一章其实没有特别难，基本都是概念性的内容：什么是框架、什么是 MyBatis、它为什么会出现、它大概解决什么问题。看 PPT 的时候，我也确实觉得自己是懂的，至少每一页都能跟下来，很多词也都眼熟。

可等我真的开始按自己的理解去整理的时候，问题就出来了。那种感觉很奇怪，不是完全不会，但脑子里就是一团雾。很多名词都见过，很多定义也好像能看懂，可一旦让我脱离 PPT 自己讲，或者换一种说法表达出来，就开始卡住。更明显的是，等我真的开始尝试做一点最小实践的时候，之前那些“好像懂了”的地方就一个个露馅了。比如 mybatis-config.xml 到底该怎么写，SqlSessionFactoryBuilder、SqlSessionFactory 和 SqlSession 为什么要拆成三层，为什么 namespace 和 id 要一起用，动态 SQL 里的 、、 到底分别解决什么问题。这些东西单看 PPT 的时候都有点印象，但真正一上手，就会发现自己根本没那么明白。

也就是从那个时候开始，我第一次认真怀疑：以前那种“把课件看一遍，就默认自己差不多会了”的学习方式，可能从一开始就有问题。

后来我开始换一种补课方法：不再只是顺着 PPT 往下看，而是给自己每一章都配一个“问题引导文件”。简单来说，就是先不急着记一堆笔记，而是先列出这一章最核心的问题，再带着这些问题去看 PPT、去整理、去回答。

这个方法最开始让我感觉真的有点用，不是我突然学得快了，而是我终于在补课的时候有了“目标感”。以前看 PPT 更像一种盲扫，看到哪算哪，看完整章之后脑子里有个模糊印象，但很难说出重点是什么，也不知道自己到底哪里懂了、哪里没懂。用了问题引导文件以后，我开始知道这一章到底该关注什么，哪些问题是主线，哪些概念是重点，哪些地方是我真正需要弄懂的。

换句话说，这个方法把我原来那种“只是看一遍”的学习方式，慢慢变成了一种必须要回答问题、必须要把理解说出来的学习方式。以前我总觉得自己看懂了，可真正要回答一个问题的时候，才会发现很多东西其实只是眼熟，并没有真正变成自己的理解。比如在 MyBatis 第二章里，我一开始其实只知道有 SqlSessionFactoryBuilder、SqlSessionFactory 和 SqlSession 这三个名词，但真正被问到“为什么要拆成三层，它们不能用一个对象代替吗”，我才发现自己会背流程，却说不清职责。再比如动态 SQL 那一章，看 PPT 时觉得标签很多，但真正开始问“ 和 为什么经常一起出现”“ 到底和 、 是什么关系”时，才发现之前的理解根本不稳。

一开始我其实并没有立刻适应这种方法。比如在第一章的课引文件里，光 MyBatis 的基础概念，我就用了一个早上。按我原来的预期，这个效率绝对算低了。

后来我才意识到，问题不完全在于慢，而在于我前半段其实花了太多时间在“整理”和“摘抄”上。我总觉得，只要是要落成文档的东西，就必须尽善尽美，不太敢直接用自己的话，反而更倾向于把 PPT 上那些看起来更专业的句子直接贴下来。这样做表面上看，文档写得很满，定义也很完整，但实际效果却很虚——看起来什么都写了，可如果让我脱离 PPT 自己讲一遍，还是会卡壳。

真正把我点醒的，是我当时去问了一句：“我一个上午才看完第一章，是不是太慢了？”回头看，这句话其实挺关键。因为我后来意识到，问题不完全在于慢，而在于我前半段其实花了太多时间在整理和摘抄教材语言上。很多话是“抄下来了”，但不等于我真的理解了。

被点醒之后，我才开始有意识地调整自己的写法。后面再写课引文件时，我不再追求每一题都写得很满，也不再要求自己一开始就把答案写得特别漂亮，而是尽量先用自己的话短答出来。哪怕表述没那么标准，哪怕一开始说得不够完整，也先写。因为至少这样，我能更快地知道自己到底卡在哪里，而不是继续困在“看起来记得很完整”的假象里。

我现在用的课引文件，形式其实很简单。不是那种漂亮模板，而是一章一个文件，把核心问题先列出来，再一边看 PPT 一边去填。比如在 MyBatis 相关内容里，我会先给自己列这样的问题：SqlSessionFactoryBuilder 是什么，SqlSessionFactory 是什么，SqlSession 是什么，这三个对象之间是什么关系，为什么 namespace 和 id 要配合使用。这样做的好处是，它会逼着我停下来想：我到底会不会解释这个概念，我是不是只是眼熟这个名词，如果让我自己讲，我能不能讲顺。

后面如果我写完了，还会再去看批注和纠偏。比如我在练习里跑通了最小的 MyBatis 查询之后，才真正意识到：namespace + id 不只是写法问题，而是 MyBatis 定位 SQL 的方式；SqlSessionFactory 也不只是“一个名词”，而是真的承担统一创建会话的作用。像下面这段代码，一开始我只是照着写，后面才慢慢开始明白它们之间的关系：

InputStream is = Resources.getResourceAsStream("mybatis-config.xml");
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(is);
SqlSession session = factory.openSession();
Worker worker = session.selectOne("Worker.Worker_id", 1);

表面上看它只是几句代码，但真正学进去之后才会发现，这里面其实正好串起了第二章最核心的主线：配置文件是怎么被读到的，Builder 是怎么把配置构造成 Factory 的，Factory 又是怎么创建出 Session 的，最后程序又是怎么通过 namespace.id 去找到那条 SQL 的。

慢慢地，我发现这种方式确实开始起作用了。最明显的变化，不是学习速度突然变得多快，而是我开始能用自己的话去解释那些原本只会照着 PPT 复述的概念和名词。以前很多词只是眼熟，真让我讲的时候会卡住；现在虽然还谈不上特别扎实，但至少已经能一点点把它们讲出来了。比如 MyBatis 的几个核心对象、动态 SQL 里的标签作用，或者微信小程序里数据绑定和 setData() 之间的关系，这些东西以前我很容易“看过就算”，现在至少能慢慢说顺。

另一个变化是，实践这件事终于开始变得有意义了。以前我对“实践”这两个字的理解其实很空，总觉得先把 PPT 看懂再说。可真正做了几次最小练习之后，我才发现很多问题只有一动手才会暴露出来。比如课件里看起来已经懂了，结果一写配置文件就卡住；或者代码跑通了，但我解释不清楚为什么这样就能跑。这时候再回头去看课引文件、再结合批注去纠偏，很多概念反而会一下子清晰很多。对我来说，“学习 + 实践 + 批注”这一套，比单纯看课件有效得多。

当然，这种方法也不是没有缺点。最大的问题就是，它真的慢。尤其是在刚开始调整的时候，速度慢得特别容易让人焦虑。有些问题看起来很简单，但真要自己回答的时候，总有一种“脑子好像会了，嘴和手却跟不上”的感觉。再加上我自己本身就容易过度加工，一不小心就会把课引文件重新写成摘抄本，或者在某一句话上反复打磨，结果时间花出去了，推进却没自己想象中那么快。

有时候我甚至会觉得，这种方法最折磨人的地方，不是不会，而是那种“好像懂了，但又说不漂亮”的难受感。它逼着你承认自己没有真的学会，而不是继续躲在“我看过了”的错觉里。所以后来我也慢慢明白了，问题引导式笔记并不是为了让每一道题都变成标准答案，而是为了把真正的问题逼出来。如果最后又把它做成了另一种形式上的“抄书”，那它的价值其实就被削弱了。

如果现在让我用一句话总结这套方法最大的价值，我会说：它让我不再是盲目地学了。以前补课更像在“扫 PPT”，看完有印象，但不知道重点，也不知道自己到底哪里不会。用了问题引导式笔记以后，我开始带着目标去学，也能更清楚地知道自己的卡点。再加上后面的实践和批注，整个学习过程比以前更有方向感，效率自然也就提上来了。

我现在当然还不敢说，靠这一套方法就能让我一下子把所有内容都吃透。但至少它让我第一次比较清楚地看见了：我到底会了什么，不会什么，哪些地方只是眼熟，哪些地方才算真正理解。对现在的我来说，这已经是一个很实在的改变了。