# Revisão de código (/pt/docs/verdent-manager/advanced-features/code-review) > Revise alterações de código com o subagente Reviewer integrado, revisão multimodelo e correções com um clique Verdent inclui um subagente integrado chamado **Reviewer**, cuja única responsabilidade é revisar seu código. Depois de terminar de escrever, basta marcar `@Reviewer` e ele examinará suas alterações sob múltiplos ângulos e produzirá uma lista estruturada de problemas ordenada por gravidade. Clique em qualquer item que você queira corrigir e ele aplicará as alterações automaticamente—sem precisar escrever comentários ou pesquisar documentação manualmente. *** ## Como acionar a revisão de código [#como-acionar-a-revisão-de-código] A forma mais direta é digitar `@Reviewer` no chat, como quando você menciona um colega de equipe em um grupo: ``` @Reviewer please review the authentication logic I just wrote ``` O Reviewer lê automaticamente o contexto atual e começa a revisar. Você também pode simplesmente chamar `@Reviewer` sem instruções—ele decidirá por conta própria o que inspecionar. Além do acionamento manual, o Agent pode invocar automaticamente o Reviewer como uma etapa final de **VERIFY** no fluxo de trabalho. Assim que o código é escrito, você não precisa se preocupar—o sistema traz o Reviewer para validar o resultado. *** ## Como é a saída da revisão [#como-é-a-saída-da-revisão] Após a revisão, você verá uma lista estruturada de **Findings**. Cada item inclui: * **Título** — uma descrição em uma linha do problema * **Explicação detalhada** — por que é um problema e seu impacto potencial * **Caminho do arquivo + número da linha** — clique para ir diretamente ao código * **Pontuação de confiança** — quão certo o Reviewer está (0–1) Os problemas são categorizados em três níveis de gravidade: | Prioridade | Significado | Exemplos típicos | | ---------- | ------------------------------ | -------------------------------------------------------------- | | **P0** | Crítico, deve ser corrigido | Erros de lógica, injeção de SQL, escalonamento de privilégios | | **P1** | Importante, deve ser corrigido | Casos extremos não tratados, possíveis problemas de desempenho | | **P2** | Sugestão | Estilo de código, melhorias de legibilidade | No topo, um resumo como `P0: 1 / P1: 3 / P2: 5` oferece uma visão instantânea da distribuição de gravidade. No final, um `overall_explanation` fornece uma avaliação de alto nível das alterações. *** ## Correção com um clique [#correção-com-um-clique] Não é preciso editar cada problema manualmente. Cada Finding inclui uma caixa de seleção: 1. Selecione os problemas que deseja corrigir (suporta selecionar todos) 2. Clique em **Fix** 3. O Reviewer aplica automaticamente as alterações 4. O status muda para **Fix done** Em alguns casos, se o Reviewer determinar que as alterações são de baixo risco, ele pode selecionar automaticamente todos os problemas e acionar a correção sem exigir confirmação. *** ## Revisão colaborativa multimodelo [#revisão-colaborativa-multimodelo] Um dos recursos mais poderosos do Reviewer é a **revisão de código multimodelo**—vários modelos de IA revisando o mesmo código em paralelo, como ter três engenheiros de diferentes formações avaliando sua implementação de forma independente. **Como habilitar** Vá em **Settings → Chat → Reviewer → habilite "Multi-model review"**. **Modos de seleção de modelo** | Modo | Descrição | | ---------------- | --------------------------------------------------------------------------------------------------- | | **Default mode** | Verdent seleciona automaticamente a melhor combinação de modelos com base na complexidade da tarefa | | **User mode** | Escolha manualmente de 1 a 3 modelos (Claude, GPT, Gemini podem ser combinados) | Você pode selecionar até **3 modelos**. O primeiro é o revisor principal; os demais são revisores secundários. Mais modelos significam cobertura mais ampla, mas execução mais lenta. Para alterações simples, um único modelo geralmente é suficiente. *** ## Review Rules (políticas de revisão personalizadas) [#review-rules-políticas-de-revisão-personalizadas] O Reviewer detecta muitos problemas comuns por padrão, mas cada equipe tem seus próprios padrões. As **Review Rules** permitem que você defina suas diretrizes de engenharia diretamente. **Onde configurar** Settings → Chat → Reviewer → editor de Review Rules (editor Monaco com suporte a Markdown). **O que você pode definir** * Todas as consultas SQL devem usar instruções parametrizadas, sem concatenação de strings * Operações assíncronas devem incluir tratamento de erros adequado com try/catch * Componentes React devem usar `memo` quando as props forem estáveis * Todas as APIs públicas devem validar as permissões do usuário Essas regras são injetadas automaticamente no contexto do Reviewer e verificadas em cada revisão. As atualizações entram em vigor automaticamente após \~500ms—sem necessidade de salvar manualmente. *** ## Fluxo de trabalho em tempo real [#fluxo-de-trabalho-em-tempo-real] Durante a revisão, você pode observar o **Working Tree Stream** do Reviewer em tempo real—mostrando qual arquivo ele está lendo e qual lógica está analisando. Ao expandir, você vê uma árvore de tarefas completa. Você pode recolhê-la se preferir uma visão mais simples, sem afetar os resultados. *** ## Casos de uso [#casos-de-uso] ### Verificação final de qualidade [#verificação-final-de-qualidade] Após implementar uma lógica complexa, execute `@Reviewer` para capturar casos extremos e bugs sutis que você possa ter perdido por cansaço. ### Validação antes do PR [#validação-antes-do-pr] Execute uma revisão antes de enviar um pull request. Corrija primeiro todos os problemas P0/P1 para reduzir idas e vindas e aliviar a carga de revisão dos colegas de equipe. ### Auditoria de segurança [#auditoria-de-segurança] Adicione Review Rules focadas em segurança (por exemplo, "todas as entradas devem ser sanitizadas contra XSS") para garantir que cada alteração seja automaticamente verificada em relação às políticas de segurança. ### Aplicação dos padrões da equipe [#aplicação-dos-padrões-da-equipe] Codifique regras do ESLint, convenções de design da API e padrões de nomenclatura nas Review Rules para que até novos colaboradores sigam as diretrizes da equipe automaticamente. ### Decisões de arquitetura com múltiplas perspectivas [#decisões-de-arquitetura-com-múltiplas-perspectivas] Para alterações importantes, habilite a revisão multimodelo para obter avaliações independentes e descobrir pontos cegos. ### Ferramenta de aprendizado para iniciantes [#ferramenta-de-aprendizado-para-iniciantes] Use o feedback do Reviewer como material de aprendizado—entender por que os problemas P0 importam ensina princípios essenciais de engenharia mais rápido do que ler documentação. *** ## Observações [#observações] * **Modelo único vs multimodelo**: o multimodelo oferece cobertura mais ampla, mas é mais lento e mais caro. Para tarefas simples ou urgentes, um único modelo geralmente é suficiente. * **Limitação do plano gratuito**: usuários gratuitos no User mode só podem selecionar modelos do pool Eco Mode; modelos premium exigem assinatura. * **Descontinuação de modelos**: se um modelo selecionado for descontinuado, ele será desativado e deverá ser substituído. * **As Review Rules são globais**: elas se aplicam a todos os projetos. Se uma regra for específica de um projeto, adicione uma observação ou remova-a após o uso. * **Status do BYOK**: se você usar sua própria chave API, chaves expiradas ou saldo insuficiente desativarão os modelos correspondentes e causarão falhas de revisão até que sejam atualizadas. *** ## Veja também [#veja-também] Conheça os subagentes integrados Use suas próprias chaves API Planeje antes de implementar