# Revisione del codice (/it/docs/verdent-manager/advanced-features/code-review) > Rivedi le modifiche al codice con il sottoagente Reviewer integrato, la revisione multi-modello e le correzioni con un clic Verdent include un sottoagente integrato chiamato **Reviewer**, la cui unica responsabilità è rivedere il tuo codice. Dopo aver finito di scrivere, basta menzionare `@Reviewer` e analizzerà le tue modifiche da più angolazioni, producendo un elenco strutturato di problemi ordinati per gravità. Seleziona qualsiasi elemento da correggere e applicherà automaticamente le modifiche—senza bisogno di scrivere commenti o cercare la documentazione manualmente. *** ## Come attivare la revisione del codice [#come-attivare-la-revisione-del-codice] Il modo più diretto è digitare `@Reviewer` nella chat, proprio come menzionare un collega in un gruppo: ``` @Reviewer please review the authentication logic I just wrote ``` Reviewer legge automaticamente il contesto corrente e inizia la revisione. Puoi anche semplicemente richiamare `@Reviewer` senza istruzioni—deciderà da solo cosa ispezionare. Oltre all'attivazione manuale, l'agente può richiamare automaticamente Reviewer come passaggio finale di **VERIFY** nel flusso di lavoro. Una volta scritto il codice, non devi preoccuparti—il sistema coinvolge Reviewer per convalidare il risultato. *** ## Come si presenta l'output della revisione [#come-si-presenta-loutput-della-revisione] Dopo la revisione, vedrai un elenco strutturato di **Findings**. Ogni elemento include: * **Titolo** — una descrizione del problema in una riga * **Spiegazione dettagliata** — perché è un problema e il suo impatto potenziale * **Percorso del file + numero di riga** — seleziona per saltare direttamente al codice * **Punteggio di confidenza** — quanto Reviewer è sicuro (0–1) I problemi sono suddivisi in tre livelli di gravità: | Priorità | Significato | Esempi tipici | | -------- | ---------------------------------------- | -------------------------------------------------------- | | **P0** | Critico, da correggere obbligatoriamente | Errori logici, SQL injection, escalation dei privilegi | | **P1** | Importante, da correggere | Casi limite mancanti, potenziali problemi di prestazioni | | **P2** | Suggerimento | Stile del codice, miglioramenti di leggibilità | In alto, un riepilogo come `P0: 1 / P1: 3 / P2: 5` offre una panoramica immediata della distribuzione della gravità. Alla fine, un `overall_explanation` fornisce una valutazione ad alto livello delle modifiche. *** ## Correzione con un clic [#correzione-con-un-clic] Non è necessario modificare manualmente ogni problema. Ogni Finding include una casella di controllo: 1. Seleziona i problemi che vuoi correggere (supporta la selezione di tutti) 2. Seleziona **Fix** 3. Reviewer applica automaticamente le modifiche 4. Lo stato si aggiorna a **Fix done** In alcuni casi, se Reviewer determina che le modifiche sono a basso rischio, potrebbe selezionare automaticamente tutti i problemi e attivare la correzione senza richiedere conferma. *** ## Revisione collaborativa multi-modello [#revisione-collaborativa-multi-modello] Una delle funzionalità più potenti di Reviewer è la **revisione del codice multi-modello**—più modelli AI che revisionano lo stesso codice in parallelo, come avere tre ingegneri di diversa provenienza che valutano in modo indipendente la tua implementazione. **Come attivarla** Vai su **Settings → Chat → Reviewer → abilita "Multi-model review"**. **Modalità di selezione dei modelli** | Modalità | Descrizione | | ---------------- | ------------------------------------------------------------------------------------------------------------ | | **Default mode** | Verdent seleziona automaticamente la migliore combinazione di modelli in base alla complessità dell'attività | | **User mode** | Scegli manualmente 1–3 modelli (Claude, GPT, Gemini possono essere combinati) | Puoi selezionare fino a **3 modelli**. Il primo è il revisore principale; gli altri sono revisori secondari. Più modelli significano una copertura più ampia ma un'esecuzione più lenta. Per modifiche semplici, di solito un singolo modello è sufficiente. *** ## Review Rules (criteri di revisione personalizzati) [#review-rules-criteri-di-revisione-personalizzati] Reviewer individua molti problemi comuni per impostazione predefinita, ma ogni team ha i propri standard. Le **Review Rules** ti permettono di definire direttamente le tue linee guida ingegneristiche. **Dove configurarle** Settings → Chat → Reviewer → editor delle Review Rules (editor Monaco con supporto Markdown). **Cosa puoi definire** * Tutte le query SQL devono usare istruzioni parametrizzate, niente concatenazione di stringhe * Le operazioni asincrone devono includere una corretta gestione degli errori con try/catch * I componenti React dovrebbero usare `memo` quando le props sono stabili * Tutti gli API pubblici devono convalidare i permessi dell'utente Queste regole vengono automaticamente inserite nel contesto di Reviewer e verificate durante ogni revisione. Gli aggiornamenti hanno effetto automaticamente dopo circa 500 ms—non è richiesto alcun salvataggio manuale. *** ## Flusso di lavoro in tempo reale [#flusso-di-lavoro-in-tempo-reale] Durante la revisione, puoi osservare in tempo reale il **Working Tree Stream** di Reviewer—che mostra quale file sta leggendo e quale logica sta analizzando. Espandendolo si rivela un albero completo delle attività. Puoi comprimerlo se preferisci una vista più semplice, senza influire sui risultati. *** ## Casi d'uso [#casi-duso] ### Controllo finale della qualità [#controllo-finale-della-qualità] Dopo aver implementato una logica complessa, esegui `@Reviewer` per individuare casi limite e bug sottili che potresti aver trascurato per stanchezza. ### Validazione prima della PR [#validazione-prima-della-pr] Esegui una revisione prima di inviare una pull request. Correggi prima tutti i problemi P0/P1 per ridurre gli scambi e alleggerire il carico di revisione dei colleghi. ### Audit di sicurezza [#audit-di-sicurezza] Aggiungi Review Rules orientate alla sicurezza (ad es. "tutti gli input devono essere sanificati contro XSS") per garantire che ogni modifica venga automaticamente verificata rispetto ai criteri di sicurezza. ### Applicazione degli standard del team [#applicazione-degli-standard-del-team] Codifica le regole ESLint, le convenzioni di progettazione di API e gli standard di denominazione nelle Review Rules, così anche i nuovi contributori seguono automaticamente le linee guida del team. ### Decisioni architetturali multi-prospettiva [#decisioni-architetturali-multi-prospettiva] Per modifiche importanti, abilita la revisione multi-modello per ottenere valutazioni indipendenti e scoprire punti ciechi. ### Strumento di apprendimento per principianti [#strumento-di-apprendimento-per-principianti] Usa il feedback di Reviewer come materiale di apprendimento—capire perché i problemi P0 sono importanti insegna i principi ingegneristici fondamentali più velocemente della lettura della documentazione. *** ## Note [#note] * **Modello singolo vs multi-modello**: il multi-modello offre una copertura più ampia ma è più lento e più costoso. Per attività semplici o urgenti, il modello singolo è di solito sufficiente. * **Limitazione del piano gratuito**: gli utenti gratuiti in User mode possono selezionare solo modelli dal pool Eco Mode; i modelli premium richiedono un abbonamento. * **Ritiro dei modelli**: se un modello selezionato viene ritirato, sarà disabilitato e dovrà essere sostituito. * **Le Review Rules sono globali**: si applicano a tutti i progetti. Se una regola è specifica di un progetto, aggiungi una nota o rimuovila dopo l'uso. * **Stato di BYOK**: se usi la tua chiave API, una scadenza o un saldo insufficiente disabiliterà i modelli corrispondenti e causerà errori di revisione fino all'aggiornamento. *** ## Vedi anche [#vedi-anche] Scopri i sottoagenti integrati Usa le tue chiavi API Pianifica prima di implementare