如何高效地学习

一、这套方法论具体的使用场景#

先说清现在的方法，我现在学一个新领域，是这个顺序：

第一步，先花几个小时甚至一整天，不看细节，只看这个领域的整体运行方式：它解决什么问题，边界在哪，几个大的板块怎么互相支撑，谁是谁的上游。

第二步，把这个结构画成一棵树。树干是核心命题，一级分支是子领域，每个分支下面再挂关键概念和它们之间的连接关系。画完之后你会发现，很多你现在记不住的东西，其实位置是确定的。

第三步，才是自顶向下，一个板块一个板块往下攻。每攻完一块，我不急着记细节，先合上资料问自己：这块东西在整棵树里占哪个位置，它和上下游怎么说话，然后才是一条分支一条分支的梳理细节。

第四步，全部学完，再把整条链路从头串一遍。

这套顺序和大多数人默认的顺序是反的。默认顺序是先从第一个字读到最后一行，边读边做笔记。看上去很扎实，其实结构没有长出来，只是堆了一堆零件。

二、为什么「边学边记」是个陷阱#

这一条我从高中一路坑到大一结束，得单独拿出来讲。

我以前记笔记的逻辑是「怕忘，所以要记详细」。于是每读一段就停下来，把定义、推导、例题全都誊一遍。抄的时候注意力全在两件事上：字写得够不够工整，公式有没有抄错。

结果就是：笔记做得特别漂亮，知识内化得特别浅。

因为记录这个动作会劫持你的注意力。你在忙着还原信息，而不是在忙着建立关系。而知识的留存，靠的从来不是保留信息的完整度，是关系的多。

所以我现在只在两种情况下记东西：

• 学完一个板块、合上书之后，写下这一块的结构和它跟别的部分怎么连。
• 后面遇到想通的难点，回头补一条思考——因为这时候我已经知道它该挂在哪里了。

第二种情况我很喜欢，也是我认为学习里最爽的部分：读到后面忽然「迎刃而解」的那一刻，或者在 AI 的辅助下把一个卡了很久的难点弄明白的那一刻，我对这个结构的理解会突然加深一层。这时候的思考是有价值的，因为它有地方可挂。

而在初学阶段就随手记下来的思考，大多数是悬空的。

三、思维模型：比知识更重要的那层东西#

如果你只记住前两节，你学到的还是一套「技巧」。技巧会过时，模型不会。

我理解的思维模型，是摄取知识时在脑子里长出来的一张图。它不解决具体问题，它决定的是：你怎么把新知识挂上去，以及将来遇到事情时，你能从哪些方向把它触发出来。

举个我自己的例子。做MiniMind实践的时候，我先建立的图是：数据、训练、推理、部署、评估五个主干，加上成本、延迟、可靠性三条横切关注面。有了这张图，我每遇到一个新名词，第一个问题不再是「它是什么」，而是「它属于哪根主干、影响哪条横切面」。前者是要我记的东西，后者是我能自己推出来的东西。

学习的目标，不该是把知识搬进脑子里，而该是把图建起来，让知识有地方可挂。

四、方法本身也要被拿来检验#

这套方法我用了一段时间，但有一个容易被忽略的副作用：它很容易变成一种新的固化规则。

一旦你开始相信”先搭主干”是对的，你就很容易开始用它解释所有结果——做得好是它对的，做得慢也是它对的。这是我一开始完全没意识到的危险。所以现在我给自己加了第二条规则：

把方法当成工具，而不是教条。每进入一个新领域，都要重新观察它到底让这件事更快了还是更慢了。

举三个我实际比较过的场景。

学 408 的计算机网络，这套方法收益最大。 计算机网络是典型的”板块之间强依赖”的领域：从应用层到物理层，每层只跟相邻层说话，主干定下了，后面每个协议、每个报文字段都有确定的位置。我几乎不用刻意去记，因为位置本身就是记忆。

学具身智能，这套方法差点把我带沟里。 这个领域业界自己都还在吵：论文和开源项目各说各话，技术路线没有定论。我一开始还想先搭主干，结果发现我搭的”主干树”其实是错的——是我在没看清的时候，硬给一个还在变的东西安了个结构。接下来每读一篇新东西都要推翻一部分，越学越乱，反而比我直接一篇篇读下去更慢。

查 Qt 的 API，这套方法完全是浪费。 查一个函数签名、一个参数怎么配，有明确正确答案的东西，没有什么结构要搭，直接查文档就行。先搭主干再查，纯属表演。

从这三个场景里，大致能提炼出几条规律：

• 结构清晰、板块强依赖的领域，收益最大。 主干一旦立住，后面填的东西几乎不用再记，因为位置是确定的。
• 业界还在吵的领域，收益很低，甚至有害。 这时候先搭的那棵”树”大概率是错的，接下来每填一块都要推翻。
• 纯操作性、有明确答案的任务，直接跳过这套方法。 查就完了。

