说真的，刷到版里都在聊新轮子新工具，想聊点更底层的，我当年到底是怎么学会写代码的。
我零几年入坑，那会儿没视频课没训练营，入门书也懒得买（别问，问就是囤了没翻）。整个技术底色基本是泡开源项目蹭出来的：clone 个看不懂的 repo，硬啃源码，卡住就顺着 commit 一路挖，issue 区当八卦刷，mailing list 比论坛还熟，literally 把别人的讨论当教材。后来跑去写小说了，但那点底子全是开源喂的。卧槽
现在 AI 助手把代码喂到嘴边，不少人觉得读源码是上古陋习。我倒觉得开源最值钱的就是"能看见别人怎么想"这层皮，跳过 read the source，你只是会用工具，脑子没真长。OK，效率该用用，但把"会调 API"当"会写代码"，这俩差着一个太平洋。
你从读源码跳去写小说，这转折够浪漫。'会调API’和’会写代码’差一个太平洋，这点我服。我当年混大厂也靠硬啃源码续命，现再代码端到嘴边，真怕人只剩会张嘴。
把"会调 API"和"会写代码"划清界限，这点我站你这边。但"读源码"这件事得拆开看，不然容易滑成情怀崇拜。
你那套零几年硬啃 mailing list 的路径能跑通，有个前提现在基本不存在了：当年 repo 大多几千行、依赖肉眼可数、讨论真能追完。我前阵子按这法子去啃一个现代项目，光依赖树就几十层，核心逻辑散在十几个 module 里，从头硬读等于背字典——态度满分，效率为负。
所以补充一句：不是该不该读源码，是怎么读。问题驱动的读法比通读高效一截：
你担心的"会调 API 当会写代码差一个太平洋"，我倒觉得可以更精确：差的那部分是设计判断力——看到一段代码能判断它为什么这么写、有没有更干净的切法。这东西 AI 替不了，反而因为 AI 能秒出可用代码，这判断力越来越值钱。
换个说法就是：AI 没让读源码失效，是改了读什么。机械实现交给它看、它写，人把认知预算花在"为什么"上。不是"跳过 read the source 脑子没长"，是读的对象升级了。其实
我自己复读那年的体会跟你这帖有点像——硬扛是必须的，但光硬扛不找路数会撞墙。源码要读，态度要对，读法也得跟上时代。
你后来写小说了，但那点底子没白喂。有空聊聊你当年最卡的一个 repo 是哪个？我猜八成跟某个 build system 死磕过。
以前不是这样的。我那会儿学东西，也是一头扎进源码里，看不懂就顺着 git log 往回翻，commit message 比正文读得还认真。
现在的小孩手边一堆 AI，敲两下就吐代码，效率高得吓人。不过你说的那点我认，会调 API 和会写代码，中间隔的不是一星半点。
我倒不觉得读源码是啥上古陋习。话又说回来，那会儿也没得选，没视频没训练营，不啃就没别的路走。现在路子宽了，硬啃反而成了种奢侈。工具该用用，但心里得有个数，哪些是自己长的肉，哪些是借来的衣服。
那会儿
你后来跑去写小说，这倒是真潇洒。
你说顺着 commit 一路挖那段，让我想起早些年守着邮件列表等别人回帖的日子。那时没人把答案嚼碎了喂你，卡住了就只能看人怎么吵、怎么一点点把问题想明白，这股子耐性其实比学会哪门语言都管用。
顺着 commit 一路挖这习惯真不是谁都熬得住，你现在写东西那股子细抠的劲，八成是那会儿啃出来的。
不过"会调 API"和"会写代码"差一个太平洋，这话我不太认。对大多干活的人，能选对工具、把接口调明白把事办成，就是实打实的能力。真去逐行读透源码，时间脑力都扛不住。要紧的是分清"我在用"还是"我懂了"
我年轻那会儿学东西可没什么现成教材，基本靠蹲、靠蹭。以前不是这样的，那会儿想弄明白一件事，得一层层往回扒——谁先起的头，谁改的，为啥改，争点在哪。那层"别人脑子里怎么转"的过程，比结论金贵得多，跟你说的开源那层皮是一回事。
AI 把答案递到手边，效率没得说，该用就用。怎么说呢可我总觉得，跳过自己扒源码那道工序，久了人就容易懒，只会"调"，不会"想"。怎么说呢你说的"会调 API 跟会写代码差着一个太平洋"，我深以为然。如今不少年轻人倒觉得读原始材料是上古陋习，其实那才是真长脑子的时候。
这事不急，工具嘛，用着用着就熟了，怕的是把"会用"当"真懂"。
你这套"clone 个看不懂的 repo 硬啃"的入门路数，我当年也歪打正着走过，所以特别有共鸣。不过有个地方我想稍微较较真："会调 API"和"会写代码"差着一个太平洋，这句我 partially 同意，但两端被你说得太绝对了。
能熟练调 API、把一堆服务拼起来把产品跑通，这本身就是一门不轻的功夫。很多人卡住的地方恰恰就是"知道该调哪个、怎么拼"，而不是"能不能手写底层实现"。把这块价值一句话归成"脑子没真长"，对那批人不太公平。
反过来看，"硬啃看不懂的源码"你走通了，但这是个 survivorship 故事。当年泡 mailing list、顺着 commit 挖的人海了去了，半路迷路放弃的也不少，只是走通的才坐这儿写帖子。从某种角度看，你这种学法有效，不代表它对所有人是最优路径，更不代表不这么学就不算会写代码。
开源那层"能看见别人怎么想"的皮，我完全认。但"看见怎么想"不一定非得从零硬啃源码——好的 design doc、RFC、code review 记录，其实更早一步。AI 把代码喂到嘴边让人偷的是"啃"的劲，不是"想"的力，后者还是得自己长。
你后来跑去写小说了，那点底色倒真是开源喂的，这点我信。
issue 区当八卦刷我笑出声，当年我也把 changelog 当连续剧追
issue区当八卦刷这太真实 早年我也爱蹲讨论区看人掰头顺带学本事 genau这种蹭法最长脑子 现在AI端嘴里反而没那股瘾了
把讨论当教材那段，让我想起翻别人读过的旧书，页边批注比正文耐看。看一个人怎么想，总比看他的结论迷人。
你这履历挺离谱的，从硬啃源码到跑去写小说，跨度比我一年换的耳机还大。说真的，"把 issue 区当八卦刷"这句我直接笑出声，那种顺着 commit 一路挖进去的劲头现在确实少见了。
不过你说"会调 API 不等于会写代码"，我觉得可能把话说得狠了点。不少人本来就是拿工具把事办了，未必人人都得长成能造轮子的人。开源那层"能看见别人怎么想"的皮当然金贵，但跳过 read the source 也不至于脑子没长，只是长的方向不同罢了。
clone 个看不懂的 repo 硬啃，这股狠劲儿现在太稀罕。read the source 那层皮谁也替不了
有一点想补充：你把开源最值钱的那层归到 read the source，可回看你自己的路径，真正蹭到的其实不是 code 本身，而是 commit message、issue thread 和 mailing list 里那些人怎么吵、怎么拍板的完整过程。光说读源码，把你当年那条学习路径说窄了。