Code Review

觸發與範圍

僅變更程式碼模式（使用者明確說「只 review 已變更程式碼」「僅看 diff」「changed code only」等）：

• 僅對當前已變更的程式碼進行 review
• 不評價未改動的檔案、函式或行
• 需要上下文時，只讀足夠理解變更意圖的最小範圍，結論仍只針對 diff 中的行

全量模式（使用者未限定範圍）：可按模組或檔案 review，但仍優先關注本次改動。

工作流

1. 收集變更

並行執行，確定 review 邊界：

git status
git diff
git diff --staged

若存在 base 分支，補充：

git diff <base-branch>...HEAD

記錄：變更檔案列表、每個 hunk 的增刪改、使用者描述的需求/任務目標。

2. 理解需求邊界

在 review 前明確：

• 使用者/任務要求改什麼
• 哪些檔案/邏輯理論上不應動

後續所有結論都對照這條邊界判斷。

3. 執行三項核心檢查

按優先順序審查 diff 中的每一處變更：

A. 需求外影響（最高優先順序）

著重檢查變更後的程式碼有沒有影響需求以外的內容，防止無意修改無關程式碼或者破壞不應該修改的邏輯。

具體檢查：

• 改動是否超出任務描述（順手重構、格式化整檔案、改命名/註釋/匯入等無關項）

  7w4.net小蔥技能站收錄全網優質技能，值得收藏。

• 是否修改了不應觸碰的模組、公共 API、配置、鑑權、錯誤處理契約
• 刪除/替換程式碼是否破壞原有呼叫方、分支、降級或相容邏輯
• 變更是否引入行為迴歸（原功能靜默失效、條件變寬/變窄、預設值變化）
• 測試/配置/文件的改動是否與需求一致，還是附帶修改

疑似越界時：標出具體 hunk，說明「需求內應有 / 實際做了什麼 / 風險」。

B. 冗餘

檢查已變更程式碼是否有冗餘的部分：

• 重複邏輯、可合併的分支、無意義的中間變數或包裝
• 未使用的匯入、變數、函式、死程式碼
• 與現有工具函式/元件重複的實現
• 過度防禦或重複的校驗、日誌、註釋塊
• 可用更小 diff 達成同樣目標的寫法

C. 邏輯漏洞

檢查變更程式碼有沒有邏輯漏洞：

• 邊界條件：空值、空集合、0、越界、併發、超時、重試
• 條件與分支：遺漏 else、早返回、競態、狀態不同步
• 錯誤處理：吞異常、錯誤傳播斷裂、部分失敗未回滾
• 資料流：型別不匹配、隱式轉換、off-by-one、單位/時區錯誤
• 安全：注入、許可權繞過、敏感資訊洩露
• 與呼叫方/被呼叫方契約是否一致

4. 輸出報告

使用以下模板，每條發現必須引用具體變更位置（檔案 + 行號或 diff hunk）：

# Code Review — [範圍: 僅變更程式碼 | 全量]

## 變更概覽
- 需求/目標：[一句話]
- 變更檔案：N 個
- 總體結論：[通過 | 需修改 | 阻塞]

## 發現

### 🔴 阻塞（必須修復）
1. **[類別: 需求外影響 | 冗餘 | 邏輯漏洞]** `path:line`
   - 問題：
   - 風險：
   - 建議：

### 🟡 建議（建議修復）
...

### 🟢 可選最佳化
...

## 範圍確認
- 疑似超出需求的改動：[無 / 列出]
- 未發現問題但需人工確認的點：[無 / 列出]

5. 行為約束

• 沒有 diff 時：先獲取變更，或請使用者指定 commit/分支/檔案，不憑空 review
• 只讀 review：預設不修改程式碼，除非使用者要求修復
• 不擴大範圍：僅變更程式碼模式下，不對未改動程式碼提「順便可以改」類建議，除非與本次 bug 直接相關
• 結論要有依據：每條發現對應 diff 中的具體變更，避免泛泛而談

快速檢查清單

- [ ] 已用 git diff 界定變更範圍
- [ ] 已明確需求邊界
- [ ] 已檢查：需求外影響 / 無意破壞不應修改的邏輯
- [ ] 已檢查：變更冗餘
- [ ] 已檢查：邏輯漏洞與邊界條件
- [ ] 每條結論有檔案/行號引用

示例

見 examples.md

這個程式碼審查 Skill 質量較好，工作流程清晰、檢查維度全面。它能幫助使用者發現程式碼變更中的範圍蔓延、冗餘程式碼和邏輯漏洞，給出的結論有具體程式碼位置支撐，輸出格式規範。示例豐富，便於理解。不過它缺少使用說明文件，對普通使用者來說可能需要一定學習成本才能上手。總體而言，這是一個實用且專業的程式碼審查助手。