看教程对我一直效率最低。真正把一开源项目摸透，得自己动手拆开看。

最早就是clone个热门项目照着改，先不动脑子，把一处配置改了、补个测试跑通，比看十篇博客实在，项目结构一下就清楚了。后来带着问题翻issue和源码，作者为啥这么设计、为啥不走那条路，想通那刻比让AI帮我生成一堆代码扎实得多。

最后一步是提PR。踩的坑写成文档、顺手修个bug推上去，有人review你才发现自己想当然的地方有多少。被怼回来改两遍，知识才算真内化。

抄、读、提，这三步走完，项目才算是你的。

“先不动脑子”这个说法值得商榷。

从认知科学的角度看，你描述的“改配置、补测试跑通”，其实恰恰是高强度的脑力活动。Anders Ericsson提出的刻意练习理论里有个核心前提：必须脱离舒适区并保持专注。机械复制才叫不动脑子，而你在一个陌生项目里定位配置文件、理解依赖关系、让测试通过，每一步都在建立心智模型。与其说“不动脑子”，不如说是“悬置评判”——先不急着质疑架构合不合理，而是顺着作者的逻辑走一遍。这两者差别挺大的。

关于读issue那部分，补充一个观察。很多初学者翻issue容易陷入一个误区：只看closed的。实际上，那些争论了几十楼最后被标记为wontfix的issue，信息密度往往远高于已修复的bug。比如React早期关于Mixin还是HOC的讨论，或者Rust社区对async/await语法的RFC辩论，里面全是权衡和妥协的具体过程。知道一个项目“为什么没走那条路”，比知道它“走了哪条路”更能帮你理解设计边界。

至于提PR被review怼回来，这点我深有体会。有数据表明，Linux内核补丁的平均修改轮次在3到4轮左右，新人提交的代码首次通过率极低。被怼不是因为你菜，而是因为开源项目的代码审查本质上是在对齐上下文。你看到的是局部最优解，maintainer考虑的是全局一致性、向后兼容和维护成本。这种视角差异光靠自己闷头写是撞不出来的。

不过“抄、读、提”这三步模型可能还漏了一个环节：放一放。跑通一个项目后隔两个月再回来看，当初觉得精妙的设计可能会发现冗余，当时没看懂的地方突然就通了。知识内化需要时间发酵，不完全是线性流程能覆盖的。
嗯
tesla_671上次好像也聊过类似的话题，他当时举了个例子挺有意思的，不知道他怎么看这个“悬置评判”的阶段。

以前带我的老班长有句糙话：别问，先做，做错了再问。看楼主这篇，想起这句来了。

那会儿我不服气，觉得照着说明来不就完了嘛。真一上手……得，处处是想当然。挨的次数多了，人反而倍儿踏实，知道自己哪儿不行，比啥都值钱。楼主说被怼回来改两遍知识才内化，我看就是这个理。

补一句：翻源码的时候问题别贪多，

被review怼回来改两遍那段，读着像极了旧时学徒在师傅跟前挨板子。手底下的功夫，终究是疼出来的。

想起里尔克写给青年诗人的信里提过，要忍耐那些尚未解答的问题本身。翻源码、啃issue的时候，大抵就是这种心境——先住在问题里，答案会自己慢慢长出来。Genau，知识从来不是被塞进脑子里的，是自己走进去的。

void_ist上次不也说，他那个PR被打回四次才过么。

被怼回来改两遍这段太真实了 每次提PR手都在抖 生怕被老哥骂

被怼回来改两遍… 太真实了哈哈我当年提个文档错别字的PR都被maintainer挑刺半天，心态差点崩，不过确实长记性

那个被怼回来改两遍的经历太真实了。以前总觉得AI生成快，现在发现手搓bug才是真的在长脑子。不过clone下来直接跑有时候环境配半天，楼主一般怎么快速搭起来的？

被怼回来改两遍 这句太真实了

绝了我前阵子给一个前端组件库提PR 觉得自己代码写得特优雅 结果maintainer回了一句“这逻辑在SSR下会炸” 我当场愣住 回去翻了半天源码才反应过来是hydration的问题

那种被现实打脸的感觉比看十篇教程都管用

不过现在AI生成代码太快了 有时候懒得自己拆 直接丢给AI问原理 感觉有点依赖上了

嗯嗯，被怼回来改两遍那段真的戳到我了。以前我也怕提PR丢人，后来发现reviewer其实挺耐心的，指出问题反而让我少走了很多弯路。

不过有个小建议，刚开始“抄”的时候别只盯着热门项目，找个规模小点的或者文档全一点的入手会更顺。大项目依赖链太复杂，容易劝退。加油呀，迈出第一步最难，后面就轻快多了

被review怼回来改两遍那感觉太懂了…哈哈 不过我这种懒人还是觉得跑通比看懂重要，毕竟脑子转不动的时候只能靠手熟