我先说反常识的：很多人把开源贡献理解成“给项目提代码”，但在维护者眼里，最缺的往往不是代码，而是可验证的上下文。我 2021 年第一次给一个 Python 小库提 PR，改了 3 行代码，顺手把 README 里两个 typo 也改了。结果维护者只回了一句：请拆成两个 PR，typo 单独提。当时我觉得他事儿多，后来我自己维护了一个 400 多 star 的小工具，才明白：一次 PR 里混入无关改动，review 成本会翻倍。你要让维护者用最小认知负担判断“这个改动安全吗”。所以新人第一步不是找 good first issue 猛冲，而是学会写清楚环境、版本、复现步骤、期望和实际。一个带最小复现仓库的 issue，价值经常大于一个 20 行但没测试的补丁。
我后来自己总结了一个很土但好用的公式：贡献净值 = 合并后节省的维护时间 - 你消耗的 review 时间。按这个公式，改一个 typo 可能节省 1 分钟，但维护者点开、跑 CI、合并也要 2-3 分钟，净值可能是负的；而一个把 Python 3.8/3.9/3.10/3.11/3.12 的失败日志整理成矩阵的 issue，可能让维护者 10 分钟定位到 collections.abc 导入问题，净值很高。再比如，给一个没有测试的边界条件补上 pytest 失败用例，哪怕代码还没改，维护者也能直接确认 bug 存在。小项目和大基金会项目也不一样：个人项目可能维护者一个人说了算，PR 24 小时内看；Apache/Kubernetes/CNCF 这类项目有 committer、PMC、SIG、CLA/DCO、lazy consensus，流程更长，但一旦合并，影响也更大。别用同一套姿势打所有项目。
怎么选项目？不要只看 star。star 多可能是历史遗留，最近 90 天没 commit 的项目，你提了也没人理。我的筛选习惯：过去 90 天 commit 数大于 20，最近 6 个月有 release，issue 关闭率别太低，good first issue 未关闭数量小于 20，平均 PR 合并时间小于 14 天（这个只能看 pulse 或自己抽样）。GitHub 搜索可以用：is:issue is:open label:"good first issue" no:assignee comments:<5 language:python，再按 updated:>2025-01-01 过滤。点进项目先读四个文件：CONTRIBUTING.md、CODE_OF_CONDUCT.md、.github/ISSUE_TEMPLATE/、.github/workflows/。如果 CONTRIBUTING 里写了必须 DCO sign-off，你 commit 时就要 git commit -s，生成 Signed-off-by: 你的名字 <邮箱>；如果要求签 CLA，一般是 Apache Individual Contributor License Agreement 或项目自己的 CLA，不签 PR 可能无法合并。别嫌麻烦，这是法律和版权边界，不是维护者摆架子。
10 步流程我按自己提 PR 的顺序写一遍：1）fork 后 clone：git clone git@github.com:你的用户名/项目.git。2）加 upstream：git remote add upstream https://github.com/原项目/项目.git。3）拉最新：git fetch upstream && git switch main && git rebase upstream/main。4）建分支：git switch -c fix/issue-1234-short-desc。5）装环境：Python 用 python3.11 -m venv .venv && source .venv/bin/activate && pip install -e '.[dev]'；Node 用 nvm use 20 && npm ci；Go 用 go test ./...；Rust 用 cargo test --all-features。6）先复现：写一个最小脚本或测试，确认失败。比如 pytest tests/test_x.py::test_edge_case -q，把失败栈贴到 issue。7）改代码，尽量小。一个 PR 只解决一件事。8）本地跑 CI：pre-commit run --all-files、pytest -q、tox -e py311、npm test、cargo clippy --all-targets --all-features。不要等 GitHub Actions 给你报错。9）提 PR：标题写 fix: ... 或 docs: ...，描述里写 Fixes #1234，附上复现命令、测试结果、截图/日志。如果项目要 DCO，git commit -s。10）响应 review：维护者让你改，就 rebase 或追加 commit，别 force push 到别人正在看的 PR；如果 7-14 天没回复，可以礼貌 ping 一次，别每天 @。
我踩过的 9 个坑，你可以直接避开：一次 PR 改 30 个文件，包含格式化、重命名、修 bug；不看 CONTRIBUTING.md 就提，CI 用 black/ruff/eslint，你全红；没复现就猜原因，提了“应该是缓存问题”，结果不是；用 AI 生成一大段代码，自己没跑通，维护者问“你测试了吗”，答不上来；把 issue 当客服，只写“报错了，怎么办”，没有版本、日志、最小仓库；在 issue 里催 @maintainer please review，一天三次；改公共 API 不写迁移说明，不更新 changelog；忽略 CLA/DCO，PR 卡在机器人检查；被拒就消失，不回复 review，也不关 PR。这些坑我都见过，有的自己踩过。维护者不是不想带新人，是他一天只有几十分钟处理开源，你让他多做一次侦探，他就少一次写核心代码的机会。
再说一个我觉得比较新的观点：AI 时代，开源贡献的稀缺价值变了。2023 年以后，AI 能写补丁、写测试、写文档，维护者不缺“看起来能跑”的代码，缺的是真实环境验证、边界条件、回归测试、供应链安全、长期维护承诺。比如一个 AI 可以生成 try/except，但它不知道你的 Windows 路径、Docker 24 的 cgroup v2、Kubernetes 1.29 的 API 弃用、Node 18 和 20 的 OpenSSL 差异。所以新人更应该抢“高摩擦低供给”的贡献：复现、失败测试、版本矩阵、文档准确性、CI 缓存、依赖升级验证。这些东西不酷，但被合并的概率高。你连续做 5 个这种小贡献，维护者记住你了，再提核心代码，阻力会小很多。
非代码贡献也值得对比一下。代码贡献显眼，但非代码贡献经常被低估。文档：把安装步骤从“pip install”改成“Python 3.11 + venv + pip install -e '.[dev]'”，减少 30% 新手 issue。翻译：至少保证术语表统一，别把 commit 翻译成“提交”又翻译成“承诺”。测试：给一个没有 Windows CI 的项目加 windows-latest matrix，可能暴露路径分隔符 bug。Issue triage：把 50 个未分类 issue 打上 bug/docs/question 标签，合并重复项，维护者会谢你。安全：看到 requirements.txt 里 urllib3<2 这种锁死，不要直接大版本升级，先看 changelog 和 CVE。社区：回答新手问题，写 FAQ。这些贡献在简历上不一定好写，但在维护者心里权重很高。
最后说心态。开源贡献不是道德积分，也不是“白嫖劳动力”那么简单。它更像一个异步协作市场：你用可验证的劳动换信任、换代码 review、换人脉、换学习。别一上来就想改核心架构，先从小到维护者不好意思拒绝的贡献开始。我的建议是：选 1 个项目，别同时开 10 个；每周固定 2 小时，先读 issue 和 PR；第一个月目标不是合并 10 个 PR，而是完整走通一次“复现-测试-修复-合并”。如果你被拒了，问一句“我下次怎么改能更容易被接受”，大多数维护者会给方向。真正难的不是写代码，是让别人愿意花时间看你的代码。你降低他的成本，他就更可能给你机会。