> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Instruindo o Devin de Forma Eficaz
> Como obter os melhores resultados possíveis.
A coisa mais importante a ter em mente ao instruir o Devin é **ser o mais específico possível**. Assim como você forneceria uma especificação detalhada ao pedir a um colega para programar algo, você deve fazer o mesmo com o Devin. Este guia ajudará você a estruturar suas instruções/prompts para usar o Devin de forma eficaz. Para estratégias mais amplas sobre como trabalhar com agentes de código de forma eficaz, confira também nosso [guia Coding Agents 101](https://devin.ai/agents101).
## Como escrever prompts eficazes
Aqui está um exemplo de prompt que demonstra como dar instruções eficazes:
No repositório do Devin, quero que você crie uma ferramenta que monitore o uso de RAM e CPU das máquinas remotas nas quais o Devin é executado. Para fazer isso, execute as seguintes tarefas:
* Crie uma tarefa em segundo plano que seja iniciada automaticamente quando o devin.rs for iniciado.
* A tarefa deve abrir uma conexão com todas as máquinas remotas criadas por fork usadas nesta sessão do Devin e monitorar o uso de RAM e CPU delas.
* Se o uso exceder 80% do recurso disponível correspondente, emita um novo tipo de evento do Devin para sinalizar isso (verifique como usamos o Kafka).
* Projete isso de forma inteligente, de modo que não bloqueie outras operações. Você deve entender como todos os contêineres dos subagentes do Devin interagem entre si.
### Por que Isso Funciona Bem
* **Detalhe:** Especifica o repositório do Devin e o propósito mais amplo (monitorar o uso de recursos).
* **Benefício:** Devin entende claramente o escopo e o domínio.
* **Detalhe:** Tarefas como "create a background task" e "emit an event at 80% usage".
* **Benefício:** Divide o trabalho em partes lógicas.
* **Detalhe:** Define "success" como emitir um evento específico ao atingir 80% de uso.
* **Benefício:** Devin sabe exatamente o que precisa alcançar.
* **Detalhe:** Menciona Kafka e interações com contêineres.
* **Benefício:** Incentiva a reutilização de código ou abordagens de design já estabelecidas.
## Boas práticas: o que fazer e o que evitar
**Faça: Forneça orientações claras**
* **Por quê:** Devin pode ficar travado sem um caminho claro ou quando se depara com muitas interpretações possíveis.
* **Como:**
* Tome decisões importantes e faça julgamentos em nome do Devin.
* Ofereça escolhas de design específicas e estratégias de implementação.
* Defina claramente o escopo, os limites e os critérios de sucesso.
* **Exemplo:** "Otimize a consulta getOrderDetails em orderService.js adicionando um índice composto nas colunas order\_id e product\_id na tabela order\_items. Refatore a consulta para substituir a subconsulta correlacionada existente por um JOIN com a tabela products para buscar os detalhes dos produtos."
**Não faça: Deixar decisões em aberto**
* **Por quê:** Instruções vagas podem levar o Devin a implementar soluções que não atendem às suas necessidades reais.
* **Como:**
* Evite instruções que exijam que o Devin tome decisões significativas de design ou implementação sem orientação. Isso pode levar a resultados inesperados.
* **Exemplo:** Não faça: "Melhore a performance do nosso banco de dados."
**Faça: Escolha [tarefas em que o Devin é bom](when-to-use-devin#evaluating-tasks-for-devin)**
* **Por que:**
* **Maximize os resultados:** Ao atribuir tarefas que se alinham às capacidades do Devin, você obtém os melhores resultados com o mínimo esforço e ACUs gastos.
* **Como:**
* Leia este guia: [Quando usar o Devin](when-to-use-devin)
* Forneça exemplos, módulos, recursos e templates que o Devin possa seguir.
* Compartilhe links diretos para sites de documentação para que o Devin possa ler detalhes como corpos de requisição de API e funcionalidades que ele talvez não conheça.
* Compartilhe nomes de arquivos específicos que você quer que o Devin analise e aprenda com eles.
* Conecte [integrações MCP](/pt-BR/work-with-devin/mcp) para dar ao Devin acesso a designs do Figma, bancos de dados, ferramentas de monitoramento e mais.
* **Exemplo:** Faça: "Refatore o gerenciamento de estado no componente Header para usar o hook useReducer do React para melhor escalabilidade e manutenibilidade. Garanta que toda a funcionalidade existente seja preservada e adicione testes unitários para cobrir a nova lógica de estado."
* **Exemplo:** Faça: "Use authTemplate.rs como referência para manter a consistência no tratamento de erros."
* **Exemplo:** Faça: "Confira a documentação oficial do Sequelize em [https://sequelize.org/docs/v6/getting-started/](https://sequelize.org/docs/v6/getting-started/) para as etapas de migração."
**Não faça: Deixar de fornecer contexto para tarefas complexas**
* **Por que:** Embora o Devin consiga lidar com trabalhos complexos, ele tem o melhor desempenho quando você fornece contexto e orientação clara.
* **Como:**
* Para tarefas que exigem conhecimento de domínio, forneça documentação, exemplos ou referências relevantes.
* Para tarefas visuais, forneça arquivos do Figma via [Figma MCP](/pt-BR/work-with-devin/mcp), designs de referência ou especificações detalhadas — o Devin pode construir a partir disso, mas não vai inventar a estética por conta própria.
* Para apps Android, o Devin pode fazer build e testar em um [emulador Android](/pt-BR/onboard-devin/environment/android-emulation). Para apps iOS, o Devin não tem acesso a um emulador de celular, então forneça critérios claros de teste.
* **Exemplo:** Não faça: "Deixe o app com uma aparência melhor" — em vez disso, forneça especificações de design específicas ou um arquivo do Figma.
* **Exemplo:** Não faça: "Melhore a performance do nosso banco de dados" — em vez disso, especifique quais queries otimizar e quais métricas devem ser atingidas.
**Faça: estabeleça verificações claras e frequentes**
* **Por que:** feedback frequente (tanto seu quanto de testes/checks/linters) garante que o Devin corrija erros de forma eficaz.
* **Como:**
* Use testes (unitários/de integração) para confirmar se estão corretos.
* Mantenha validações de build, verificações de lint e análise estática para garantir a qualidade do código.
* Ative o [Devin Review](/pt-BR/work-with-devin/devin-review) com [Auto-Fix](/pt-BR/work-with-devin/devin-review#auto-fix) para que o Devin responda automaticamente a comentários de revisão e a falhas de CI — criando um ciclo fechado em que os PRs evoluem até atingirem qualidade pronta para merge, sem que você precise intervir.
* **Exemplo:** Faça: "Execute npm test após cada iteração."
* **Exemplo:** Faça: "Garanta que o pipeline no CircleCI não falhe."
* **Exemplo:** Faça: "Passe nas verificações do ESLint/Prettier antes de fazer qualquer commit."
**Não faça: deixar de fornecer feedback**
* **Por que:** sem feedback, o Devin não saberá se as soluções dele atendem aos seus padrões.
* **Como:**
* Evite atribuir tarefas sem definir como você vai avaliá-las.
**Faça: Defina checkpoints e subtarefas claros**
* **Por que:** Dividir tarefas complexas em checkpoints menores ajuda o Devin a manter o foco e reduz erros.
* **Como:**
* Divida as tarefas em subtarefas verificáveis e inicie uma sessão do Devin para cada subtarefa.
* Defina o que caracteriza sucesso para cada subtarefa e, opcionalmente, estabeleça checkpoints dentro de cada subtarefa.
* Peça que o Devin retorne após concluir cada checkpoint ou subtarefa.
**Exemplos:**
* **Exemplo:** Faça: "Ao trabalhar com o conjunto de dados, verifique que ele tenha pelo menos 500 linhas e contenha as colunas X, Y, Z."
* **Exemplo:** Faça: "Ao modificar a API, confirme que o endpoint retorna status 200 e inclui todos os campos obrigatórios."
* **Exemplo:** Faça: "Ao atualizar a UI, verifique que o componente renderiza sem erros no console e corresponda à especificação de design."
**Não faça: Deixar de definir requisitos específicos de validação**
* **Por que:** Sem etapas de validação definidas, o Devin não consegue concluir tarefas com segurança.
* **Como:**
* Evite critérios de sucesso vagos.
* Não deixe etapas de verificação implícitas ou indefinidas.
* **Exemplo:** Não faça: "Garanta que está funcionando."
O Devin possui um ambiente de desktop completo — shell, IDE e navegador. Peça que o Devin teste o próprio trabalho antes de abrir um PR:
* **Suba o app:** "Execute `npm run dev` e verifique se a nova página é renderizada em `/settings`."
* **Teste no navegador:** "Abra o navegador, navegue até a página de login e confirme que o fluxo de OAuth é concluído com sucesso."
* **Verificação visual:** "Tire screenshots em larguras de desktop (1440px) e mobile (375px) e confirme que o layout corresponde ao design."
* **Gravação de tela:** "Grave a tela enquanto você testa o fluxo de checkout de ponta a ponta."
Isso permite que o Devin faça QA das alterações da mesma forma que você faria — antes mesmo de você precisar analisar o PR.
For tarefas repetitivas ou complexas, recomendamos usar e iterar sobre [Playbooks](/pt-BR/product-guides/creating-playbooks). Saiba mais sobre [como usar playbooks de forma eficaz](/pt-BR/product-guides/using-playbooks). Playbooks são prompts reutilizáveis e compartilháveis que simplificam a delegação de tarefas. Por exemplo, se você quiser que o Devin lide com falhas recorrentes em builds de CI, crie um playbook que inclua as etapas gerais que o Devin deve seguir sempre.
Para contexto persistente que o Devin deve manter em todas as sessões — como padrões de código, bugs comuns e suas correções, fluxos de implantação ou como usar ferramentas internas — use [Knowledge](/pt-BR/product-guides/knowledge). Itens de Knowledge são recuperados automaticamente quando relevantes, então você não precisa repetir as mesmas instruções em cada prompt. Você pode fixar Knowledge a repositórios específicos ou aplicá-lo globalmente.
**Playbooks vs. Knowledge:** Use Playbooks para procedimentos passo a passo vinculados a tarefas específicas. Use Knowledge para dicas gerais, convenções e contexto que se aplicam amplamente ao longo das sessões.