Por que a IA te dá resposta ruim? Os erros mais comuns de engenharia de prompt (e a correção de cada um)

Fala aí, beleza? Na maioria das vezes o problema não é o modelo, é o pedido

Você já usa IA todos os dias, já pegou intimidade com a ferramenta, mas o resultado continua ali no morno: nem errado, nem bom. E o pior é não saber ONDE está o furo, porque a resposta parece ok até você tentar usar ela de verdade

Então bora fazer isso virar diagnóstico. Cada erro aqui embaixo vem com o sintoma que tu reconhece na hora, a causa e a correção baseada no que Anthropic, OpenAI e Google documentam. Se quiser a base completa antes, tem um guia de engenharia de prompt para devs aqui no blog

Erro 1: pedido vago (a resposta vem genérica e você não sabe por quê)

Sintoma: o texto sai óbvio, morno, do tipo que serviria pra qualquer pessoa do mundo. Você lê e pensa "isso eu já sabia" 😀

Causa: a instrução foi curta demais e implícita. Você esperou que o modelo INFERISSE o que queria, e ele fez o que qualquer um faria sem informação: entregou a média

Correção: a documentação da Anthropic é bem direta nisso, instruções explícitas funcionam melhor que prompts vagos. Se você quer um comportamento acima do esperado, precisa PEDIR esse comportamento, não esperar que o modelo adivinhe

E tem um dado do Google que ajuda a calibrar o tamanho: segundo o programa Workspace Labs, os prompts de melhor desempenho têm em média cerca de 21 palavras, enquanto os prompts que as pessoas costumam tentar têm menos de nove palavras

Olha o tamanho do buraco… a distância entre o que a galera escreve e o que funciona é mais que o dobro. Só que atenção, essa média é do contexto do Gemini para Workspace, não é uma regra universal pra todo produto de IA. Use como termômetro, não como lei

Como prevenir: escreva a saída desejada ANTES de escrever o pedido. Se você não consegue descrever como a resposta boa se parece, o modelo também não vai conseguir

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Erro 2: contexto de menos (a IA responde certo, mas pro caso errado)

Sintoma: a resposta está tecnicamente correta e completamente inútil pro seu cenário. Tipo receber um plano de marketing lindo pra uma empresa que não é a sua

Causa: o modelo não conhece suas normas, seu público, seu fluxo de trabalho. Ele não tem como saber

Correção: a analogia oficial da Anthropic é ótima aqui, trate o modelo como um funcionário brilhante, porém NOVO, que não conhece as normas nem o fluxo de trabalho da empresa. Quanto mais preciso o pedido, melhor o resultado

Se liga: você não largaria uma tarefa importante no colo de alguém no primeiro dia dizendo só "faz aí", né? Você explicaria o cliente, o histórico, o que já foi tentado

O Google reforça o mesmo ponto por outro caminho: ser específico e contextual usando detalhes concretos, nomes, datas, títulos de projeto, códigos de produto, IDs de caso, nomes de política. Detalhe concreto no lugar de descrição genérica

Como prevenir: o guia de prompts do Google Workspace organiza um bom prompt em quatro áreas, e dá pra usar isso como checklist antes de apertar enter:

• Persona: quem está pedindo
• Tarefa: o que fazer
• Contexto: informação adicional que o modelo não tem
• Formato: como a saída deve ser entregue

Passou nas quatro? Manda. Faltou uma? É bem provável que seja ela o gargalo

Erro 3: várias tarefas no mesmo prompt (o modelo pula ou embaralha etapas)

Sintoma: uma parte do pedido é atendida muito bem e o resto é ignorado ou feito pela metade. Você pediu um monte de coisas e recebeu metade

Causa: tarefa multietapa espremida numa chamada só

Correção: a Anthropic documenta o encadeamento de prompts (prompt chaining) exatamente pra isso, quebrar a tarefa complexa em subtarefas menores, cada uma na sua própria chamada. O ganho é em precisão, clareza e rastreabilidade, porque cada etapa recebe a atenção total do modelo

Quando encadear, segundo a própria doc: tarefas multietapa como síntese de pesquisa, análise de documento ou criação iterativa de conteúdo. Se o pedido envolve múltiplas transformações, citações ou instruções, o encadeamento evita que o modelo pule ou embaralhe etapas

O padrão mais comum de encadeamento é a autocorreção, e ele é fácil de copiar:

1. Gerar o rascunho
2. Revisar o rascunho contra critérios explícitos
3. Refinar com base na revisão

Três chamadas, não uma. Parece mais trabalho e é MENOS trabalho, porque você para de reescrever tudo no final

Como depurar: quando o encadeamento falha, isole em prompt próprio a etapa que está falhando. Aí você descobre se o problema é a instrução daquele passo ou a entrada que chegou nele

Uma ressalva honesta: nenhuma fonte oficial define um número máximo de tarefas por prompt. A orientação é qualitativa, quebre em subtarefas quando a coisa for multietapa