还有一个我最近才固定下来的做法：让 Codex 先帮我搭一个最小 MVP，然后我自己去体验和实践一遍。 搭出来的东西不一定好用，但它给了我一个具体的抓手——结构不再是文档里的目录树，而是一个能跑、能点、能拆的东西。我在这上面碰到的每一个问题，都比从零读文档时碰到的问题更容易挂到该挂的位置上。但这不意味着一开始就命令codex带你学习整个领域，因为此时指令是发散的，llm不知道你想学什么，恰好你对整个领域也不懂，这个时候你只会被它牵着鼻子走，没有思考与对痛点的觉察，只是泛泛过一遍，没有更多体悟。

学计算机组成原理的时候，我把这个思路用得更极端了一点：跟着 ESP32 一起学。 单片机没有那么多现代优化设计，缓存、流水线这些概念都长得更”裸”，反而更贴近 408 讲的东西。抽象掉了太多细节的现代 CPU，对初学者来说其实更难理解——你看到的每个现象背后隔着好几层优化。ESP32 上的现象和课本能对得上，学起来的感觉是”看见了”，而不是”背下来了”。

所以现在我的做法是：先拿一个小任务试一次，看这套流程在这个领域里跑得通不通，跑不通就换掉，而不是硬套。

这个”试一次”的动作，比任何一条方法论都重要。因为方法的有效性是相对于领域的，不存在跨领域通用的最优学习流程。

五、去哪拿知识：为什么我先看开源博客#

结构搭好之后，第二个问题就是：拿什么填？

这一点我也有过一个明确的转变：我现在学一个新领域，是先找开源博主观看，而不是先读官方文档。

原因很直接。官方文档告诉你的是这个东西设计上应该怎么用，它必然完整、严谨、覆盖面广，但也必然均匀——每个章节的密度差不多，不告诉你哪里是别人真正踩过的坑。

而开源博客是一个人思考之后的产物。写博客的人要向读者解释，他的脑子里已经有一套结构了，他写出来的，是他认为最重要的那部分，而且这也代表产业界的前沿嗅觉，而不是全部。

这两者的差别是：

所以我现在的顺序一般是：

1. 先找 2-3 篇高质量开源博客(eg.me)，快速建立对这个领域的判断——它解决什么问题、业界在关注什么、常见分歧在哪。这一步往往一两个小时就能完成，但它决定了后面所有阅读的方向。
2. 再回到官方文档，这时候你已经不是从零开始读了，而是带着问题去查。比如你已经知道大家都在关心分布式一致性，那你去读文档里对应章节，效率比从头顺读高一个量级。
3. 最后回到博客，看有没有你没覆盖到的问题，或者别人给出的、官方文档不会给的经验。

博客给我判断，文档给我准确，两者顺序反过来就是浪费时间。

我特别想说的是：一篇好的博客的价值不在于它讲了多少，而在于它替我做了取舍。

官方文档是作者不用做取舍的地方——它必须把所有可能性都写上。博客是作者做完取舍之后的结果。而学习本质上就是在别人的取舍里省下自己的时间。

这也解释了为什么我一直强调”结构比内容重要”：因为取舍本身就是结构。知道该舍弃什么，比知道要记什么难得多。

六、一次失败，和一次转向#

上面这套东西，不是自己想明白的，是被两件事打回来的。

第一件是那笔账。它的荒谬性我在开头讲过了：当评价体系本身没有出口，冲进它里面的人越努力，越是在替它免费运转。

第二件才是方法层面的。

大二上，带教老师跟我说了句话：以后学习要以项目驱动。

正好那学期我开始打比赛。两件事撞在一起，我才慢慢懂了这句话的分量。

一句话证伪了我之前所有的时间观：如果一项「技术」学完之后没有产出，那它在供需关系里就是无用的损耗。

这个结论听起来激进，但它只是把商业逻辑搬到了学习上。任何一项技能的真实价格，取决于它能不能被别人用上、能不能换回东西。你在题海里刷出来的熟练度如果没有出口，它就不是能力，只是一堆没有连接索引的数据。

而且这里有个更狠的推论：恰恰因为没有推免、没有出口，「绩点」是唯一一个我可以确定毫无用处的指标。 它既不能帮考研——考研看的是初试分数和复试表现，不看本科绩点；也不能帮就业——面试官不会翻你的成绩单。也就是说，我大一拼命维护的那个数字，在四年后的两条主要出路里，一条都不沾。这不是”没用但也无害”的东西，它是纯粹的时间黑洞：每一小时投给绩点，都是从真正有用的地方偷来的。

那次组会之后，我做的事情变了。大二上打比赛，大二下沉下去深耕技术，到现在——大三刚开始——我把重心从技术挪向了产品和设计。

