Engenharia de prompt: como conversar melhor com LLMs sem depender de tentativa e erro

Você abre o ChatGPT, Copilot ou outra ferramenta com LLM e escreve: “me ajuda com esse erro”. A resposta vem confiante, bem formatada e… pouco útil. Talvez genérica demais. Talvez suponha uma stack que você não usa. Talvez proponha uma solução que até parece boa, mas não encaixa no problema real.

Esse é um bom ponto de partida para falar de engenharia de prompt: não como uma coleção de frases mágicas, mas como a prática de tornar sua intenção mais explícita para o modelo. Em vez de jogar uma pergunta solta e torcer pelo melhor, você descreve objetivo, contexto, restrições, formato esperado e critérios de qualidade.

Isso não transforma a LLM em uma fonte infalível. Também não elimina revisão, teste ou senso crítico. Porém, reduz ambiguidades e aumenta a chance de receber uma resposta útil, verificável e mais fácil de ajustar.

TL;DR

• Engenharia de prompt é a prática de estruturar melhor instruções para LLMs.
• Bons prompts deixam claro: objetivo, contexto, papel, restrições, formato, exemplos e critérios de qualidade.
• Mais contexto costuma ajudar, mas contexto demais, bagunçado ou irrelevante pode atrapalhar.
• LLMs podem errar, inventar informações e soar confiantes mesmo quando estão incorretas.
• Use a resposta como apoio para pensar, escrever, planejar ou diagnosticar — não como decisão final sem validação.

Engenharia de prompt é menos “frase mágica” e mais intenção explícita

Um prompt vago deixa muitas decisões por conta do modelo.

Por exemplo:

Faça um resumo disso.

Esse pedido pode gerar respostas muito diferentes dependendo do que o modelo “entender” como importante. É um resumo para estudar? Para enviar ao time? Para uma pessoa executiva? Deve ter exemplos? Deve preservar termos técnicos? Deve apontar dúvidas?

Agora compare com uma versão mais estruturada:

Resuma o texto abaixo para uma pessoa desenvolvedora júnior que está estudando o tema.
Priorize conceitos principais, exemplos práticos e dúvidas em aberto.
Use até 8 tópicos.
Separe claramente fatos apresentados no texto de interpretações suas.

A segunda versão não é perfeita, mas comunica melhor a intenção. Ela reduz espaço para interpretações indesejadas e facilita revisar a saída.

Portanto, engenharia de prompt pode ser vista como uma espécie de especificação leve. Ela não substitui requisitos, documentação, conversa com pessoas usuárias ou critérios de aceite. No entanto, ajuda a organizar o que você já sabe sobre a tarefa antes de pedir ajuda.

Essa ideia combina com práticas de desenvolvimento cuidadosas: clareza, feedback curto, revisão e melhoria contínua. O valor não está em “ganhar uma resposta pronta”, mas em melhorar a qualidade da conversa com a ferramenta.

Por que as respostas variam tanto?

LLMs geram respostas com base em padrões de linguagem e no contexto recebido. Elas não “entendem” uma tarefa do mesmo jeito que uma pessoa da sua equipe entenderia depois de participar de reuniões, ler código, conhecer restrições de negócio e sofrer junto com a pipeline quebrando numa sexta-feira.

Quando o pedido é incompleto, o modelo precisa preencher lacunas. Algumas perguntas ficam sem resposta:

• Para quem é a resposta?
• Qual é o objetivo?
• Qual profundidade é esperada?
• O que deve ser evitado?
• Como a saída será usada?
• Quais tecnologias, regras e limitações importam?

Veja um exemplo em desenvolvimento.

Pedido vago:

Crie uma API de usuários.

Esse pedido pode gerar uma API REST, GraphQL, com autenticação JWT, sem autenticação, usando Node.js, Java, Python, banco relacional, banco em memória, arquitetura em camadas, arquitetura minimalista… o cardápio é grande.

Uma versão mais útil seria:

Quero uma proposta de design para uma API REST de usuários em Java 21 com Spring Boot.
Contexto: a aplicação já usa PostgreSQL e autenticação via JWT.
A API precisa permitir criação, consulta por ID, listagem paginada e desativação de usuários.
Restrições: não incluir exclusão física; não usar bibliotecas além das já comuns no Spring Boot; considerar validação de e-mail único.
Formato da resposta: liste endpoints, payloads de entrada, respostas esperadas, regras de negócio e critérios de aceite.
Se faltar alguma informação, liste perguntas antes de assumir.

A diferença não está em “convencer” a IA com uma frase secreta. Está em remover ambiguidade.

Por outro lado, existe um trade-off: mais contexto tende a melhorar a adequação da resposta, mas contexto excessivo, desorganizado ou irrelevante pode confundir a tarefa. Um prompt de muitos parágrafos com histórico, opinião, logs soltos e requisitos misturados pode virar uma gaveta bagunçada.

Às vezes, o melhor prompt é o que entrega o necessário — nem menos, nem muito mais.

Engenharia de prompt na prática: uma estrutura simples

Uma forma prática de melhorar seus prompts é usar um checklist. Não como fórmula rígida, mas como lembrete do que costuma influenciar a qualidade da resposta.

Objetivo

Diga claramente o que você quer obter.

Em vez de:

Me ajuda com isso.

Prefira:

Explique este erro e proponha passos de diagnóstico antes de sugerir correções.

Ou:

Revise este texto para deixá-lo mais claro para pessoas não técnicas, sem mudar o significado.

O objetivo define o “tipo de ajuda” esperado. Diagnosticar, resumir, revisar, comparar, planejar e explicar são tarefas diferentes. Quando o objetivo não aparece, o modelo tende a escolher um caminho por conta própria.

Contexto

Inclua as informações necessárias para a tarefa: cenário, público, tecnologia, dados disponíveis e decisões já tomadas.

Por exemplo:

Estou investigando uma falha em um teste de integração em uma aplicação Java com Spring Boot.
O teste deveria retornar HTTP 201 ao criar um usuário, mas está retornando 400.
A validação de e-mail único foi adicionada recentemente.
Quero hipóteses priorizadas, não uma correção direta ainda.

Contexto não significa despejar tudo. Significa dar ao modelo as peças relevantes do quebra-cabeça.

Um cuidado importante: não envie senhas, tokens, dados pessoais, informações de clientes, trechos confidenciais ou código proprietário sem autorização e sem entender as políticas da ferramenta usada. Prompt bom não compensa vazamento de informação sensível.

Papel ou perspectiva

Pedir um papel pode ajudar quando ele delimita o tipo de análise.

Exemplo:

Analise como uma pessoa revisando código Java para identificar riscos de legibilidade, manutenção e comportamento inesperado.

Isso é melhor do que apenas:

Aja como especialista.

“Aja como especialista” sozinho não resolve falta de contexto. É como pedir para alguém “ser sênior” sem explicar o problema, o sistema, as restrições e o que precisa ser decidido. Pode até soar bonito, mas não entrega muito.

Use papéis para indicar perspectiva, não como comando de autoridade.

Restrições

Restrições evitam soluções incompatíveis com a realidade.

Exemplos:

Não use bibliotecas externas.
Considere Java 21.
Mantenha a solução em até duas classes.
Não proponha mudanças na API pública.
Priorize alternativas com menor impacto no código existente.

Restrições são especialmente úteis quando há muitas soluções possíveis. Além disso, ajudam a evitar respostas que parecem boas em um projeto idealizado, mas impraticáveis no seu contexto.

Formato de saída

Pedir formato ajuda a usar e revisar a resposta.

Exemplos:

Responda com: hipótese, evidência no código, risco, sugestão de correção e teste recomendado.

Ou:

Organize em uma tabela com colunas: problema, impacto, prioridade e ação sugerida.

Ou ainda:

Responda em etapas numeradas, começando por verificações que não alteram código.

Formato não é detalhe cosmético. Ele guia o raciocínio e torna a resposta mais auditável. Quando a saída vem organizada, fica mais fácil perceber o que é suposição, o que é recomendação e o que precisa ser validado.

Exemplos

Quando tom, formato ou padrão de qualidade forem difíceis de explicar, dê um exemplo.

Por exemplo:

Use este estilo de resposta: - “Confirmado”: informação presente no texto. - “Hipótese”: interpretação possível, mas não comprovada. - “Pergunta em aberto”: algo que precisa ser validado.

Exemplos orientam bastante a saída. O trade-off é que eles também podem limitar alternativas melhores. Se você der um exemplo rígido demais, talvez o modelo copie o padrão mesmo quando outro formato seria mais adequado.

Critérios de qualidade

Explique como você pretende avaliar a resposta.

Exemplos:

Se faltar informação, liste perguntas antes de assumir detalhes.

Diferencie fatos, hipóteses e recomendações.

Aponte riscos e testes necessários antes de sugerir implementação.

Não invente bibliotecas, APIs ou referências. Se não souber, diga que precisa verificar.

Critérios de qualidade mudam a conversa. Em vez de pedir apenas uma resposta, você pede uma resposta revisável.

Isso é importante porque uma resposta “bonita” pode estar errada. Critérios explícitos ajudam a reduzir esse risco, mas não substituem validação.

Do pedido vago ao prompt útil: exemplos práticos

A melhor forma de entender engenharia de prompt é ver a diferença entre um pedido solto e uma instrução mais clara. Os exemplos abaixo não são “prompts prontos universais”. São modelos de raciocínio para adaptar ao seu contexto.

Desenvolvimento: investigar um erro

Pedido inicial:

Por que meu teste está falhando?

Problemas desse pedido:

• não mostra o erro;
• não mostra o comportamento esperado;
• não informa linguagem, framework ou ambiente;
• não pede um tipo específico de ajuda;
• incentiva chute.

Versão revisada:

Estou investigando um teste de integração que falha em uma aplicação Java 21 com Spring Boot.
Comportamento esperado: ao enviar uma requisição válida para criar usuário, a API deve retornar HTTP 201.
Comportamento atual: o teste retorna HTTP 400.
Mudança recente: adicionamos validação de e-mail único.
Abaixo estão o trecho do teste, o payload e a mensagem de erro.
Quero que você proponha hipóteses priorizadas. Para cada hipótese, indique: evidência, como verificar e possível correção.
Não proponha alteração de código antes de listar as verificações.

Como revisar a saída:

• tente reproduzir o problema;
• valide cada hipótese;
• confira se a sugestão respeita a arquitetura do projeto;
• não aplique correção sem entender a causa;
• execute os testes depois.

A LLM pode acelerar a investigação, mas não executa o sistema por você. Pelo menos não neste cenário. Ainda bem — alguém precisa continuar apertando o botão vermelho com responsabilidade.

Escrita: revisar uma mensagem técnica

Pedido inicial:

Melhore essa mensagem.

Versão revisada:

Revise a mensagem abaixo para comunicar uma atualização de incidente a pessoas não técnicas.
Contexto: houve instabilidade no login entre 10h e 10h25. O serviço já foi restabelecido. Ainda não temos causa raiz confirmada.
Restrições: não invente causa; não minimize o impacto; separe impacto atual de próximos passos.
Formato: título, resumo, impacto, status atual e próxima atualização.
Tom: claro, direto e sem linguagem defensiva.

Esse tipo de prompt é útil porque evita um erro comum: o modelo “embelezar” demais a mensagem e acabar afirmando coisas que ainda não foram confirmadas.

Quando o assunto é incidente, clareza importa mais do que floreio. Se a causa raiz ainda não foi confirmada, o texto precisa dizer isso. Se o impacto existiu, o texto não deve escondê-lo. O prompt ajuda a deixar esses limites explícitos.

Resumo: transformar conteúdo longo em material de estudo

Pedido inicial:

Resume esse texto.

Versão revisada:

Resuma o texto abaixo como material de estudo para uma pessoa iniciante no tema.
Inclua: - conceitos principais; - exemplos citados; - termos que merecem revisão; - dúvidas em aberto; - uma lista de 5 perguntas para autoavaliação.
Limite a resposta a aproximadamente uma página.
Não adicione informações externas ao texto.

Como revisar a saída:

• compare com o material original;
• veja se nuances importantes foram omitidas;
• confira se o modelo não adicionou interpretações próprias como se fossem fatos;
• use o resumo como apoio, não como substituto da leitura.