Erro 4: nenhuma definição de formato (você recebe um texto quando queria uma tabela)

Sintoma: a resposta certa, embrulhada no formato errado. E aí você gasta um tempão reformatando algo que teria levado segundos pra pedir direito 😛

Causa: "formato" é justamente a área que mais some do prompt. É o quarto item daquele guia do Google e é o primeiro que a gente esquece

Correção: declare a saída esperada e separe as partes do prompt com delimitadores

A Anthropic recomenda tags XML por tipo de conteúdo, citando exemplos como <instructions>, <context> e <input>. Isso reduz a interpretação errada quando o prompt mistura instrução, contexto, exemplo e entrada variável

Na prática fica assim:

<instructions>
Resuma o material abaixo em uma tabela com 3 colunas: problema, causa provável, próximo passo
Máximo de 5 linhas
</instructions>

<context>
Quem vai ler é o time de suporte, sem background técnico
</context>

<input>
cole aqui o relatório
</input>

A doc também indica combinar as tags XML com outras técnicas, como multishot (<examples>) e chain of thought (<thinking>, <answer>)

A OpenAI orienta a mesma ideia com delimitadores no geral: markdown, listas, blocos de crase e tags XML pra indicar claramente as partes distintas da entrada

E aqui vem uma ressalva que quase ninguém comenta, mas é ouro: a OpenAI avisa que a escolha do delimitador depende do conteúdo. Se o material que você está colando JÁ contém muito XML, um delimitador XML tende a funcionar pior

Faz todo sentido, né? O delimitador precisa se destacar do conteúdo, senão ele vira parte do conteúdo

Como prevenir: o guia de design de prompts do Google fecha o ponto, escolha UM formato de delimitador (tags no estilo XML ou cabeçalhos markdown) e mantenha o mesmo dentro do prompt. Misturar vários estilos no mesmo texto é pedir confusão

Erro 5: nenhum exemplo (ou exemplos demais)

Sintoma: tem os dois extremos, e eles se parecem na frustração

Sem exemplo nenhum, o modelo inventa um padrão próprio e você fica corrigindo estilo em vez de conteúdo

Com exemplo demais, ele COPIA o exemplo em vez de resolver o seu caso

Correção: a Anthropic recomenda incluir de 3 a 5 exemplos no prompt (multishot prompting) pra mostrar exatamente o que se espera. E define três critérios de qualidade pra esses exemplos:

• Relevantes: espelham o caso real, não um caso de brincadeira
• Diversos: cobrem casos de borda e evitam que o modelo pegue padrões não intencionais
• Estruturados: organizados de forma clara

A orientação de marcação é envolver cada exemplo em <example> e o conjunto em <examples>, pro modelo distinguir o que é exemplo do que é instrução:

<examples>
<example>
Entrada: cliente reclamou de lentidão no checkout
Saída: tipo bug | Checkout lento | Prioridade: alta | Time: pagamentos
</example>
<example>
Entrada: sugestão de modo escuro no app
Saída: tipo melhoria | Modo escuro | Prioridade: baixa | Time: design
</example>
</examples>

Do outro lado, o Google alerta que incluir exemplos demais pode fazer o modelo sobreajustar a resposta aos exemplos (aquele overfitting), e recomenda evitar linguagem ambígua e excessivamente persuasiva

Como prevenir: use os exemplos pra cobrir os casos de BORDA, não pra repetir o mesmo caso várias vezes. Exemplos diferentes ensinam mais que o mesmo exemplo repetido

Erro 6: prompt inflado e cheio de regras que se contradizem

Sintoma: quanto mais você escreve, PIOR fica. O modelo trava, fica burocrático, ou simplesmente ignora metade do que você mandou

Esse aqui pega quem já estudou um pouco, porque a pessoa aprende as técnicas e empilha todas de uma vez

Causa: excesso de restrição e instruções que brigam entre si

Correção: a Anthropic publicou que o melhor prompt não é o mais longo nem o mais complexo, e sim o que atinge o objetivo de forma confiável com a estrutura MÍNIMA necessária

O exemplo oficial de instrução conflitante é delicioso de tão comum: pedir "deixe documentação conforme apropriado" e, no mesmo prompt, "NÃO adicione comentários". Duas regras, mesmo pedido, sentidos opostos. O resultado degrada e você fica sem entender o motivo

E tem um caso que mostra o tamanho disso: a Anthropic removeu mais de 80% do system prompt do Claude Code para os modelos mais avançados, sem perda mensurável nas avaliações de código, relatando que estava restringindo demais o modelo

Oitenta por cento. Fora. Sem piorar nada

Vale a ressalva: esse dado é específico do Claude Code com os modelos da geração Claude 5, não é uma promessa de que cortar 80% do seu prompt vai dar certo em qualquer lugar. Mas o recado serve, andaime demais atrapalha

