團隊協作與 CI/CD 整合

11.1　把 Claude 接進「自動管線」：GitHub Actions / GitLab CI

先用一張表，把這章會提到的五種團隊能力一次看完。每一種下面都會再細講，這裡只要對照「它大概在做什麼、什麼情況用得上」即可。

想像團隊裡有一條「輸送帶」：每次有人把寫好的程式碼送上去，輸送帶就自動跑一連串檢查——有沒有壞掉、有沒有照規矩寫、要不要通知誰。工程師管這條輸送帶叫 CI/CD（持續整合 / 持續部署）。它的重點是「自動」：不用人盯著，code 一進來就跑。

而你可以把 Claude 接到這條輸送帶上。接好之後，每次團隊有人推 code，Claude 就會自動上工，幫忙做兩件事：一是自動審查程式碼（看看這次改動有沒有問題），二是自動分流待辦——也就是把湧進來的問題回報（issue）先分個類、貼個標籤、排個輕重緩急，工程師管這個動作叫 triage。

至於「接哪一條輸送帶」，看你團隊把程式碼放在哪個平台：放在 GitHub 就用 GitHub Actions；放在 GitLab 就用 GitLab CI。兩者概念一模一樣，只是設定檔放的位置和寫法略有不同。這部分通常由團隊裡熟悉該平台的人設定一次，設好之後全團隊自動受惠，你不用每次手動叫它。

下面是設定檔大概的樣子，給負責設定的人參考；新手看過知道「原來是貼一段設定」即可，不用照做。

GitHub Actions（放在 GitHub 的團隊）

# 放在你的 repo 裡 .github/workflows/claude.yml
# 這只是示意：實際設定請照 GitHub Actions 官方文件
name: Claude Code Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        # 需要在 repo 設定裡加上 API 金鑰等機密，細節見官方文件

實際要接的時候，官方給了兩條路。快速版：在自己電腦的終端機、專案資料夾裡對 Claude Code 打一句 /install-github-app，它會帶你走一輪互動式安裝——前提是你對這個 repo 要有管理員（admin）權限，不然它問不到需要的授權。這個指令背後做的事，是幫你裝上一個叫「Claude」的 GitHub App（會跟你要 Contents、Issues、Pull requests 三項的讀寫權限），再引導你把 workflow 檔案加進 repo、把 ANTHROPIC_API_KEY 存成 GitHub Secret。手動版：自己到 github.com/apps/claude 裝這個 App、自己去 repo 設定裡加 secret、再把官方範例的設定檔複製進 .github/workflows/ 資料夾，效果一樣，只是每一步自己按。兩條路殊途同歸，團隊裡負責設定的人挑順手的走就好。

另外值得一提：這個 Action 不是只吃 Anthropic 的 API 金鑰。企業使用者如果本來就把 AI 用量掛在 Amazon Bedrock、Google 的 Vertex AI 或 Microsoft Foundry 底下，也能把這條 CI 管線接去那邊算錢（第 20 章會給一張更完整的官方現成配方清單）。走 Bedrock 那條路時有個聰明作法：用 GitHub 內建的OIDC 機制，讓 workflow 執行當下才跟 AWS「借」一個有時效的臨時身分，事情辦完身分就失效——比把一組長期有效的 AWS 金鑰貼進 GitHub Secrets 安全得多。這幾種企業後端要不要接、怎麼接，是團隊裡管基礎建設的人才需要煩惱的事，一般成員完全不用碰。順帶一提，同一個 prompt 欄位不只能拿來做審查，也能拿來呼叫團隊自己寫的 Skill（第 8 章教過怎麼做）或裝好的 plugin，把日常在用的自訂流程原封不動搬進 CI——這跟接下來 11.2 要講的官方 Code Review 服務是兩回事：Code Review 是裝好就自動生效的固定服務，這裡則是你自己接 workflow、自己決定要跑什麼，彈性換來的是要自己維護那份設定檔。

GitLab CI（放在 GitLab 的團隊，目前為 beta）

GitLab 這條路的整合方式不太一樣：它不是裝一個現成的 App，而是在 CI job 裡用一行指令把 Claude Code 本身裝進那台跑 job 的機器，裝完就能呼叫。提醒一次：這項整合目前是 beta（測試中），而且是由 GitLab 官方（不是 Anthropic）在維護，寫法還在調整，正式導入前務必先看一眼官方當下的 GitLab CI/CD 文件。

最小可動的設定大致長這樣，給負責架設的人參考：

# .gitlab-ci.yml：先在 GitLab 的 CI/CD Variables 裡加一個遮罩過的 ANTHROPIC_API_KEY
stages:
  - ai

claude:
  stage: ai
  image: node:24-alpine3.21
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  before_script:
    # 一行指令把 Claude Code 裝進這台 runner
    - apk add --no-cache git curl bash
    - curl -fsSL https://claude.ai/install.sh | bash
  script:
    - >
      claude -p "審查這個 MR 並依需求動手改"
      --permission-mode acceptEdits
      --allowedTools "Bash Read Edit Write mcp__gitlab"

