六重自動化程式碼審查：我們怎麼讓 AI 寫出生產級程式碼
📌 關鍵要點 Key Takeaways
- 六個審查層：安全性、效能、可維護性、測試覆蓋率、API 相容性、商業邏輯
- 實測 6 個月數據：問題攔截率 94%，誤報率 7.2%
- 用 Claude Code sub-agents 實作，每個審查員是獨立的 agent
- 審查一個 PR 平均花費 $0.18 美金（Claude API token 費用）
- 上線後生產環境 bug 減少 81%
為什麼 AI 寫的程式碼需要多重審查？
AI coding agent 有一個根本問題：它不知道自己不知道什麼。我們實測 500 個 AI 生成的函數，問題分布：SQL injection 風險 12%、未處理 edge case 34%、N+1 查詢 23%、型別不安全 41%、缺少錯誤處理 28%、測試覆蓋不足 56%。
沒有任何單一審查員能捕捉所有問題。所以我們設計了六個有不同專長的審查員，每個只負責自己的領域，串行執行。
六個審查員詳解
1安全性審查員（Security Guardian）
完全不管程式碼是否運作正確，只看安全性。System prompt 包含完整的 OWASP Top 10 清單和我們自己累積的安全漏洞資料庫。
攔截最多的問題：硬編碼的 API key（const API_KEY = "sk-..."，AI 生成時特別容易犯）、用字串拼接建構 SQL query、在 response 裡回傳密碼欄位。
攔截率：安全問題 97%
2效能審查員（Performance Analyst）
專長是發現會在高流量下崩潰的程式碼模式。AI 生成的程式碼特別容易出現 N+1 查詢——10 筆資料是 10 次查詢，1000 筆就是 1000 次。它看到這種模式就警告：
// 問題模式：
const users = await prisma.user.findMany();
const usersWithOrders = await Promise.all(
users.map(u => prisma.order.findMany({ where: { userId: u.id } }))
);
// 正確做法：
const users = await prisma.user.findMany({
include: { orders: true }
});
攔截率：效能問題 89%
3可維護性審查員（Code Quality Judge）
規則硬性執行：函數超過 50 行拒絕，同樣邏輯出現兩次以上拒絕，Magic number 沒有命名常數拒絕。這是誤報率最高的審查員（11.3%），因為可維護性有主觀成分。誤報不阻擋 merge，只生成建議報告供人工判斷。
攔截率：88%（誤報 11.3%）
4測試覆蓋率審查員（Test Coverage Inspector）
不只看覆蓋率數字，而是看有沒有測試重要的邊界情況。覆蓋率 90% 但沒有測試空輸入，還是會擋下來。它會主動列出「這個函數應該要測試哪些情況，但目前缺少」。
攔截率：測試不足問題 91%
5API 相容性審查員（Compatibility Guardian）
對照當前 API schema 和新程式碼，找出任何破壞性變更：刪除欄位、修改型別、改變回傳格式。在 ShopAI 開發過程中，這個審查員攔截了 3 次會讓 LINE Webhook 串接失敗的 API 修改。
攔截率：相容性問題 96%
6商業邏輯審查員（Business Logic Validator）
對照原始需求文件，確認程式碼確實實作了被要求的功能。真實案例：需求是「免費用戶每月最多 100 次 API 呼叫」，AI 寫了計數機制，但把計算週期設成 30 天而不是自然月——技術正確，商業邏輯錯誤。
攔截率：商業邏輯問題 87%
GitHub Actions 整合方式
# .github/workflows/ai-review.yml
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
ai-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Six-Layer Review
run: |
claude-code review \
--layers security,performance,maintainability,testing,compatibility,business \
--pr-diff "${{ github.event.pull_request.diff_url }}" \
--fail-on critical,high \
--warn-on medium \
--output github-comment
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
每個審查員的 system prompt 放在 .claude/reviewers/ 目錄下，獨立管理，按需更新而不影響其他審查員。
六個月真實數據
| 審查員 | 攔截問題數 | 誤報率 | 平均花費時間 |
|---|---|---|---|
| 安全性 | 142 | 3.1% | 28s |
| 效能 | 89 | 8.9% | 41s |
| 可維護性 | 203 | 11.3% | 35s |
| 測試覆蓋率 | 167 | 5.4% | 22s |
| API 相容性 | 31 | 2.8% | 19s |
| 商業邏輯 | 78 | 9.1% | 52s |
| 合計 | 710 | 7.2%（平均） | 197s（總計） |
710 個攔截的問題，如果進入生產環境每個都是潛在事故。6 個月 Claude API 費用約 $324 美金，節省了約 400 小時 debug 時間——怎麼算都划算。
誤報率 7.2% 的處理策略
誤報太多會讓開發者忽略所有警告，整個系統就失效了。我們的三層策略：
- 分級處理：Critical/High 強制阻擋 merge；Medium/Low 只生成報告，人工判斷
- 白名單機制：PR comment 加
<!-- ai-review: ignore security-001 -->，審查員下次跳過 - 每月校準：審查上個月所有誤報，更新 system prompt 減少同類誤報