没人教，没人陪，如何练会书上的知识？

from @unsplash

如果说学习能力分为 3 个层次^[1]：

1. 学会别人手把手教的技能
2. 学会书本上教的技能
3. 学会没有人教的技能

那么我们要如何一点点突破呢？

练会更重要

我想，很多人和我一样，不太愿意和那些觉得自己知道，但是做不出来东西的人合作，虽然我以前就是那样的人。另外一方面，我自己的原则是绝对不能说：「你连这都不知道啊」，「只要那么那么做就可以了」之类的话来显得自己好像知道一样。困难是别人要面对的，自己不能在行动上帮忙就不要瞎指挥，连提出建议也最好在别人明确表示自己希望得到帮助的情况下。

我这么选择，是因为很多东西我也只是知道，而不是做到过。我们都知道做出一家 Alibaba 能挣钱，但我们都没做出过 Alibaba，所以千万别给别人这样的建议：「想挣钱，做出一家 Alibaba 就行了」。

这个例子可能有点极端，但生活中这样的例子挺多的。关于工作的，关于婚姻的，感觉自己知道的人挺多的，真正有高度的建议可能是很少的，更别说有意义的指导了。

我（们）不能做那样的人^[2]。

当别人需要我们的时候^[3]，甚至当这个世界需要我们的时候^[4]，我们不能成为那个只会胡乱动嘴的人。如果以此作为要求，「知道」真的不应该是学习的终极目标，连「学会」可能都不是，「练会」才是，「能做出产品」才是。

所以我希望和大家探讨的是「如何练会书上的知识」。不过，我们先来看看第一个阶段：学会有人手把手教的技能。

如何练会别人手把手教的技能

有人手把手教的技能其实很多，在 google 上输入这样的关键词，比如how to cook jiaozi，how to make noodles 都可以搜到很多手把手的教程，甚至还有手把手的视频；百度上这样的内容也不少。甚至，很多更有难度的技能也有手把手的教程，比如编程，弹吉他之类的。

如何学会这些有人手把手教的技能呢？我的个人经验是，老老实实练到手熟。

选择那些看起来最靠谱的教程（流量越多的教程可能越靠谱），或者花钱买来更靠谱的作者出版教程，然后放下自己的各种情绪：觉得老师太啰嗦啊，觉得自己很聪明之类的。老老实实的按照教程做一遍，纯模仿。一遍练不熟，就练 3 遍，5 遍。

我给出这样的思路是因为我自己的学习经历。

我刚开始学编程的时候，就是用这样的方式学会了一些基础的 web 开发，而后从事软件开发的工作。在工作中，需要自己学习写新的代码，使用新的技术和工具时，我也是这样做的——把代码写 3 遍，有时候再加上一篇分析代码的博客。

编程这样看起来需要思考才能下手的事情，怎么能靠纯模仿（甚至是死记硬背的模仿），来学会呢？

首先，思考是没有错的，如果你会思考的话。但刚开始的时候接触到一个新领域的时候，连最基本的概念都没有，怎么思考？我们可能在另外一些领域是专家^[5]，但在刚刚开始入门学习的那个新领域，最好在一开始承认自己不知道，不然很容易犯全知遮蔽的错误（以为自己全都知道，所以自己把自己的视野给遮蔽了，无法进步）。

举个例子。现在（2018年4月）非常热门的两个科技创业方向是：区块链和人工智能。我曾在一段时间以前听一个在区块链行业里开交易所的老师，一个被很多人视为大咖的人说，现在进入人工智能领域已经没什么机会了（他建议进入区块链行业）。当时他没有解释为什么，但我想这在很多人看来是错误的判断。我现在在一家做计算机视觉（和 AI 沾边）的公司工作，了解到这个行业中比较成熟的 AI 技术不过是语言识别和计算机视觉等，更多 AI 技术的问题其实还没有解决，比如自动驾驶，比如大数据医疗。怎么会没有机会呢？

模仿那些在一个领域真正经典的案例，可以帮我们获得一些基本概念，甚至是出现频率很高的核心概念。从而获得一些思考的抓手^[6]。

其次是，入门的时候不要太贪婪。很多领域都有几十年甚至几百年的历史，这期间又有无数比我们聪明的人为这个领域创造了大量的知识，我们不应该期待自己一两天就消化了这样大量的积累。