Nas práticas de 2026 a Anthropic ainda recomenda duas coisas que corrigem muita coisa de graça:

• Dar permissão explícita pro modelo expressar incerteza em vez de chutar (deixar ele dizer "não sei")
• Explicar o PORQUÊ por trás da instrução, pro modelo entender o objetivo e não só a regra seca

Como prevenir: releia o prompt caçando pares de regras que brigam. É o exercício mais rápido e mais ignorado da lista

Erro 7: desistir na primeira resposta ruim

Sintoma: a pessoa testa uma vez, o resultado sai capenga e ela conclui que "a IA não serve pra isso"

Causa: tratar prompt como sorteio, não como processo

Correção: o Google descreve a engenharia de prompt como um processo iterativo e orientado a teste, definir objetivo e resultado esperado, testar sistematicamente e refinar. Dentro da conversa, a orientação é reformular ou fazer perguntas de acompanhamento quando a primeira resposta não serve

Ou seja: iterar não é sinal de que seu prompt fracassou, iterar É o método

Como prevenir: guarde o prompt que funcionou como template reutilizável. Isso muda seu jogo mais que qualquer técnica nova

E pra quem trabalha via API ou Console, tem mais duas alavancas documentadas:

• Role prompting: definir o papel do modelo pelo parâmetro system da Messages API, o que ajusta o tom e mantém o modelo dentro dos limites da tarefa, com ganho maior em cenários complexos como análise jurídica ou modelagem financeira
• Ferramentas do Console da Anthropic: prompt generator, prompt improver e templates com variáveis, marcadas com chaves duplas no formato {{variavel}}

Sobre variáveis, a orientação é envolver em tag XML quando o conteúdo é longo ou ambíguo, deixando inline apenas as variáveis simples

O mesmo prompt em ferramentas diferentes: o que eu vi na prática

Esse diagnóstico todo fica muito mais concreto quando você aplica O MESMO pedido em lugares diferentes e compara

Foi o que eu fiz no teste de Codex vs Antigravity: antes de escrever qualquer prompt, criei um arquivo de contexto do projeto com a análise do projeto, a stack, as regras que o código deve seguir e os comandos que precisam rodar. Usei o MESMO arquivo nas duas ferramentas, pra partir do mesmo ponto

Depois quebrei o projeto em 5 prompts sequenciais, em vez de pedir tudo de uma vez: setup inicial mais autenticação, upload de PDF, integração com IA, dashboard, landing page e polimento final

Repara que isso é o Erro 3 sendo evitado na origem 🙂

O primeiro prompt descrevia o comportamento esperado em detalhe: o que acontece depois do login, pra onde redireciona quem não está logado, que o dashboard mostra só uma mensagem de boas-vindas com o nome do usuário. Nada de "faz um sistema de login"

E eu fecho todo prompt com uma lista explícita do que NÃO fazer: não criar upload, não criar formulários, não criar nada além da autenticação e da tela de boas-vindas

Passei a usar esse final justamente porque, numa comparação anterior, as ferramentas iam além do pedido. A IA passar dos limites tem lado bom e lado ruim, e o jeito de controlar isso é delimitar o escopo no texto do prompt mesmo

Outra coisa que virou hábito: terminar o prompt pedindo pra ferramenta rodar o projeto e confirmar que login e registro funcionam. O critério de PRONTO entra dentro do próprio prompt, não fica na minha cabeça

Teve um comentário que me pegou também: eu tinha avaliado como ponto positivo um tema claro/escuro que eu nem tinha pedido, e a crítica foi certeira. Extra não pedido não é ganho automático, só conta se o extra for algo que o usuário já queria

E pra comparação valer alguma coisa, padronizei as condições: mesmo arquivo de contexto, prompts idênticos, o modelo mais avançado disponível em cada ferramenta e o esforço de raciocínio em nível médio onde essa opção existe

Sobre custo, um dado do meu uso: durante os testes e a gravação do curso, consumi menos de 50% da cota do plano Pro do Codex. É estimativa minha, não tenho certeza exata do número

E já aviso o viés: eu tenho MUITO mais vivência com o Antigravity do que com o Codex, então minha opinião pode estar torta por isso. Quem usa mais a outra, bora trocar uma ideia nos comentários

No vídeo acima você vê os 5 prompts na íntegra e o resultado que cada ferramenta entregou com o mesmo pedido, que é o teste mais honesto pra separar o que é limitação do modelo do que é falha do prompt

Por onde começar a corrigir hoje

Agora inverte o diagnóstico: pega o último prompt ruim que você escreveu e passa ele pelos sete sintomas

O próximo passo é bem concreto: reescreve esse prompt com as quatro áreas do guia do Google (persona, tarefa, contexto e formato), testa de novo e SALVA o que funcionou como template

Na maioria das vezes você não precisa de um modelo melhor, precisa de um pedido melhor 😀

até o próximo post!