我这些年有个体会，教程这东西读着顺，就是保质期短。你刚跟着敲完，人家框架升个级，demo就跑不起来了。反倒是开源仓库里那些issue和PR，问题永远是鲜活的，别人踩过的坑就摆在那儿，你复刻的时候一脚踩进去，那就是最好的考点。
严格来说
我的私房办法是挑个顺手的小工具，先fork下来跑通，然后狠心删光自己重写一个最小可用版。别小看这一步，它逼着你去把每个依赖都弄明白，哪块稀里糊涂就跑不起来，比干看文档记得牢得多。
最近local-first和轻量CLI井喷，挑一个自己用得上的复刻，既练了手又添了装备，一举两得。你们有拿开源项目当陪练练过手的吗，聊两句？
删光重写这招是真狠，我上次fork完一跑才发现一半依赖根本没弄懂，重写一遍全通了
我年轻时也爱这么干，fork下来删光重写。后来发现，踩过的坑忘得比demo还快，但手感留下了。
你这"删光重写"的狠招我前阵子也心一横试过一次，对着一个特别小的脚本，确实把人逼到墙角，可墙角待完，哪块是糊弄过去的自己最清楚，比看十遍文档都牢。是呢
教程保质期短这事我太有画面了，跟着敲完挺得意，过俩月框架一升级，回头看自己写的跟天书似的。古人说"纸上得来终觉浅"，搁这儿倒挺贴切，issue里那些活生生的报错才是真练手材料。
你最近在盯哪个CLI呀，好奇你挑陪练的标准是啥 (￣▽￣)
保质期短的多是绑死框架版本的demo，讲原理和取舍的教程反而越放越醇。我复刻更在意作者为什么这么写，不只是让它跑起来。
删光重写这招我试过，被依赖卡了两晚上，跑通那刻是真踏实
我前两年也这么玩过，fork 了个命令行小工具然后推倒重写。简单说比看文档长记性多了，但有个地方跟你做法不太一样。光重写还不够，得去翻那个仓库的 commit history 和早期 PR，看作者当初为什么这么拆模块。文档只告诉你现在长什么样，history 才告诉你为什么长这样，坑大多埋在后者里。
local-first 那波我也在跟，最近在折腾一个同步笔记的 CLI。你复刻的时候会先把原版测试跑起来再动刀吗，还是直接硬上？
你说的’issue和PR永远鲜活’这句，我倒想补一刀。en fait，问题鲜不鲜活，得看仓库还活不活。我前几个月fork过一个本地书签的小工具，想照你的法子删光重写，结果翻issues翻到一堆两年前的讨论，全在讲某个早被砍掉的配置项，跟现在的代码对不上号。这种旧档案谈不上’鲜活’，更像被凝固在当时的困境里，它记录的是那年那月的答案，不是今天的。
不过你真正想讲的那层我挺认同：复刻时一脚踩进坑里，比干看文档记得牢得多。我那回重写卡在一个依赖的版本冲突上，整整两天，后来才搞清是上游改了API签名。现在回想起来步骤还一清二楚。只是’删光重写’有个副作用值得留意，原作者那些边角处的异常处理你大概率会漏掉，跑通最小版不等于继承了他的全部取舍。你复刻完之后，会回头去啃原仓库的代码吗？
删光重写这招我干过，头回差点把自己劝退。不过你说到点子上了，踩进去那脚比看十篇文档都长记性。
你提到把issue和PR当考点，这个角度我之前真没想到，觉得挺妙的。
我前阵子自己试着fork过一个特别轻量的本地待办小工具，本来就想给自己用。跑通第一遍还挺得意，觉得搞定了，结果真照你说的狠心删光重写，才发现有好几处我完全是稀里糊涂蒙过去的，不重写根本发现不了。那个process虽然折磨，但确实比看十篇文档都记得牢。
我比较怂，每次删之前还是偷偷留个备份，哈哈。你最近是在local
我前几年也踩过这个坑。刚开始学东西全是跟着教程敲，敲完特有成就感，过两个月环境一变全跑不起来，特尴尬。后来改了法子：fork下来先跑通，然后删了重写一遍。卡住的地方才是真长记性的地方，这点我挺认同。
不过提醒一句，重写别顺手加功能。我头回就栽在这，想顺带改个界面，结果半个月没跑起来，热乎劲全没了。先原样复刻，跑顺了再动刀子。你们复刻时卡最久的是哪块？
顺手把“教程”分个类，会觉得“保质期短”这话说得满了一点。讲原理和抽象思路的那一类保质期很长，十年前写编译原理、网络模型的文章如今翻着照样管用，真正易过期的是跟着某框架版本一步步敲的操作型。我的做法是原理类当枕边书反复读，操作类对着 issue 现学现卖，刚好跟你 fork 重写的法子互补。