更重要的是，入门时也没必要贪婪。

以编程为例，很多人可能知道int a = 1;这句话是在给 a 赋值，但如果问：为什么计算机会把这行代码理解为给 a 赋值，以及计算机是怎么给 a 赋值的，如何检查计算机真的给 a 赋了值；这些问题对刚刚入门的我来说是没法回答的。然而，这并不影响我继续使用 int a = 1; 这样的代码，写出我预期的结果。这就好像很多人并不知道感冒时怎么发生的，也不知道感冒药是怎么治疗感冒的，但是知道吃感冒药能解决自己的不适。

这或许就是传说中的「先用起来再说」，或者用英语说 heuristic。在刚刚入门一个领域的时候，如果奢求自己什么都要一下搞懂，那更有可能实现的是不是从入门到精通，而是「从入门到放弃」。

当然，那些「为什么是这样」的思考其实很有价值，只不过他们的价值在学习的初期阶段体现不出来。如果我们能把他们记下来，其实有助于我们突破第二阶段的学习。

另外，对于这种「先用起来再说」的学习方法。很多人可能持反对态度，他们的建议通常是：知其然，也要知其所以然。如果这句话是对一个已经涉足某领域的人说的，是很有价值的；但如果是对一个正在入门的人说，我怀疑给出建议的人是在刷存在感（或者优越感），要不然就是在唱高调^[7]。别怕他们，自己认真入门就好。学习是要分阶段的，理解底层原理（也就是知其然，也要知其所以然）是很有必要的，但如果连入门都做不到，理解底层原理基本上就是空谈。

从手把手中进阶

从手把手的教学中学到东西听起来很容易：模仿 + 重复。但做过的人应该体会过「连照抄都能抄错」的窘境；更好玩的是，自己拿着明显^[8]抄错了的作品信誓旦旦的问别人：我做的没问题啊，怎么就不行呢？^[9]

正是在改正这些错误的过程中，我们学到了做出产品的基本逻辑：哪部分的工作和另外一部分的结果是有因果关系的。

以煮饺子为例，我以前煮的饺子经常会黏在锅底；在我看来，别人煮饺子都是把饺子放进沸水锅里，然后等一会就熟了，然后就可以吃了，从来不沾锅底；但后来我知道，在把饺子放入锅里之后，需要用大勺子轻轻搅动一下饺子，让沉在锅底的饺子浮起来；这个搅动的含义简直太隐蔽，谁会第一次就知道那个大勺子伸进锅里是为了让饺子浮起来呢？我看到的只是大勺子伸进了水里，然后出来了，中间埋下了什么伏笔，完全不清楚；直到自己煮的时候真的犯了错误，就有了机会能学习到这个因果逻辑。

但手把手的学习到这里还没有结束，手把手的教程中还有更多可以挖掘的东西：自己主动改变一些示例作品中的组件，看看会有什么结果（或者错误）。从中你可能会遇到更多问题，也会从这些问题中学到更多的因果逻辑。

更进一步，到这里你可能对自己通过手把手练熟的小作品有了一定的把握，也有了一些展望：我把这个小作品迁移到别处实践一下行不行。比如你模仿的作品是制作一个简单的小程序，你能不能多添加几个页面，给你的朋友展示一下？我个人类似的经历是，在通过模仿进行学习之后，把新学到的代码的语法、一些协议的规范、一些计算机底层的操作慢慢地用到工作相关的工程中。

当我们尝试着跳出教程中设计的示例时，会有更多未知的问题等待着我们。不断解决这些问题同时，你的学习简直就是超速行驶；虽然有些问题真的会难到我们，但这就是学习的过程，痛并快乐着。

当然，这个跳出原有范例的进阶过程，必须建立在把原来的模仿重复了很多遍以至非常熟悉的基础上^[10]。

如何练会书本上教的技能

看书，绝对是超越自身感觉的一种很好的途径。

上文提到，我们在不断模仿经典案例的过程中，可能会发现一些因果关系；在以后的实践中，我们就可以通过控制不同的因，来实现不同的果。

