GitHub 賞金接單全攻略：從註冊到提交 PR 的完整流程

📅 生成日期：2026-05-23

第 1 章：GitHub Bounty 是什麼，為什麼值得做

如果你在程序員圈子裡混過，"接私活"這個詞一定不陌生。傳統私活通常意味著：在某個外包平臺跟幾十個人競標、加微信談需求、被甲方反覆改需求、最後可能還被拖欠尾款。而 GitHub Bounty 走的是一條完全不同的路——你不需要跟任何人社交，不需要寫標書，只需要讀懂代碼、寫好代碼、提一個漂亮的 PR，錢就可能到你賬上。

GitHub Bounty 到底是什麼？

簡單說，GitHub Bounty 就是開源項目維護者（或第三方平臺）在某個 Issue 上掛一筆賞金，誰先提交符合要求的 Pull Request 並被合入，誰就拿走這筆錢。

它本質上是一種"眾包開發"模式：項目方把需求寫清楚，開發者自己評估能否做、值不值得做，做完提交，審核通過即結算。整個過程發生在 GitHub 上，你唯一需要打交道的就是代碼和 PR 評論——沒有甲方半夜發 60 秒語音方陣。

主流平臺與真實金額

目前活躍的 Bounty 平臺主要有這幾家：

重點推薦 Algora。理由很簡單：支付走 Stripe，直接到銀行卡，不需要搞錢包、不用 KYC 繁瑣流程，對國內開發者最友好。而且它在 2024-2025 年活躍度非常高，每天都有新 Bounty 上線。

關於金額，不要被 Gitcoin 上那些 $60,000 的 bounty 嚇到——那是極端案例。絕大多數 bounty 落在 $50-$500 區間。我見過有人在 Algora 上花一個週末搞定一個 TypeScript 類型修復的 bounty，拿 $150；也見過有人花兩週做一個完整功能模塊，拿 $3,000。關鍵在於你挑什麼難度的活、你的技術棧匹不匹配。

為什麼值得做？

第一，門檻極低。 不需要簡歷、不需要面試、不需要任何資質證明。GitHub Profile 就是你的名片，你的代碼就是你的簡歷。只要你有一個像樣的 GitHub 賬號和能跑通的開發環境，就可以開始。

第二，回報直接。 做完 = 交 PR = 審核通過 = 錢到賬。中間沒有商務談判、沒有合同糾紛、沒有催款環節。PR merged 的那一刻，錢就自動進入結算流程。

第三，積累開源聲譽。 你提交的每一個 PR 都是公開的，永久留在 GitHub 上。這意味著你在賺錢的同時，也在給自己的 GitHub 貢獻記錄添磚加瓦。一份漂亮的 Contribution Graph 在求職時比簡歷上寫"熟悉開源協作"有力一百倍。

第四，倒逼技術成長。 Bounty 不是玩具項目——你面對的是真實生產環境的代碼庫，有嚴格的 CI 檢查、Code Review 和代碼規範要求。為了過審，你必須寫出高質量、可維護的代碼。這對技術水平的提升比刷 LeetCode 快得多。

什麼樣的人適合做？

如果你滿足以下條件中的 2-3 條，就可以試試：

• 有至少一門編程語言的熟練使用經驗
• 用過 Git，知道 branch / commit / rebase 的基本操作
• 讀過開源項目的源碼，能理解別人的代碼結構
• 英語閱讀能力過關（大部分 Issue 和 PR 討論都是英文）
• 每週能擠出 5-10 小時的自由時間

不需要是全棧大神。很多 $50-$200 的 bounty 就是修個 bug、加個小功能、寫幾行配置。你完全可以從這種小單開始積累經驗和信心。

以我自己為例，第一單是個 $75 的 Python CLI 工具小修復，代碼改動不到 30 行，但過程中學到了那個項目的 PR 模板規範、CI 流水線怎麼跑、maintainer 的 Review 風格。這些經驗在後面的單子裡全用上了。

如果你的 GitHub Profile 還是一片空白，下一步我們就從這個開始。

第 2 章：從註冊到提 PR 的六步完整流程

搞清楚了 Bounty 是什麼，接下來就是實操。這一章會按順序走完六個步驟，每一步我都會給出具體命令和最容易踩的坑。

第一步：註冊 GitHub 並完善 Profile

如果你已經有一個 GitHub 賬號，不要直接跳過這步——Profile 是 Maintainer 對你的第一印象，直接影響你的 PR 會不會被認真對待。

Profile 的核心要素：

