你有沒有試過向不懂技術的朋友解釋什麼是 Pull Request，然後看著他們的眼睛像 Krispy Kreme 輸送帶一樣變得空洞？現在想像一下，告訴他們 AI 不僅可以理解你的 repo，還可以為你開啟 PR。歡迎來到 2025 年，你的程式碼編輯器有點像副駕駛，有點像後座駕駛，如果設置正確，還會是一個相當不錯的實習生。
本指南將向你展示如何將 GitHub 連接到 Claude Code 並自動產生 Pull Request。我們將透過逐步設置、真實世界的工作流程以及一些需要避免的坑，從「蛤？」變成「發佈！」。你將連接 GitHub，讓 Claude Code 了解正在發生的事情，並讓它開啟和更新你可以實際合併的 PR，而不會覺得自己與演算法惡魔達成了交易。
請注意：你將在這裡看到兩個主要路徑——使用 Claude Code 的 GitHub Actions 整合，以及使用 Model Context Protocol (MCP) 伺服器，以便讓 Claude 安全地、有範圍地存取 GitHub API。你應該選擇哪個？如果你想要在 GitHub 中即插即用的 PR 協助，那麼 Actions 路線是你的最佳選擇。如果你想要透過本地、聊天驅動的 repo 控制和細化的權限，MCP 則是你的強大工具。
我們要構建什麼
- 安全地將 GitHub 連接到 Claude Code。
- 讓 Claude 分析你的 repo、提出變更並開啟 PR。
- 新增防護措施，使其不會將你的整個 monorepo 重新命名為“final_final_v2”。
為什麼這很重要
因為上下文切換是沒有人投票贊成的生產力稅。AI 能夠以你期望初級開發人員（在他們表現良好的一天）的嚴謹性開啟 PR，這實際上可以節省時間。不是為了取代人類——冷靜——而是為了取代工程中「唉，樣板」的部分。
路徑 A：使用 Claude Code GitHub Actions 自動產生 PR
如果你整天都待在 GitHub 中（加入俱樂部），此路徑會為你提供一個機器人，它可以分析 issue 和 PR 中的程式碼、建議變更，甚至直接從你的 repo 開啟或更新 PR。
你需要什麼
- 你控制的 GitHub repo（或你可以打破而不會哭泣的分支）。
- Repo 管理員權限，用於配置 Actions 和 secrets。
- 如果你的 action 或 workflow 需要，則需要 Claude API 金鑰。
步驟 1：在你的 repo 中啟用 GitHub Actions
- 前往你的 repository → Settings → Actions → General。
- 啟用“Allow all actions and reusable workflows”（如果你的安全人員已經在側目你，則可以限制為你組織批准的 actions）。
步驟 2：新增 Claude Code workflow
建立 .github/workflows/claude-pr-bot.yml，並根據你喜歡的 workflow 觸發。以下是兩種常見模式：
選項 1：Issue 驅動的 PR
- 當你開啟一個帶有特殊標籤（例如 ai-pr）的 issue 時，workflow 會執行。
- 它會讀取 issue 提示（例如“新增深色模式切換”），建立一個新分支，使用 Claude 編輯檔案，推送提交，並開啟一個帶有詳細摘要的 PR。
選項 2：在現有 PR 上以評論驅動的編輯
- 當你評論 @claude please refactor the settings modal 時，workflow 會執行。
- 它會分析差異、提出變更，並將更新推送到 PR 分支。
入門 workflow（高階草圖）
name: Claude PR Bot
on:
issues:
types: .
- 關於整合和用例的快速指南，讓你從鳥瞰角度了解在真實團隊中可以自動化哪些（以及哪些不應該）內容。
- 如果你是視覺學習者，此演練將從頭到尾展示自動產生的 AI PR 的實際運作。
路徑 B：透過 MCP 將 GitHub 連接到 Claude Code（適用於本地高階使用者）
如果你希望 Claude 使用你的本地 repo 上下文——你機器上的檔案、你正在處理的分支、你信任的命令——MCP 會為你提供一個授權的橋樑。可以將其視為你的 repo 的門衛：它決定 Claude 可以打開哪些門。
你需要什麼
- Claude Desktop 或支援 MCP 工具的 IDE 整合。
- 你在本地執行的 GitHub MCP 伺服器，已配置一個限制範圍的 token。
- 一個僅具有你真正需要的範圍的個人存取 token (PAT)（例如 repo:status、public_repo、pull_request write）。
步驟 1：取得 GitHub MCP 伺服器
- 有一個官方的開源伺服器，它公開了選定的 GitHub API 操作（搜尋 issue、建立分支、開啟 PR 等）。它是可配置的，因此你只需啟用你需要的內容，這也可以減少 AI 混淆並讓安全性保持良好。如需 MCP 伺服器和範例的更廣泛視圖，請查看中央目錄。
步驟 2：配置你的客戶端以與伺服器通訊
- 在你的客戶端配置文件中（例如，你的 AI 應用程式的 JSON 配置），註冊 GitHub MCP 伺服器，透過環境變數將你的 token 傳遞給它，並將允許的 repo 加入白名單。
- 專業提示：將 token 放在你的系統鑰匙串或 dotenv 檔案中，而不是你的配置文件中。不要成為你下次全體員工大會中的警示範例。
步驟 3：測試工具介面
- 要求 Claude 列出未解決的 issue、讀取特定檔案或建立分支。驗證它無法執行你未明確允許的任何操作。
- 僅在你對基本命令進行健全性檢查後，才應啟用 create_pull_request。
步驟 4：讓 Claude 提出並開啟 PR
- 提示範例：「在 repo org/app-frontend 中，建立一個新的分支 feat/dark-toggle，在 SettingsPanel.tsx 中實現深色模式的設定切換，更新測試，並開啟一個帶有 QA 檢查清單的 PR。」
- 伺服器協調：讀取 repo 狀態、寫入變更（如果你配置了本地檔案工具）、推送分支、使用你的模板開啟 PR，並發布摘要。
真實對話：你實際需要的防護措施
- 唯讀試執行：在授予寫入權限之前，讓 Claude 產生一個 unified diff (git diff)。在你親自檢查後再合併。
- 模板化的 PR 正文：包含風險說明、測試計劃和推出步驟。讓機器人完成模板；讓人們審查它。
- 標籤規則：自動套用 ai-generated 和 needs-tests 等標籤，以保持內容的可發現性和誠實性。
- 分支命名：要求帶有分支保護規則的前綴（ai/ 或 bot/）。機器人也需要制服。
軼事時間：我要求 AI「修復身份驗證錯誤」。它透過刪除身份驗證來「修復」它。非常有利於生產力！但對其他一切來說都是可怕的。保持範圍狹窄、提示具體，並保持 CI 測試的嚴格性。
從零到 PR：一個真實的端到端場景
場景：修復 React 專案中不穩定的 debounce 測試
- 你開啟一個 issue：「Debounce util：CI 中 200ms 邊界上的 flake。」你將其標記為 ai-pr。
- Workflow 觸發。它搜尋 debounce.ts 和相關測試。
- Claude 提出一個 diff：使用 jest.useFakeTimers 調整計時器，在 asserts 中新增邊距，更新文件。
- 機器人開啟一個帶有以下內容的 PR：標題、摘要、理由、測試計劃和風險評級。
- 你審查 diff，並提出反饋：「delay=0 時的邊緣情況。」
- 你評論 @claude handle delay=0 with immediate flush; add test。Workflow 重新執行，推送一個 commit。
- CI 通過。你 squash 並合併。在某個地方，一個不穩定的測試哭喊著「我認輸了」。
好的提示是什麼樣的（以及要避免什麼）
- 好：「將深色模式切換新增到 SettingsPanel.tsx；持久化到 localStorage；更新 SettingsPanel.test.tsx；遵循我們的 ESLint 規則；僅修改 /src/ui/ 和 /src/utils/；最多 250 行。」
使其安全：安全性和合規性快速檢查
- Token 範圍：僅在需要時使用 repo:contents write；PR 建立首選 pull_request write。
- Repository 允許清單：將機器人鎖定到單個 repo 或組織。
- 日誌記錄：確保機器人記錄其操作和提示（減去 secrets）。當它「改進」你的 Dockerfile 時，你會想要證據。
疑難排解：當機器人無法正常運作時
- 它無法推送分支：檢查 Actions 權限是否具有 contents: write，以及你的 token 是否具有 repo 寫入權限。
- 它開啟空的 PR：你的上下文構建器沒有向其傳遞正確的檔案。收緊你的檔案選擇邏輯。
- 它在大 repo 上超時：將上下文限制為已變更的路徑或 manifest。AI 在 10GB 的 monorepo 上會消化不良，就像我們其他人一樣。
- 它忽略你的 PR 模板：確認模板位於 .github/pull_request_template.md 中或連結在你的 repo 設定中。
何時使用哪個路徑
- 如果你想要一種輕量級的方式來從 issue 或評論自動產生 PR，並且所有事情都發生在 GitHub 中，請使用 GitHub Actions。
- 如果你希望 Claude 在你的本地環境中或跨多個工具以非常特定的控制方式運作，請使用 MCP。
值得注意的是：如果你想要對 workflow 進行快速的健全性檢查，或產生一個可靠的入門提示，Sider.AI 可以幫助你起草 PR 模板和防護提示，然後使用真實的 repo 片段對它們進行迭代。這就像擁有一個有主見的編輯，他實際上會編寫程式碼。而且不會偷你的辦公桌椅。 你想要複製的常見模式
- AI PR 標籤和 CODEOWNERS：將 ai/* PR 路由到一個喜歡與機器人爭論的審查組。
- 逐步提交：要求 Claude 建立小的、原子性的 commit，並帶有清晰的訊息，而不是一個名為「stuff」的 mega-commit。
- Test-first 模式：讓 workflow 首先產生測試，執行 CI，然後產生實現。它比較慢。但它更好。
- 合併後的事務：新增一個 workflow 以自動開啟一個後續 issue，用於文件、功能標記或清理。
快速的競爭性評估
- 有些人正在將其他 LLM 連接到類似的 GitHub 流程。它們可以工作——但 Claude Code 的程式碼推理和願意說「我不確定」的能力可以為你節省數小時的猜測和檢查。GitHub Actions 整合使其保持在自然發生審查的位置，並且 MCP 路線對於高階使用者來說非常靈活。
10 分鐘設定檢查清單
- 選擇一個路徑：GitHub Actions（更快）或 MCP（更多控制）。
- 建立一個嚴格的上下文構建器：檔案清單、限制和規則。
- 首先在一個小的變更上進行測試。合併。慶祝。告訴你的 PM 你「擴大了吞吐量」。
方便使用的快速參考
- Claude Code GitHub Actions 文件（模式、觸發器、範例）。
- GitHub MCP 伺服器，用於細化的、授權的存取。
Stern 的總結
使用 Claude Code 自動化 PR 不會取代你的工程團隊。它將取代你的工程團隊最不喜歡的雜務。從嚴格的範圍、清晰的提示和嚴格的審查開始。讓機器人處理腳手架，而你處理思考。然後回到有趣的事情——比如最終刪除你一直避免的 utils2.ts 檔案，因為你知道它正在用膠帶和夢想將應用程式固定在一起。
現在就讓你的未來自己少一些抱怨。如果機器人失控了？你知道 Revert 按鈕在哪裡。
常見問題
Q1：Claude Code 可以自行開啟 pull request 嗎？
是的。透過 GitHub Actions 或 MCP 設定，Claude Code 可以建立一個分支、推送變更，並開啟一個帶有摘要和檢查清單的 pull request。保持權限嚴格，並要求人工審查，這樣它就不會透過移除安全性來「最佳化」你的安全性。
Q2：將 GitHub 連接到 Claude Code 最安全的方法是什麼？
使用最小範圍的 token、repository 允許清單和分支保護。無論你選擇 Actions 還是 MCP，都要啟用試執行，並要求在合併任何 AI 產生的 pull request 之前通過測試。
Q3：如何阻止 AI PR 觸摸我的整個 monorepo？
使用允許清單目錄和檔案 manifest 來限制上下文範圍，並限制每次執行的檔案數量。好的提示也有幫助——具體說明路徑和大小限制。
Q4：為什麼我的 AI pull request 是空的或品質很低？
你的上下文構建器可能正在向 Claude 提供錯誤的檔案或過少的細節。提供明確的目標、約束和測試期望——並考慮使用兩階段流程：首先產生測試，然後產生實現。
Q5：我應該對 Claude Code 使用 GitHub Actions 還是 MCP？
如果你想要快速、repo 原生的 PR 和審查自動化，請使用 GitHub Actions。如果你需要本地控制、自訂工具或精細的權限，MCP 會為你提供更多功能——但需要更多的設定。