但通过模仿学到的所谓「因果关系」中，可能有很大一部分其实是「相关关系」，而不是真正的因果律。

举个例子，人们可能会觉得感冒药是用来治疗感冒的，因为从直觉上判断好像就是这样的。而事实上，感冒药的作用是治疗鼻塞，发热等感冒引起的难受，而不是治疗感冒本身^[11]。消除了感冒带来的不适症状，可以减少身体的压力，让你有心思学习和工作。而在你专心工作的同时，身体就默默地和感冒抗争——是你的身体治好了感冒，而不是感冒药。我们所谓的吃完感冒药，感冒就好了，只不过对于两者相关性的感觉^[12]。

我在统计学中学到过一句话：

Correlation does not imply causation

中文意思是说「相关性不等于因果律」。如果我们把相关性误以为是因果律，下次再想通过控制因来得到果，却不知道某些未知的变量已经发生变化时，结果就会出乎意料。这是一个很重要的概念，但我们的主题不是讨论它。我们想讨论的是如何学习到更深层次的知识，来让自己把握更接近真实的因果律。

对于很多领域，模仿能给我们带来的进步会随着熟练程度的提高而收益递减^[13]。过度重复甚至会造成 overlearning，限制了大脑对未知解决方案的想像。另一方面，成为一个领域的专家所需要的更底层的知识，通常又很难通过个人肉眼凡胎的短期观察来发觉，这个时候想要进阶，阅读是个不错的选择。

对于书，肯定不是所有的书都是在讲底层原理的。有很多书，比如学炒菜做饭的书，其实就是手把手的教程，可以归入上文提到的学习方案^[14]。

还有一些书，更类似于工具书，他们不太讲述底层原理，也不太提供手把手的完整教程，但他们会把很多相关知识都说一下，给一些短小的示例。把这种书通读一遍可能会比较痛苦^[15]，但肯定有人这个干过。我读过一本200页左右，还算有趣的工具书，其他工具书大多数都没读完过。如果说有什么经验的话，那就是：

把那些小知识放到大的项目中去用！

现在，我可以告诉你，我读完的那本工具书叫做《Ruby 基础教程》。它里面讲的都是 Ruby 这门编程语言中的一些基本语法：如何赋值，如何操作字符串等等。看这种书其实是大多数想学编程的人的选择，但这些同学应该都会遇到一个问题：看完了，然后呢？

可能很多人都踩过这样的坑：知识点都看过了，甚至背下来了，但是不知道怎么应用。更重要的是，因为不知道怎么实践工具书中的这些知识，所以对这些知识的理解总是停留在知道的层面，无法深入。

有些人学习这些工具性知识的条件比较好。他们可能正在做某个工程，带着工程中的问题去学习这些知识，会很有动力，也很有目标的去实践这些知识。但另外一些人可能没有这样的场景，甚至会遇到这样的尴尬：比如我在找工作的时候发现，要想找到工作，从而获得在工程实践中学习的机会，需要先学会那些通过工程实践才能学会的知识。

如果你也面临这样的尴尬，突破的方法之一是，自己给自己设计项目做。如果你觉得自己一个人的设计项目的能力有限，那么可以在网上搜索有什么项目可以做^[16]，比如 Youtube 上的这位帅哥就设计了一个12周做12个 web 应用的设计，比如我当初模仿一个叫 Michael Hartl 的博士设计的项目来实践，还录制了几集 YouTube 视频，感兴趣的可以看一下。

很多时候我们到这里就没动力了。自己给自己找事干，还不赚钱，很多人因此就不做了。但是这么想是有问题的。自己给自己找事情做不是不赚钱，只是不一定赚钱而已。给别人打工看起来是比较稳定，但让老板承担不确定性，我们自己也是要付出代价的，比如若是有什么认知升级的机会的话，可能老板先行，若是有什么财富自由的机会的话，老板也是占先的。这是他们应得的，毕竟他们为员工承担了更多创业的不确定性；从另一个角度来讲，这也是员工和老板的交易，是买卖双方为了互相满足需求而产生的交换^[17]。

最后，我们要能够从讲述原理的书中学习。不过，让我们先来定义一下什么是「讲述原理」。

