OpenClaw
應用場景入門10 min

用 OpenClaw 自動化 GitHub PR 程式碼審查

手把手教你用 OpenClaw 建置 AI 驅動的 PR 自動審查流程:GitHub 整合、PR Reviewer 程式碼分析、Conventional Commits 規範化提交,提升團隊程式碼審查效率。

最後更新: 2026-03-31

所需 Skills

GitHub (gh)
推薦

透過 gh CLI 操作 GitHub(Issue/PR/倉庫等)。

查看指南
PR Reviewer
推薦

自動化的 Pull Request 程式碼審查。

查看指南
Conventional Commits
推薦

產生/驗證 Conventional Commits 提交訊息。

查看指南

你將建置什麼

一條完整的 PR 自動審查流水線:

  1. 自動建立 PR — 根據 commit 歷史,AI 產生規範的 PR 描述
  2. AI 程式碼審查 — 自動分析程式碼,發現 bug、安全漏洞和風格問題
  3. 提交規範化 — 強制使用 Conventional Commits 格式
  4. 可操作的回饋 — 直接在 PR 中留下行內審查評論

建置完成後,每次開 PR 都會自動觸發 AI 審查,無需人工介入。

為什麼需要 AI 輔助程式碼審查

人工程式碼審查不可或缺,但在實際執行中存在明顯瓶頸:

  • 審查品質不穩定 — 不同審查者關注點不同,有人看命名規範,有人看錯誤處理。哪些問題能被發現,取決於「今天誰來審」
  • 審查疲勞 — 看完幾百行程式碼後注意力明顯下降。研究顯示持續審查超過 60 分鐘後,效率大幅降低,關鍵 bug 往往藏在大段 diff 的末尾
  • 等待時間長 — 審查者有自己的開發任務,一個 PR 可能等幾個小時甚至幾天。這會阻塞提交者,催生「攢一堆再提」的大 PR,引發合併衝突
  • 擴展性差 — 團隊越大,審查瓶頸越嚴重。資深開發者越來越多時間花在審查上,新成員又可能不夠熟悉程式碼庫

AI 審查不是要取代人工審查,而是處理那些系統性檢查(安全模式、常見 bug、風格問題),讓人工審查者集中精力在架構設計、業務邏輯上。可以理解為——在人看之前,先過一遍底線品質關。

前置條件

開始之前,確保你已經:

  • OpenClaw 已安裝並設定好(快速上手指南
  • GitHub CLIgh)已安裝並完成認證(gh auth login
  • 一個 GitHub 儲存庫 用於測試(個人專案即可)
  • Node.js 18+

第 1 步:安裝所需 Skills

按順序安裝三個 Skill:

bash
# 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

驗證安裝:

bash
clawhub list

三個 Skill 都應顯示為 installed

第 2 步:設定 GitHub 認證

GitHub Skill 需要一個具備以下權限的 Personal Access Token:

  • repo — 完整的儲存庫存取權限
  • read:org — 讀取組織成員資訊(如果是組織儲存庫的話,可選)

如果你已經透過 gh auth login 完成認證,Skill 會自動使用現有憑證。否則:

bash
# 查看目前認證狀態
gh auth status

# 如需登入
gh auth login

第 3 步:設定 PR Reviewer

PR Reviewer Skill 開箱即用,但你可以自訂行為:

bash
# 查看預設設定
clawhub inspect pr-reviewer

核心設定項:

  • 審查深度quick(快速掃描)或 thorough(深度分析)
  • 關注領域:安全、效能、風格、bug,或全選
  • 自動評論:是否直接在 PR 上發布評論

第 4 步:建立第一個自動審查 PR

用一個真實 PR 來測試整個工作流:

4.1 建立功能分支

bash
git checkout -b feature/test-ai-review

4.2 寫一些程式碼

在專案中修改一個檔案。為了測試效果,可以故意引入一些常見問題,看審查器能否捕獲:

非同步呼叫缺少 await(非同步 bug):

javascript
// Bug:非同步呼叫缺少 await
function getUserData(userId) {
  const response = fetch(`/api/users/${userId}`);  // 缺少 await
  return response.json();  // TypeError: response.json is not a function
}

SQL 注入漏洞:

python
# 安全問題:使用者輸入直接拼接到 SQL 查詢中
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = '{user_id}'"  # SQL 注入風險
    return db.execute(query)

硬編碼金鑰:

javascript
// 安全問題:API 金鑰直接暴露在原始碼中
const stripe = require('stripe')('sk_live_abc123secretkey');

N+1 查詢問題:

python
# 效能問題: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 幫你產生:

bash
git add .
# OpenClaw 自動產生符合 Conventional Commits 規範的提交訊息
# 例如 "feat(api): add getUserData function for user data retrieval"

4.4 建立並審查 PR

bash
# 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 專案中,審查器可以捕獲不必要的重新渲染:

jsx
// 效能問題:每次渲染都建立新的物件參考,導致子元件重新渲染
function ParentComponent({ items }) {
  return (
    <ChildComponent
      style={{ margin: 10 }}        // 每次渲染都是新物件
      onClick={() => doSomething()}  // 每次渲染都是新函式
    />
  );
}

團隊級設定

在團隊中共享審查設定:

  1. 將 Skill 設定匯出到儲存庫中的 .openclaw/ 目錄
  2. 提交到程式碼儲存庫
  3. 團隊成員使用相同設定安裝——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 建立工作流檔案:

yaml
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 審查只在特定條件下執行,節省成本:

yaml
on:
  pull_request:
    types: [opened, synchronize]
    paths-ignore:
      - '*.md'
      - 'docs/**'
      - '.github/**'

或者要求加上標籤後才觸發審查:

yaml
- 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 平台。核心步驟:

  1. 安裝 clawhubpr-reviewer Skill
  2. OPENCLAW_API_KEY 設為環境變數
  3. 傳入 PR 編號和儲存庫資訊
  4. 確保 CI Bot 對 Pull Request 有寫入權限

實際效果

使用這套工作流的團隊通常會看到:

  • PR 處理速度提升 40% — AI 先處理明顯問題,減少人工審查壓力
  • 審查品質穩定 — 每個 PR 都經過相同標準的分析
  • 提交歷史更規範 — Conventional Commits 讓變更日誌自動化
  • 正式環境 bug 更少 — AI 能捕獲人工容易忽略的問題

常見問題排查

"GitHub CLI not found"

確保 gh 已安裝並在 PATH 中:

bash
# macOS
brew install gh

# Linux
sudo apt install gh

# Windows
winget install GitHub.cli

PR 建立時提示"Permission denied"

檢查 Token 權限:

bash
gh auth status

確認包含 repo 權限。如有需要,重新認證:

bash
gh auth login --scopes repo

PR Reviewer 沒有評論

檢查 Skill 安裝和設定:

bash
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 會根據條件自動匹配。這樣關鍵變更能得到充分審查,低風險更新不會被拖慢。

相關場景