用 OpenClaw 自動化 GitHub PR 程式碼審查
手把手教你用 OpenClaw 建置 AI 驅動的 PR 自動審查流程:GitHub 整合、PR Reviewer 程式碼分析、Conventional Commits 規範化提交,提升團隊程式碼審查效率。
最後更新: 2026-03-31
所需 Skills
你將建置什麼
一條完整的 PR 自動審查流水線:
- 自動建立 PR — 根據 commit 歷史,AI 產生規範的 PR 描述
- AI 程式碼審查 — 自動分析程式碼,發現 bug、安全漏洞和風格問題
- 提交規範化 — 強制使用 Conventional Commits 格式
- 可操作的回饋 — 直接在 PR 中留下行內審查評論
建置完成後,每次開 PR 都會自動觸發 AI 審查,無需人工介入。
為什麼需要 AI 輔助程式碼審查
人工程式碼審查不可或缺,但在實際執行中存在明顯瓶頸:
- 審查品質不穩定 — 不同審查者關注點不同,有人看命名規範,有人看錯誤處理。哪些問題能被發現,取決於「今天誰來審」
- 審查疲勞 — 看完幾百行程式碼後注意力明顯下降。研究顯示持續審查超過 60 分鐘後,效率大幅降低,關鍵 bug 往往藏在大段 diff 的末尾
- 等待時間長 — 審查者有自己的開發任務,一個 PR 可能等幾個小時甚至幾天。這會阻塞提交者,催生「攢一堆再提」的大 PR,引發合併衝突
- 擴展性差 — 團隊越大,審查瓶頸越嚴重。資深開發者越來越多時間花在審查上,新成員又可能不夠熟悉程式碼庫
AI 審查不是要取代人工審查,而是處理那些系統性檢查(安全模式、常見 bug、風格問題),讓人工審查者集中精力在架構設計、業務邏輯上。可以理解為——在人看之前,先過一遍底線品質關。
前置條件
開始之前,確保你已經:
- OpenClaw 已安裝並設定好(快速上手指南)
- GitHub CLI(
gh)已安裝並完成認證(gh auth login) - 一個 GitHub 儲存庫 用於測試(個人專案即可)
- Node.js 18+
第 1 步:安裝所需 Skills
按順序安裝三個 Skill:
# 1. GitHub 整合(基礎能力) npx clawhub@latest install github # 2. PR Reviewer(程式碼分析) npx clawhub@latest install pr-reviewer # 3. Conventional Commits(提交格式化) npx clawhub@latest install conventional-commits
驗證安裝:
clawhub list
三個 Skill 都應顯示為 installed。
第 2 步:設定 GitHub 認證
GitHub Skill 需要一個具備以下權限的 Personal Access Token:
repo— 完整的儲存庫存取權限read:org— 讀取組織成員資訊(如果是組織儲存庫的話,可選)
如果你已經透過 gh auth login 完成認證,Skill 會自動使用現有憑證。否則:
# 查看目前認證狀態 gh auth status # 如需登入 gh auth login
第 3 步:設定 PR Reviewer
PR Reviewer Skill 開箱即用,但你可以自訂行為:
# 查看預設設定 clawhub inspect pr-reviewer
核心設定項:
- 審查深度:
quick(快速掃描)或thorough(深度分析) - 關注領域:安全、效能、風格、bug,或全選
- 自動評論:是否直接在 PR 上發布評論
第 4 步:建立第一個自動審查 PR
用一個真實 PR 來測試整個工作流:
4.1 建立功能分支
git checkout -b feature/test-ai-review
4.2 寫一些程式碼
在專案中修改一個檔案。為了測試效果,可以故意引入一些常見問題,看審查器能否捕獲:
非同步呼叫缺少 await(非同步 bug):
// Bug:非同步呼叫缺少 await
function getUserData(userId) {
const response = fetch(`/api/users/${userId}`); // 缺少 await
return response.json(); // TypeError: response.json is not a function
}
SQL 注入漏洞:
# 安全問題:使用者輸入直接拼接到 SQL 查詢中
def get_user(user_id):
query = f"SELECT * FROM users WHERE id = '{user_id}'" # SQL 注入風險
return db.execute(query)
硬編碼金鑰:
// 安全問題:API 金鑰直接暴露在原始碼中
const stripe = require('stripe')('sk_live_abc123secretkey');
N+1 查詢問題:
# 效能問題:N+1 查詢——每筆訂單都觸發一次資料庫查詢
def get_orders_with_items(user_id):
orders = Order.objects.filter(user_id=user_id)
for order in orders:
order.items = OrderItem.objects.filter(order_id=order.id) # N+1!
return orders
4.3 使用 Conventional Commits 提交
不用手寫提交訊息,讓 OpenClaw 幫你產生:
git add . # OpenClaw 自動產生符合 Conventional Commits 規範的提交訊息 # 例如 "feat(api): add getUserData function for user data retrieval"
4.4 建立並審查 PR
# OpenClaw 自動建立 PR 並產生 AI 描述 # PR Reviewer 隨後自動分析 diff
幾秒鐘內,你會看到:
- 一份格式規範的 PR 描述,自動總結了你的變更
- 針對具體程式碼行的審查評論
- 一條總結評論,包含整體評估和改進建議
審查評論範例:
🔒 安全問題 (第 14 行, auth.py):
使用者輸入直接拼接到 SQL 查詢字串中,
存在 SQL 注入攻擊風險。
建議修復:使用參數化查詢。
- query = f"SELECT * FROM users WHERE id = '{user_id}'"
+ query = "SELECT * FROM users WHERE id = %s"
+ return db.execute(query, (user_id,))
⚡ 效能問題 (第 8 行, orders.py):
偵測到 N+1 查詢——OrderItem.objects.filter() 在迴圈內
對每筆 order 呼叫一次。請使用 select_related() 或
prefetch_related() 將其合併為一次查詢。
- orders = Order.objects.filter(user_id=user_id)
+ orders = Order.objects.filter(user_id=user_id).prefetch_related('items')
🐛 Bug (第 3 行, api.js):
fetch() 回傳 Promise 但未使用 await。
response.json() 會失敗,因為 response 是一個
pending 的 Promise,而不是 Response 物件。
- const response = fetch(`/api/users/${userId}`);
+ const response = await fetch(`/api/users/${userId}`);
第 5 步:自訂審查工作流
安全優先審查
對安全敏感的儲存庫,可以讓 PR Reviewer 重點檢查安全問題:
- SQL 注入模式
- 硬編碼的憑證或 API 金鑰
- 不安全的資料處理(未驗證的輸入、缺少過濾)
- 相依套件漏洞
- 前端程式碼中的 XSS 漏洞
- 不安全的反序列化模式
效能導向審查
對效能敏感的服務,讓審查器聚焦效能模式。比如在 React 專案中,審查器可以捕獲不必要的重新渲染:
// 效能問題:每次渲染都建立新的物件參考,導致子元件重新渲染
function ParentComponent({ items }) {
return (
<ChildComponent
style={{ margin: 10 }} // 每次渲染都是新物件
onClick={() => doSomething()} // 每次渲染都是新函式
/>
);
}
團隊級設定
在團隊中共享審查設定:
- 將 Skill 設定匯出到儲存庫中的
.openclaw/目錄 - 提交到程式碼儲存庫
- 團隊成員使用相同設定安裝——Skill 會自動讀取專案級設定
進階:引導審查重點
你可以透過自然語言指令來調整 PR Reviewer 的審查方向。
按語言定制
執行審查時,告訴 Agent 重點關注什麼:
- Python:檢查裸
except:區塊、缺少型別註解、Django ORM N+1 查詢 - JavaScript/TypeScript:標記遺留的
console.log、非同步呼叫缺少await、硬編碼金鑰 - Rust:標記正式環境程式碼中的
.unwrap(),建議使用正確的Result處理
按目錄定制
對不同目錄設定不同審查等級:
- 核心業務邏輯(
src/core/)— 全面審查,涵蓋安全、bug 和效能 - 測試檔案(
src/tests/)— 快速檢查正確性 - 文件(
docs/)— 輕量級風格審查 - 指令碼(
scripts/)— 聚焦安全和 bug
自訂規則
讓審查器標記專案特定的反模式,例如:
- API 路由中直接存取資料庫而沒有走 Repository 層
- 頁面元件缺少 Error Boundary
- API 端點沒有限流
整合到 CI/CD
要實現每個 PR 都自動審查,可以將 PR Reviewer 整合到 CI/CD 流水線中。
GitHub Actions
在 .github/workflows/ai-review.yml 建立工作流檔案:
name: AI PR Review
on:
pull_request:
types: [opened, synchronize]
jobs:
ai-review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install OpenClaw and skills
run: |
npm install -g clawhub@latest
clawhub install pr-reviewer
- name: Run AI Review
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
OPENCLAW_API_KEY: ${{ secrets.OPENCLAW_API_KEY }}
run: |
clawhub run pr-reviewer \
--pr ${{ github.event.pull_request.number }} \
--repo ${{ github.repository }} \
--auto-comment
控制審查觸發條件
限定 AI 審查只在特定條件下執行,節省成本:
on:
pull_request:
types: [opened, synchronize]
paths-ignore:
- '*.md'
- 'docs/**'
- '.github/**'
或者要求加上標籤後才觸發審查:
- name: Check for review label
if: contains(github.event.pull_request.labels.*.name, 'ai-review')
run: clawhub run pr-reviewer --pr ${{ github.event.pull_request.number }}
其他 CI 平台
同樣的方式適用於任何支援 Node.js 的 CI 平台。核心步驟:
- 安裝
clawhub和pr-reviewerSkill - 將
OPENCLAW_API_KEY設為環境變數 - 傳入 PR 編號和儲存庫資訊
- 確保 CI Bot 對 Pull Request 有寫入權限
實際效果
使用這套工作流的團隊通常會看到:
- PR 處理速度提升 40% — AI 先處理明顯問題,減少人工審查壓力
- 審查品質穩定 — 每個 PR 都經過相同標準的分析
- 提交歷史更規範 — Conventional Commits 讓變更日誌自動化
- 正式環境 bug 更少 — AI 能捕獲人工容易忽略的問題
常見問題排查
"GitHub CLI not found"
確保 gh 已安裝並在 PATH 中:
# macOS brew install gh # Linux sudo apt install gh # Windows winget install GitHub.cli
PR 建立時提示"Permission denied"
檢查 Token 權限:
gh auth status
確認包含 repo 權限。如有需要,重新認證:
gh auth login --scopes repo
PR Reviewer 沒有評論
檢查 Skill 安裝和設定:
clawhub inspect pr-reviewer
確認你的 OpenClaw AI 供應商已設定且有可用額度。
常見問題
支援。GitHub Skill 基於 `gh` CLI,完全相容 GitHub Enterprise Server 和 GitHub Enterprise Cloud。只需透過 `gh auth login --hostname github.yourcompany.com` 設定企業網域。認證完成後,所有 GitHub 相關的 Skill(包括 PR Reviewer)的使用方式與 github.com 完全一致,無需額外設定。
GitHub Skill 是 GitHub 專用的,但 PR Reviewer 和 Conventional Commits 可以搭配任何 Git 平台使用。GitLab 使用者可以安裝 GitLab Skill,傳入 Merge Request ID 替代 PR 編號。Bitbucket 同理。核心審查邏輯與平台無關,只有發布評論的整合層因平台而異。
AI 審查是人工審查的補充,而非替代。它擅長系統性檢查——捕獲安全漏洞、常見 bug 模式、風格違規和效能反模式,而且不會疲勞、不會遺漏。但它無法評估高層架構決策、業務邏輯正確性,或判斷整體方案是否合理。最佳實踐是讓 AI 做第一輪掃描,處理機械性檢查,讓人工審查者專注於設計和意圖。
費用取決於你使用的 AI 供應商和被審查的 diff 大小。一個典型的 PR 審查(分析約 500 行 diff)在大多數供應商上的費用約 $0.01-0.05。更大的 diff(1000+ 行)可能在 $0.10-0.15 左右。你可以透過對非關鍵路徑設定 `quick` 審查深度,以及用路徑篩選器跳過自動產生的檔案、vendor 目錄和文件來控制成本。
可以。PR Reviewer 支援靈活的檔案模式設定。你可以按 glob 模式排除檔案(如 `**/*.generated.ts`、`vendor/**`),限制只審查特定目錄,或對不同路徑設定不同審查深度。在 `.openclaw/pr-reviewer.yml` 中設定即可。大多數團隊會排除自動產生的檔案、lock 檔案和 vendor 相依套件,讓審查聚焦在團隊實際撰寫的程式碼上。
PR Reviewer 會將大 diff 拆分成邏輯區塊分別分析。對於超過 1000 行的 PR,會優先審查高風險檔案——涉及認證、資料庫查詢、API 端點和安全敏感邏輯的檔案會以最大深度審查,測試和設定變更則用輕量級審查。你也可以設定一個行數門檻,超過時自動提醒作者將 PR 拆分成更小的可審查單元。
支援所有主流程式語言,包括 JavaScript、TypeScript、Python、Go、Rust、Java、C#、Ruby、PHP 等。審查器自動套用語言特定的規則——比如在 Rust 中檢查 `unwrap()` 誤用,在 JavaScript 非同步程式碼中檢查缺少的 `await`。你也可以在設定檔中為每種語言定義自訂規則。審查器根據副檔名偵測語言,無需手動設定。
AI 審查和 Linter 解決的問題互補,可以很好地搭配。Linter 強制執行確定性規則(格式、import 順序、未使用的變數),AI 審查捕獲語意層面的問題(邏輯 bug、安全模式、效能問題),這些是規則工具無法偵測的。在 CI 中,先跑 Linter 處理格式問題,再跑 AI 審查做深度分析。PR Reviewer 知道常見的 Linter 規則,會避免重複回饋相同問題。
OpenClaw 會追蹤儲存庫隨時間的審查指標。執行 `clawhub stats pr-reviewer` 可以查看按類別分類的問題統計、合併前解決了多少、以及程式碼庫中的常見模式。這有助於識別反覆出現的問題——比如 SQL 注入警告頻繁出現,說明需要加強團隊訓練或改進 ORM 抽象。你可以將指標匯出為 JSON 格式,整合到看板或團隊報告工具中。
可以。你可以定義審查範本,根據 PR 標籤、分支命名規範或變更檔案路徑套用不同規則。例如,`hotfix/*` 分支使用安全優先的最大深度審查,`docs/*` 分支僅做輕量風格檢查。在 `.openclaw/pr-reviewer.yml` 的 `templates` 欄位中定義範本,PR Reviewer 會根據條件自動匹配。這樣關鍵變更能得到充分審查,低風險更新不會被拖慢。