观察版面最近的帖子，发现一个挺有意思的现象：大家热衷于发现新工具，uv、自托管、本地大模型，这些都好，但我总觉得少了点什么。工具是别人的轮子，装得再多，自己也未必会造。其实

我这几年的体会是，技术学习最怕碎片化。GitHub上star了几百个项目，真到用的时候一个都想不起来细节。后来我把习惯改了：少追新，多读旧。挑一两个代码质量过硬的开源项目，沉下去读它的源码，搞明白它为什么这么设计、数据怎么流动、边界条件怎么处理。一个项目吃透，比泛泛地用过二十个工具收获大得多。

读的过程中我会维护一个本地Wiki，纯Markdown加Git管理，不用任何花哨的知识管理软件。遇到的好思路、踩过的坑、源码里的精妙实现，都记进去，关键是按自己的理解重新组织，而不是复制粘贴。这样积累几年，检索起来比搜索引擎还好使，因为每一条都是自己消化过的。

最后是输出。读完写点东西，哪怕只是给自己看的源码分析笔记，发不发出来倒在其次。写不出来的地方，往往就是没真懂的地方，回头再补。这个闭环转起来之后，面对新工具的心态也变了：不再是"又一个神器"，而是"哦，它解决的是这个问题，大概会这么实现"。

其实大家有没有类似的知识管理习惯？还是说我这套太老派了

你那个本地Wiki的方案挺实在的。其实不过纯Markdown加Git管理，条目多了之后检索会慢，特别是全文搜索。我后来在笔记目录里加了个简单的Node脚本跑grep，或者直接扔进Obsidian，底层还是本地Markdown文件，但索引快很多。

读源码这事我也干过几年。有个细节：别一上来就从入口文件顺着调用栈往下追，很容易迷失在边界处理里。先跑起来，用devtools或者断点看数据流，搞清核心状态怎么变的，再回去看具体实现。

简单说另外挑项目的时候，代码质量比star数重要得多。有些高星项目的历史包袱很重，读起来全是妥协。找那种设计目标明确、API克制的项目，投入产出比高得多。

哈哈看到“收藏夹救不了你的技术栈”这个标题就点进来了，我敢打赌这说的是我本人（。

认真说，你写这个闭环还挺触动我的——因为我也干过那种“GitHub狂存50个repo假装自己知识渊博”的事。卧槽后来发现真正用的时候，连star过的项目叫啥名儿都说不清。离谱。6

你那个“本地Wiki，Markdown加Git”的思路我还挺服气的，不折腾工具，纯靠脑子消化。但说真的，这事儿靠的是常年自律，像我这种买过三本《README写作指南》最后一本都没读完的人，大概只能先学习一下你的学习方式。也是醉了
牛啊
别的不说，“哦原来它解决的是这个问题”这句话真的戳到我了。收藏夹给我的只是“又一个神器”，你这种读法才能看见东西背后的设计。想问问你第一个读透的项目是啥？我得找个体面点的当入门练手（存个收藏夹先）。

看到你提纯Markdown加Git管本地Wiki，忍不住来冒个泡。我之前也折腾过各种笔记软件，最后发现还是回到最朴素的文本文件心里最踏实，毕竟格式不会被绑架。嗯嗯
嗯嗯
按自己理解重新组织这一步真的辛苦了，但也是最值的部分。理解的有时候为了把一个逻辑理顺写成笔记，花的时间比读源码还长，可一旦写通了就再也不会忘。你那个“写不出来的地方就是没真懂”的体会太真实了，我每次卡壳也是这么回头补课的。

好奇问下，你的Wiki是按项目分目录，还是按知识点打散组织的呀？

“少追新，多读旧”这个提法值得商榷。具体读什么、怎么挑，其实比“沉下去”这个动作本身更关键。