• 頭像：用一張清晰的照片或專業頭像。不要用默認的像素小人。
• Bio：一句話說清楚你做什麼技術棧。例如："Full-stack dev, TypeScript & Rust enthusiast. Open source contributor." 不需要太長，但要讓人一眼知道你能幹什麼。
• Pinned Repositories：把你最好的 6 個倉庫置頂。如果沒有拿得出手的項目，花一個週末做一個高質量的 Demo 項目放上去。哪怕是 Stars 數為零，代碼質量和 README 寫得好也能加分。
• Contribution Graph：如果有歷史貢獻記錄，綠色的格子本身就是最好的名片。如果一片空白，從今天開始做貢獻。

最容易忽視的點：README 裡的個人項目 README。在 GitHub 上創建一個與你用戶名同名的倉庫，裡面的 README.md 會渲染在你的 Profile 頁面頂部。這是你的個人廣告位——放技術棧標籤、聯繫方式、最近在做的事。

# 示例：創建一個 Profile README
mkdir biebiebie  # 替換為你的 GitHub 用戶名
cd biebiebie
echo "# Hi, I'm biebiebie 👋" > README.md
git init && git add . && git commit -m "init profile"
# 在 GitHub 上創建同名倉庫，push 上去

第二步：找到適合自己的 Bounty

Bounty 不是越多越好，是越匹配越好。以下是高效的搜索策略：

平臺搜索技巧：

在 Algora 上，使用標籤（Label）過濾是最高效的方式。關注以下標籤組合：

• good first issue + bounty：新手友好型，適合練手
• 你的技術棧標籤：python / typescript / rust / react
• bug：修 bug 通常比做新功能更容易過審

按難度篩選的實操標準：

我的篩選鐵律：

1. Issue 描述模糊的一律跳過——"improve performance" 沒有具體指標的不碰
2. 倉庫最近 30 天有 commit 的才接——死倉庫的 PR 沒人合
3. 先看 CONTRIBUTING.md——如果倉庫沒有寫清楚貢獻規範，說明 Maintainer 可能不夠專業
4. 同一 Issue 下已經有 PR 在 Review 的，除非你確定自己能做得更好，否則跳過

第三步：創建 Personal Access Token

這一步很多人會問：為什麼需要 Token？因為你需要用 git 命令推送代碼到 GitHub，而 GitHub 從 2021 年起不再支持密碼認證，必須用 Token 或 SSH Key。

創建步驟：

1. 登錄 GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic)
2. 點擊 "Generate new token (classic)"
3. Note 填寫 "bounty-work"（方便以後識別）
4. 勾選權限：repo（完整倉庫訪問權限）、workflow（如果需要觸發 CI）
5. 設置過期時間：建議 90 天，不要選 "No expiration"
6. 生成後立即複製保存——GitHub 只顯示一次

安全注意事項：

• 不要把 Token 硬編碼到代碼裡。 每年都有人把 Token 提交到公共倉庫，然後被 GitHub 自動掃描到並吊銷。
• 使用 Git Credential Manager 存儲 Token，或者用環境變量：

  # macOS / Linux
  git config --global credential.helper osxkeychain

  # 首次 push 時輸入 Token，之後自動記住

• 如果你用 SSH Key 替代 Token，更推薦——ssh-keygen -t ed25519 -C "your_email@example.com"，把公鑰添加到 GitHub SSH Keys。

第四步：Fork 倉庫 + 本地開發

標準 Git 工作流：

# 1. Fork 目標倉庫（在 GitHub 網頁上點擊 Fork 按鈕）

# 2. Clone 你 Fork 的倉庫
git clone https://github.com/YOUR_USERNAME/REPO_NAME.git
cd REPO_NAME

# 3. 添加上游倉庫（保持同步）
git remote add upstream https://github.com/ORIGINAL_OWNER/REPO_NAME.git

# 4. 創建功能分支——務必從最新的 main 分支切出
git checkout main
git pull upstream main
git checkout -b fix/issue-42-description

# 5. 開發 + 提交
git add .
git commit -m "fix: resolve issue #42 - update validation logic"

# 6. Push 到你的 Fork
git push origin fix/issue-42-description

分支命名規範很重要。好的分支名讓 Maintainer 一眼看懂：fix/issue-42-null-check、feat/add-pagination、docs/update-api-reference。不要用 my-fix 或 test 這種沒有信息量的名字。

Commit Message 規範同樣關鍵。推薦 Conventional Commits 格式：

<type>: <short description>

<optional body>

例如：

