程式碼審查流程（Code Review）

觸發時機

當使用者要求審查程式碼、Pull Request 或提交記錄時， 啟動此審查流程。

審查步驟

Step 1：取得程式碼

使用 exec 工具或 git-read 工具取得要審查的程式碼內容。 若使用者提供的是 PR URL，先取得 diff。

Step 2：依序執行四個審查維度

維度 A：程式碼品質

• 命名是否清晰（變數、函數、類別名稱）
• 函數是否符合單一職責原則（SRP）
• 是否有明顯的重複代碼（DRY 原則）
• 複雜度是否合理（循環複雜度 ≤ 10）

維度 B：安全性

• 輸入驗證是否完整
• 是否有 SQL Injection、XSS 等常見漏洞風險
• 敏感資訊（API Key、密碼）是否未被 hardcode

維度 C：可維護性

• 是否有足夠的註解（複雜邏輯必須有說明）
• 單元測試覆蓋率是否足夠（核心邏輯 ≥ 80%）
• 錯誤處理是否完整

維度 D：效能

• 是否有明顯的 N+1 查詢問題
• 是否有不必要的重複計算

Step 3：產出審查報告

使用以下格式輸出：

## 程式碼審查報告

**審查對象：** [檔案名稱或 PR 標題]
**審查日期：** [今天日期]
**整體評級：** [A/B/C/D]

### 問題清單
| 嚴重度 | 維度 | 位置 | 問題描述 | 建議修改 |
|--------|------|------|----------|----------|
| 🔴 高 | 安全 | line 42 | ... | ... |
| 🟡 中 | 品質 | line 67 | ... | ... |

### 優點記錄
- [列出 1～3 個值得肯定的設計決策]

### 總結建議
[2～3 句總結，說明最值得優先處理的問題]

重要原則

• 發現問題要具體說明位置（行號或函數名稱）
• 每個問題必須附上建議的修改方向
• 評級標準：A（無重大問題）、B（有中等問題需修改）、 C（有高嚴重度問題）、D（需重大重構）
• 不做商業邏輯的合理性判斷，只評估技術品質