# 程式碼審查 (/zh-Hant/docs/verdent-manager/advanced-features/code-review) > 透過內建的 Reviewer 子代理、多模型審查與一鍵修復來審查程式碼變更 Verdent 內建一個名為 **Reviewer** 的子代理，唯一的職責就是審查你的程式碼。寫完程式碼後，只要標記 `@Reviewer`，它就會從多個角度掃描你的變更，並輸出一份依嚴重程度排序的結構化問題清單。點選任何想修復的項目，它就會自動套用變更——不必手動撰寫註解或翻查文件。 *** ## 如何觸發程式碼審查 [#如何觸發程式碼審查] 最直接的方式是在聊天中輸入 `@Reviewer`，就像在群組裡提及隊友一樣： ``` @Reviewer please review the authentication logic I just wrote ``` Reviewer 會自動讀取目前的上下文並開始審查。你也可以不附帶任何指示，直接呼叫 `@Reviewer`——它會自行決定要檢查哪些內容。 除了手動觸發之外，Agent 也能在工作流程的最後一個 **VERIFY** 步驟自動呼叫 Reviewer。程式碼寫完後，你無需操心——系統會自動讓 Reviewer 介入驗證結果。 *** ## 審查輸出長什麼樣 [#審查輸出長什麼樣] 審查完成後，你會看到一份結構化的 **Findings（問題清單）**。每一項包含： * **標題** — 一行描述問題 * **詳細說明** — 為什麼這是問題，以及它的潛在影響 * **檔案路徑 + 行號** — 點選即可直接跳到程式碼 * **信心分數** — Reviewer 的確定程度（0–1） 問題分為三種嚴重程度： | 優先級 | 含義 | 典型範例 | | ------ | ------- | ---------------- | | **P0** | 嚴重，必須修復 | 邏輯錯誤、SQL 注入、權限提升 | | **P1** | 重要，應該修復 | 缺漏的邊界情況、潛在效能問題 | | **P2** | 建議 | 程式碼風格、可讀性改善 | 頂部會有一段如 `P0: 1 / P1: 3 / P2: 5` 的摘要，讓你一眼掌握嚴重程度分布。結尾則有一段 `overall_explanation`，對這些變更提供整體性評估。 *** ## 一鍵修復 [#一鍵修復] 不必手動逐項編輯每個問題。每個 Finding 都附有一個核取方塊： 1. 勾選你想修復的問題（支援全選） 2. 點選 **Fix** 3. Reviewer 自動套用變更 4. 狀態更新為 **Fix done** 在某些情況下，若 Reviewer 判斷變更屬於低風險，它可能會自動全選所有問題並觸發修復，無需確認。 *** ## 多模型協同審查 [#多模型協同審查] Reviewer 最強大的功能之一就是 **多模型程式碼審查**——多個 AI 模型平行審查同一份程式碼，就像讓三位背景各異的工程師獨立評估你的實作。 **如何啟用** 前往 **Settings → Chat → Reviewer → 啟用「Multi-model review」**。 **模型選擇模式** | 模式 | 說明 | | ---------------- | ------------------------------------- | | **Default mode** | Verdent 會依任務複雜度自動選出最佳的模型組合 | | **User mode** | 手動選擇 1–3 個模型（Claude、GPT、Gemini 可混合搭配） | 你最多可以選擇 **3 個模型**。第一個是主審查模型，其餘為次要審查模型。模型越多，覆蓋面越廣，但執行也越慢。對於簡單的變更，通常單一模型就足夠了。 *** ## Review Rules（自訂審查政策） [#review-rules自訂審查政策] Reviewer 預設就能抓出許多常見問題，但每個團隊都有自己的標準。**Review Rules** 讓你直接定義自己的工程準則。 **在哪裡設定** Settings → Chat → Reviewer → Review Rules 編輯器（支援 Markdown 的 Monaco 編輯器）。 **你可以定義什麼** * 所有 SQL 查詢必須使用參數化語句，禁止字串串接 * 非同步操作必須包含妥善的 try/catch 錯誤處理 * 當 props 穩定時，React 元件應使用 `memo` * 所有公開 API 必須驗證使用者權限 這些規則會自動注入 Reviewer 的上下文，並在每次審查時檢查。更新約在 500ms 後自動生效——無需手動儲存。 *** ## 即時工作流程 [#即時工作流程] 在審查過程中，你可以即時觀察 Reviewer 的 **Working Tree Stream**——顯示它正在讀取哪個檔案、分析哪段邏輯。展開後可看到完整的任務樹。如果你偏好更簡潔的檢視，也可以將其收合，不會影響結果。 *** ## 使用情境 [#使用情境] ### 最終品質檢查 [#最終品質檢查] 實作複雜邏輯後，執行 `@Reviewer` 來抓出你可能因疲勞而遺漏的邊界情況與細微錯誤。 ### PR 前驗證 [#pr-前驗證] 在提交 pull request 前先執行一次審查。先修復所有 P0/P1 問題，可減少來回往返，也減輕隊友的審查負擔。 ### 安全稽核 [#安全稽核] 加入以安全為導向的 Review Rules（例如「所有輸入必須經過 XSS 清理」），確保每次變更都會自動依安全政策檢查。 ### 落實團隊標準 [#落實團隊標準] 將 ESLint 規則、API 設計慣例與命名標準編入 Review Rules，這樣即使是新貢獻者也能自動遵循團隊準則。 ### 多視角架構決策 [#多視角架構決策] 對於重大變更，啟用多模型審查以取得獨立評估，找出盲點。 ### 初學者的學習工具 [#初學者的學習工具] 把 Reviewer 的回饋當作學習素材——理解 P0 問題為何重要，比閱讀文件更快學會核心工程原則。 *** ## 注意事項 [#注意事項] * **單模型 vs 多模型**：多模型提供更廣的覆蓋，但更慢也更耗費。對於簡單或緊急的任務，單一模型通常就足夠。 * **免費方案限制**：User mode 下的免費使用者只能從 Eco Mode 的模型池中選擇；進階模型需要訂閱方案。 * **模型淘汰**：若所選模型被下架，它會被停用，必須更換。 * **Review Rules 是全域的**：它們適用於所有專案。若某規則僅針對特定專案，請加上備註，或在使用後移除。 * **BYOK 狀態**：若使用你自己的 API key，過期或餘額不足會停用對應模型，並導致審查失敗，直到更新為止。 *** ## 延伸閱讀 [#延伸閱讀] 了解內建子代理 使用你自己的 API key 在實作前先規劃