Claude Academy
載入中

PR 審查循環中的 AI

第 10 課5 分鐘

Claude 既進行審查也接受審查。它會根據組織的政策審查傳入的 PR，並處理自己 PR 上的審查意見。這讓工程師能夠專注於 PR 審查中的行為判斷，而這最終歸結為判斷意圖與風險。

有何改變

傳統方式AI 原生
審查能力是根據人力產出來規劃的。PR 需要等待審查者閱讀全部內容，審查品質會隨審查者的負荷而變化，而作者則在待辦事項不斷累積時持續追蹤進度。所有 PR 都會經過一組相同的審查流程，發現的問題會依嚴重程度排序。人類的注意力則提升到更高層次，關注變更是否達成計畫的預期目標，以及風險是否可接受。

開始使用

  • 先決條件：來自第 3 階段：建置的更新版 CLAUDE.md 檔案、技能（如果審查流程要強制執行書面政策的話），以及已定義的子代理。
  • 基礎設施：已安裝 Claude 整合的儲存庫，可以是由您的 Claude 組織擁有者啟用的受管理 Code Review 服務，或是在您自己的 CI 中執行的 claude-code-action，並視需要透過 Amazon Bedrock、Google Cloud 的 Vertex AI 或 Microsoft Foundry 進行模型呼叫（CI/CD 實踐涵蓋了部署選項）。要求程式碼擁有者核准的分支保護政策也是值得採用的。

如何執行

  1. 受管理的 Code Review 服務是最快的起點。您的 Claude 組織擁有者可以啟用它並選擇儲存庫。當您需要控制管線，或希望 API 呼叫透過您自己的雲端協議路由時，可以使用 claude-code-action 在您自己的 CI 中執行審查（CI/CD 實踐涵蓋了這方面的配置）。
  2. 技術主管會在儲存庫根目錄撰寫審查政策，命名為 REVIEW.md，並依組織關心的審查流程分類：錯誤與邏輯錯誤；安全性與漏洞；依規格（來自需求實踐的 spec.md）、實作計畫（來自計畫模式實踐的 plan.md）以及設計原則進行合規性檢查。REVIEW.md 也定義了何謂「重要（Important）」，以區別於「小問題（Nit）」，以及哪些項目應該略過。
  3. 技術主管會設定人工審核的門檻。發現的問題本身不會核准或阻擋 PR，分支保護仍然需要程式碼擁有者的核准。如果平台工程師想根據發現的問題來限制合併，可以讀取檢查執行所發布的嚴重程度計數，這些計數以機器可讀的方式呈現。
  4. 當審查者或作者在審查意見中標記 @claude 時，Claude 會處理該意見並推送修正。PR 討論串會同時記錄請求與變更。這個修正循環是透過 claude-code-action 執行的。在受管理服務中，留言 @claude review 則會改為請求一次全新的審查。對於 Claude 開啟的 PR，可以更進一步，讓 Claude 全程照看該 PR 直到合併。團隊會將此循環包裝成自訂的斜線指令，掃描 PR 上尚未解決的審查意見與失敗的檢查，處理它們並推送修正，直到 PR 變為綠燈，只等待程式碼擁有者的核准。
  5. 審查發現的問題會回饋到 CLAUDE.md 中。當某個錯誤第二次被審查標記出來時，修正內容會作為該次審查的一部分寫入 CLAUDE.md，而由於審查會讀取 CLAUDE.md，從下一個 PR 開始就能捕捉到這個錯誤。審查也會標記出某項變更是否使 CLAUDE.md 過時。
  6. 技術主管每月會調整一次設定，方法是為發現的問題評分以改善審查者的表現，並在 REVIEW.md 中限制小問題（Nit）的數量。產生的路徑以及 CI 已經強制執行的任何項目都會被排除在外。

實際樣貌

REVIEW.md：

markdown
# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.

以下範例是檢查執行針對一個為保險公司客戶入口網站新增理賠狀態面板的拉取請求所列出的內容，其中 claims-core 是入口網站後端背後較舊的內部系統：

嚴重程度檔案:行號問題
重要portal/src/claims/StatusPanel.tsx:22合規性：該面板在每次渲染時都會發出請求。plan.md 指出必須進行快取，因為 claims-core 每秒只允許 50 次請求
重要claims-api/routes/status.py:31安全性：錯誤路徑會記錄整個 claims-core 的回應內容，其中包含 policy_holder_name
小問題claims-api/tests/test_status.py:8錯誤：沒有測試涵蓋沒有預期日期的 paid 理賠情況

第一個發現之所以存在，僅僅是因為合規性審查流程會讀取已提交的 plan.md，而僅查看差異內容的審查者並不會開啟這份文件。

治理考量

職責分離得以保留，因為撰寫程式碼的代理無法核准自己的程式碼。REVIEW.md 中的審查政策適用於所有 PR，而發現的問題、修正、評分與核准都會記錄在 PR 歷史中，因此 PR 本身就是稽核紀錄。核准則是由人類透過分支保護機制做出，並以這些發現作為依據。

如何衡量

  • 領先指標：首次審查所需時間，應降至以分鐘計，以及在沒有人類觸碰分支的情況下解決的審查意見比例，這些資料直接儲存在 Git 上。
  • 落後指標：在合併前捕捉到的缺陷與漏洞，與逃逸到生產環境的缺陷與漏洞相比，資料來自 PR 歷史與事件追蹤系統。