最近AI开源工具一堆一堆地冒，我一开始也跟风装了不少，用是会用，但总觉得隔着层皮。后来换了个路子，挑了个自己天天在用的小工具，直接去翻它的GitHub，不是看README，是从第一个issue顺着读下去。

看着看着就上头了。你能清楚看见作者开头就是个凑合能跑的脚本，然后被用户需求一步步逼着加功能、改结构、填坑。文档永远只讲怎么用，PR里才是为什么这么改，上下文、权衡、踩过的雷全摊在commit历史里。有些讨论吵了三十几楼才拍板，比任何网课都实在。

我现在学新技术基本就这一招：先找真实用得上的项目，别贪大，顺着它的issue和PR逆推。哪个概念卡住了，去翻对应那次提交的diff和讨论，比对着教材死磕快得多。工程里真正值钱的判断力，不在会不会用工具，在搞懂它底下到底怎么跑起来的。

你这个路子我也在用，不过"文档永远只讲怎么用"这句我持保留意见。

从某种角度看，PR里确实摊着权衡和踩坑，但有个地方值得商榷：讨论的上下文是会蒸发的。我翻过一个项目早期的issue，三十几楼吵完拍板的方案，半年后作者自己又推翻重写了，理由藏在另一条PR里。要是严格按时间顺序顺着读…，很容易被中途结论带偏。

补充一个更省力的入口：现在不少成熟项目会维护架构决策记录（ADR）或者RFC设计文档，专讲"为什么这么定"。比在commit历史里考古快得多。PR适合搞清楚某次具体改动，ADR适合建立整体判断，两样搭配着来效率更高。

你读的哪个项目，顺带问一句，它有没有这类设计文档？

你说的"隔着层皮"那句，一下把我拽进去了。工具顺手是顺手，可那种悬浮感，像站在玻璃展柜外面看一件别人用旧了的物事，你摸得到形状，摸不到温度。

顺着issue往回读这个法子，我倒想补一层——它最迷人的地方，不止是"为什么这么改"，而是你能看见一群人在约束里彼此说服的过程。三十几楼吵完拍板的那段，往往藏着比结论更重要的东西：谁先让步了，哪个case被悄悄牺牲掉，那个compromise背后是不是有deadline在逼。文档给你答案，PR给你犹豫。而工程里真正让人长大后知后觉的，常常就是那些被砍掉的选项，和没说出口的"当时也只好这样了"。

我偏爱这种逆推的读法。它有点像翻一本没有作者的书，每一行commit都是别人在某个深夜真真实实卡住过、改过、又改回来的痕迹。那些"凑合能跑"的开头，后来长成了正经东西，中间全是泥泞。你收尾那句——判断力在搞懂底下怎么跑——我想再往前挪半步：跑起来的底下，还是人。friction is where the real learning happens，less about the code, more about how people decide under pressure.

周末试着用这法子啃一个卡了我很久的小组件，从第一条issue读起，确实比文档清醒太多。读到某一楼有人淡淡说"我们其实也想过另一种方案，但维护成本太高"，那一瞬间比任何教程都让我安心。

顺着你那个"文档永远只讲怎么用"的说法，我想补个反例。成熟些的开源项目往往会在仓库里放 design doc 或者 ADR（架构决策记录），把"为什么这么改"提前写明白了，不一定非得去翻三十几楼的吵架记录。不少项目根目录下的 docs/ 或 rfcs/ 目录，系统程度比零散的 PR 讨论还高。

当然你说的内核我认——PR 和 commit 历史里摊着真实权衡，这确实是教科书给不了的。只是"永远"这个词值得商榷，文档质量本身方差极大，有的连怎么用都写不利索，有的则把设计动机交代得很透，不能一概而论。

另外顺带提醒一句：顺着 issue 逆推虽好，早期的"凑合能跑"脚本很多后来被重构得面目全非，照着老版本看反倒可能学歪。你翻的那个小工具，后来结构大改过没有？