第一个真正做成的东西是 chatparty：一个用专家交叉验证来抑制幻觉的多 agent 系统。整体开发半个月，中途卡在 autogen 框架没有 state 状态——对话一旦跑起来就不可打断、不能换话题。我们的解法是每次使用时重新注入可更改的文档，再固定前缀，在尽量压低 token 消耗的同时把话题切换做了出来。跑通之后又发现新问题：聊到十轮以上，模型的输出容易变味，开始像在写实验报告，于是改成硬编码筛选来做 harness 工程，掰掉模型那种模糊的同一趋向性。至于多 agent 的作用，后来被证明主要用于外挂上下文来解决对话腐坏——但这次尝试对我意义很大：这是我第一次完整地设计并验证一套软件，从需求到方案到交付。

做比赛那段时间，我记住并熟练了多进程多线程的用法——这种东西是跟着一个真问题长进来的，到今天还在用。而大一刷题那一整年，真正留在脑子里的，只剩线性代数里”秩”的根本概念：行列式中真正有效的关系的个数。这个概念，还是我后来学LoRA微调时自己想通了才真正留下的。

至于为什么现在转向产品和设计——就是 Joye 那次拷问。那两连问让我意识到整套商业闭环的优先级：技术只是其中一环，而且不在最前面。所以现在我观察一个东西，会先从用户和整体结构流程看起，而不是先看它用了什么技术。

从那以后我的判断标准变了：不是我学过什么，而是我能拿它做出什么。

七、技术在我手里的角色，变了#

大二下那半年，我基本泡在技术里：框架、源码、部署，能自己解决的绝不问人。那时候我对技术的理解很朴素——技术强就是能力强，其他都是虚的。

转折发生在一个比赛里。Joye 看了我的自动书记系统之后，问了我一句话：用户为什么不用 Codex 和 Claude Code，而要用你的自动书记系统？ 我说我这是垂类细分，更具体，通用工具没我做得好。他接着追问：那你为什么考虑围绕 Codex 生态做插件，做一个 agent 友好的软件？

当时我直接傻在那了。后来才想明白：接进 Codex 生态，会省去大量无效的搭建时间，而且获客面也大得多——我在那之前做的所有”更具体”，都是在自己跟自己较劲。

那次之后我才看清一件事：技术从来不是孤立被定价的。 有人愿意为你的产出付钱，付的从来不是”你会 Java”或者”你会 PyTorch”，而是你能把他说不清的一个想法，变成一个能跑起来、他能用、代价可接受的东西。技术只是这个转换过程里最末端的一环。

所以现在我理解的技术，是「需求到解决方案那段转换里的骨架」，而不是某一种具体的编程语言或某个具体框架。

这个变化对我最实际的影响，是学东西的顺序变了：

• 先弄清需求为什么存在，谁在为它付代价；
• 再弄清方案的整体骨架，有哪些可替换的部分；
• 最后才落到具体工具。

顺序反过来——先精通工具，再去想有没有场景——就是我大一的状态：在题海里泡了一年，根本不知道自己在解决谁的问题。

这也是我大三一开始就把重心从技术挪向产品和设计的原因：技术练到”够用”之后，瓶颈往往不在技术本身，而在你判断什么值得做、把它做成什么样。 这后半段能力，恰恰是做题蛆叙事里永远不会练出来的部分。

八、这些方法有它的边界#

我不想把它写成一个整齐的升级路线，说得像按部就班就能变强。

几点反过来的话：

第一，主干结构不是一次搭成的。 我现在每学完一个大领域，都会试着推翻自己上一轮画的那棵树。有几次推翻得很彻底，说明我上一轮的理解本来就是错的。

第二，这套顺序有明显的成本。 先看全景、拒绝细节，这个阶段是很枯燥的，而且会让你感觉什么都没学到。这种「感觉什么都没学到」的阶段，正是它在起作用的时候，就像刚进健身房的前两周。

第三，它不适合所有科目。 需要熟练度的技能（乐器、游泳、写作的手感）大概只能靠时间堆，没法先搭结构再填。

第四，先看博客也有代价。 博客会过时，也可能只适用于作者的场景。所以我把它当判断力来源，不用它当准确来源——具体怎么实现、参数是什么，还是得回官方文档和源码。

第五，我也没有完全做到的部分。 有时我依然会掉进一头扎进去的刷题模式里，只是现在掉进去的次数少了一些，爬出来的速度快了一些。

最后：我还在验证这些#

这套「先搭主干，再填分支」的方法，我正式用下来差不多两个月。它对我最大的改变不是成绩，而是进入新领域时不再无从下手——以前面对一个陌生的东西，第一反应是慌，不知道从哪看起；现在第一反应是先找它的骨架。

如果你也在琢磨学习方法，或者试过类似的路子，无论成功还是翻车，都欢迎聊聊。

我最近在思考的其实是这个：怎么判断一个方法在自己这里是真的有用，还是只是让你感觉自己在进步？

我从题海走到这里，中间绕了很远的路。如果你也在那条路上，希望这篇能让你有所启发。