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