程式碼審查與品質改進

程式碼審查不是走個流程——要發現隱患、給出可操作的審查意見、追蹤到修復完成。這個案例展示如何用 LanMate 把程式碼審查從「看一眼說沒問題」變成結構化閉環，讓問題不遺漏、修復可追溯。

用到的技能

• 內建技能（隨 LanMate 安裝，開箱即用）：LanMate 本身可讀寫程式碼檔案，無需額外內建技能
• 技能商店：程式碼審查請求方法論——編寫結構化審查請求，含變更摘要與自測清單；程式碼審查接收方法論——以接收者角色處理審查意見，建立分類到驗證的閉環；程式碼品質審查器——掃描複雜度、重複程式碼、命名規範等品質問題；程式碼安全掃描器——掃描硬編碼金鑰、SQL 注入、XSS 等安全風險

場景痛點

• 審查請求沒上下文：只丟一個變更連結，審查者不知道改了什麼、為什麼改、怎麼測的
• 審查意見全靠感覺：「這裡不太對」「建議優化」，沒有嚴重程度和具體建議
• 品質問題反覆出現：函式過長、魔法數字、重複程式碼，每次審查都提但每次都不改
• 安全風險被忽略：硬編碼金鑰、SQL 注入、XSS，靠人眼審查根本看不過來
• 修復沒有閉環：提了意見就完事，改沒改、改得對不對無人追蹤

推薦流程

提示詞範例

提交審查前自查

我準備提交一個程式碼變更，請幫我生成結構化審查請求：
- 變更摘要：本次改了什麼、為什麼改（1-2 句話）
- 變更範圍：涉及的檔案列表和每個檔案的改動類型（新增 / 修改 / 刪除）
- 自測清單：我應該自測哪些場景
- 風險提示：哪些改動可能影響現有功能
- 回滾方案：如果出問題怎麼回滾

讀取 src/ 目錄下的程式碼檔案，根據最近的改動生成。
自測清單要具體到測試場景，不要寫「全面測試」這種泛化表述。

接收他人程式碼變更進行審查

請審查 src/ 目錄下的程式碼變更，逐檔案生成審查意見：
1. 先分析變更範圍：哪些檔案改了、每個檔案改了什麼
2. 逐檔案審查，每條意見包含：
   - 檔案名稱和行號
   - 問題描述
   - 嚴重程度（阻斷 / 重要 / 建議）
   - 修改建議（具體到怎麼改）
3. 匯總變更中的亮點（值得學習的寫法）

重點檢查：
- 邏輯錯誤和邊界條件（空值、越界、例外未處理）
- 是否引入不必要的複雜度
- 是否有硬編碼值應該提取為設定

程式碼品質評估

請掃描 src/ 目錄下的程式碼，生成品質審查報告：
1. 函式複雜度：標出圈複雜度過高的函式（建議閾值 15 以上標記）
2. 重複程式碼：標出重複出現的程式碼區塊
3. 命名規範：檢查函式名、變數名是否表意清晰、是否符合約定
4. 程式碼異味：過長的函式、過深的巢狀、過大的類別

每個問題輸出：
- 檔案名稱和位置
- 問題類型
- 嚴重程度（高 / 中 / 低）
- 重構建議

不要報告純格式問題（如縮排、空格），聚焦影響可維護性的實質問題。

安全掃描

請掃描 src/ 目錄下的程式碼，偵測安全風險：
1. 硬編碼金鑰：檢查是否有 API 金鑰、密碼、Token 寫死在程式碼中
2. SQL 注入：檢查是否有拼接 SQL 語句的寫法
3. XSS：檢查是否有未轉義的使用者輸入直接輸出到頁面
4. 敏感資訊洩露：檢查日誌中是否列印了敏感資料

每個風險輸出：
- 檔案名稱和行號
- 風險類型
- 嚴重程度（嚴重 / 高 / 中 / 低）
- 修復建議

無法確認是否為風險的位置標註「需人工確認」，不要自行判定。

生成審查報告

請匯總以上審查結果，生成一份程式碼審查報告：
- 問題列表（含檔案、行號、問題描述、嚴重程度）
- 按嚴重程度分組統計（阻斷 / 重要 / 建議）
- 每個問題的修復建議
- 責任人和建議修復期限
- 審查結論（通過 / 需修改後通過 / 不通過）

阻斷級問題必須在報告中置頂，並說明不修復的後果。
輸出 HTML 報告。

驗收標準

• 審查請求含變更摘要、變更範圍、自測清單，自測場景具體可執行
• 每條審查意見含檔案名稱、行號、嚴重程度和具體修改建議
• 品質報告聚焦可維護性問題，不報告純格式問題
• 安全風險按嚴重度分級，無法確認的標註「需人工確認」
• 審查報告含問題列表、修復建議、責任人和審查結論，阻斷級問題置頂

常見錯誤