Resumos são úteis, mas podem achatar ideias complexas. Às vezes, o detalhe que ficou de fora era justamente o mais importante.

Planejamento: decompor uma tarefa

Pedido inicial:

Planeje essa feature.

Versão revisada:

Quero decompor uma entrega pequena em etapas de implementação.
Contexto: precisamos adicionar a opção de desativar usuários sem apagar registros do banco.
A aplicação já tem endpoint de criação e consulta.
Gere uma proposta com: - etapas técnicas; - dependências; - riscos; - perguntas em aberto; - sugestões de testes.
Não estime prazo. Não assuma mudanças em telas, porque ainda não sabemos se haverá interface.

Esse tipo de resposta pode ajudar a começar melhor uma conversa com o time. Porém, prioridades, esforço e sequência real dependem do contexto da equipe, do produto e do sistema existente.

Aqui, o principal ganho não é terceirizar o planejamento. É criar uma primeira estrutura para discutir melhor: o que falta decidir, onde estão os riscos e quais testes podem proteger a mudança.

Análise: interpretar dados ou resultados

Pedido inicial:

Analise esses números.

Versão revisada:

Analise os dados abaixo apenas com base nas informações fornecidas.
Quero que você: - descreva tendências observáveis; - diferencie conclusão forte de hipótese; - aponte lacunas nos dados; - cite possíveis vieses; - diga quais conclusões não podem ser sustentadas.
Não invente contexto externo.

Esse cuidado é essencial porque LLMs tendem a completar narrativas. Se você entrega uma tabela incompleta, o modelo pode produzir uma explicação plausível, mas sem base suficiente.

Nesses casos, um bom prompt não pede apenas “uma análise”. Ele pede limites: o que pode ser concluído, o que é hipótese e o que ainda precisa de dados melhores.

Um ciclo prático para escrever, testar e revisar

Engenharia de prompt é iterativa. Parece mais com refinar uma especificação, uma busca ou um teste exploratório do que com escrever uma senha encantada.

Um ciclo simples ajuda.

Escreva a primeira versão

Comece com objetivo e contexto mínimo.

Por exemplo:

Quero revisar este trecho de documentação para deixá-lo mais claro para pessoas desenvolvedoras júnior.
Mantenha o tom didático.
Aponte ambiguidades antes de reescrever.

Não tente antecipar todas as possibilidades logo de início. Uma primeira versão boa o suficiente já permite aprender com a resposta.

Inspecione a resposta

Depois da resposta, pergunte:

• Ela atende ao objetivo?
• Respeitou as restrições?
• Inventou informações?
• Explicou suposições?
• O formato facilita usar ou validar o resultado?
• Faltou algum dado importante?

Essa etapa é onde muita gente perde qualidade. A resposta vem bonita, formatada e confiante; a tentação é copiar e seguir. Mas texto bem escrito não é sinônimo de resposta correta.

Refine a instrução

Use o que deu errado para melhorar o prompt.

Exemplos de refinamento:

Priorize alternativas com menor impacto no código existente.

Não proponha mudanças de API pública.

Antes de responder, liste informações ausentes que podem mudar a recomendação.

Separe “o que sabemos” de “o que precisa ser verificado”.

Refinar não é “brigar” com a ferramenta. É ajustar a especificação.

Se a resposta veio genérica, talvez falte contexto. Se veio longa demais, talvez falte restrição. Se inventou detalhes, talvez faltem critérios de qualidade e validação. O prompt melhora quando você observa o tipo de erro que apareceu.

Valide fora da conversa

Essa é a parte menos glamourosa e mais importante.

Valide com:

• código executável;
• testes automatizados;
• documentação oficial;
• fontes primárias;
• dados originais;
• revisão humana;
• critérios definidos pelo time.

Pedir para a própria LLM “confirmar se está certo” não é validação independente. Ela pode repetir o erro com mais convicção. É o equivalente conversacional de perguntar para seu bug se ele tem certeza de que é bug.

Ferramentas podem apoiar análise, geração de cenários e investigação, mas continuam exigindo validação técnica. A decisão final precisa considerar o sistema real, as restrições da equipe e o impacto da mudança.