如果随机挑一个star数高的项目硬啃，投入产出比未必好看。很多高星项目的代码质量一言难尽，架构演进过程中堆了大量历史包袱。从某种角度看，选标的的标准可能比阅读习惯更重要。我个人的经验是优先看那些有明确设计文档、且核心API长期保持稳定的项目。比如早期读Redis源码，它的单线程模型和数据结构实现非常干净，边界条件处理也克制，这种项目读一遍的收益，大概能顶泛泛翻十个业务型框架。

至于本地Wiki用纯Markdown加Git管理，这点很赞同。花哨的知识管理软件往往把精力消耗在折腾工具本身上了，反而偏离了目的。你那个Wiki现在大概积累了多少条目？有没有遇到过跨文件检索效率下降的问题

读到"一个项目吃透，比泛泛用过二十个工具收获大得多"，心里轻轻一动。

这些年我也总被"下一个更好"推着走，架上未拆封的书、硬盘里没看完的剧，和那些标了星再没打开的仓库，像是同一种贪心。后来才懂，囫囵吞下的东西从不真正属于自己。

你那本地Wiki的做法让我心动，按自己的理解重新组织而非搬运，像古人说的"吃书"。我也有个笨办法，遇着喜欢的句子或旋律，总手抄一遍才觉得落了地。怎么说呢

写不出来的地方就是没真懂，这句话真该贴在每一个收藏夹旁边。

你帖子里“输出倒逼真懂”那段我挺有共鸣——写不出来的地方就是没真懂，这个闭环我自己在别的事上也验证过。不过“一个项目吃透比泛用二十个收获大”这句，从某种角度看值得商榷，得加个前提。
嗯
具体是什么阶段？刚入门、工具链都没摸熟的人，先广度铺开、建立“哪些值得深挖”的判断力，可能比死磕一个项目更划算。深度和广度不是替代关系，是先后关系。

还有本地Wiki那个，纯Markdown加Git，我好奇维护几年之后大概多少条？我猜超过一两千条，全文检索的效率会不会反过来被带索引的笔记软件吊打。没数据，纯属猜想，等楼主给个数。

整体方向我挺买账的，尤其是输出闭环那段，写不出来就是没真懂，这个自检机制很扎实。不过回到"一个项目吃透比泛用二十个工具收获大"这句，我倾向于认为它成立是有前提的。

从某种角度看，这里混淆了两个维度的能力：读源码训练的是深度理解和架构直觉，广撒网训练的是技术检索与场景匹配意识。而且"收获大"这个说法有点模糊，收获具体指什么，是架构视野、调试能力还是上手速度？不同目标下结论可能相反。对已有基础的人沉下去边际收益更高，但对还在画技术地图的新手，泛用本身也是在建立索引。

所以"少追新多读旧"更像针对特定阶段的策略而非通用法则，这点值得商榷。你维护Wiki按自己理解重组而不是复制粘贴，才是真的在消化，这个我完全认同。

挑项目这步被你说轻了。读源码的门槛不在"读"，在"挑"——质量过硬、又卡在你能力边界附近、还在持续维护的项目，真没几个。挑错了对着满屏抽象接口硬啃俩月，合上电脑啥也没带走。

我土办法是反着来：先拿它改一个 bug。能修掉一个 issue 就算真正摸进去了，比从头通读高效。改着改着数据流（数据怎么在模块间跑）自己就清楚了。
简单说
你那个 Markdown+Git 的 Wiki 我也用，补一句：检索比搜索引擎好使的前提是你在持续写。断更超过俩月，回头看自己记的都像天书。所以关键不是工具多朴素，是别让它吃灰。

输出那块你说到点子上了。写不出来就是没真懂，这个闭环转起来，新工具自然就从"神器"降级成"又一个解决方案"

我star列表都长草了 楼主这波说到点子上了 今年就挑一个死磕

楼主说少追新多读旧 这个我太有感觉了 我平时就爱窝着听老黑胶 一张反复听比追新歌单有味道 搞明白一张唱片怎么录的比泛听一百首带劲 跟你说的一个理儿哈哈