留意這裡的 --permission-mode acceptEdits：CI 裡沒有人可以在旁邊按「允許」，所以得先講好一個權限基準，讓它自動接受編輯檔案這類常見動作；--allowedTools 則把它這次能用的工具鎖死在清單內。兩者搭配著用，才不會變成一個「什麼都能做」卻沒人看管的帳號。

接管線時最容易踩的三個坑

下面這三個，是團隊實際接上這類自動化之後，出過事、也被資安研究者點名過的常見疏漏。就算設定這條管線的不是你，看過知道「有這幾種雷」，之後在別的地方聽到類似狀況，至少聽得懂在講什麼。

11.2　每個 PR 都自動被審一遍（Code Review）

團隊一起寫程式時，有個重要的習慣：誰改了東西、想併進主線之前，會先發一個「請大家檢查我的修改」的請求，這個請求叫 Pull Request（簡稱 PR）；大家檢查、留意見的這個動作，就叫 PR review（程式碼審查）。這是團隊維持品質的關鍵一關——但也很耗資深工程師的時間，每一筆都要人看。

把 Claude 接進來之後，每一個 PR 都會自動先得到一份 Claude 的審查意見：哪裡可能有 bug、哪裡寫法可以更好、有沒有漏掉什麼。它不會取代人的最終決定，但它像一個不會累、不會漏、隨時線上的「第一道審查」，先把明顯的問題挑出來，讓資深工程師把精力留給真正需要判斷的地方。

兩者不是互相取代，而是接力：Claude 先把基本面掃一遍，人再專心看「值不值得、對不對方向」這種需要判斷的事。

對團隊長期維持程式品質很有幫助，尤其人多、PR 多的時候，差別最明顯。這同樣是設定一次、之後每個 PR 自動生效的能力——設好之後，連你自己發的 PR 也會自動被它看一遍。

看懂它標的三種嚴重度

這套自動審查在 Anthropic 那邊有個正式名字，就叫 Code Review，目前是研究預覽階段的官方代管服務（僅 Team／Enterprise 方案才有；組織如果開了 Zero Data Retention 這類更嚴格的資料保留政策，這項服務也用不了）。運作原理是背後同時派出好幾個 agent 平行分析這次改動的 diff，還會連帶看改動周邊的上下文程式碼——不是只盯著改了哪幾行，也會看這幾行放進整個檔案、整個模組之後合不合理。找到的每一個問題，都會標上一個嚴重度：

有一件事新手很容易誤會，特別點出來：這個審查的 check run 永遠回報「neutral（中立）」的結論——它預設不會擋你合併 PR，就算標出一堆 🔴 Important 問題也一樣。它的定位是「先幫你看一遍、留意見」，最後按不按合併鍵，還是人來決定。想把它變成「有 Important 問題就不准合併」的硬性關卡，得自己額外設定，後面會講怎麼做。

用 REVIEW.md 校準審查標準，跟 CLAUDE.md 是兩回事

每個團隊對「這算不算嚴重問題」的標準不一樣。如果覺得預設的審查尺度不合團隊胃口，可以在 repo 根目錄放一個 REVIEW.md 檔案，專門調校審查行為。它的內容會逐字塞進每個審查 agent 的系統提示、優先權最高，而且不會展開裡面的 @import 引用（單純當一段文字貼上去）。可以拿它做這些事：

• 重新定義「什麼程度才算 Important」（例如：只有真的會影響行為、洩漏資料、或擋住回滾的才算）
• 限制一次最多回報幾條 Nit，別讓一份 PR 被瑣碎意見洗版
• 列出完全不用審查的路徑或檔案類型（自動產生的程式碼、lockfile 之類）
• 加團隊自己在意的自訂檢查規則

💡 範例：REVIEW.md 可以怎麼寫

# 審查標準
## 什麼才算 Important
只有真的會讓功能壞掉、洩漏資料、或讓人沒辦法回滾的問題，才標成 Important。

## Nit 數量上限
一次最多回報 5 條 Nit，別讓 PR 被瑣碎意見洗版。

## 不用審查
- CI 本來就會擋的：lint、格式、型別錯誤
- 自動產生的檔案（src/gen/ 底下）與所有 lockfile

觸發時機自己選，別讓留言洗版

預設情況下，Code Review 在每次 PR 開啟、以及之後每一次 push 都會重新跑一輪。如果團隊習慣小步快跑、一天推十幾次 commit，這個預設可能會讓討論串被洗成一長串留言。想要更節制，可以改成純手動——在留言裡喊一聲 @claude review 或 @claude review once 才觸發，主動權留在人手上。

不想裝 GitHub App、只是想自己在本機先看一眼這次改動有沒有問題，Claude Code 的終端機裡也有對應的一次性指令，不用先走完整條 CI 管線：

