很多人觉得给开源项目做贡献，得会写代码、得懂架构、得是大佬。其实不是。上周我帮 Vue 官网文档改了个错别字——把“组件化”误写成“组建化”，提了 PR（Pull Request），不到两小时就被合并了。那会儿我连 Vue 的源码都没看过。
先找一个你真正在用的项目
别一上来就冲 Linux 内核。打开 GitHub，搜你每天都在用的工具：VS Code 插件、Obsidian 主题、Typora 的中文翻译、甚至是你常逛的某个博客生成器（比如 Hexo 的某个主题）。点开它的 Issues 页面，筛选标签 good first issue 或 help wanted。这些是维护者特意标出来、适合新人入手的问题。
改文档，是最实在的起点
文档错漏、翻译生硬、命令少了个空格、截图过时了……这些都不是小事。用户卡在第一步，很可能就放弃了。找到一处，点右上角铅笔图标（Edit this file），GitHub 会自动帮你 fork 仓库、编辑、提交 PR。整个过程不用装 Git，不用配 SSH，浏览器里点几下就完事。
跑起来，再试改一行代码
挑个轻量级 CLI 工具，比如 Hyperapp 或 commander.js。按 README 把项目 clone 下来，npm install && npm test 跑通。然后看测试失败报错，顺着找对应文件，试着改一行逻辑——比如让某个提示语多输出个感叹号，再跑测试确认没崩。本地 OK 后，push 到自己 fork 的仓库，发 PR。
一个真实例子：
我在用 http-server 时发现它启动后不显示当前路径的完整地址（只写了 Starting up http-server），查源码发现是 lib/http-server.js 第 182 行少拼了个 url.format()。补上后，本地启动就显示 Available on: http://192.168.1.10:8080 了。PR 描述就写：feat: show full URL in startup message，附上截图，当天被合并。
别怕提问，但要带上下文
在 Issue 里问“这个怎么修？”不如贴三样东西：你运行的命令、完整的报错信息（截图或文字）、你已尝试过的步骤。维护者不是客服，但看到你动了手、留了痕迹，通常都会耐心回复。我自己就在 Windows Terminal 的 Issue 里靠贴出 wt --version 和配置 JSON 片段，拿到了修复建议。
贡献不止于代码
帮新用户回答 Stack Overflow 上的同类问题；把英文 issue 翻译成中文发到国内论坛；整理一份新手避坑指南发到项目 Wiki；甚至只是给某个 PR 认真 review 并指出变量命名不一致——这些都是贡献。开源不是拼体力，是拼真实参与感。
你昨天用的那个小工具，今天就能少一个 bug。你改的那行注释，可能就是别人第一次读懂的关键。动手，就现在。