很多人学技术卡在第一步：教程刷了一大堆，真上手还是两眼一黑。我后来换个路子，直接去给开源项目补文档，效果比报班实在得多。

门槛是真低。翻标签 good first issue，挑 Documentation 类的，基本就是改个错别字、补一段参数说明。不像啃源码那种从天书开始，这种活儿十分钟就能交第一版，maintainer 当天就给反馈。正反馈来得快，人才坐得住。
其实
但别以为写文档就是抄抄文档串。你想把一个函数讲清楚，光看签名不够，得顺着调用链把源码读一遍，再翻测试看边界情况怎么跑。等于为了写两句人话，被迫把源码和测试都练了。这比对着视频敲代码扎实，因为你是带着问题去读，不是被动接收。

最值钱的是被 maintainer 改回的那一刻。你觉得写挺好，对方一个 PR review 给你拆成"这句不准确"“格式不合规范”“例子该放上面”。简单说被驳回两三次，代码风格、commit 习惯、英文写作的边界，全刻进肌肉记忆了。这些网课不会手把手教，因为真人改你东西的羞耻感和收获是绑定的。C’est la vie，被改回不是丢人，是有人免费给你做 code review。

别再囤课了。挑个你天天用的小工具，从补一段文档开始，比看一百小时视频都长进得快。bon appétit，去 fork 吧。

第一次提 PR 真正卡住人的不是写，是敢不敢把东西亮出去让人改。你把被改回的羞耻感当礼物，这点我认，但很多人其实倒在这一步之前——文档改完了，对着提交按钮犹豫半天，怕写得太蠢被挂。我自己的路子是先挑维护者语气明显温和、issue 里标了 good first issue 的项目，头两个 PR 合并不合并不重要，把"被人改"脱敏才是关键。等你对 review 评论没感觉了，什么代码风格、commit 习惯才进得去肌肉记忆。

补文档还有个作者没展开的价值：它逼你站到读者那边想问题，纯写代码练不出来。你读源码是为了讲清楚，但讲清楚的前提是想明白"一个新手会卡在哪儿"。这种读者视角比英文写作难得，也最能迁移——以后你交代任何事都会先想对方懂什么、不懂什么。

强迫症表示，被 maintainer 把格式一条条劈开，前两次确实憋屈，第三次开始反而爽，终于有人把标准定死了，不用自己瞎琢磨。

小补充不算反驳：文档贡献有天花板。等 typo 改完、参数补齐，拐点在去修那个"因为看不懂才没文档"的 bug。文档缺口底下常藏着真设计问题，顺手挖下去才从写手变成 contributor。别停在最舒服那层。

你们遇到过改文档改到一半发现原函数命名本身就误导人的情况吗？这时候提俩 PR 还是硬在一个里全干完？

我之前给个小工具补文档，本来只想改错别字，结果为讲清一个参数翻了半天源码，比刷十节视频记得牢多了。

读到被 maintainer 驳回那段，那种被人认真挑错的滋味，年轻时只当是难堪，如今倒觉得是种稀罕的运气。肯花心思改你东西的人，总比随手点赞的人金贵些。

我前阵子也是，为了补段参数说明，硬把源码和测试都翻了一遍。楼主说"带着问题去读"是真的。

你那句“被改回的羞耻感和收获是绑定”，我盯着看了好一会儿。人到了某个年纪才慢慢懂，肯认认真真驳回你的人，是把你当一块可雕的璞石在看，连陌生人都懒得敷衍你了，反倒是顶奢侈的对待。

被maintainer打回那一下真够酸爽的。不过楼主这句C’est la vie用得比我地道，差点当成老乡了 (￣▽￣)

我前阵子也试着给一个小项目补过文档，楼主说得"被 maintainer 改回那一刻"真没夸张。第一次提 PR 被人整段重写，红红绿绿一片，那酸爽……但回头看确实比刷十节视频都管用，毕竟被人指着说"这里不对"的时候，脑子是格外清醒的。

不过得抬个杠：good first issue 里的文档活儿有时候也挺坑，碰上项目本身文档就乱成一锅粥，你补半天等于在沙子上盖楼。挑项目比挑任务还重要，这事儿没人提前跟我说过。

你补的是哪类？可以可以后端还是前端那种？

楼主说当天就给反馈，我经历里不全是这样。活跃项目的文档 PR 常排到后面，等一两周才有人看也正常。

我去年也给一个小项目提过第一个PR，补的是配置项说明。自个儿觉得写挺清楚了，结果maintainer回了一长串，连"例子里的变量名和正文对不上"都给我圈出来。脸是有点热的，但改完再交，确实比原先像样太多。楼主说被改回是在免费做code review，这点我深有同感。

顺着想多一层：补文档最妙的是逼你换双眼睛看代码。写代码的人脑壳早陷在实现里，默认读者都懂自己的上下文；真要写两句人话给别人看，你就得跳出来琢磨"一个从没碰过这项目的人，看到这步会卡在哪"。这个视角的切换，闷头自己写代码是练不出来的。没事的
抱抱
不过想补个小提醒：这法子治的是"会一点但没手感"的人。要是一个字代码没写过，直接去读源码调用链、翻测试边界，怕比看视频还劝退。它更像进阶私教，不是零起点。囤课那事我也觉得倒不必全扔——有人就吃结构化课程给的确定感，关键是别把"买"当"学"了。

你们最近都在补哪类项目的文档？我那个PR后来merge了，还挺长成就感的 (￣▽￣)

帖子里说 Documentation 类 issue 基本就是改错别字、十分钟交第一版，这点我得补个 caveat。

我前阵子给一个 Python 库补 docstring，挑的正是 labeled Documentation 的 good first issue，结果第一版被 maintainer 退回四次：参数类型写成了 str 但实际接受 PathLike，默认值描述漏了 None 分支，example 放在 docstring 末尾而非开头。没有一行代码改动，纯文字，但每一处都是顺着源码和测试才确认出来的。

所以"门槛低"和"被改回刻进肌肉记忆"其实是一回事：低的是入口，不是天花板。十分钟能交的是草稿，不是合格 PR。你后面那句"为了写两句人话被迫读源码和测试"才是关键，前面的"十分钟"反而把这件事说轻了。

补个数据：GitHub Octoverse 里 doc 类 PR 平均合入周期比 feature PR 短，但 changes requested 的比例反而更高，说明 maintainer 对文字的较真不亚于代码。Sic.