先只讀審查；確認問題與範圍後，才讓它修。執行 --fix 前先確認工作目錄乾淨或已有 commit，修完後檢視 diff 並跑既有檢查。

💡 本機一次性 diff 審查（不需要先裝 GitHub App）

# 先只讀審查目前的改動
/code-review

# 確認審查結果後，才允許它嘗試修正；完成後自行看 diff
/code-review ultra --fix

# 從 check run 的 Details 文字裡解析出嚴重度統計
gh api repos/OWNER/REPO/check-runs/ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

# 解析出來的物件有 normal（= Important 數）／nit／pre_existing 三個欄位
# 自己在 CI 腳本裡判斷 normal 是否為 0，決定要不要讓這一步失敗

11.3　在 Slack 報一個 bug，它還你一個修好的版本

前面兩節是「程式碼一進來，它自動審查」。這一節更進一步：連『報修』都能在聊天室裡完成。如果你的團隊用 Slack（一個常見的工作聊天工具），可以把 Claude 接進去，之後任何人——包括完全不會寫程式的同事——只要在 Slack 標記 @Claude 說一句「這個功能壞了」，它就會自己動起來。

它接到報修後，會走完一整套流程：先去調查問題出在哪，找到原因後動手修，修好把結果回傳給你，並附上「Create PR」按鈕——由你點一下，才會開出那個 PR（也就是 11.2 講的那種「請檢查我的修改」請求）送回團隊，等懂的人確認、按下合併。整個過程你只丟了一句話，加上最後點一下按鈕，剩下它包辦。

整個流程像這樣，一句話進、一個 PR 出：

1. 1

   有人在 Slack 報修

   任何同事在 Slack 標記 @Claude，用一句白話描述問題，例如「結帳頁面的按鈕按不動」。不需要懂程式，講得出「哪裡怪怪的」就行。

2. 2

   Claude 自己去調查

   它接到訊息後，會去翻相關的程式碼、追問題的源頭，搞清楚到底是哪裡出了狀況。這一步以前都得工程師親自來。

3. 3

   Claude 動手修好

   找到原因後，它直接改程式碼把問題修掉，就像一位工程師坐下來把 bug 解決。

4. 4

   回傳結果，你點「Create PR」才開 PR

   修好的版本它會回傳給你，附上「Create PR」之類的按鈕；由你點下去，才會把這份「請檢查我的修改」的 PR 建立、送回團隊。懂的人看過、確認沒問題，按下合併，這個 bug 就正式修掉了。

11.4　用 Chrome 幫你抓「線上網頁」的 bug

前面講的都是「程式碼層面」的協作。最後這個能力不太一樣：Claude in Chrome 能讓 Claude 實際操作 Chrome 瀏覽器——像真人一樣開網頁、點按鈕、填表單、捲動畫面，親眼「看」網頁的反應。

這有什麼用？有些網頁的問題，光看程式碼看不出來，非得實際操作一遍、看到畫面當下的反應才抓得到。比方說「點這個按鈕後畫面卡住」「在某個步驟才會跳錯」這類，得真的走一遍流程才重現得了。讓 Claude 直接用瀏覽器跑一次，它就能在現場觀察、找出問題在哪。

所以這個能力特別適合前端問題，或那種「要看到實際互動才能重現」的 bug。它把「人坐在電腦前一步步試、找問題」這件事，也交給 Claude 來做。

11.5　自動化雖好，這幾件真實出過的事故值得知道

前面幾節都在講「把 Claude 接進團隊流程之後能做什麼」。這一節換個角度：當你讓它自動讀 issue、PR 留言這類「任何人都能打字進去」的內容，還讓它有權限自己動手改 code、開 PR，等於也幫這些外部輸入開了一道通往你程式碼庫的門。資安研究者已經實際挖出幾起真實案例，不是紙上談兵的假設風險，看過會讓你對「權限給多少」更有感。

資安公司 Check Point 揭露過三個跟這類「協作自動化」直接相關的漏洞，全都已經修復，整理如下：

三起的共同點值得記住：問題都不是出在「Claude 本身判斷錯誤」，而是出在「別人提供的專案設定檔」被當成可信任的東西直接吃下去。你 clone 一個不熟的 repo，那個 repo 帶的 .claude/ 設定就跟著一起進來——這跟你會不會提防一個陌生人給你的隨身碟裝進自己電腦，是同一種戒心。

這則案例的教訓，跟第 20 章教的「把自主 agent 的權限收到最小」是同一個方向，只是這裡換成一個真實發生過的具體場景：只要 Claude 會自動讀「任何人都能寫進去」的文字（issue、PR 留言），就要假設那段文字有可能被拿來惡意誘導，而不是只把它當成單純的問題描述。團隊裡負責接這些自動化的人，權限給得越窄、讓它能碰到的機密越少，就算真的中招，能造成的傷害也越小。這部分完整的收緊做法，第 20 章「安全硬化」那一節有更完整的四面收窄框架，這裡先讓你知道：這不是危言聳聽，是真的出過事。