物理学家费曼，在他的物理学讲义中提到这样一件事：假如人类毁灭，而地球人只能给以后的世界留下一句话的时候，他选择留下的是「这个世界是由原子构成的」。在他看来，整个世界都是运行在原子和原子的互相作用之上的吧，而原子就是这个世界最底层的原理。

然而，对于单独一本讲述原理的书，几乎不太可能一路深挖到原子在其中如何作用。因为那样的话，这本书几乎是写不完的，甚至连科学家都已经过世了，都还没有写完。根据我的观察，大多数探讨原理的书，都会假定某些更底层的概念已经是正确的，然后以这个假定为基础，探讨具有一定深度的原理，而不是无限深度的原理。

更进一步，他们会假定读者已经理解了那些更底层的概念，但是，事实并不是这样的。我就经常是那个并不理解更底层原理的读者。如果按照作者的建议先看那些更底层的原理，我们可能会发现，理解那些更底层的原理需要更更底层的原理。这样无限循环，一本书是看不完的，甚至连读者都已经过世了，一本书还没看完。

为了突破这个窘境，我们可以选择冒着一定风险，先接受那些更底层的原理是正确的，只对那些原理做一个大概了解，就在原来的书中继续探索下去。

另一方面，根据我们一开始提到的原则，「练会」在这个阶段依然是最重要的，尽管他们是原理，看起来和实践无关。但我们也要自己给自己设计方法，让自己刻意的用。设计不出来怎么办？和之前提到的方法一样，搜索一下别人是怎么用的。

后话

当然，还有第三个阶段：学会没人教，甚至没人能教的技能。我目前对此也是无能为力，希望能够和朋友一起探索吧。

---

1. 这个模型出自《财富自由之路》第 28 章 ↩

2. 首先，我选择这样做和道德没什么关系，其实也从个人利益出发，觉得这样做更有利于自己和自己所在的团队。其次，这样选择并不总是最优的，但在不确定性总是存在的生活中，谁能保证自己的选择总是最优呢。这种选择只不过是经过思考之后，更有可能是好的。 ↩

3. 据说，幸福很大程度上来源于被别人需要 ↩

4. 实际上，如果我们只会动动嘴，这个世界很可能就不太需要我们 ↩

5. 虽然也很有可能没有成为过专家 ↩

6. 按照《Learning how to learn》 的说法，这个抓手可以叫做 chunk，组块。 ↩

7. 按照《现代汉语词典》的解释，唱高调是指说不切实际的漂亮话或者光说的好听而不去做。总之，就是说出的话自己都没做到过，未来会不会做也是一个大大的问号。 ↩

8. 对于懂的人是明显的，对于不懂的人其实是不明显的 ↩

9. 出现这种情况的原因可能是因为我们不知道那些错误和什么原因构成了因果关系。所以当出现错误的时候，我们的注意力无法放到原因更可能出现的地方，而是乱找原因，所以不容易找到正确的原因。 ↩

10. 不然你会发现，旧的逻辑没记住，解决新问题时无依无靠；新的知识本来就不熟悉，能不能用来解决当前的问题，一点信心都没有。最后就是无从下手，问题解决不了，新知识也无法学会。 ↩

11. 我这里找到了一个丁香医生的科普回答来证明，更专业的论文证明我会在找到之后进行替换。 ↩

12. 感冒药欺骗了你的神经系统，让他没那么难受 ↩

13. 因为熟练到已经不用过脑子的程度后，人们就失去了反思的机会。当然，总有人能想办法让自己这些动作，比如运动员找教练审视自己的动作。但另一方面，通过阅读寻找更底层的因果关系，更能找到刻意练习的方向，这绝对是一种不错的进步方法。 ↩

14. 在英文中，这类书大概都叫做 xxx cookbook，而在软件开发领域，也有一些书用 cookbook 命名，比如Mysql cookbook，这本书教你一步一步的处理 Mysql 中的问题，就好像厨书一样。 ↩

15. 痛苦只是因为大脑有些不适应，所以释放一些抗议的信号，但习惯就好了。 ↩

16. 搜索关键词可以选择the use cases of XXX。 ↩

17. 这说明在成交的那一刻，两者在劳动力价格这件事上的意见是相左的，老板认为买入值得，员工觉得卖出值得，所以产生了交易吧。 ↩