fix: resolve null pointer in user validation (#42)

Added null check before accessing user.email in the validate()
function. This prevents a crash when email is not provided.

開發過程中的幾個要點：

• 先跑通項目的測試套件，確保你的改動不會破壞現有功能
• 如果你的改動引入了新邏輯，補上對應的測試用例
• 遵守項目的代碼風格——如果項目用 ESLint，你就用 ESLint；用 Black 就用 Black

第五步：提交 PR 的正確姿勢

PR 是決定你能不能拿到錢的關鍵環節。以下是一個高通過率 PR 的模板：

## Description
Fixes #42: Add null check for user.email in validate()

## Changes
- Added null guard before accessing `user.email` in `src/validators/user.ts`
- Updated unit test to cover null email scenario

## Testing
- [x] All existing tests pass
- [x] Added new test case for null email input
- [x] Manually verified in local dev environment

## Screenshots (if UI change)
<!-- Before / After screenshots -->

## Related Issues
Closes #42

高分 PR 的核心原則：

1. 關聯 Issue：在 PR 描述裡寫 Closes #42 或 Fixes #42，這會讓 GitHub 自動關聯 Issue，合併後自動關閉。
2. CI 必須全綠：提交前在本地跑一遍項目的 lint 和 test。CI 掛了再修很掉印象分——Maintainer 會認為你不夠仔細。
3. 改動要小且聚焦：一個 PR 只做一件事。如果你發現代碼裡還有另一個 bug，不要順手修，另開一個 PR。改動越小，Review 越快，合入越快。
4. 回覆 Review 要及時：Maintainer 提的修改意見要在 24 小時內響應。如果你拖一週才回復，可能另一個競標者已經改完合入了。

常見錯誤：

• 在 PR 裡引入大量無關改動（格式化、重構無關代碼）
• PR 描述只有一句話 "fixed the bug"，沒有說明改了什麼
• 不寫測試，或寫的測試覆蓋不到邊界情況

第六步：Bounty 支付流程

PR 被合入後，支付流程因平臺而異：

Algora 支付實戰經驗：

Algora 的支付流程最為順暢。你需要在 Algora 設置裡綁定 Stripe 賬戶。首次提現時 Stripe 會要求上傳身份證明文件——這是金融合規要求，正常操作。上傳後通常 1-2 天審核通過，之後提現就是秒到。

一個細節：Algora 的 Bounty 金額顯示的是 USD，但 Stripe 提現到國內銀行卡時會按當日匯率自動換算為人民幣。沒有中間商賺差價，實際到手金額和標價差距很小。

稅務提醒：Bounty 收入屬於個人勞務報酬，按中國稅法需要自行申報。單筆小額（幾百美元）通常不觸發關注，但如果月入上千美元，建議諮詢稅務專業人士。

六步走完，你已經有能力獨立完成一次 Bounty 接單。但實際過程中還有不少坑——下一章我們專門講。

第 3 章：避坑指南 — 常見被拒原因與競爭策略

流程走通了不代表每次都能拿到錢。我自己在早期踩過的坑，加上觀察其他競標者翻車的案例，總結了下面這些血淚教訓。

PR 被拒的六大常見原因

第一名的教訓：很多倉庫的 CONTRIBUTING.md 會明確寫出代碼風格要求、Commit Message 格式、PR 標題前綴等規則。不讀就直接寫代碼 = 白寫。我就因為這個被拒過——一個 Rust 項目要求所有 PR 標題以 feat: / fix: / chore: 開頭，我沒注意，PR 寫了 "Add new endpoint"，Maintainer 直接留言 "Please follow our PR title convention" 然後關了。

AI 生成代碼的現實

這個問題繞不開。現在很多人用 ChatGPT / Claude 寫代碼提 PR，平臺方也在應對。

現實情況：目前的 Bounty 平臺（Algora、Gitcoin 等）沒有自動化的 AI 檢測機制——它們不像學術論文查重那樣掃代碼。但 Maintainer 是人，他們會讀你的代碼。

什麼情況下會被發現：

• 代碼風格與項目完全不一致（比如項目用函數式風格，你提交了類式 OOP 的代碼）
• 註釋風格突變（全英文項目突然出現中文註釋或 AI 典型註釋風格）
• 代碼裡有明顯的 AI 痕跡（// This function does X 這種教科書式註釋）
• 與你歷史 PR 的代碼風格完全不同

我的建議：AI 可以輔助——用它理解代碼結構、生成測試用例、寫文檔註釋。但核心邏輯必須自己寫、自己理解。如果你連自己提交的代碼都解釋不清楚，Review 時 Maintainer 一個問題就能讓你露餡。Bounty 不是一次性交易，被一個倉庫拉黑後，你在這個生態裡的路就窄了。

競爭策略：如何讓自己的 PR 脫穎而出

熱門的 Bounty 經常有 3-5 個人同時提交 PR。以下是拉開差距的關鍵：

1. 速度 vs 質量，永遠選質量。 第一個提 PR 的人不一定拿到錢。Maintainer 會對比所有 PR 的質量，擇優合入。與其趕時間交一個半成品，不如多花半天打磨到可以直接合入的水平。

2. 在 Issue 下先留言表明意圖。 在開始寫代碼之前，在 Issue 下面評論一句："I'd like to work on this. Planning to implement X approach." 這樣做有兩個好處：一是表明你在做了，減少無效競爭；二是 Maintainer 可能會提前給你方向性建議，避免你走彎路。

3. 提供超出預期的價值。 如果 Issue 要求修一個 Bug，你不僅修了，還補了 3 個測試用例、更新了相關文檔——這就是超出預期。多付出的 30 分鐘可能成為從 3 個競標者中勝出的關鍵。

4. 善用 Draft PR。 如果你需要較長時間開發，可以先提交一個 Draft PR。這等於提前佔位，讓其他競標者看到已經有人在做了。同時 Maintainer 可以提前看你的方向對不對，給出反饋。

5. 建立復購關係。 如果你在同一個倉庫連續高質量完成 2-3 個 Bounty，Maintainer 會記住你。後續該倉庫的新 Bounty 可能會在 Issue 裡直接 @ 你。這種"回頭客"關係比在平臺上跟陌生人競爭高效得多。

第 4 章：個人心得與長遠建議

寫了這麼多，最後聊聊我自己的感受和一些不那麼"技術"但很重要的東西。

Bounty 的長期價值遠超賞金本身

做 Bounty 一年多，我最大的感受是：真正的回報不在賞金，而在賞金之外。

開源聲譽的複利效應。 GitHub Contribution Graph 上越來越密的綠色格子，在求職時比你想象的有用。我有一次面試，面試官上來就說"我看到你在 XX 項目上提交了幾個 PR，質量不錯"，直接跳過了算法題環節，聊了半小時架構設計就發 offer。這不是個例——對真正懂技術的面試官來說，一串高質量的開源貢獻記錄比 LeetCode 刷了 500 題更有說服力。

技術視野的拓寬。 接 Bounty 意味著你會接觸到不同領域、不同語言的代碼庫。Rust 的 CLI 工具、TypeScript 的 Monorepo、Python 的數據處理管道——短期看是賺錢，長期看是在給自己積累技術廣度。這種廣度在做架構決策時特別有價值。

英語的被動提升。 所有高質量的 Issue 討論、PR Review、文檔都是英文的。不需要刻意學英語，讀著寫著就進步了。我現在讀英文技術文檔的速度至少是兩年前的兩倍。

新手最該避免的三個心態

誤區一："我先學完再開始。" 不需要。你不可能把某個技術棧學到完美再開始接單。Bounty 本身就是最好的學習方式——真實的代碼庫、真實的問題、真實的 Review 反饋。邊做邊學，效率遠高於閉門造車。

誤區二："我一定要搶到最大的 Bounty。" 新手最大的敵人不是能力不足，是預期過高。$50 的小單也是單，它的價值不僅是 50 美元，而是讓你走通整個流程、積累第一個成功案例。我的前三個 Bounty 加起來不到 $200，但第四個就拿到了 $1,200 的單——因為前面積累的經驗和信譽讓我能快速判斷什麼單能接、怎麼高效完成。

誤區三："被拒了就是我不行。" PR 被拒太正常了。即使是資深開源貢獻者，也有被拒的時候。被拒不是失敗，是免費的 Code Review。認真讀 Maintainer 的反饋，改完再提交，或者把經驗用到下一個 Bounty 上。

從偶爾接單到穩定副業

如果你想從"偶爾賺點零花錢"升級到"穩定的副業收入"，以下是三條路線：

1. 深耕一個倉庫。 找一個活躍的開源項目，持續貢獻。Maintainer 認識你之後，新 Bounty 會優先考慮你。這種關係的價值遠超在平臺上隨機搶單。
2. 建立技術棧壁壘。 選定 1-2 個技術棧做深。比如專精 Rust CLI 工具開發或 TypeScript 類型系統。當某個技術棧的 Bounty 出現時，你的競爭力會比泛泛之輩強很多。
3. 把 Bounty 當成作品集。 你完成的每一個 Bounty 都是公開的、可驗證的工作成果。這些 PR 就是你最好的作品集。用它來證明能力、拓展人脈、甚至吸引遠程工作的機會。

最後說一句實在的：GitHub Bounty 不是暴富捷徑，它是一個用技術能力換真金白銀的公平遊戲。不需要背景、不需要人脈、不需要學歷——只需要你能讀懂需求、寫好代碼。在現在這個 AI 氾濫的時代，能沉下心讀懂一個代碼庫並解決真實問題的人，反而越來越稀缺。

開始你的第一個 Bounty 吧，做完之後你會回來感謝今天的自己的。