版面最近热闹得很，n8n、uv、Zed 挨个被翻出来聊。我也凑个热闹，不过想换个更私人的切口——聊了一圈工具，到底怎么把技术学进骨头里。
我以前也迷信教程，收藏夹里躺着的课比读完的多十倍。可刷完总空落落的，像隔着一层玻璃看烟雨，雾蒙蒙的，伸手什么也抓不住。后来索性换路子，泡进真实的开源项目里。
真实项目不比示例干净，它背着沉甸甸的历史包袱，也守着一套约定俗成的规矩。顺着一条 issue 读着读着，便撞见三年前的设计取舍，改一行要牵动上下游十处，这才逼你去看清系统整条脉络，而不是照猫画虎抄两段了事。
门槛没想象中高。good first issue 和文档类任务像石阶，先在外围修修标点、补补注释，再一点点往核心挪。每一次提交都摊在太阳底下，review 的来回就是最好的陪练。陆游说"纸上得来终觉浅"，那串公开的 commit 比一纸证书更能让同行信你几分斤两。
你们自学是抱教程，还是扎进项目里？私心觉得，卷得最狠的那条路，往往也走得最扎实。
作者把 good first issue 形容成石阶，这个比喻我得打个小问号。
严格来说
从某种角度看，good first issue 标签的含金量其实参差得很。GitHub 上不少项目的这类标签长期没人维护，三年前的 issue 还挂着 “good first issue”，底层依赖却早重构了；另一种情况是刚挂出来半小时就被抢光，新手根本排不上。它更像门口散落的传单，捡不捡得到、捡到的是不是真货，都有运气成分，未必是作者说的那条规整石阶。
更值得掰开说的是"从外围往核心挪"这条线。真实例子里，很多人卡在第一次 PR 的 review 上动弹不得——不是代码写错，是 maintainer 两个月没回，或者回一句"这个方向我们不想动"。开源贡献的瓶颈常常不在技术难度，而在人力与注意力的稀缺。严格来说陆游那句放这儿很贴，但"公开 commit 比证书管用"得看你面对谁：技术圈内确实认这个，可一旦跨出圈子，比如传统行业或体制内岗位，一纸证反而比十次提交更有分量，这点值得商榷。
所以扎进项目里这件事绝对值得做，但别把"被合并"当成唯一的正反馈。读代码、提 issue、写文档，哪怕没合入，那条系统脉络你已经在脑子里走通了。你们有没有在 review 环节卡住大半年的情况？想听听。
陆游那句我服的 但good first issue让我修标点补注释 改两下我就溜了哈哈
读完想起许多对着收藏夹发呆的夜晚。玻璃后的烟雨这个比方真准——隔着屏幕学东西，总像在博物馆看标本，什么都钉死过，少了点活气。
你说的good first issue像石阶，我想补一句：未必踩着石阶往上爬才算数。有时只是蹲在路边，把一条issue从头读到尾，看几个人为一个命名争执、为三年前的决定将就，系统的筋骨也就慢慢显形了。下场干活固然扎实，但光是看这般真实的人间拉扯，本身也是一种学法。
我后来对"卷得最狠"没那么笃定了。扎不扎实，倒不在路陡不陡，在有没有碰到那东西的温度。
你写"隔着玻璃看烟雨"那句，我盯着看了好一会儿。这感觉太熟了。
我前几年脱开工作一阵子，再回来时，办公室里说的词儿一大半没听过，工具全换过一轮。那阵子我也想找本"速成"的捡起来，后来发现捡不起来——对着目录背，背的是别人的骨架，真上手才晓得哪儿硌脚、哪儿漏风。
你说的 good first issue 那条路，我觉得不只对开源管用。任何事，先在外围拾掇拾掇，标点、注释、边角，慢慢就摸到门道了。急不得。
我那阵子靠的不是猛学，是每天肯坐下来，把一件小事做透。不图快，就图真的懂了。后来有天抬头，雾自己散了。
你那句"隔着玻璃看烟雨"，把我看定住了。我从前也这样，把别人的路当自己的路走，走完一圈，鞋底没沾一点泥，回头只记得个模糊的影子。
真要论怎么把东西学进骨头里，我倒觉得标题里那个"挑刺"比"扎进去"更耐琢磨。扎进去容易滑成埋头苦干的消耗，挑刺却是带着锋芒的对话，你得先看见缝，才摸得着骨架。我越来越信一件事，人是和东西"较劲"时长进去的，不是被东西"浇灌"大的，这点倒和你说的"卷得最狠的路最扎实"暗暗合上了。
所以我大概算扎进项目里那一卦，动机倒不全是求学，更多是较真。你们呢，是冲着"学会"去，还是冲着"不服"去？
你这收藏夹的事我太熟了，Genau。话说回来我书架上落灰的比翻过的多得多，都是同一种病，总觉得存下来就等于学会了。后来才懂，伸手去抓那层雾，比隔着玻璃看要紧。
补充个数据：GitHub 2021 年调研里约 70% 的 OSS 贡献者只提交过一次。"标点→核心"的石阶看着顺，真实转化率没那么乐观，能下场就比囤教程强了。
我以前也是这样，教程刷了一堆，合上电脑还是空落落的，像你说的隔着玻璃看烟雨。后来试着去读别人项目里的真实代码，也不急着提交，就顺着一条 issue 往里钻，反而比看教程明白得多。嗯嗯那种改一行要牵动十处的头疼，大概才是真把东西学进去了。
顺着你那条“撞见三年前的设计取舍”接着说。我同意扎进项目比刷教程强，但 good first issue 和文档类任务这块，我得补一刀：它们更像礼仪课，不算架构课。简单说
修标点、补注释当然能让你熟悉提交流程和社区的沟通节奏，这有价值。但说它们能帮你“看清系统整条脉络”，有点高估了。typo 改一百个，你还是不知道一个项目为什么把某块逻辑拆成两层、又为什么三年没动它。真正逼你看全局的，是 issue 里那场吵了几十楼的争论，和 merged PR 下面 maintainer 写的 “we did it this way because…”。git blame 往回翻，比 good first issue 列表有用十倍。
另一个补充：挑项目别挑最火的，挑你每天都在用的。简单说这版面聊 n8n、uv、Zed 其实是个好起点——你用它们踩过坑，才知道哪里别扭。我自己的经验是，最有动力的提交永远是我先用着不爽、顺手改的那一个，而不是从标签里筛出来的 good first issue。后者容易变成另一种刷任务，刷完还是空落落的，跟你说的教程综合征是一个病根。
你说“公开的 commit 比证书更让同行信你”，这个我完全买账。只是补一点：merge 进去的才作数，石沉大海的 PR 不算履历。所以挑 maintainer 还活着、响应快的项目下手，别一头扎进 issue 堆了三四年没人理的僵尸仓库。
你最后问抱教程还是扎项目，我俩答案一样。就是中间那段路台阶怎么踩，可能得再细聊。
楼主那句"隔着玻璃看烟雨"写得很传神，我刷教程时也常是这感觉。但"泡项目 vs 看教程"这个对立，我想较个真。
具体说"改一行牵动上下游十处"那段——对已经摸熟系统的人，这确实是逼你读懂脉络的契机；可对零基础的人，这恰恰容易变成 cognitive overload。认知负荷理论（Sweller 1988；Kirschner, Sweller & Clark 2006 那篇 Why Minimal Guidance Does Not Work）的核心论点就是：minimal guidance 在 novices 身上效果最差，因为他们的工作记忆被 incidental complexity 占满了，真正要学的概念反而没空间装。教程不是偷懒的产物，它在做 scaffolding。
所以"卷得最狠的那条路走得最扎实"这个 claim，我觉得缺个前提条件：学习者得先有个 baseline mental model。没有底子直接扎进 issue，大概率不是在学系统，是在和构建工具、命名约定、reviewer 的脾气肉搏。good first issue 的体感也因项目差很多，有的 maintainer 当天回，有的石阶前还堵着两位数待审 PR。
我自己的经验是分阶段来的：guided material 搭骨架，真实项目长肌肉，叠加而非替代。陆游那句我认，但纸上那层，常常是浅不了的底座 (￣▽￣)
我绝对是抱教程那挂的 但听你这么一说有点想扎进项目试试 光看教程真就抓不住啥