先立一个总标准：没有输出的输入，都不算学会
判断一次学习有没有效，标准只有一个：你能不能用自己的话，把它讲给一个不懂的人，并让对方听懂（费曼）；或者更进一步，能不能把它用到真实问题上。
「读完了」「看完了」「收藏了」都是输入动作，不是学习结果。这条标准听起来简单，但它会淘汰掉八成的「无效努力」。
读书：别把「读完」当目标
- 带着问题读：读书前先写下一个「我想解决什么问题」——哪怕最后没找到答案，也比漫无目的翻完强十倍。
- 两类书两种读法：方法论/工具书（速读抓框架，用到再回查）；思想类/经典书（精读 + 复述 + 写批注）。别用读小说的方式读工具书，也别用查字典的方式读思想书。
- 读完只留三样：这本书修正了我哪个认知；有哪些方法我下个月就要用；有哪些话我不同意、为什么。三样写进知识体系的对应领域，书就可以放回书架了。
看源码：最大的坑是「从头看到尾」
看一个开源项目的源码，最常见的死法是按目录顺序从头读——读两周，前面的全忘，最后只记住了 README。
- 从「一个具体问题」切入：想知道「它是怎么做限流的」，就顺着这一个问题从入口追到实现。问题驱动的阅读，读多少都是有效积累。
- 先画调用链，再读实现：把关键路径的调用链画出来（谁调了谁、数据怎么流动），再深入细节——你是在读「架构」不是读「代码」。
- 给源码写注释：读懂了就用自己的话在关键处写注释（fork 一份），写不出来就是没懂。写完的注释，就是你以后回查的索引。
做项目：学习效率最高的方式，但方法决定天花板
- 做「略超出当前能力」的项目：全都会做的项目是复习不是学习；完全不会的是劝退。找到那个「会 60%，需要查 40%」的边界，进步最快。
- 项目要有「复盘点」：不是为了做完，是为了做完后能回答「哪里做得差、为什么、下次怎么改」。只做不复盘的项目，等于学了三遍又忘三遍（复盘方法见个人复盘）。
- 刻意替换依赖：用开源组件时，试着把其中一个换成自己写的简化版——理解程度完全不同。我常对团队说：能徒手写出来的东西，才是你真会的。
安排节奏：别被「每天学习两小时」绑架
- 学习是长跑不是冲刺：稳定的每周 3–4 次、每次 45–90 分钟，远好于周末突击一天。
- 给学习设「停止条件」：一个主题学到能解决当下问题、形成一篇能讲的东西，就可以停了——知识是学不完的，你的问题是有限的。
- 季度轮换主题：一个季度一个主攻方向（架构/业务/AI），避免每个方向都浅尝辄止。
落地清单
- 每次输入前写下要解决的问题
- 读完书只沉淀三样（认知修正/待用方法/反对观点）
- 看源码从具体问题切入，画出调用链
- 项目设复盘点，做「会 60% 需要查 40%」的题目
- 每个主题设停止条件，季度轮换主攻方向