Limites e cuidados ao usar LLMs no trabalho e nos estudos

LLMs são úteis, mas têm limites importantes. O problema é que elas podem errar com uma escrita muito convincente.

Alucinação e verificabilidade

A LLM pode inventar:

• APIs que não existem;
• parâmetros incorretos;
• comportamentos de bibliotecas;
• referências;
• justificativas;
• detalhes sobre um código que ela não viu.

Por isso, peça respostas verificáveis.

Exemplo:

Se citar uma API, indique como eu posso verificar na documentação oficial.
Se não tiver certeza, sinalize incerteza em vez de afirmar.

Mesmo assim, não delegue a verificação. Rode o código. Consulte a documentação. Confira no repositório. Teste a hipótese.

Ambiguidade

Se o pedido permite interpretações diferentes, a resposta pode seguir uma direção inesperada.

Uma boa prática é pedir perguntas de esclarecimento:

Se houver informações insuficientes para uma recomendação segura, faça até 5 perguntas antes de responder.

Isso é especialmente útil em arquitetura, requisitos, análise de dados e decisões de produto.

Quando o modelo pergunta antes de responder, a conversa pode ficar um pouco mais lenta. Em compensação, a resposta tende a ficar mais alinhada ao problema real. Esse é um bom trade-off quando uma suposição errada pode custar caro.

Dados sensíveis

Evite inserir:

• senhas;
• tokens;
• chaves de API;
• dados pessoais;
• informações de clientes;
• segredos comerciais;
• código confidencial;
• logs com dados sensíveis;
• documentos internos sem autorização.

Antes de usar uma ferramenta no trabalho, entenda as políticas da organização e da própria ferramenta. Se não souber se pode enviar algo, trate como se não pudesse.

Um prompt bem estruturado não justifica expor informação sensível. Quando necessário, remova ou anonimize dados antes de pedir ajuda — e faça isso seguindo as regras da sua organização.

Responsabilidade pela decisão

Use LLMs para:

• explorar opções;
• organizar ideias;
• gerar rascunhos;
• revisar clareza;
• levantar hipóteses;
• criar checklists;
• comparar alternativas.

Mas tenha cuidado ao usar respostas em decisões críticas, especialmente em segurança, dados, saúde, finanças, jurídico ou produção de software. A responsabilidade continua humana e organizacional.

A ferramenta pode ajudar a pensar. Ela não deve ser o piloto automático de decisões que exigem contexto, responsabilidade e validação.

Checklist final para o próximo prompt

Antes de enviar seu próximo prompt, revise:

• Qual resultado eu quero?
• Que contexto é indispensável?
• Para quem e para qual uso essa resposta será produzida?
• Quais limites ou restrições precisam ser respeitados?
• Em qual formato a resposta deve vir?
• Um exemplo ajudaria a reduzir ambiguidade?
• Como vou verificar a resposta antes de usá-la?

Uma versão compacta de prompt poderia seguir este modelo:

Quero [objetivo].
Contexto: [informações relevantes].
Público/uso: [quem vai usar e para quê].
Restrições: [limites, tecnologias, tom, escopo].
Formato: [estrutura esperada].
Critérios de qualidade: [como avaliar].
Se faltar informação, [pergunte antes de assumir / explicite suposições].

Prompts melhores não dependem de palavras secretas. Dependem de intenção, contexto e critérios claros.

Para começar, escolha uma tarefa rotineira: revisar uma mensagem, resumir um texto, investigar um erro ou planejar uma pequena entrega. Primeiro, faça um pedido vago. Depois, reescreva usando a estrutura deste artigo. Compare as respostas. Esse contraste costuma ensinar mais do que decorar qualquer lista de “prompts perfeitos”.

Próximos Passos

• Escolha uma tarefa real que você já faria hoje com apoio de uma LLM.
• Escreva uma primeira versão do prompt usando objetivo, contexto, restrições e formato.
• Revise a resposta procurando suposições, lacunas e pontos não verificáveis.
• Refine o prompt uma vez e compare o resultado.
• Valide fora da conversa antes de usar a resposta.

Se você curte discutir práticas de desenvolvimento, qualidade e uso responsável de IA no dia a dia, participe da comunidade SCCB.