CI 與 AI 自動審查

前兩堂你學會了讓好幾個 Agent 在各自的工作區平行開發。現在換一個新的煩惱：它們一起交出成果時，誰來檢查？

一份一份切換資料夾、手動跑測試、逐行讀修改，很快就會讓你變成整個流程最慢的一環。這堂課要請兩位幫手來分擔：一位是自動跑測試的機器人，一位是會讀程式、留下建議的 AI 審查員。

三道關卡的分工

先看全貌，再一個一個設定：

測試守門、AI 提醒、你做決定。三者的角色不能互換。

CI：每次推送都自動檢查

CI（Continuous Integration，持續整合）的意思是：每次有人推送程式碼，就自動在一台乾淨的電腦上把專案裝起來、跑一遍檢查。

為什麼要「乾淨的電腦」？因為「在我的電腦上可以跑」是最常見的陷阱。也許你裝過某個套件但忘了寫進 requirements.txt，也許 Agent 改了一個只有你電腦上才有的設定。CI 每次都從零開始，這些問題無所遁形。

GitHub 內建的 CI 服務叫 GitHub Actions。你只要在專案裡放一個設定檔，GitHub 就會照著做。

寫第一個 workflow

在專案裡建立 .github/workflows/tests.yml：

name: tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v6
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest

YAML 用縮排表示層級，縮排錯了檔案就讀不懂，這是最常見的錯誤。

幾個重點：

• uses 是使用別人寫好的步驟，例如 actions/checkout 負責下載你的程式碼。@v6 是版本，各步驟的最新版本請以它們的官方頁面為準。
• run 是執行一行指令，就和你在終端機打的一樣。
• requirements.txt 要列出所有套件，包含 pytest。CI 的電腦上什麼都沒裝。

把這個檔案 commit 並推上 GitHub，到專案頁面的 Actions 分頁，就能看到它在跑。之後每個 Pull Request 下方都會出現一個綠色勾勾或紅色叉叉。

讓測試成為真正的守門員

光是跑測試還不夠，要讓「沒通過就不能合併」。在 GitHub 專案的設定裡，可以替 main 分支加上保護規則，把 tests 設成合併前必須通過的檢查（required status check）。設定的位置可能隨 GitHub 改版移動，可以搜尋 GitHub 官方文件中的 branch protection 或 rulesets。

這樣一來，不管是你還是 Agent，只要測試沒過，合併按鈕就是灰的。還記得「讓 Agent 寫測試、跑測試」那堂課嗎？你當時寫下的每一個測試，現在都變成了自動執行的守衛。

測試失敗時

紅色叉叉出現時，點進去就能看到失敗的步驟和紀錄。你也可以直接請 Agent 處理：

（gh 是 GitHub 的命令列工具，需要先安裝並登入。）

AI 審查：多一雙眼睛

測試只能檢查你想到要測的事。程式碼裡還有很多測試抓不到的問題：命名讓人看不懂、某個邊界情況沒處理、不小心把金鑰印進記錄檔。這正是 AI 審查擅長的地方。

Claude Code 提供 GitHub Actions 的整合。最簡單的設定方式，是在專案資料夾裡開啟 Claude Code，執行：

/install-github-app

照著提示走，它會幫你安裝 Claude 的 GitHub App、把金鑰存成專案的 Secret，並準備好 workflow 檔案的 Pull Request。你需要是這個 GitHub 專案的管理員，電腦上也要先裝好並登入 gh。

設定完成後，你可以在任何 Pull Request 或 Issue 的留言裡呼叫它：

@claude 請審查這個 Pull Request，特別注意金額計算和錯誤處理，有問題請在對應的程式行留言。

設定時也可以選擇加入自動審查的 workflow，讓每個新的 Pull Request 都自動被審查一次。實際可選的項目和產生的檔案內容可能隨版本更新，請以 Claude Code 官方文件中關於 GitHub Actions 的說明為準。

其他選擇：GitHub Copilot 也有 Pull Request 審查功能，市面上還有許多 AI 審查服務。概念都一樣：讀修改內容，留下建議。

幫手，不是關卡

這是這堂課最重要的一段。

AI 審查很有用，但它有三個特性，讓它不適合當作必須通過的關卡：

• 它會漏看：沒留言不代表沒問題。它可能專注在某個地方，就忽略了另一個地方。
• 它會誤判：有時候它指出的「問題」其實不是問題，或者是你們團隊刻意的寫法。
• 它不一定每次都一樣：同一份修改審查兩次，留言可能不同。

相比之下，測試每次的結果都一樣，過就是過、沒過就是沒過，這才是守門員該有的特性。

一個好習慣：當 AI 審查抓到一個真正的 bug，除了修好它，再補一個測試。這樣同樣的錯誤下次就會被守門員擋下，不必再靠運氣。

安全與費用

• 金鑰只放在 GitHub Secrets：在 workflow 裡用 secrets.ANTHROPIC_API_KEY 這樣的方式引用，絕對不要把金鑰寫進檔案。/install-github-app 會幫你設定好。
• 權限給最少：workflow 只開它需要的權限，AI 審查不需要能推送程式碼的話，就不要給。
• 兩種費用：GitHub Actions 依執行時間計算時數，私人專案有免費額度上限；AI 審查每次都會用掉 token。可以限制 Agent 最多跑幾輪、只在需要時用 @claude 呼叫，而不是每次推送都審查。最後一堂課會更完整地談成本。