程式碼審查流程（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（需重大重構） - 不做商業邏輯的合理性判斷，只評估技術品質
