差点走上歧路:开源贡献不是集邮

为了贡献而贡献,不深入研究仓库,结果被拒了 20 个 PR。直到一个大哥点醒我。

· 4 min read

我差点走上歧路。

说”差点”是因为我还来得及回头。但如果你在做开源贡献,我希望你别踩我踩过的坑。

集邮式贡献

事情是这样的:我开始做开源之后,产生了一种幻觉——PR 数量等于贡献质量。

于是我像集邮一样到处提 PR。看到一个项目,翻翻 issue,找到一个能改的地方,写几行代码,提交。然后换下一个项目。最多的时候我同时在四五个不同的仓库里提 PR,每个仓库的代码我都不超过读了 20%。

结果呢?20 个 PR 被关掉了。

不是因为代码写得差——说实话那些改动本身没什么技术问题。被拒的原因五花八门:方向不对、改动没意义、维护者不需要、风格不匹配。但归根结底就一个原因:我不了解这些项目。

我在给一个从未深入读过的代码库提 PR,就像一个陌生人跑到你家说”我觉得你家沙发应该换个位置”——技术上可能没错,但你凭什么?

被拒的 PR 长什么样

回头看那些被拒的 PR,模式很清晰:

改了个 typo。 在一个我从没贡献过的项目里,改了一个 README 里的拼写错误。维护者直接关了,连 comment 都没留。不是因为改错了,而是这种 PR 对他们来说毫无价值——他们需要的不是 typo hunter,是真正理解项目的人。

改了个格式。 某个项目有个函数命名风格不一致,我提了个 PR 统一了命名。维护者说”这是我们的历史遗留,不影响功能,不改”。我连这个项目的代码规范都没读过。

提了个”我觉得更好”的方案。 在一个 Rust 项目里,我按照自己的审美重构了一段代码。维护者看了两秒就关了——“We have our own style guide, please read it first.” 他们的风格指南我根本没打开过。

这些 PR 的共同点是:我在用我的标准衡量别人的项目。

一个大哥的点醒

后来有一次在 GitHub 上跟一个开发者聊起来,我提了一嘴自己被拒了很多 PR。他没嘲笑我,但说了一段让我脸红的话:

“你现在的做法是打一枪换一个地方。每个项目你都只摸了个表面,提了个浅层的改动就走了。这不是贡献,这是刷存在感。你真想做好开源,就选一个项目,扎进去。读它的代码,读它的 issue history,读它的 design decisions,读到你能给新人解答问题的程度。到那个时候你提的 PR,维护者不会拒。”

这段话刺痛了我。因为他说得对。

我一直在做的事情本质上是偷懒。改 typo、改格式、改命名——这些改动不需要真正理解项目,只需要会用 grep。我挑的都是”最容易下手”的问题,而不是”最需要解决”的问题。

转变

从那以后我换了个思路:

选一个项目深耕。 不再到处撒网,而是选一个我真正感兴趣的项目,花时间读它的代码。不只是读要改的那几行,而是读整个架构、整个测试体系、整个 CI pipeline。读到我能回答 issue 里新人的问题。

选一门语言精通。 我之前什么语言都碰一点,Java、Python、TypeScript、Rust,每个都是”能写”但都不”精通”。现在我专注于把一门语言真正吃透——不是会写 hello world,而是理解它的设计哲学、它的最佳实践、它的社区文化。

先当用户,再当贡献者。 在提任何 PR 之前,先用这个项目。用它做点东西,踩它的坑,感受它的痛点。只有你自己被某个 bug 坑过,你提的 fix 才有说服力。

先在 issue 里帮忙。 不急着写代码,先去 issue tracker 里回答问题、帮忙复现 bug、讨论设计方案。让维护者认识你,知道你是认真的。

结果

转变之后,我的 PR 通过率明显不一样了。不是因为我代码写得更好了,而是因为我选对了问题

现在回头看,那 20 个被拒的 PR 不是浪费。它们是最好的学费。如果没有那些拒绝,我可能还在到处刷 PR 数量,觉得自己很厉害,实际上什么都没学到。

开源不是集邮。一个真正有质量的贡献,胜过一百个无人在意的改动。


——Jiahao Ren, 2026 年 5 月